Forum OpenACS Development: Re: Re: OACS 6 and beyond

Collapse
Posted by Rocael Hernández Rizzardini on
Gustaf, moving oacs to oo might be the next path, specially to grow and distinguish, maybe you can set a wiki to put together your ideas, and the interested parties can comment on that.

Besides technology, making easy for new commers will be important factor if we are going to put an effort, this means easy ways to learn and be productive.

Collapse
Posted by Jun Yamog on
Moving to OO doesn't mean its going to be easier and productive. It may do it considering starting from 4.x the db schema is not traditional and OO-like but its not guranteed.

I was chatting with an ex-aD developer regarding this thread. Contemplating on history, it MAYBE all the power and complexity of ACS 4.x that scared new comers. That wasn't much an issue during the 3.x days, in fact its just like doing PHP only much more sane and easier. The 3.x codebase was easy to pickup and the output cycle was shorter (near instant gratification to a developer).

Anyway I don't want to muddle the thread any further since the decision to make ACS OO and make it powerful yet complex was decided years ago by aD.

Collapse
Posted by Rocael Hernández Rizzardini on
Easy to learn sometimes is just at least: good tutorials & wikis, and ways to keep them up-to-date (probably making them part of the process for new pieces of code that goes into the core), these is something that we don't have even with the actual openacs.

Probably the target audience is not newbie programmers such as PHP seems to have. We might like to target professional - competent programmers that OO, DB and webservers is not something new, probably already mastered, those that care about programming, then those ones can try, realize and see the power of openacs as a web framework.

Collapse
Posted by Malte Sussdorff on
I just had a discussion with an experienced PHP developer that I converted to OpenACS. He mentioned what is irritating is the fact that you have to deal with three files for one page and that variables are automatically set in each of them, without an explanation.

Example:

- If you call db_* you do not know which variables are returned in the tcl statement. So if you are searching for the variable you have not much of a clue, unless you look into the .xql file(s). So extending db_* calls with a documentation part that allows us to write which variables are expected to be returned could help

- This is especially true if you enter the variable in the .adp file without even calling it in .tcl.

But I agree with Rocael's assessment, we should not try to target the same group of people that PHP is targeting, for this OpenACS is just too complex as a framework.

One note though on XoTCL. Before we move forward in this direction, we definitely need training materials which describe common tasks as done before and how they are done afterwards, so we do not loose the experienced developers that OpenACS has at the moment. And obviously we should stay backwards compatible, so the old style of development still works.