Forum OpenACS Q&A: openacs 4.5 problem set

Collapse
Posted by Rafael Calvo on
Does any one have the problems set ported for OACS 4.5, postgres ...
maybe?
I thought I had seen it on the bboard, but I can't find it
Collapse
Posted by Todd Gillespie on
Wow! That was a flash to the past.

Anyway, that link is not very helpful. Those pset ports were done two years ago, which is an eternity, even adjusting for the glacial progress of software development. Let's examine some key differences:

  • Postgres 7.0.1 was the current version, and many folks were still using 6.5.3. Current version (in case this thread is read in the future) is 7.2.1. Major changes include OUTER JOIN support, breaking of the row-size limit, non-blocking VACUUMs, full-text indexing, etc; all of these substantially affect the pset text.
  • ad_page_contract everywhere.
  • acs_objects added, unified across OpenACS.
  • User model changed almost beyond recognition.
  • APM package management system added.
  • templating as core, rather than an add-on.
I find it hard to overstate how radically different the psets will be when you take the above into account. All the above should be added, the kludges to get around their absence removed, and we should probably remove the repeated instances of philg telling us how brilliant he is. Just scrap them and start over.

As for me, I think the psets are a dismal failure in the face of oacs4.5. The psets teach the ACS from bottom-up, rather than top-down, which doesn't encourage new people to learn the ACS APIs, it encourages them to reinvent the wheel. Better to teach rapid development within the oacs framework, and from there drill down into the internals and the construction concepts. That would entail a bit more prototyping and development support code, which I have been dabbling in; but the hopeful result would be a system that helps new users along, provides some assistance to the experienced, and the community is happy b/c new members could come into the community with some knowledge of the ACS APIs/style/customs rather than just Tcl/bash/postgres (& looking to reinvent the wheel).

That's my theory, at least.

Collapse
Posted by Jade Rubick on
I think this goes into the "crucial but who is going to step up and do it" category.
Collapse
Posted by Jon Griffin on
I am in the process of writing (from scratch) the PSETS for some jr employees.

As was stated above, time is the problem.

Collapse
Posted by Rafael Calvo on
I agree with Todd, and a top down approach at this stage of OACS would be more beneficial. Maybe 2 PSETS are needed, one for developers, one for "users"

I will be working on this, and I am trying to set aside some time to do it. I will let people know about the progress

Collapse
Posted by David Geilhufe on
Well, as folks begin to generate new content, please drop me a line.

I have been adding content to openacs.musetech.net (VMware installs, cvs, psets) in the eventuallity the new site launches. Even if it does not launch, at least all this stuff will be in a single place, making it much easier to build a directory of resources.

Collapse
8: Url correction (response to 1)
Posted by Tapiwa Sibanda on
David, I think the correct url is openacs.museatech.net

:^)

Collapse
Posted by Lars Pind on
Speaking of the user problem set:

When you're writing down user documentation, you'll probably become aware of things that are completely impossible to explain to any normal person

(for example "to make someone a site-wide admin, visit /permissions, then select "Object 0", and grant "admin" on that object to the person you wish to make site-wide admin").

File these as SDM bugs, please, so we can start cleaning up the user interface. It needs attention, and there's *tons* of low-hanging fruit, things where we could just add a page or two, or do really small things that'd help much.