by Aoirthoir » Sat Sep 02, 2006 9:57 am
Ok I have thought more about this and here is my thinking Mr. Steve.
Most things should be able to be changed non-programmatically through the INI files setting = value system. So for instance, right now to change the Logo, we can copy the Dataface_Logo.html to the particular dattaface programs tempaltes/ folder and I assume also the individual table folders templates/ folder. Then within that we can change the logo.
Most of the time the logo is a singular change. Maybe a text heading, or a graphic image. Other times perhaps someone wants to add menus and so forth. I don't know if Dataface_Logo.html is the best place to do it, but since it is basically an HTML file, they should be able to put any HTML code into it they want, and any smarty code. Well that part of it would be programmatically changing a setting. For those who want to add crazy things, like menus up there, a speech about freedom, or any other thing, then they would need to go into the code. That makes a lot of sense. So its best to keep the ability there always.
However for those who just want to create a logo or a heading, it makes sense to be a part of the ini file.
So that is the kind of thing I mean when i say, move everything to an Ini file structure. Go ahead and keep the smarty, this is a very important part of the extensibility of Dataface, and many of us really need this feature. But also, for things that are kind of more or less static, it would be great to be in an ini file.
Another thing about ini files, as we talked before, is a global ini. So in the apps main directory we should have all the inis that we available already. Especially things like fields.ini, valuelists.ini. Relationships.ini might be usable, but it also might be difficult. For generic relationships, if field names are all the same then it would work. But I think that relationships.ini is something that would create a lot of bugs if it were global, until it was really thought out and planned out.
So fields.ini specifies settings for universal fields. Thus I could put in there:
[ID]
widget:type = hidden
visibility:list = hidden
And it would apply across the board to all tables that have that ID field. Yet be overidden if there is a fields.ini in a tables folder. Same for valuelists.ini.
Also, in regards to that above I dont know if there is a way begin to map a standard to the ini files. So consider this setup for the fields.ini instead of (or in addition to) that above:
[ID]
visibility:list = hidden
visibility:view = hidden
visibility:edit = nothidden (ok I dont know what the opposite of hidden is)
Also in regards to that, different screens should have some kind of name. This way, we could create our own screens, and have dataface settings applied to them. Now that is another one of those things that are way future, because it will take a lot of thought on how to do that. But if we had a way to name screens and also had a way to interface dataface to it directly we could do something like this:
[ID]
[ID]
visibility:list = hidden
visibility:view = hidden
visibility:edit = view
visibility:report = view
This is again some loose brainstorming, and I dont have an idea how to implement it yet. The other stuff...global inis, inis for settings dataface already has, are more implementable in a near release of Dataface. In fact, as you said, you've used this as a guiding principle thus far. Which I think is what gave me the idea in the first place.
Ok back to the cats, then the docs for me.
