Feature Request Global Fields.ini

[Aoirthoir]

I know I know...I still have to get all my other requests over to the issue tracker. I really am going to try to do it this weekend. (no plans finally)..

Now Ive got to thinking, there are a lot of fields that are used universally..at least in my apps. I am not sure if it is the case with other folks apps. Some of them, such as the ID_ fields I usually do not want displayed at all. Also a lot of the relationships are repeated throughout etc.. Now with relationships I know this is a bit different because they are based on the table. But as far as the fields.ini...

what if there were a global one. It could be stored in pathtoapp/conf. Then if a field in any table matched a field name in the global fields.ini it could use its specs. Of course you could easily override this with a tables/tablename/fields.ini.

Also..another what if... In my case I am very strictly sticking to a field naming and table naming convention that I am working out...So what if fields.ini allowed for field Prefixes? Thus for instance I could define

[ID_]
widget:prefix = true
widget:settings bla bla

Then any field with that prefix (it could be any prefix a user chose) would have those settings. This could also be on a global basis in conf/fields.ini or it could be on a table by table basis as well.

Now the same thing then would work say with valuelists in that case...For instance currently I am using fields of the form LINK_LIST_STANDARD_SOMETHING or LINK_LIST_TYPE_SOMETHING which then of course link to tables named LIST_STANDARD_SOMETHING or LIST_TYPE_SOMETHING (a STANDARD is any kind of standard list that is well accepted or created by a standards organization, thus ZIP codes, State Names, ISO codes and so forth, whereas a TYPE list is something that is more made up by me, such as a TITLE for a name Mr., Mrs., Dr., and so on...) Yes those are long names. I think I am going to reduce them to something like LS and LT for link standard and link type. Which then would give me field names of LS_STATE and LT_TITLE (I would eliminate the LINK_ portion of the field name and in the future will probably just know that if a field has one of my prefix codes, then it links to the table of the same name...hope all that makes sense)..

So back to the valuelists thing...If we had a global value list and a global fields.ini specifying which field uses which vocabulary, then any field of that name in any table would access that automatically. Thus for instance I would not have to go into tables/VENDOR/valuelists and tables/CUSTOMER/valuelists.ini and so on. Hope that is making sense.

Now of course later on if we take the prefix idea and mix it with some delegate classes? Then if we are following a prefix naming convention, and there is a field with said prefix (say LS_SOMETHING), we could automatically map that to the matching table as a valuelist. This last part of course I imagine is a bit more work and not really as I see it a "part of dataface" since it is probably something more specific to what I am doing rather than the method others prefer to use. But the globals stuff and the prefix stuff would be cool

Ah and that makes me think...what if there were a way to create our own mods to the ini setup easily? Dont know how or what I am thinking exactly on this point so I will stop now

[shannah]

This is an excellent idea. How about we take it even a step further and rather than using prefix, we use full regex.

e.g.

[/password/]

would match any field with 'password' in the name

[/'^ID_/']

would match any field beginning with 'ID_'.

Of course, an application that used a lot of these rules may take a bit of a performance hit with having to run these regexes on every field that is loaded - so it would be a feature to use responsibly. We would see how much of a hit it would take when it is implemented.

-Steve

[Aoirthoir]

HOLY COW! That's even better than I thought. The possibilities are endless.

As a sidenote..Ive been going over the MySQL books that I have. One of the options that mysql has is for Char(0). The books state it is basically for legacy aps that no longer have values in a certain field, this way you can maintain the field name and position, but basically not break the code from your app.

This just reminds me how much better dataface is then hard coded stuff. NEVER will we have to maintain a place holder for a dataface app because if we no longer need a field, or as in your examples for changing relationships from a one to many to a many to many, a field ends up moved to another table...well dataface wont worry about it because if a field does not exist in a table, dataface doesnt even mind...