Xataface Forums

Mr. Steve,

As I understand it, delegate classes are simply the same name as the table.php.

Thus I would have path.to.dfApp/tables/Customers/Customers.php.

Since the delegate classes are already in the Customers directory, is there a PHP reason for
naming it Customers.php instead of DelegateClasses.php?

I am trying to ensure I understand the possible naming schemes. For instance would TablenameFields.ini be possible instead of /tablename/fields.ini. Would it even be beneficial to have such a thing to reduce the size of the directory tree?

Or, would it be beneficial, or possible to create something similar in the index.php to the path.to.dataface pointers, but instead path.to.tables? Or path to an individual table? Path to ini files and so on?

The idea being to store all information in one place IF it makes sense. So if I have 30 apps that are going to reuse certain tables, I can have all the inis, Delegates etc for those tables stored in one central location, and usable across apps...with path.to.app/tables/tablename overriding anything stored there, or deprecating it...for instance lets say I have a relationship in the central location and I do not want to display it in a certain app...in path.to.app/tables/tablename/relationships.ini:

[TABLENAME]
Relationship = off
or some other method of turning it off here....

Throughout the development of dataface I have tried to adhere to the spirit of Agile software development. In particular I try to use convention over configuration wherever possible. This has the benefit of being easier to learn and harder to forget. One effective means of keeping all of your configuration in one place is to use symbolic links for your tables directory (or specific table directories).

I prefer having a path tablename/fields.ini vs tablenameFields.ini because it allows me to group everything together about a table into a single directory.

eg:

tablename/
+---- fields.ini
+---- valuelists.ini
+---- actions.ini
+---- relationships.ini
+---- fieldname/ (directory for fields stored in container field named fieldname)

...

I understand the desire to centralize as much as possible so as to minimize duplication of code and configuration. I would like to add the flexibility to centralize these things, but in a way that will not sacrifice clarity. (e.g. if you create a big project and leave it to someone else, it should be easy for that new person to pick up where you left off...).

Possibly adding some sort of __extends__ flag to an ini file to indicate that it inherits all directives from another file would be easy enough to follow....

Ok I agree with that. I also think the system you hae set up is pretty good. It is like a built in file system based project manager. Currently I have to deal with PHP code and try to figure out what is treed to what...using the file system tree..I can see exactly how my dataface app is treed...So I do like that.

Originally my question was going to be about the tablename.php and I was wondering, that since it is already in the table/tablename directory...could it just be named table.php kind of like how fields.ini is always fields.ini...

I prefer this over the above...though implied otherwise in my question...method of tablefields.ini..

Unless a person just has to zip it all up with no folders...but I think the folder method is superior.

Sorry for the confusion.

As to the __extends__ flag...I like that a lot. You could have path.to.app/valuelists and path.to.app/table/tablename/valuelists.ini which extends the valuelists..same for fields and so on..I dig it.