Re: Package proposal: DataObjectOnSpeed (naming is discussable :-))

Lukas Smith wrote:

- It will try to auto-detect the field types and choose appropriate form element types for them. As this sometimes is not possible out- of-the-box, this can be influenced by setting some new config properties in your classes.

We were actually thinking of making it possible to not have to auto-detect anything. Basically the idea was to be able to define "complex" datatypes like "email" in the MDB xml schema.

Well, auto-detection is a little misleading here, but I chose this for the lack of a better expression... actually, the thing that tries to auto-detect the field types is the DataObject generator. My class simply uses the values the generator has determined for the fields, and adds some content checking - i.e. if it´s a string according to DataObject, check if it has Linebreaks in it. If so, make a textarea instead of a normal input field... of course this works only if you already have some field contents which is unlikely for newly added records. Switching to MDB would help *a lot* in determining what form element to use for what field types, as the field types are defined a lot more precisely.

- It will try to set up some *very* basic validation rules based on the field´s datatype. If you need to add to or alter these rules, you can do so after auto-generation.

Here we were thinking about using the Validate class.

That´s one possibility. On the other hand, if we´re using QuickForm, why not use the built-in validation rules? Email address format checking is so common, for example, that QuickForm has a standard rule for it as well. I would be hesitant to include a whole other package just for some validation rules that QuickForm already provides. Thus, I´d say let´s stick to QuickForm´s rules and if the user wants to add more complex ones in his DataObject-derived classes, he can always add them manually.

- It will automatically follow table relations to build select boxes (if the links.ini file is correctly configured).

This is where the DB_Structure class Wolfram is working on would come into play.

Sounds very interesting for sure!

Overall very cool. Especially since it exists today!

Hah, for *once* I was the quicker ;-))

I will try to find the time to look at the source. Maybe you also want to join us in our grand plans.

I can gladly try, but remember how much time I was able to spend on, say, LiveUser lately :-(((

Let me lay out the plan again briefly: The MDB Manager will be rewritten to become DB_Schema which will allow people to read schemas into an object structure defined by DB_Structure. Since DB_Structure is extensible as well as the datatype handling in MDB you can define your own datatypes which simply map to simpler datatypes (like email is actually a text datatype). However using Validate you could validate the email to have the correct format. Wolfram is involved with DB_Structure and Alan with MDB_DataObject. I am basically working on MDB 2.0 and DB_Schema/DB_Structure. However we are all suffering time constraints so one more hand would be great.

Sounds complex. Is there already some source publically available for reviewing? Maybe I can tweak my class a little already to make the transition from DB_DataObject to MDB_DataObject with schema manager et al a little less painful when it happens. CU Markus