Forum OpenACS Q&A: What *should* a good architecture Look Like?
From my perspective (as someone trying to make this easily
installable/upgradable) I want to see the following:
1. The ability to get bug-fixes inserted into my working website.
This implies a separation between the presentation and the ACS
framework (data paths, transactions, queries, etc.)
2. The ability to add new features to a working website. This
implies that functionality be provided in modules that can be used
independently, or in concert, to achieve certain goals.
And a final goal (requirement) I would have is:
3. The ability to provide a consistent look-and-feel throughout the
site without having to hand-edit every page in the system. This
implies a way of templating the presentation, or providing site-wide
customizations that are registered/recognized throughout the site by
the disparate pieces of the system.
We might have one lemma implied by the above, which would be that:
4. The existance of "Release" programs to move an existing data set
from one form to another. I.e., if a data model changes, it should
be possible to craft programs/scripts that would reorganize or
correct the data as required to move from one known state of the ACS
So, let's discuss *these* issues, and leave the language wars for
This would allow different modules of the ACS to be inserted at a later time. However, this doesn't deal with the troublesome issue of cross-linkage between many pieces of the ACS.
4.0 will be a big effort, we may be better off trying to solidify 3.2.2 as much as possible and do what we can to set aside a fairly large chunk of time to port 4.0 over.
Then again, 3.3 may be a simple upgrade. We'll just have to see.
that the new templating scheme (karl.arsdigita.com) will be
included in 3.3.
I agree with solidifying 3.2.2. Let's make it a final version. We'll
see about 3.3 when it comes out.
I only read this about three-four days ago, had meant to drop you a line and a pointer. Poke around here, Michael Feldstein posted a pointer to it in one of these forums (yes, we know we need to get site-wide searches working). I think it was him. He spends some of his time poking around the aD site looking for interesting stuff.
It looks like Karl's system is going to be rolled into ACS 3.3. Here'ss the latest:
It looks pretty extensive.
From looking at Karl's system, I'm quite impressed. I haven't tried it yet, though I'm tempted to tomorrow, time permitting... I've got a couple legacy AOLserver (non-OpenACS) sites that could really benefit from it.
Michael, do you have the link I'm thinking of handy?
BTW, let's all thank Michael for his digging up this stuff for us. Digging through the aD site isn't on my daily agenda, though perhaps it should be. Feldstein seems to be finding everything worth knowing about. That's useful.
I do think we need a good templating scheme but it needs to be simple, and not much more time-consuming than the current all-in-one approach, or it's just not going to get used.
Janine, I think there's a need for both approaches. Some of my clients would find the more "ornate" system very useful. They develop large quantities of fairly detailed (and interactive) online training/educational material with folks collaborating across (world-wide) organizations. Their workflow process is very messy and the technological savvy of the contributors varies enormously. The content needs to be easily localized/internationalized. In this sort of a situation, Karl's system would be just the ticket. Admittedly, most of these clients would want to implement this in ACS Classic behind their fire walls. However, I foresee the day when they will go to an ASP for this sort of a thing, in which case running it on OpenACS would work just great (provided that Postgres continues to scale up).
Apparently, there will be an effort to at least partly implement this in ACS 3.3.
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.
It would be nice to have it up so we can play with it and get some experience with it. Hint hint :)
It would be nicer to find out what aD plans to do in this area long-term. I've not dug around in a few weeks, but last time I did it appeared that they've not settled on a single approach.
- Downloading the source (each file individually rather than the tarball)
- Installing 00-ad-preload.tcl and the *.preload files from the ACS/OpenACS Tcl library
- Naming my database pools main, subquery, and log
- Following the rest of Karl's installation instructions (i.e. .ini file settings)
I'm guessing, from looking at Karl's site, that the full-fledged DPS 1.0 will eventually *not* be database agnostic, but to date, the templating ascpets at least are. I'm tied up with work today, but if nobody beats me to it, I'll grab the latest OpenACS source from sourceforge and see how well Karl's DPS 0.4 drops in to place this weekend.
I'm interested in hearing what other people have to say about David's post above. Also, Ben, do you (or does anyone else) have any insight into where aD will actually end up going with 4.0?
Thanks you guys.
Also, just something on my mind. There's some doctor, I can't remember his name, who has done research into sleep cycles. He says the typical person's sleep cycle is about an hour and a half. (when you finish rem and are ready to start stage one again.) So, if you give yourself sleep in increments of an hour and a half (if that's your cycle--it is mine) then you won't be fighting your body so much. Also, Thomas Jefferson did some experimenting with this. If I remember right, he found something similar. So, I'll be working on that code in either 3 or 4 1/2 hours. Good night.
First, I must not have been there when I first read the overview to the DPS--because he certainly uses XML. So, my post above seems a little bird brained.
Second, I've got most of the module implemented on my test system. There is actually a bit more to it than the 4 step process mentioned in the Solid post above. Those manual downloads are just the Tcl libraries. He's got an installation directory that gives you more code, and more complete instructions (there's seven or eight steps to the installation).
Third, I'm stuck. Well, not really. I'm tired, and if I can't get things going better in the morning, then I'm stuck. I'm converting the data model tonight, and I've got an outer join that looks too hairy for me tonight. It is as follows (I've messed with the formatting a little so this is more readable, I'm big on using white space for readability, but this messge is getting formatted funny):
create or replace view ad_site_node_page_map_ext as
p.page_id, p.page_title, p.page_url, p.description as page_description,
sn.parent_id, sn.asset_stub, sn.description, sn.nav_title
from ad_site_pages p, ad_site_node_page_map npm, ad_site_nodes sn
where p.page_id = npm.page_id (+)
and sn.node_id = npm.node_id;
I'm sure I could figure it out eventually, but maybe someone more keen on these things can offer some advice. I'll work on it in the morning if nobody responds.
Also, I did some diffs between ACS code and openACS code. It seems that with the openACS views, you don't use create or replace. You just use replace. Is that an oversite, or is that required?
I read the conversion document, and it didn't mention varchar2 data types. As far as I know, that's an Oracle idea, right?
Is connect by on the PostgreSQL to do list? Just checking. That sure would be nice if it were there.
Anyway, to sum things up. There were only a couple of changes to the data model for the DPS. 2 outer joins, one connect by, and two clobs. I've just touched the actual code working on my server a little. Without the data model, you can't really go too far. If anyone else is working on this right now, let me know.
Finally, can I request a code review from someone more senior with these things? I would just like someone to take a look at an outer join conversion. Without any data in the data model, it might take me a little time to prove my join does what I think it should be doing. Maybe a quick glance by someone accustomed to this stuff would be valuable.
Here's the original join:
create or replace view ad_site_node_index_pages as
select sn.node_id, sn.parent_id, sn.nav_title, sn.asset_stub,
from ad_site_nodes sn, ad_site_pages p
where sn.index_page_id = p.page_id (+);
And here's my join:
create or replace view ad_site_node_index_pages as
select sn.node_id, sn.parent_id, sn.nav_title, sn.asset_stub,
from ad_site_nodes sn, ad_site_pages p
where sn.index_page_id = p.page_id
union select sn.node_id, sn.parent_id, sn.nav_title, sn.asset_stub, null as page_title, null as page_url
from ad_site_nodes sn
where 0= (select count(*) from ad_site_pages p where p.page_id = sn.index_page_id);
In short - it works, but I don't recommend it. I knew that going in but as tedious as it is it's all we had time for. The client insisted he wanted the plain ACS look until very late in the project, then we had to jam something in when he changed his mind. I was glad he changed his mind, I think the ACS is *too* plain for a commercial site, but I wish he'd done it earlier!
The templating and form systems seem to work well. I've not attempted to make the site map stuff work at all on Solid (yet).
Clobs should become lztext, which is used just like varchar(). varchar2(n) should become either varchar(n) for small strings or lztext for bit strings where you don't want to state a limit.
Connect by is not on the PostgreSQL "todo" list, sorry :(
<blockquote>>>>> "David" == David Richards <mailto:email@example.com> writes:
David> Hello, I'm kind of a newbie in the ACS world. I've spent 5
David> or 6 months reading Philip's book, loading and configuring
David> the toolkit, and doing this and that with it. I've kind of
David> migrated over to the openACS partially for now--I'm just
David> small fries today, and so are my clients.
David> Over at the openACS, there's a lot of discussion about
David> adding an abstract presentation layer. Your solution seems
David> to be the favorite among all informed. However, we have
David> some questions regarding what will actually be implemented
David> in ACS 4.0. Since we need to convert those parts of the
David> toolkit that are Oracle specific, we are a little wary
David> about which ACS versions are converted, which add-on
David> modules are converted, etc.
Yea, this business with Oracle/postgres is agonizing. I admire you
guys for trying to deal with it.
So, as far as you know, will
David> your Dynamic Publishing System 1.0 be a package in ACS 4.0?
Yes, DPS will be two modules starting with ACS 3.3: templates and
David> Or will 4.0 take another aproach to this abstraction layer?
David> Right now, the best we can do is just search the Arsdigita
David> pages for any clues as to where this part of the ACS is
David> Also, I've been doing a conversion of your 0.4 code because
David> I've got to decide on a working model to use really quickly
David> here. I know that on your installation page you warned us
David> of using the DPS with AOLserver 3.0--that it's buggy, etc.
David> Is this still the case? Any specific areas I could take a
David> look at?
I've written a patch for the ADP parser that fixes the specific
problems I was encountering. It's part of the AOLserver binary
release and also available from
David> Finally, after following your installation instructions, I
David> was left with 2 files in the /template directory of your
David> source. index.tcl and template.el. I haven't had time to
David> look at those yet. Do they belong somewhere?
template.el is a sort of abortive attempt to write some macros to
make it easier to write the spec files in emacs. index.tcl is
just a redirect to the doc directory...
David> David Richards