Xataface Forums

I am quoting from the other forum, because it seems more relevant here.
==============================================
Just marking a thought for later. A lot of the things in dataface can be changed in delegate classes and smarty templates. I am thinking that perhaps though, anything that is static, or based on a table, could be ini-ified. We would still have delegate classes adding our own extras of course. But things like tab names, link names, tab order, header placement etc...could all be in INIs..(i know loads of work..thats why its just marked as a thought...)
Posted by shannah at Thursday 20:57
shannah
Good call... I have used this as a guiding principal thus far. Tab names can actually be set in the ini file... not documented yet.. and I want to try it out again to make sure it works before publishing it.

What kind of header placement do you have in mind?

-Steve
Posted by Aoirthoir at Thursday 22:06
Aoirthoir
Regarding header placement, I meant the names of all the things. Or menu/tab placements. So for instance we could determine if we want the menus on the left/top/right. (or two or three? or all four for the insane)..

Same thing with the placement of all the menus. Using style sheets a lot of this stuff can be moved anywhere. I have had luck in the past using style sheets to set some things up. But other times they just wont obey.

But its good to know a lot of this functionality is already there. I really have to get to flowcharting it all. At next week's meeting I will bring up purchasing that. And a good PHP IDE. I really really need one that will show the file dependencies..as well as class dependencies and so forth.

And dang you are up late dawg.
==============================================

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.

This in fact has been implemented, in fact prior to your post. See http://framework.weblite.ca/forum/dataface-users/128