Forum OpenACS Development: Re: How OpenACS coding could get its groove back

Joel, I agree 100% code needs to be easy to write. Actually why write it at all? For simple applications there is no need. Several efforts have been made toward this. There is some code in the core associated with groups. The CR has a different take on the same problem. Both auto generate pl code and data model.

As usual I disagree with both of these approaches for one major reason: you never write down the data model, so it can't be very useful. You never write down your pl code, so it can't be very easily debugged, and you can't add anything special.

So when I started using ACS4, I wrote a package to help me write Oracle packages. When I started using OpenACS and writing in pg, I needed to port code from Oracle. So I wrote a few procedures to make queries in pg as simple as in Oracle, that is the object.new type queries. The procedures are actually used in the cronjob package, with examples in the /www pages xql files.

Then I combined the two ideas into query-writer. It was a difficult to use package with no documentation, but it did exactly what I wanted it to do: write pl code and handle inserting and updating data.

Recently I upgraded the package to be more user friendly. Now all that is required to create a pg package is to write the data model. There is a wizard where you supply the name of the table, the primary key and the name of the 'object' you want this to be. The wizard rummages through the database and loads the query-writer tables with all the necessary data.

Another improvement is the almost complete elimination of pl code. From the information already provided, the pl code which creates the object type is written, plus an object_p function is created, and a drop script is written as well. All object create,update,delete pl is eliminated. I achieved this by just including tcl apis for acs_object__new, etc. This is very nice as when you realize you have forgotten a table attribute, you just add it without having to drop and resource the pl functions. None of this precludes you adding pl functions as before. But if additional code needs to run that can be based on the attributes inserted into the object, you can use a table trigger to get the same effect.

The tcl api for the new object still isn't written down, and I need to address this issue so that query-writer could be used just to generate apis.

On the downside I have never ported to Oracle. It does write the pl code for an oracle package, but the datamodel is for pg. Also there are 8 little tcl procs that need to be written to handle the generation of insert/update/delete in Oracle. This is probably a 3-5 day effort overall, but the package isn't feature complete, why port it?

Query-writer is undergoing some major changes at the moment. qw_groups are being tied to rel_segments. A qw_group is more like a role, an idea that is best supported by a rel_segment. Currently there are two groups: admin and the default group. Qw_groups encompass a set of objects+attributes+values+operations. If your application need more than two roles, you can now create a rel_segment and add the user to the rel_segment to give them the role. Another major change is support for file uploads and sub-attributes. If you object has an associated file, you can write a handler for the upload (examples exist). The handler could write the file to disk, or stuff it into an attribute field. Sub attributes were needed for dates. But sub attributes also required multi-attribute filters, to both combine and remove attributes. Until now query-write didn't support filters on more than a single attribute. Now there is a place to run filters or other code after all attributes have passed validation. Additional call back locations are being created as well.

Overall the query-writer form processing page acts like a generalized ad_page_contract. It enforces the same filters on objects and attributes whenever these are created or updated. (But note that query-writer also enforces a 'role contract')

Jade, if query-writer becomes feature complete and I port it to Oracle, that might be a good time to consider adding it to /contrib. Until then I think it mainly serves as an example that achieving a rapid development environment is possible, at least technically.

I've spent a lot of time recently looking at other development frameworks, mostly related to CMS products. Technically OpenACS is in the upper tier of available products. Philosophically OpenACS is nowhere. There is no coherient vision on the OpenACS way of doing things. For instance a lot of Java frameworks stress Model2 or MVC ( Model-View-Controller). OpenACS does a better job of this, I think, than what Java applications are achieving with JSPs or even taglibs. But we are not talking about this, or how it is being achieved, or not. It simply isn't on our language list.

Additionally, although I'm not an xml lover by any means. This is still an important technology. It would be a nice, useful feature if package ui created xml which could be transformed via xslt into the various formats needed. This is something else that doesn't seem to be on the radar screen.

Related to this, is the lack of discussion on how groups of developers, designers, and managers can work togeather to build and maintain a site. It is actually pretty easy to throw togeather an app on OpenACS, however maintaining it, or adapting it is not well covered. Since packages will sit around and be reused and updated for years, you would think this would be a huge concern to the OpenACS community. It shouldn't be a mystery why folks constantly create packages that do almost the same thing as other existing packages. You simply cannot maintain code when it is so hard to figure out why it was written the way it was. Again, this is mostly due to a lack of good, well understood philosophies for development with OpenACS.