adrian

I think there is a bug that exists when you change a field's type. The contents of the data field in the 'fields' db table is deleted. Most importantly (for me at least), is the tags.

Yeah, that is exactly what I need - "field metadata". I am thinking it would be a great addition to PW if it were possible to set up custom metadata fields. Really just a another field in addition to tags that accepted an array of objects would do the trick. Anyway, the tags field is working fine for now.

Well it turns out you can access the tags really easily: $field->data['tags'] and I think this will do exactly what I need. I know this is not the intended usage of the tags (I realize it's just meant to help keep the admin side of things clean), but I think it might be the best option for me in this case. I have used the Page field in a couple of cases already and it has worked a treat, but unless I am not seeing all the possibilities, I am not sure how it will work for me in this case. For the sake of clarifying my needs, here is some code to show what I am trying to do: $questions = $pages->get('/modules/local-overview/questions/')->fields; $form = $modules->get("InputfieldForm"); $form->action = "./"; $form->method = "post"; $form->attr("id+name",'subscribe-form'); foreach($questions as $question){ $qn = $question->name; $field = $modules->get("InputfieldText"); $field->label = $question->label . ' (' . $question->data['tags'] . ')'; $field->attr('id+name',$qn); $field->columnWidth = 50; $field->value = $answers->$qn; $form->append($field); } This would do the trick so long as I only have one tag listed for the field. I will refine this a little better, but it is doing the trick to tell the front end user what units to use when filling out the form. Obviously I could have the template file write out each question manually and enter the units at the end of the label, but I think this approach makes life easier. Would there be a way to use Page field in this case that I am missing? Thanks again

Thanks for the quick reply. When editing a field, under the advanced tab there is a 'Tags' field. I was hoping to be able to use this for a purpose that perhaps it is not designed for, hence the need to access this from one of my template files. Perhaps there is a better approach to my problem. I have several fields which users need to fill out in either metric or imperial units based on their country. I was hoping to use the tags field to define the possible unit options (eg km vs miles, liters vs gallons etc). Then in my template file logic I would tell them the unit to use based on determining their country and the options for that parameter. Hope that makes sense

Basically I am wanting to access all the tags (either as a string or array) for a field. Not sure if this is possible, but it would be something simple like: $field->tags Based on what I see here: http://processwire.com/api/variables/fields/ I don't think it is possible, but maybe someone knows of another way I might easily be able to access these. Thanks

Hi everyone - still very new to PW, but I am coming up against this decision too. First just let me say how awesome I think the pages model works for the structure of a typical website, but when it comes to a web app (the distinction between a site and an app is often vague in my mind), I am wondering if perhaps it wouldn't be better to go with a custom database table to store user submitted data and use SQL (which I am comfortable with). I do feel at times like the PW pages model and API it is making things more cumbersome when it comes to data querying and manipulation (but quite possibly this is just my inexperience with it still). The database is starting to fill up with so many tables - maybe this really isn't something I should be concerned about, it just feels inefficient - seems like there must be lots of joins going on to pull all this data together. I am certainly no database guru, so maybe this is fine, but are there any guidelines/use examples as to when it might be more appropriate to go with custom tables? Thanks

Thanks Ryan - sounds like you are on it Yeah, I figured they weren't a replacement for pages when dealing with lots of entries. Definitely a great option to have in the arsenal though and I think they will be much friendlier for the client with those couple of enhancements.

Hi everyone - only a couple of days in PW so far, but loving it. Just wondering if there might be a way to name the headers of the collapsible repeaters in the page edit view and also have them collapsed by default. I don't think this is what woop is asking for. What I am trying to achieve is a personnel directory and as it stands, it becomes difficult to edit - once you get a lot of entries you end up with a lot of scrolling. If it was possible to set them to be collapsed to start with and then use values from one or more of the fields (ideally I'd like to concat first_name and last_name) as the title for the header bar. I know it is possible to adjust the visibility for the field to "collapsed ...", but this collapses the entire repeater field, rather than the individual items. I am thinking that I might actually be bette off going back to parent>child approach I had originally set up as I think the repeater approach will become a little unwieldy when there are lots of entries. Anyone have any suggestions - am I missing some obvious setting? Thanks