Forum OpenACS Q&A: Response to What *should* a good architecture Look Like?
In other words, I'm kind of a newbie at some of this, although I've done what I can to this point to make a meaningful contribution.
One issue that seems to plague me as I try to sleep and wakes me up in the morning is the issue you've been discussing on this forum--site-wide maintenance of presentation. I know that at least three of the possibilities have been discussed on this thread, and a fourth (introducing Python to the openACS) is mentioned on another thread.
I don't give the Python idea too much consideration because I believe there are at least three other possibilities that would be more practical, maintainable, etc. Python may have some wonderful redeeming features. In my mind, however, I can't justify the extra effort of a major conversion, and then the extra effort of keeping the openACS in sync with ACS. I understand that you can encapsulate Tcl in Python, but when the ACS is upgraded, the upgrade can be more than just code changes. It can also be file system changes, and other things that would be harder to port to the openACS if the openACS were encapsulated with Python.
Sorry for the long digression.
The following is a list of what I think I can do to build a unique look and feel on an ACS-based site:
1) I can copy or edit each page as built by aD to your own specifications. With this approach, I'd need to keep these changes current manually as bug fixes and new realeases are implemented.
2) I can create content sections to edit the basics--background color, top section, and a side bar. I haven't really tested this much, but I'm assuming this would be the easiest way to implement a moderate divergence from the plain-vanilla site.
3) I can create my own ad_header and ad_footer procs. ad_header can cover the top and left-hand side of the page. ad_footer can cover the bottom and right-hand side of the page. I can get tricky with the Tcl procs I build and adjust the type of look and feel based on user, user group, content section, etc. Naturally, I'd be starting from scratch with this approach, so I'd have to think up my own architecture and maintenance.
4) I can mess with the templating stuff in Beta 3. I've just glossed over some of this stuff from the admin pages. It seems that this builds a bunch of adp files for each template. There's something with forms also. I'm really drawing a blank right now. (I'm far from my working system...enough excuses. Sorry.)
5) I could use Karl Goldstein's templating system as has been mentioned on this discussion board. I understand that I'll have access to a partial implementation of Karl's ideas with ACS 3.3. From one or two comments on this thread, it sounds like I can actually get his code today. I haven't dug deep enough into this to confirm or deny this. (anybody feeling authoratative on this issue?)
6) I can work with XML as defined in http://dev.arsdigita.com/doc/xml.html. (A doc by Karl Goldstein). I think this is different than Karl's templating system. I believe that the templating solution doesn't use XML, although it seems that he's shared a lot of underlying ideas between the two ideas. This XML approach requires the implementation of an XML parser (which I'm assuming isn't readily available in postgres). It sounds like this solution would require some effort in building a generalized architecture and administrative views of the system. (Is there any more work in this direction? Am I wrong in any of my assumptions? If so, it wouldn't be the first time!)
7) I could wait for ACS 4.0 and its subsequent port to the openACS, whatever that turns out looking like. I know that the major links for this approach are probably http://photo.net/doc/style.html, http://dev.arsdigita.com/doc/templating-etc. This would mean you build style tags and use them in your adp files. Also, it looks like it uses some or all of Karl's templating ideas. I guess everything from 3.3 and later will be pushed into packages instead of modules, offering a hierarchal presentation of a site.
My main concern is do I have these options clear in my mind? Are there more options than this?
If I've got a clear idea of my options, it seems that the only truely feasable options are 5, 6, and 7. They seem to be the only comprehensive approach to the problem that might have future support somewhere. The safest move seems to be to wait for 4.0. Since I'm impatient, I'll probably be building something with either of Karl Goldstein's ideas and then see if I can port my site into 4.0--if 4.0 offers all the functionality I'm going to require.
So, am I completely off base? Do you disagree? If I surf around Karl's stuff, can I actually find Tcl code and data models that will implement some or all of his ideas? Or do I need to build based on the specs he writes about? (I've only had time to read the overview of his templating solution.)
Sorry about the length of this post. It's a brain dump of all my thoughts and concerns on the issue.
