XApperator

Gotchas

index field name, should only be one field who has attribute value of 'isindex=1', if more than one the app will use the first one it finds in the config.xml document order

The dynamic title and message file parsing overhead will probably end up being too expensive but makes it easy to manage config.xml files during development. Really need to do a static merge of standard UI message files into an apps config.xml files as it goes into testing or production

we always save when user hits save without checking to see if any fields were different

XApp doesnt have a DataMapping feature like Hibernate to allow you to edit small parts of a bigger and more complex data file. XApp expects to be dealing with a dedicated simply structured XML file and will only persist fields it knows about through the apps condig.xml file

The XApp controller has a relatively explicit relationship with its data objects through the config.xml file schema section. There is a plan to build an table or XML file inspection feature but the result would be a generated config.xml file and not an implicit discovery like change to the controller ala Rubys ActiveRecord i/f

XApp doesnt have any concept of object association, apart from the foreign key field which unites records in a single data file. There is also no cacading or parent-child relationships between records, they're all flat. This is why there is also no cascading persistance when it comes to saving records after changes as theres really no need. Each record is a simple standalone atom that may as well be saved immediately.

theres a slight possibility of field collision between the fieldnames of the data records and the core XApp directives as the two are merged and submitted as CGI paramaters from the browser. For this reason the XApp core variables are prefixed with 'x-'. It isnt failsafe as user could still name a field the same but could catch it with a DTD or Schema perhaps used in the editing tool

Authored using: XApperator