Forum OpenACS Q&A: Different look of every instance of given package

I would like to have many instances of one package ( eg. mysite.com/subsite1/notes , mysite.com/subsite2/notes etc. ) but with completely different look. I know that I can setup different look of each subsite master templates but what about templates included in given package.
Is this possible to have different look of these templates in every instance of given package?
Hi Marcel,

Currently out of the box 4.5 does not yet support this. But in the future it may. I have given my idea to DonB about this. Maybe you would like to implement or help out in the idea.

Here is the snip that I gave Don.


In OACS we can surely implement something that will transform html package output into different looks at different instances. Here it goes:

/packages/bboard/www/master.adp will contain something like this.

<master>
<table class=datarows>
        <tr>
        <th>message title</th>
        <th>author</th>
        </tr>
        <mutiple> (damn forgot the syntax... you know what I mean)
                :       
        </multiple>
</table>

Notice that its still html nothing fancy but no formatting stuff.

Subsite template or your idea of each folder can be set a template. Will look at ad_paramter Transform type. This can be: tcl proc, XSLT, CSS.

- tcl proc is like "new_page [transform_page slave_content]" where transform_page is a bunch of regexp, if then etc. What ever the programmer wants to do with the thrown content of the package "slave_content" to be come his "new_page".

- XSLT... err buzzword and standards compliant to do this stuff. Should be slower than regexps.

- CSS... does nothing same as now, but the problem is we don't have a standard markup languange. So we can't apply CSS to all packages.

What we need to do is:

1. Use XHTML on all pages. We don't really need to impose all but we must start. Since CSS method is already here. We just agree what CSS classes and markup we need. We just use plain XHTML so the option of just using CSS will not require anyback end processing.

2. Make a standard on the new markup like: Table that is a row data

<table class=datarows>
<tr>
        <th>row header</th>
</tr>
<tr>
        <td>data</td>
</tr>
</table>

Form to input data

<form class=dataentry>
        <table>
                <tr>
                        <td class=label>Name</td>
                        <td class=datainput><input type=text></td>
                </tr>
        </table>
</form>

3. modify acs-template a bit. Not too sure but this is where you can tell me (DonB) if there is a lot of stuff to do or not.

This way we can have simple developers with html still continue on with html but in a standard way. And we have the power of transforming content like CCM's bebop. But unlike bebop we can offer 3 types of transformation XSLT, tcl code (regexp, concat, etc.) and still fall back to good old html. No processing required just CSS. Bebop only supports XSLT.


The above idea is just preliminary. There are still things that needs to be worked out. But on the high level this should do what you want.
Trash that idea above...I am so blinded. I think this is better.

We just use the foo.tcl of a template to manipulate the package HTML output.  Maybe just do a doc_return after manipulating the package html.  Or still make use of foo.adp.

DaveB gave idea of something like ad_returntemplate -xslt "foo.xsl".  Or maybe xsl_return.  Neophytos is also going to put in some xsl stuff pretty near.

So what do we do then to make all this things work?  Well simply come up with a standard XHTML that all packages will return.  That way a single template can be used to transform things.  Than having your template say... if package is news do this.... if package is bboard then do this.

I will look at the xsl of bebop and see how we can standardize this stuff.  One the package XHTML is done on the packages.  We can outright do CSS and tcl transformation without additional code to OACS.  XSLT is just a matter of adding to OACS.

The problem with XSL rather than templates is that you've just moved beyond the vocabulary and skills of 90% of the web page designers on the planet.  Not to mention their software tools.

From what I've read the XSL approach of bebop wasn't considered a rousing success by all the aD folk in the field.

Is there anyone out there with real-world bebop experience (presumably one or more of our ex-aD community members) who would like to comment?  If the rumors I've heard are wrong and that clients and page designers as well as aD hackers were in love with the bebop approach, I'd love to hear about it.

Ok,

Here is my up-too-late answer:

Use adp templates for each subsite. We will need to mirror the package templates in a subsite specific place. Either filesystem, or database (possibly the CR with filesystem storage). This way when we get ambitious it will be easy to implement web-based editing of the templates. The users will only be editing adps, and we can disable <% %>  for those and any other security features we need.

It won't be easy to edit templates, but anyone who can learn HTML can figure out how to use it.

I almost forget. Use the package default template unless there is  subsite specific one.

This also partially alleviates the "I modified some files, how can I upgrade" but only if you only modify the ADPs and the new tcl files provide the same datasource, but its a start.

Hi Don,

Yup bebop is a real pain... Its like programming a VB app without Visual Studio.

But there are benefits. Bebop is more than XSL. What I am proposing above is to just use standardize agreed XHTML not beboptize OACS. With it CSS will work on all sites. Since all packages output the same html. Its easy to do regexp and tcl processing on consistent and standard html.

I will make a proposal spec that will include:

1. Sample HTML that we can all agree on. Much like that I have posted above.

2. helper...Tcl procs definition. A sample will be a proc that will take a HTML table of datarows that I have posted above into an array of lists. That way we can easily manipulate the data if needed in tcl. Like removing/rearranging a column of bboard in a particular instance. This way bboard does not care what HTML is should display for each instance. Its up to the tcl or xsl template to bother about that.

3. Maybe a sample working demo. Of course no xsl on this. I will wait for what Neophytos will come up with.

So there is no black magic to the proposal just plain XHTML that is standard and consistent accross the whole system. Atleast the goal is to make CSS to work on all packages. Since its standard its very easy to process it in tcl. Since XHTML is XML, why not throw in XSLT as well.

Anyway I will try to put a simple proposal doc.

Marcin, if you have a package mounted at /subsite/notes then any files you place in the filesystem at ${acs_root_dir}/www/subsite/notes will overide files from the package directory ${acs_root_dir}/packages/notes/www.

Unfortunately there's a bug so you cannot just overide the adp page of a tcl/adp pair, you will have to copy both to the new location and then modify the adp page and/or the tcl.

Jun, I had the same (I think) idea a while ago.  My concern was that there is not much design reuse in adp pages as there is code reuse in tcl pages, and this makes enforcing consistent design etc. a pain.

We already have our own XML-like markup language with adp tags, but it's used mostly as a wrapper around Tcl programming constructs.  If we extended the usage to the page level design with <sectionheader>, <loginwidget> and <sortabletable> etc. then pages would look consistent, development would be faster, and design could be changed in one place.

As you mention, the HTML output of these tags would all be labeled logically for CSS transformation by the client, which would handle the vast majority of design changes a website owner would want to make.

The hard part is identifying the common design idioms you want to support, and coming up with logical names.  I thought this surely must have been done before, but last time I looked, I couldn't find anything I could just pinch from.  I'd like to see something like this happen though, so let me know if you want a hand. (not interested in regexping or xslting at the mo, sorry).

Hi Stephen,

Glad to hear the someone is also concerned about the consistency of the HTML. I had to do a lot of this with bboard, ticket-tracker lite and file-storage. Because I had one project that need multi instance of this.

Just like you I initally thought of <sectionheader>, <loginwidget> and <sortabletable>. But that would break existing things. So why now just plain XHTML, since that is what we get anyway after the package passes control to the subsite template. Also at least the CSS option of changing the look is there w/o performance problem.

For example <loginwidget> can be just

<form class="loginform">
<table>
<tr>
<td class="label">email</td>

<td class="datainput"><input type=text></td>
</tr>
</table>
</form>

Since loginform will always be the same coming out of /register we change drastically the look from one subsite to another. Like making the form have the email and password side by side. And have another instance the email and password is on top of one another. The input HTML is always the same structure so we can process it easily.

Anyway me, DavB and DonB have a little chit chat. I think its best to hold on with the idea until we can come up something substantial. I will definitely ask help from you once its there.

<blockquote><i>Marcin, if you have a package mounted at /subsite/notes then any files you place in the filesystem at ${acs_root_dir}/www/subsite/notes will overide files from the package directory ${acs_root_dir}/packages/notes/www.
<p>
Unfortunately there's a bug so you cannot just overide the adp page of a tcl/adp pair, you will have to copy both to the new location and then modify the adp page and/or the tcl</i></blockquote>
Interesting ... for Greenpeace I wrote a "gp_return_template" that does a little regexp magic to massage ad_conn file into a path to a magic directory tree that is exploded into a NRO (greenpeace germany etc) package path.  It looks for a template there then returns it instead of the default one if it finds it.
<p>
Something similar in ad_return_template would probably make the trick Stephen mentions work without having to move a copy of the tcl file over.
<p>That's an interesting low-tech approach to solving the specific problem mentioned by Marcel.  Any comments?
<p>As far as extending acs-templating in ways so that we can define sitewide styles for things like tables, toolbar widgets and stuff, it's needed.  Lars Pind has done some thinking about this, too, maybe he'll chip in.