Field naming, namespacing, and how we can prevent excess of fields

[Rob]

We're getting more deeply into a project that has a lot of content, a lot of different templates and a lot of fields.

As I understand it, you cannot have more than one of the same field (i.e. with the same name) in a single template.  I understand this from a DB design and performance perspective and it makes sense.

The issue here is that there may be perfectly legitimate cases where you might want to have a "description" field in more than one place on one page/template.  Let's say I have a page that contains details of a person and their profession. I might want a "description" field for them and a "description" field for their job.

In this case, what I would do currently is have a field called "person_description" and a field called "job_description".  This works fine, but it would be nice to be able to nest or group fields so that instead what I get is "person.description" and "job.description" but under the hood I only need a single "description" field which is used twice on the same template by virtue of being "namespaced" in some way.

One option I have is to create 2 repeater fields and both have the "description" field as a child.  I can't see why this wouldn't work, but unless I am mistaken I can't restrict the number of items to 1, like I can do with the image field, and then just get the auto-dereferenced first item.  I also know that I can visually group/nest items with the fieldset type, but I believe that this is purely visual.  It is a great and very helpful feature but it would be nice to have this nesting control at the actual field level not just as a visual helper.

I would welcome people to share their methods for managing large sets of fields, because I can see things getting pretty unwieldy quite quickly, and also I don't like the idea of having templates filled with extremely verbose field names that I have "manually" namespaced by having lots of underscore in their names!

I hope this all makes sense and perhaps it will help generate some ideas for managing large field sets and how to minimise clutter for the developer.

Thanks!

[apeisa]

Name them this way:

description_person

description_job

would keep them together on normal view.

You also might benefit from new field tags introduced on 2.3.

I am not sure I understand your concern well enough, but for me namespaces in fields sounds like overengineering and would complicate it. KISS

[Joss]

On the latest version, when sorting out your field list, use the tags under the advanced tab - very useful!

On the actual template, you have two related field types - tabs and field sets.

This allows you to make you form multi tabbed if you wish and/or to create nested sets. Since you will often use several tabs, I often create 4 sets (the end of the tab or field set is created automatically when you create the first) and have them sitting in my fields list ready to use. Like other fields, you can rename them in context of the particular template.

Also, you can change the width of the fields on a per-template basis, so you could have 3 in a row (33% each) if that helps keep things related together.

One way or another, you probably have enough variations there to keep things pretty neat!

Joss

[Rob]

Name them this way:

description_person

description_job

would keep them together on normal view.

You also might benefit from new field tags introduced on 2.3.

I am not sure I understand your concern well enough, but for me namespaces in fields sounds like overengineering and would complicate it. KISS

Well, it seems to me that PW has been designed to allow the same field to be used in more than one template, but sometimes (in fact, a lot of the time) there can be a need for the same field used multiple times on one template.

having to have "description_person" and "description_job" pretty much destroys the concept of having simple re-usable fields.  I thought the point was to be able to have nice, simple, generic field names that can be re-used.  If I have to have prefixes or suffixes on my field names, this re-usable field concept goes out of the window.

Basically the repeater concept has the ability to namespace by "nesting" fields under a "parent" field, and as I suggested above it would just be nice to have the ability to limit to a single item.  The repeater need not "repeat" anything, it can just be a container for other fields.

On the latest version, when sorting out your field list, use the tags under the advanced tab - very useful!

On the actual template, you have two related field types - tabs and field sets.

This allows you to make you form multi tabbed if you wish and/or to create nested sets. Since you will often use several tabs, I often create 4 sets (the end of the tab or field set is created automatically when you create the first) and have them sitting in my fields list ready to use. Like other fields, you can rename them in context of the particular template.

Also, you can change the width of the fields on a per-template basis, so you could have 3 in a row (33% each) if that helps keep things related together.

One way or another, you probably have enough variations there to keep things pretty neat!

Joss

Sorry if I wasn't clear, but this is NOT to do with visual organisation but being able to keep fields generic and reusable.  I don't want x_title, y_title and z_title if instead I can group my fields in a sensible way and only have a single "title" field in the CMS that can be flexibly used in several places.

[Soma]

description_job and description_person are two different things at the end and makes perfect sense to separate them. I see no reason to have them both share same field like "description".... unless you have them separated by the template context. Person template and job template.

Repeater is nothing more than if you have a template person and job, and have the job be children of the person.

[Rob]

Then why does Ryan even bother even touting the ability to reuse fields? You might as well say that you should prefix the template name onto the field if they are 2 different things on 2 templates, but I bet plenty of people have a "title", "description" or "heading" field that is used on multiple templates.  Why not allow me to have multiple fields on the same template in difference contexts?

In fact, with a repeater, I can do it already because, as I have already said, a repeater is really just a container for multiple existing fields.

The simple solution here is to implement the same "max items" option in repeater field that I have with an image field, so I can just say "1 max item" and then have it dereference the first item automatically.  This would effectively make the repeater a more flexible field type without having any impact on it's current use.

As for the reason to have them share the same field is simple - less fields to manage for the developer, and it fits with the ethos of PW that was sold to me when I first came across it!!  I'm surprised by the "there's only one way to do things" attitude on display here, it's not in keeping with the open-mindedness I've generally found in this community.

[Joss]

I must admit, I am rather confused by what you want to achieve.

In processWire, each field (not field type) has its own table.

So, if you, for instance, create several different templates for different types of news articles, but each has a common "Main Text" requirement, then you might wish to create just one main_text field and use it throughout those templates. You will end up with one table in the database with all the "main_text" from the various pages and templates.

However, within one template, how would you have multiple identical fields all storing to the same place? Surely you want the various fields for the various bits of information stored separately?

So, 5 textareas - intro_text, main_text, sidebar_text, footer_text, summary_text - or whatever you want. Each will be stored in their own table, but they will all be textareas.

With repeater fields, they are actually separate pages (you can find them under the Admin page) that are called into another page.

As for the "only one way to do things" comment, you can do things lots of different ways, however, it has to work within the design of the database!

Joss

[apeisa]

You can reuse fields between templates (so you don't need different body field for each of your templates), but using same field multiple times on same template is pretty confusing concept to be honest. It's like having twins and giving them same name.

[nik]

(I'm slow, so probably some of this has been said before, sorry.)

Then why does Ryan even bother even touting the ability to reuse fields? You might as well say that you should prefix the template name onto the field if they are 2 different things on 2 templates, but I bet plenty of people have a "title", "description" or "heading" field that is used on multiple templates.  Why not allow me to have multiple fields on the same template in difference contexts?

One reason would be complexity, like Antti said. Adding one level of abstraction on database level doesn't sound like it's going to make things faster, does it? But I must admit I've been thinking about field naming for a minute of two myself without being able to come up with a solution that feels like it's perfect. I've even gone down that "templatex_fieldy" route more that once and it really fits in sometimes, not that I'd recommend it in general though. There are multiple ways of doing things and while it really is a good idea to have generic fields like you've described, it's not necessarily the way to go all the time. And I don't think any of the previous comments were meant to imply that.

In fact, with a repeater, I can do it already because, as I have already said, a repeater is really just a container for multiple existing fields.

 

The simple solution here is to implement the same "max items" option in repeater field that I have with an image field, so I can just say "1 max item" and then have it dereference the first item automatically.  This would effectively make the repeater a more flexible field type without having any impact on it's current use.

This I have to disagree with, a bit . I wouldn't describe a repeater "just a container", but that may have something to do with the fact that I've had to debug the code in the early stages of repeaters to solve a performance issue. It sure is a container for *data* but not so much for fields (yes, it's possible to look at this from another direction too). So, in my opinion, complexity is the key once again.

I do like the idea of "max items" option for repeaters and that actually would give you one kind of namespacing by setting the limit to 1, but I wouldn't use that as a solution for the problem you've brought out. Not in large scale anyway. Actually what bothers me most with this is probably the name; if the fieldtype is designed for repeating content, shouldn't that alone be good enough reason to at least reconsider whether it's a good fit for namespacing?

As for the reason to have them share the same field is simple - less fields to manage for the developer, and it fits with the ethos of PW that was sold to me when I first came across it!!  I'm surprised by the "there's only one way to do things" attitude on display here, it's not in keeping with the open-mindedness I've generally found in this community.

Yes, I was also a bit surprised to see how easily this conversation went down one particular route. There was more in the topic that just the example you used. Unfortunately I can't give you any more tools to handle things like namespacing or preventing excess of fields than the other guys did. But that doesn't mean I'm thinking there's only one way to do things. I think grouping of fields in the admin does solve a part of the problem (via tags or prefixes) but also I have a feeling there necessarily isn't an easy way to have a short and neat list of reusable fields if the site itself is complex. I'd be happy to see someone prove me wrong though .

[apeisa]

One possible solution for this might be new repeating fieldtype. We have few of those already, like files, images and comments.

[diogo]

I thought of this many times also, and also think that in some situations a field could be used more than once in a template. But I accept the argument that the database is prepared to have only one per template and that it doesn't justify doing a big change to it only because of this. Namespacing would be overcomplicating in my opinion.

Anyway, I'm with Rob here, and glad that there is this discussion again

[owzim]

I agree that repeaters should have a limit option.

And it would be great if one could set up a field, set all the options which are specific to that field and then on a template to template basis use that field (with its specific characteristics) multiple times and name it in the template creation process, but I guess that would throw over some of core mantras of PW.

[apeisa]

Shadow fields? They inherit everything but name/label from some other field. Thus they can be used on same template as their "parent".

Not that I like it (I don't), but it would probably be one solution for this kind of issues.

[interrobang]

In the past I had similar thoughts a few times, though it woukld not solve Robs issues: It would be great if every fieldtype had setting "max items" and could be repeatable. So a reapeater would be the same as a fieldset with max_items>1.

In many case a repeater is just too much, for example when you just want the user to be able to enter multiple urls.

[diogo]

Shadow fields?

I'm not sure if I like it, but you get a like for a great brainstorming line

[Rob]

That's a bit more like it, let's get some discussion going!

[diogo]

That's a bit more like it, let's get some discussion going!

Yeah!! At least until Ryan jumps in and kick our asses with his arguments

[Rob]

One idea that just popped into my head is the idea of fields having a parent in the same way that pages do. This would actually NOT reduce the number of fields, but it would perhaps be a structural improvement that would make complex templates and sites easier to manage.

If we were able to "nest" fields with a parent/child relationship then we might end up with templates with structure like this:

Employee (template name)

- Name

- Age

- Description

- Salary

- Department

- Name

- Description

- Role

- Name

- Description

 

With the above structure, you would have multiple "Name" and "Description" fields, but each would be nested under another field.  If this nesting structure was visually indicated on the field listing in the CMS then it would be a clear visual AND structural way to have a field hierarchy.

Accessing this data would look something like $pagedata->name, $pagedata->department->name, $pagedata->role->description etc.  Or, in my case because I use TWIG templates, {{ pagedata.name }}, {{ pagedata.department.description }} etc.

I suppose my basic "issue" (if it can even be called that) here is that the page fields are just a single-level flat list, and having some extra structure would be nice.  All just food for thought anyway, I welcome feedback and discussion!

[diogo]

Rob, this idea is not very different of your previous one of imposing a limit to just one repeater. So, I can imagine that this kind of field would work exactly like a repeater works behind the scenes (creating a repeater page under "admin" and adding the repeater pages to it) but without the need of grouping the fields inside a "field#1" label or the "+add item" button.

Edit: Just like with repeaters, this wouldn't be more than a single page field type on steroids

[Rob]

Another thing that this is all making em think about is the general concept of "composite" fields - those can have multiple parts.  Repeaters items are basically creating this functionality by combining multiple fields into a new template type and creating pages of this type to hold the data.

Is it worth considering a better/different way to tackle this concept?

I know that I can write my own composite field type, and I have done as a test, but there was a notable learning curve and it isn't much good to those PW users who are a bit less technical or who have less PHP skills.  The repeater has abstracted some of this work, but it feels like some people are suggesting that the repeater is not an ideal candidate to "kludge" this kind of functionality.

@diogo - Yes it is very similar, I guess I am just trying to think out loud and get some ideas down on paper so they can be further developed and refined.

[teppo]

For the visual part tags help a lot; each field can have multiple tags and thus it's easy to group fields together in whatever way you want to. They of course "only" make fields list more readable.

This "shadow fields" concept Antti mentioned would be interesting to take a step further, though that could become very complicated very fast. Would only difference be name / label or would they actually need to function more like "variation fields", making it possible to inherit most settings from parent field and override them as needed etc.? 

+1 for the idea about adding limit to repeaters. That would be nice improvement. I know that they're essentially for repeating stuff and for limited use you could always skip repeaters and use individual fields (and fieldsets for visual effect), but sometimes it'd be nice to have the benefits (and flexibility!) of repeaters while still being able to enforce some guidelines for content creators.

Repeater with limit set to 1 seems kind of silly to me, though I do see why you'd want that in some situations. I'd still strongly suggest using fieldsets for that.

[Rob]

For the visual part tags help a lot; each field can have multiple tags and thus it's easy to group fields together in whatever way you want to. They of course "only" make fields list more readable.

This "shadow fields" concept Antti mentioned would be interesting to take a step further, though that could become very complicated very fast. Would only difference be name / label or would they actually need to function more like "variation fields", making it possible to inherit most settings from parent field and override them as needed etc.? 

+1 for the idea about adding limit to repeaters. That would be nice improvement. I know that they're essentially for repeating stuff and for limited use you could always skip repeaters and use individual fields (and fieldsets for visual effect), but sometimes it'd be nice to have the benefits (and flexibility!) of repeaters while still being able to enforce some guidelines for content creators.

Repeater with limit set to 1 seems kind of silly to me, though I do see why you'd want that in some situations. I'd still strongly suggest using fieldsets for that.

A fieldset is a visual-only organisation tool, which is not the same as being able to logically/structurally group fields.  It doesn't prevent the problem of an ever-growing list of fields that have to be manually "namespaced" by using prefixes and the like.

I think that if it is not used to excess, there is no good reason to not use repeaters for this purpose.  It serves the purpose of grouping fields into "composite" fields and it uses standard PW techniques to do it (pages under the hood).

It is a matter of preference, but for me a repeater used in this way can help me re-use my generic fields in a useful way and reduces the actual number of fields I need to create and manage in the back-end.  This is a win-win situation for me, and based on everything I've read here, the suggestion is that PW can happily scale to a huge number of pages. If repeater items are just pages (whic hthey are), and the scaling is handled well, I can see little downside to this approach!

[diogo]

If the repeater serves this purpose, I don't think we should be put away by it's name. The only reason I think this should be a new fieldType is because the repeater carries two unnecessary things for this purpose: the serialization numbers, and the extra visual grouping. Of course those could also be removed in case the max would be 1, but with the extra work, why not just have a different kind of field?

[ryan]

I think that some kind of aggregate fieldtype that encompasses others would be a fine way to go. I don't see it as something I would personally use all that often, but I can understand why others might find it useful–it's a worthwhile idea. From the implementation side, a single item repeater probably would be the quickest/simplest way to implement such a type of grouping. But there are some significant differences to the point where it may be better off as it's own fieldtype, perhaps that extends FieldtypeRepeater. Either that, or something new that just takes a similar approach. After all, an aggregate field wouldn't need but 1 "ready page", it wouldn't need a repeater parent page, and could be built around the Fieldtype class interface rather than the FieldtypeMulti interface. It would have less overhead than repeaters would in some areas. There are surely even more efficient ways it could be built, but the repeater-model approach would be the most likely way to make it something tangible in a shorter period. I'll keep marinating on it here. 

[Lance O.]

+1 for the ability to limit the number of repeaters.