Introducing ROLLED OATS

Echo the thoughts below.

I started using a rich set of DHTML components, but they are hard to manage and place in forms without doing a lot of programming.
So, (1) start managing the components and provide a central, and short process for programming the form rendering and management.
(2) Keep components in the DB so that they can be easily managed by collaborating programmers
(3) Since any one form page can go on for panel after panel, etc. make it easy to add all of these components into one page at the place where the $form is created.
(4) this particular module keeps the componet data in the node body... As such, there is no need to create extra DB tables for the field managed by the javascript; I am not necessarily promoting this as the one and only way of storing data, but this particular module is helping me create some forms quickly. The format of the body is a javascript structure which can simply be evaluated by the client with the data mapped to the form elements which utlimately feed the body. A more prolix arrangement could gain knowledge of fields which map to DB fields other than the body. But, a more prolix arrangement required lot's of prolix programming (beyond the scope of today).
(5) Do as little extra programming as possibe. (I just want to keep programs short, and I hope that this worked.)
(6) Open up Drupal to DHTML components made by outside Javascript packages and maintainers. (More programming for the buck even when open source it counts)
(7) Pass more work to the Filter. (This is a little more tricky. I am really seeing the reason for the delta in the Filter. Right now I am just showing what's stored as an array of fields converted from javascript form to eval'ed PHP arrays. But, surely there are needs for delivering both an administrative view and a showy view of the same body. So, I am hoping to do that without breaking any Drupal design rules. So, for now, and pehaps for as late as tonight, I am burdening the Filter. -- check with me in a few days.)

In all, I don't think I have created any database hearisy. But, of course, if data is stored entirely in a body for some nodes, then it will be difficult to call on the DB to view it. However, it is probably reasonable to process the data for SQL access at any time once it is captured. A cron job could create a SQL view of a body, i.e it could split the body into table elements for later viewing. Another possibility is that routines that alter nodes before storage could provide DB preparation by either replacing text in the body with ID information or by just assuming the array strored in the body can be mapped into the fields of a SQL table. In effect this creates two copies of data, which is OK.

So, right now, this module stores the data obtained in the array as a javascript structure. And, the components are set up for each of them to go and get their piece of data and restore their state. One example is the dynamic tree which restores it's state of check boxes. The tree cannot really get it's state of checkboxes from the HTML it needs to render the tree. The tree component want's a ul/li list and expects javascript to initialize it's checkbox state. So, having Drupal render form elements of indented checkboxes can't begin to feed the component; furthermore, this sort of form rendering requires programming in PHP a fairly good sized piece of code to obtain functionality already provided by the OAT component.

Thanks again for your question. It has allowed me to think more about this. Perhaps, I just fell into this approach. But, I am enjoying it.