Forum OpenACS Development: Solving once and for all the customization of ADP/TCL pages in packages

1: Solving once and for all the customization of ADP/TCL pages in packages

Posted by Dave Bauer on 09/17/02 03:44 AM

Ok, you know you do it. We all do. You edited one of the tcl/adp
templates in an OpenACS package. And now they have gone and updated
the package. How do you stay in synch with CVS? Right now this is alot
of hard manual labor to merge in changes.

What we need is a way to replace the pages that are served without
changing the packages.

I have some ideas which I will list:

1) Have a openacs-4/local/packagename/www directory. Pages in there
override pages in openacs-4/packages/packagename/www. This is ok if
you want to change the look once for every package instance of a package.

2) Allow somehow the mounting of more than one package at a URL. They
would have to be ordered so the RP would be able to check them to see
which package a URL belonged in. So you could mount myforums along
with forums, and replace some/all of the pages with your own. Basing
this per-URL opens up the possibility of mounting a package more than
once, and using a different UI with each one. This allows for much
more reuse of data models.

3) A spiffier, but of course, more complex version of #2. Every
package has a "library" package and "display" package. THe library
package is a service, and all the UI goes in the display package.
There really is no need to mount tcl and sql files under a URL. So you
load up the forums service, and you can then install a foo-forums
package at one URL and a bar-forums at another URL. Hmm, as I am
writing this I like this idea best. Basically tcl library files are
already used in this way. Actually we can use openacs like this
already, except I am not sure if foo-init.tcl and foo-procs.tcl are
loaded on startup for unmounted packages.

Ok, after reading this #3 seems like the answer because it only
requires a minor change. Install forums, but don't mount it, or mount
it in a secret place (messy.) Then mount you custom-forums which relys
on the library and data-model of forums. CVS update updates forums,
adnd you have to run upgrade scripts, fix your package to conform to
API and data model changes, but an update won't overwrite any of your
files.

This seems to easy. I must be missing something.

Please poke holes in this proposal.

2: Response to Solving once and for all the customization of ADP/TCL pages in packages (response to 1)

Posted by Ivan Histand on 09/17/02 04:03 AM

#1 seems more intuitive and possibly easier to implement, it would require only a small function change in the request-processor (unless I am missing something) #3 seems like it would require a change in every package to support it.

Ivan

3: Response to Solving once and for all the customization of ADP/TCL pages in packages (response to 1)

Posted by Dave Bauer on 09/17/02 04:27 AM

Ivan,

#3 does not really require any changes to existing code.

The UI that is built into a package is the default. If you want a different one, install it as a seperate package. It still can call all the same tcl library procs and use the same data model. All you are doing is giving it its own package.

I least I don't think so. Not unless you want to make changes. What #3 doesn't do is address if you only want to change 1 page. It assumes you want to replace the entire UI.

4: Response to Solving once and for all the customization of ADP/TCL pages in packages (response to 1)

Posted by Jun Yamog on 09/17/02 05:42 AM

Hi Dave,

I think #3 is good especially IF the packages make use heavily of /tcl. And all /www files are just for presentation. You can just copy the orig /www files and make you own package that only contains /www files. That should work right now without any mods from the current packages. Of course in reality not all packages makes of /www for presentation only.

There is actually 2 ways to do this:

1. Preprocessed templates

2. Run time transform templates

Preprocessed templates are what we have right now. Where in we create the adp or like template:: makes use of. Say for example if all packages makes of the form builder then just updating the acs-templates/resources then everything is done. So we may just add in more display elements that are customizable. And the packages will just make of this elements.

Run time transform template is something I wish to look at more. I have posted a few ideas in the past. But there are good for nothing until I really get something running. Its basically have a uniform set of output for all packages. So that this service can transform the pages on while its being requested. Either XSLT or regexp. May provide more flexible benefits at the price of performance.

I think the preproccessed templates is something that most will agree on or use. What we need to do is make more display elements (data table, action links, etc.), have the packages make use of this rather than html, and have the templating system package aware so the changes are not global unlike now.

But I don't think that will be something we can have until a volunteer steps in. I think I like your #3 proposal. It should work with minimal changes. Although that will depend if the package you are using actually does the work on /tcl not on /www.

5: Response to Solving once and for all the customization of ADP/TCL pages in packages (response to 1)

Posted by defunct defunct on 09/17/02 12:37 PM

I haven't given it a lot of in depth thought. But somehting like #3 is definately a worthwhile goal....

6: Response to Solving once and for all the customization of ADP/TCL pages in packages (response to 1)

Posted by Dave Hwang on 09/17/02 11:05 PM

I vote for #3.

I implemented #3 when I released ec-lite demo for ACS4. as three separate packages (data model, UI, and demo data). You can install the data model as a service, and mount only the UI in your site map. You can take the UI, customize (ie. "fix") it, and mount your own version instead. Then you can install the demo data package and populate your tables. At the time, people thought it was weird that I did that.

However, I assumed that most people would be intereseted in changing the look but not want do deal with the engine underneath. By separating it into two separate packages, it's a clean break, and you only need to be concerned with changes in the API and data model. On the other hand, it requires a little more discipline on the part of the developer because now you are essentially writing a service and a stock UI (which may get replaced altogether) rather than a monolithic "application".

7: Response to Solving once and for all the customization of ADP/TCL pages in packages (response to 1)

Posted by Tom Jackson on 09/18/02 02:08 AM

Using a slightly modified ad_return_template, you could do #3. I did this at mydomain.com by using a proc in place of the optional directory path. But you don't need to separate adps from tcl files, you just make a new adp for your tcl file, hopefully in some separate directory structure available to the web designer. This method allows you to work on a per-file basis, just add the proc that selects the template according to your taste.

8: Response to Solving once and for all the customization of ADP/TCL pages in packages (response to 1)

Posted by Jun Yamog on 09/18/02 04:25 AM

I think Tom's suggestion is very good, its safe. Why not just explicitly put in ad_return_template to which adp file you want to serve.

I am sure a lot of people are not as disciplined as Dave H. But I hope more people will write their packages with a mindset that the /www dir will more likely be replaced.

9: Response to Solving once and for all the customization of ADP/TCL pages in packages (response to 1)

Posted by Lars Pind on 09/18/02 09:45 AM

Seems to me there are two different siutations here: Customizing the .ADP only (just change the layout, but keep the pageflow), and customize both .TCL and .ADP.

Also, will #3 work if you only change a page here and there, or is that unsupported?

/Lars

10: Response to Solving once and for all the customization of ADP/TCL pages in packages (response to 1)

Posted by Dave Bauer on 09/18/02 12:32 PM

Lars,

Good points. So we really want to solve both problems. The easy answer is if you want to change ADPs you have to duplicate the TCL, but that doesn't seem like the best answer. I think it is true that we really want to allow both of these options.

So what we possibly want is seperate service and UI packages along with a directory that will override built in ADP for the UI. This lets people who don't want to fool with the logic still change the display, and also allows people who need to write a new page flow do so.