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

5: Re: How OpenACS coding could get its groove back (response to 3)

Posted by Jade Rubick on 10/24/03 08:29 PM

Tom, I think your query-writer is a very interesting project. I don't have time to look at it right now, but when it is in a state that you think even beginners could use, please put it in /contrib.

I'd like to take a look at it at some point.

I think a tutorial showing what it can do would convince a lot more people to use it.

Maybe we can put it on a Wiki once we get that set up. :)

6: Re: How OpenACS coding could get its groove back (response to 5)

Posted by Tom Jackson on 10/24/03 09:20 PM

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.

14: Re: How OpenACS coding could get its groove back (response to 6)

Posted by Tilmann Singer on 10/26/03 05:40 PM

I still find coding on OpenACS relatively groovy. It's easy to create a package, write a datamodel and do relatively sophisticated things quickly.

One feature that makes that a lot more efficient and still flexible is ad_form, once you got used to it.

Of course I don't use xql files or i18n-ize my code from the beginning, and to be honest I'm also reluctant to create acs_objects unless I'm 100% sure I'll need them.

And I don't like to create tcl api's for stuff that accesses the database. If some data from the db is only needed on one page, and slightly different on another page, what's the point in generalising this into an exra abstraction? One groovy factor of OpenACS coding is to write an sql query or dml directly into a tcl file, reload page and voila - changes are in effect. Instead of changing tcl file here, change call of tcl proc there, select file to be watched etc. etc.

I'm not saying there is no point in tcl apis (and I'm well aware DaveB will come over now and beat me for this), but they should only be used for operations that really are used in many places. Otherwise they decrease the groovyness of OpenACS which comes a lot from the fact that it directly deals with the database.

Lack of philosophy: I think that OpenACS has still a good foundation in some very sound principles, which I found to be well described in Phil's book, such as the closeness to the database, two-tier architecture etc. And a bunch of best-practices that have developed over time and in sum make out the quality of OpenACS sites such as abstract urls, inline display of form errors, redirect to display page after an update with POST, etc. etc. These are not as famous as big paradigms like MVC, but they have proven to work very well in the world of web apps.