Forum OpenACS Development: Re: Proposal for hooking forms to metadata
- I put Jaguar on my Mac and I've been messing with Objective-C so I've got objects are objects on the brain.
- I had seen the acs-subsite code (odd place for it). The code I wrote serves two purposes. Make object_types etc objects and generate forms from object_types. I was insprired in part by add_form_elements.
- I'm going to mess with query-writer this week. I noticed it only runs on Postgres and I run Oracle.
- I really like the form templating stuff because it will do almost all the work for free but you can still customize form layout if you like. In fact you can template the same code differently by instance, something that's difficult with the rest of the templating system.
I've spent that last month looking at the java/tomcat/struts/turbine. Some parts are interesting but the thing that struck me was how much code you have to write to do anything. My wife ( a graphic designer ) can write tcl pages to process forms, send email and insert into a database and she does not think it's hard. I think java etc is hard, too much complexity to solve the 'scalablity problem'. It solves it by ensuring you'll never have one.
That said I think there is much room for improvement in openacs. The metadata model is a good start but not complete. This causes poeple to not use it or extend it in package specific ways. There are two ways to implement form validation. ad_page_contract and the forms package. This causes a UI problem. There are things I like about both and perhaps ad_page_contract could be extented to work better with the forms package.
One thing I did like about struts is the MVC model. It seems like this could be implemented in the request proceesor but that would be a whole different discusstion.
Where to go from here? I think the first steps would be to make the object_types etc objects and extend the attributes to support form templates. I think this would help the permission system and make the form system more usable.
By making object types objects you can give groups of people access to groups of objects. For example you could make an abstract type called developer_forum have supertype of forum, give the developer group access to developer_forum and write queries like
select object_id from acs_objects where object_type = 'developer_forum'and get a list of forum objects the developer group can access. You can also control what attributes users have access to as well as what enums they could choose. This could be done by granting permissions instead of writting code.
Added data to the attributes so forms can be generated from the meta data would allow packages to be more dynamic and configurable. It would also allow the development of a RAD package. The are pieces of that now but I would be nice to add to the core because even if a package was not completed by RAD it could be started that way. That would help insure that sql runs on all supported databases and the sql object interfaces and metadata are created in a consistant manor.
I think all of this can be done with a second set of tables so there will no impact on existing apps. Should we start a discussion about what should be in those tables?
