Dataface Delegate class?

[Aoirthoir]

Currently we have the ability to set up conf/ApplicationDelegate.php, which lets us extend DF. I assume DF is just set to somehow do a requires/include of that file. The same with tables/tablename.php for the tables Delegate Class.

I am curious then if there is some automatic (read ini driven) mechanism to require/include php files or use User/Developer created Delegate classes in the Dateface path. Thus, we would be able to create Delegate classes that would be used by all of our Dataface apps, not just on an app by app basis?

I know a while back on the forum a post about path.to.dataface/modules was made. And the statements made at that time were that it was not used currently. Has this changed? If so how do we use it? If it is not being used at this time, I assume anyone could simply go into the DF php files and add their own imports/includes. Perhaps just in dataface-public-api.php. And then place their classes in modules or any other place to which they had done a requires/include.

However I am thinking along the lines of the Dataface/modules directory. So there would be one central location for all addons, and merely placing them in the directory, as the README suggests, would get them added to the api. Or, perhaps in conf.ini, the modules to be used would be chosen under a [modules] heading. So for a module to be used, it would have to be under that heading. Further perhaps their could be a directory structure under modules to make it more manageable.

Thus the directory structure would be something like:

path.to.df/modules/gantt/
path.to.df/modules/INIPermissions/
path.to.df/modules/ReportWriter/

With the modules heading in conf.ini looking something like this:

[modules]
allModules = 0/1
somesetting = gantt
somesetting = ReportWriter/pdfOUT.php (only include one report..not the entire tree..)

Since ini files are modifable by the user, and we can create our own code to read them, this could be something that we would be able to assist Mr. Steve with if he and others are interested.

Of course if it already exists...we just need to learn how to use it. And if it doesnt, the example I just gave isnt the only way to do it...

Comments and ideas most welcome...

[njw]

The only real issue with this solution I can see, is that would then be putting application code, i.e. stuff we have written, in with the Dataface code. There's a lot to be said for keeping the Dataface provided code totally separate from application code, for ease of upgrade.

I would suggest that a different solution would be to have the site specific code in a separate directory to Dataface and the DF applications. There could then be a conf.ini line that tells DF where to look?

By the way, when's your Reportwriter module ready? I could really use it!!!

[shannah]

I agree with Neil on this issue due to upgrading. Perhaps a tiered system would be best. The ability to specify a sort of modules include path in the conf.ini, but modules could also be added to a modules directory within dataface also.

-Steve

[Aoirthoir]

Then in combination with your suggestion, there should be an ini in the dataface directory perhaps modulesdir.ini. Or perhaps this would be better just in the app dir. This would just point to where the modules are. Or...that itself could be specified as a Dataface Variable in conf.ini like so:

[_modules]
module_dir = whatever
module_url = whatever (not sure if this would be needed but dataface has two in the index.php of our apps

and then the rest would follow the code above...so we could specify where a module was..and it would not break if we installed another version of DF and we would not have copy an ini back over into the DF folder...

--------------------------------------

Oh I dont have a report writer...I was askin Mr. Steve about one. Then as I began to understand just what smarty is, I realized it could be used for a report writer.

Here is my situation. I programmed years ago in DOS. COBOL, Clarion, Basic....couple other things. Then since I didnt have a degree, it was rough getting work, married life followed, other sundries, and I gradually stopped programming. I came to this company for the shipping department about the time I had decided to start programming again. Well eventually I saw a lot of the issues they were having and I made recommendations. As it turned out many of them were similar to what they had in an RFP last year. They had their network consultant interview me to insure I knew what I was talking about and so plans were put in place to begin the project...

Well all this time Ive been doing the shipping until we could find a suitable replacement. We've found one but I am still training him. But now my day can consist of about 25% programming related functions vs. maybe 5% before. With a lot of learning going on at home. Now that I am doing less physical work, I am able to even do more at home.

Now I am just learning PHP and MySQL. Of course a lot of it is very common code. So when yall put code snippets in here I can usually figure out what that code snippet process is. But I do not know how it relates to the rest of the dataface system. For instance which parts are dataface methods or variables, which are PHP etc. Thus the reason I asked my company to purchase the flow charting software. So all of the php files in the dataface distribution, including non-DF php files are flowcharted. Though my site only shows the DF ones for now, until I figure out if I should put them on source forge.

So what I did was created a bookmark list of ALL of the pages on the DF site. Then I had my assistant print out all of those. Then I had him print out all of the forum conversations. Finally last week, me and my ex gal (who also works here) came in on saturday and organized it all. This week I went through the Feature Requests and Errors and added what I could to the Issue tracker. Ive also completely gone through all of the pages on the site and forum related to ini settings. Except for the permission pile I had. That will be done tonight. I will do the same with the API, Delegate classes, triggers etc.

After I have eliminated duplicates from the pile (for instance different forum conversations asking how to do the same thing and getting the same answer...) and put what info is what together, I will begin to enter it into a dataface database. Then I can add relationships between any of the items if I want. (I'll explain more on that later...)

OK long and the short of all of that? Now I've begun to understand the DF framework. I've a ways to go of course...But now I can start t6o tear it apart and see how I want to accomplish some of the things like the report writer. And now at least I know where I have to go to accomplish that. So we have to lay out goals for the Report writer, specs, and so on. One major goal for me, is that it should be written entirely in DF and Smarty. The actual report definitions should be stored in SQL which is then combined with the SQL of the tables you wish to get reports on. Or the definitions stored in INI files. It should also allow delegate classes and actions to extend for things we had not thought of. It should also allow SQL queries for reports, and this would HAVE to include joins and thus queries on our tagged records. Which will really just be a many to many relationship...so we could do a query, tag the only certain records from that query, and then run a report just on the tagged records. So a lot of things having to do with the report writer, will be usable in other areas.

But that is on the back burner for a few more weeks. Once I have the DF handbook ready, and my Invoices printing from our DFapp...I will be able to start to think about the RW.

But, I am willing to collaborate on ideas any time..to start laying the foundation.