Forum OpenACS Development: Easing Customization of Package ADPs

Posted by Dave Bauer on 11/19/02 09:08 PM

This is a continuation of the discussion about custom ADP templates for packages started here: https://openacs.org/forums/message-view?message_id=62150

Tom Jackson:

As you know, I am a big fan of separating the tcl/db grunt code from the presentation code. Not everyone is, and we have useful, necessary apis like ad_form. However I still feel the long range solution for OpenACS is to create data structures in one file and pretty it up based on some other file. Since it seems agreement what is pretty is hard to come by, I suggest the new file structure:
packages/package/tcl
packages/package/www
packages/package/sql
packages/package/adp
packages/package/adp/plain
packages/package/adp/css
packages/package/adp/custom
Right now we have plain. Moving to css will take effort, and in the process we will destroy the plain, but working, ui. Custom sites will always make their own adjustments. As it stands now, these adjustments make updates from bug fixes, etc. difficult to incorporate into the running website. This method would allow webmasters the ability to get the fix into the plain or css adp, test it on their site with their data, and roll it into their custom page if they like the result. Of course it also keeps those pesky designers away from the tcl files :).

Also Tom mentions having per instance customizations.

2: Re: Easing Customization of Package ADPs (response to 1)

Posted by Dave Bauer on 11/19/02 09:10 PM

This is where it gets tricky. Changing ADPs for sevearl instances of the same package. One way is just to put the files in openacs-4/www/sitenode/.

This will work, but is it the best way? This doesn't seem to allow packaging of the customizations, and doesn't allow "reload" of query files while a server is running.

3: Re: Easing Customization of Package ADPs (response to 1)

Posted by Peter Marklund on 11/20/02 09:18 AM

Isn't there a maintenance issue with having two sets of templates in a vanilla install (css and plain)? Everytime we make a change that affects a template we have to remember to make the change in two different files and also test both of these files. To me it is annoying enough to have the issue with duplication between PostgreSQL and Oracle in the db layer.

4: Re: Easing Customization of Package ADPs (response to 3)

Posted by Jeff Davis on 11/20/02 10:21 AM

I agree with Peter here, multiplying the number of
adp pages by 2 and putting them in seperate directories
makes keeping things up to date much harder (it is too
easy to overlook making a parallel change in a different
directory). I think given the experiences with the sql
datamodel directories I think we would have been better
served with a naming convention for sql files like we have
with .xql files.

We could have a precedence (which could be changed on a per
package basis) for resolving which adp to serve
(so it would default to something like -css, -plain, ""
and would look first for page-css.adp then page-plain.adp
etc).

On the other hand, I like the idea of being about to substitute
a .adp in a parallel tree for doing per site
customization, but more because it makes
merging new releases into the tree hugely easier and less
error prone.

5: Re: Easing Customization of Package ADPs (response to 1)

Posted by Dave Bauer on 11/20/02 04:09 PM

Jeff,

I agree. The main reason I am interested in this issue it to make it easier to merge in changes and bug fixes.

I also think that having one set of templates standard for a package is much easier to maintain. I just want to make it easier to customize the UI without touching the code.

6: Re: Easing Customization of Package ADPs (response to 1)

Posted by Tom Jackson on 11/20/02 06:50 PM

I think the issue with making changes to a datasource file (.tcl), that affects an adp template should be taken seriously. Aside from bug fixes, why would the developer make incompatible changes to the datasource file? Developers should spend more time providing datasources that can be used with a number of templates. If real changes are necessary for new functionality, why not provide a new datasource file, with new templates? This was recently done with the forums ui. The .vuh files were added to provide a different path through the same data.

Templates serve as different views of the same data, The purpose of the template is to make it easy to provide different views. Making it difficult to use alternate templates, will definitely cut down on the number of changes package maintainers will need to make when they mess with the datasource files. I'm not sure this is a good thing. Instead, create a standard method to allow someone to take the basic ui and hack away at it, adding css, or maybe creating some xml feed, etc.

If a package is so undeveloped, that the basic datasource files have bugs (with the data format, tcl code fixes should not affect the format of the data), fix those before porting to a different db, and before contemplating styles. If a package works, but you just don't like the way it works, create a new datasource file and new templates. If a ui works, but you just don't like the way it looks, create a new template, don't edit the one that already works. Support the ability for developers to add to a package and discourage incompatable datasource changes that are not bug fixes.

7: Re: Easing Customization of Package ADPs (response to 6)

Posted by Jeff Davis on 11/20/02 09:09 PM

I want to make sure I understand your argument so here is an example. Take the emoticon thing in forums, say we add emoticons and then later avatars. You would argue that we should have something like message-view, message-view-emoticons and message-view-emoticons-avatars as pages all because we have changed the datasource?

8: Re: Easing Customization of Package ADPs (response to 1)

Posted by Tom Jackson on 11/21/02 09:32 AM

I think I wrote before thinking through this one. When a package is modified as in your example, probably a number of changes will be made to a lot of the files, making it difficult to extract any bug fixes. Is there any current method used for packages, like the tagged releases for OpenACS, that could be used to protect current users from future package modifications?

I don't think it is great having multiple templates, but it might be useful to support the possibility. I have done this before just by using a slightly modified ad_return_template, allowing it to return templates based on an absolute path. Maybe if you could create a simple data model for alternate templates/directories, that gets read into an nsv at server startup, would provide a simple, general and high performance solution.