Forum OpenACS Development: Re: Notes from OpenACS 6 Design Discussion in Heidelberg

Collapse
Posted by Andrew Piskorski on
More and better support for rapid development would be very welcome, and the specifics Don touches on above mostly sound good to me. (Except for auto-generation of the SQL DDL for data models; so far I'm leary of that.) It certainly would be very nice to write PL/SQL only when you really want to write PL/SQL, rather than being forced to do so repeatedly for boilerplate code.

However, you OpenACS gurus who will be designing most of this stuff, please keep in mind all the discussions and reported problems with that other recent rapid development tool - ad_form.

Historically, the switch from OpenACS 3.x to 4.x seems to have given substantial additional power at the cost of a moderate increase in complexity and decrease in development speed. (And from what I've heard from those who've actually used it, ACS 5 Java probably gave a huge increase in complexity and a great decrease in development speed, for nebulous or un-realizable increases in power. Last I heard anyway; perhaps it has improved since then.)

If OpenACS 6.x could improve on the power of OpenACS 4.x and 5.x while beating the rapid development and short learning curve of OpenACS 3.x, that would really be slick. Given what others have talked about here, I suspect it can be done, too.

As for "improving the power", I don't see any mention of Lars' "object soup" ideas. What happened with that one? Was it discarded as a bad idea, tabled for later discussion for a later version, or?

Also, Peter's original list above doesn't seem to have "best of breed Content Management toolkit" on it at all. I find that surprising, given all the past discussion of how hugely useful it would be to dig out all the existing almost-never-used OpenACS Content Management functionality and re-factor it into one cohesive, integral, widely used whole.