adrian

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