Forum OpenACS Development: Use of master templates

Collapse
1: Use of master templates
Posted by Jon Griffin on 08/18/02 01:12 AM
I think that all packages that use their own master template should be reworked. This is yet another piece of cruft leftover from AD and needs to go away.

For example, I need to use news, it has its own master template which doesn't work with mine. This means my choices are:

  • Change the master.adp in the news directory
  • Change all the references to <master src=master> to just <master>(which is what it should be).
The problem is with cvs. If I get a new cvs I have to edit these files again, and again.

News was one of the first packages ported and at that time not much was known about templating so the author created his own template. This was the way it was done, but it is wrong. Your own site template should work out of the box with every package.

So, package owners, before the 4.6 release can you get rid of all the instances of <master src=...> and replace it with a simple <master>? This will make the release much cleaner and also get rid of some (albeit small) files.

Collapse
2: Response to Use of master templates (response to 1)
Posted by Bart Teeuwisse on 08/18/02 03:01 AM
Hear, hear! I'd like to add that all should use templates. In my opinion packages that don't use templates yet should be reworked so that they do in 4.6.

Time permitting I will remove the ecommerce specific master template or make it work with the template.

On a similar mode I'd like to see better documentation of the templating system. There are a number of poorly documented features such as the -return_errors flag of ad_page_contract. The templating system is such a powerfull component of OpenACS but many packages use only a fraction of the available features. Better documentation of the templating system would promote use of the templating system and prevent duplicate code as well as time wasted digging through the code to unearth undocumented capabilities.

Collapse
3: Response to Use of master templates (response to 1)
Posted by Roberto Mello on 08/18/02 06:17 AM
Who would have 2 or 3 hours to invest in revamping the templating system documentation? It's a very important system within OpenACS and we'd love to see it better documented.

Whoever would like to help with that, let me know. I have some suggestions as to what needs to be added/fixed.

Collapse
4: Response to Use of master templates (response to 1)
Posted by Arjun Sanyal on 08/18/02 06:56 PM
Jon: I don't understand what is wrong with the news package's master template. It calls up to the global master, sets the title property. I think package local masters can have value, as long as they call up to the global master. Can you clarify?
Collapse
5: Response to Use of master templates (response to 1)
Posted by Jon Griffin on 08/18/02 07:05 PM
Yes, the package master adds things like context_bar and title.

These are in my master template. I really think that local masters are not a good idea, both from a cvs modification point of view and a plain old pain in the rear, if you forget to change one of them point of view.

I know I can simply modify the package master, but again, I shouldn't have to and it screws up cvs updates.

Collapse
6: Response to Use of master templates (response to 1)
Posted by Don Baccus on 08/18/02 09:47 PM
Yeah I've had this in my head for 4.7, but not 4.6 because of the time it will take and the fact that people with customized versions of packages will need to deal with the change, too.

Is my thinking wrong, here?  We need to figure out just which set of things to kick upstairs to the master template to be customized or tossed out as the site author sees fit.

context bar's a biggy.  So are the headers that so many packages put out arbitrarily.  I've done several sites where we've suppressed those by ripping code out of huge numbers of scripts where one could just leave them out of the master template if they're properties passed up the hierarchy.

Those are obvious (and have been discussed before, including very recently).  What other page elements need to be kicked up to the master?

Remember that we're looking for a code freeze for 4.6 in a couple of weeks if possible.  Most of our thinking needs to be for 4.7 (which will be blasting off for development right on the heels of 4.6).

Collapse
7: Response to Use of master templates (response to 1)
Posted by Bart Teeuwisse on 08/18/02 10:19 PM
Not something that needs to be kicked to the master template but something equally anoying: the default error message handler is not templated. Every time an ad_page_contract rejects the input an error page is presented to the user which is not templated.

Could this make it to the 4.6 todo list too?

Collapse
8: Response to Use of master templates (response to 1)
Posted by Don Baccus on 08/18/02 10:50 PM
I did stick in ad_return_exception_template into the tree some time ago ...

For use of it to happen in 4.6 we need someone to step up to the plate and volunteer to do it within the next couple of weeks.  Janine will be managing the 4.6 release process so if you can commit, get in touch.

Bruno Mattarollo also figured out how to template the 404 page returned by the request processor.  He's back from holiday tomorrow, Jon's interested in the same thing, and maybe they can get put their heads together and get this in 4.6, too?  Jon?

If not both of these things should be in 4.7 for sure.

Collapse
9: Response to Use of master templates (response to 1)
Posted by Jon Griffin on 08/18/02 11:21 PM
I will talk with Bruno to see what he has done.

I think ideally it needs to be some kind of sub-site aware package as different sub-sites need their own templated errors. Maybe acs-error or some such name. Definitly a core package.

Collapse
10: Response to Use of master templates (response to 1)
Posted by Don Baccus on 08/19/02 02:54 AM
Can't it just be part of acs-subsite?  It seems fundamental and acs-subsite is self-aware, so to speak.  Thus far that's worked fine for me with my simple little ad_return_exception_template code.  My example db-error.adp template's in acs-subsite/www/shared, not a great place for it.  perhaps acs-subsite/www/error-templates or something like that?

And it would make sense for parameters that might modify behavior on errors to be set at the subsite level along with other look-and-feel parameters, rather than off in another package.

If there are good reasons for having a new error package we should, of course, but my first thoughts are that this should just be a acs-subsite enhancement.

Collapse
11: Response to Use of master templates (response to 1)
Posted by Jon Griffin on 08/19/02 02:58 AM
You are probably right I will look at subsites closer.

I do want to look into cleaning up the RP as I told you before so we can easily add filters and etc for things like code red and not checking perms on certain file types etc. So it looks like two seperate though related tasks.

Collapse
12: Response to Use of master templates (response to 1)
Posted by Don Baccus on 08/19/02 03:48 PM
Over in the dotLRN forum there was a thread in which the issue of not checking perms for certain file types was discussed.  I think the consenus was to create a special directory which isn't checked (sometimes you want to check some, but not all, GIFs or JPEGs for perms, for instance).

Anyway I suggest you try to find that thread and maybe contact those who had opinions ...

I should also add my caching of permissions code stuff that I added for GP's version of the request processor.

Collapse
13: Response to Use of master templates (response to 1)
Posted by Jon Griffin on 08/19/02 07:47 PM
I am going through the packages I use and would like to make some more suggestions:
  • Many pages have plain wrong html. There is no excuse for this. I will clean up what I use, but package maintainers please check your code. This also messes up master templates when you have extra td's table's and etc.
  • I don't want your suggested fonts in the adp pages. We should think about making a sitewide css file and using it, or completly dropping all font,size etc in markup. I think that in the year 2002 we can safely add a style sheet and the 2% of users who don't have compliant browsers can read it anyway. I am not talking about a huge file, just things for font sizes and etc.
  • I know it has been brought up, but all pages should be templated.
  • I change all the admin pages to a "admin-master" template as I don't really need the admin interface as heavy as most designers like to make the public pages. This should really be added to the core and another parameter added along with template masters.
Collapse
14: Response to Use of master templates (response to 1)
Posted by Jun Yamog on 08/20/02 04:34 AM
Hi,

Regarding returning a templated ad_complain what we used is this code here: 

#
# We replace ad_return_complaint with a procedure that uses
# the templating system by calling a special error template.
#
proc_doc ad_return_complaint {exception_count exception_text} "Return a page complaining about the user's input (as opposed to an error in our software, for which ad_return_error is more appropriate)" {
    global error_message
    if { $exception_count == 1 } {
	set problem_string "a problem"
	set please_correct "it"
    } else {
	set problem_string "some problems"
	set please_correct "them"
    }

    set error_message $exception_text
    doc_return 200 text/html [template::adp_parse [template::util::url_to_file "/www/templates/error" [ad_conn file]] {}]
}

Do you think we can use this an iterim 4.6 solution? 4.7 is another thing though.

Since the html on all packages are going be changed for 4.7 I better start get cranking for my proposal on how the html should be. There was a thread about this but I think its best to stop the discussion and start with a more solid proposal.

Collapse
15: Response to Use of master templates (response to 1)
Posted by Jeff Davis on 09/02/02 05:40 PM
I am going to work on removing the package local master templates. My plan is to rationalize the current package local master.adp's first (so that they all expect title and context_bar and optionally focus) and once they are all in about the same state I am going to change the default master and remove the package local masters (well, some will remain but primarily as wrappers which set properties and such but emit no html of their own).

I will post my progress here and any problems I run into.

Collapse
16: Response to Use of master templates (response to 1)
Posted by Jon Griffin on 09/03/02 03:23 AM
There should be NO package locals. Put if statements in the master template and be done with it. It is a simple fix.

Then you can add or not add context_bar etc. on a site basis. I repeat, I don't want a developer telling me what templates I need. To change all the locals is an excercise that should be left for the package maintainers. If they don't want to do the work the package should be turned over to someone else.

The master template should have a minimal amount of anything in it. By using if exists @context_bar@ you can get rid of all the package masters.

Collapse
17: Response to Use of master templates (response to 1)
Posted by Jeff Davis on 09/03/02 09:28 AM
I agree there should not be any package local master templates but as
an intermediate step I am making sure that all the packages pass the
same things to the master template (most don't).  In some cases the
context bar is generated in the package local master, in others it is
is in the page and no master is included, and in some it is not
present at all.  Your simple step would break about 150 pages and I
think it is important not to break too much while fixing this.

If we agree the work is important, should be done consistently across
all the packages, that we want to have a code freeze in 2 weeks, and
we would like to break as little as possible in the process then
my approach works pretty well.  In any case, the lions share of the work is in the tcl code and adp pages not the masters so the removal
of the local master and final rollover to a sitewide master is a
pretty small part of the work.

Collapse
18: Response to Use of master templates (response to 1)
Posted by Don Baccus on 09/03/02 05:48 PM
If we want to reach the goal of being able to customize context bars etc on a site-wide basis by 4.6, we can't shove it on all the package maintainers and expect the "perfect" solution in two weeks.  Many packages aren't really scheduled for active work for 4.6 and we're resource poor.

So I think Jeff's interim plan is fine.  We can always work on further cleaning up individual packages later.  Jeff's approach gets us site-wide customization in a very short period of time, which is a real win IMO.

Collapse
19: Response to Use of master templates (response to 1)
Posted by Jon Griffin on 09/04/02 02:23 AM
OK, As long as it really does get done I think that is ok. Just had to voice my concern as many "temporary" fixes become very permanant.

I will also fix any packages I am using so that they don't need sub-site templates.

Collapse
20: Response to Use of master templates (response to 1)
Posted by Jeff Davis on 09/04/02 03:11 PM
Don you said:
context bar's a biggy. So are the headers that so many packages put out arbitrarily. I've done several sites where we've suppressed those by ripping code out of huge numbers of scripts where one could just leave them out of the master template if they're properties passed up the hierarchy.
I am not sure what you mean by "headers", do you just mean title and context bar or something else? There do not seem to be to many that actually use header_stuff (there are some with style sheets local like directory and I think bug tracker).

If there is something I should be fixing besides floating title and context up to the sitewide master let me know. I have not fiddled with the local css...

Collapse
21: Response to Use of master templates (response to 1)
Posted by Jeff Davis on 09/07/02 12:07 AM
I have checked in the bulk of the changes to remove all package local master templates and rationalize the context bar generation. I have not templated the error messages or the tcl pages which are not currently templated.

Here are my notes per package with the packages that are currently outstanding. Hopefully I have not broken too many things but if anyone does an install please let me know how it goes and if you run into problems with the templated pages just send me an email and I will fix it. 


OUTSTANDING ISSUES: 

notdone bug-tracker/ since Lars working on it...
notdone cms/ swamp+frames ugh.  Kill Karl Now.
notdone cms-news-demo/ ?
notdone ecommerce/ cb_vals (mailed Bart T. to ask about whether he was
                           doing -- he said he would).
notdone lars-blogger/ cb_vals need to check if it's up to date.
notdone photo-album/ cb_args (I have butchered it and am not to a
                     point where I can check in).
notdone search/ (annoying streaming output to deal with)

ALL PACKAGES:

** +did acs-admin/ cb_vals (-> cb_args)
** +did acs-api-browser/ cb_vals (-> cb_args) 
Skipped acs-automated-testing/ (not sure if this needs special treatment).
Skipped acs-bootstrap-installer/ No ADP
Skipped acs-content/ No ADP
Skipped acs-content-repository/ No ADP
Skipped acs-core-docs/ No ADP 
Skipped acs-datetime/ ADPs are examples
Skipped acs-developer-support/ no ADPs 
Skipped acs-events/ No ADPs 
Skipped acs-interface/ No ADPs 
Skipped acs-kernel/ No ADP
Skipped acs-lang/ ADP is an example
Skipped acs-ldap-authentication/ ADP is example
Skipped acs-mail/ No ADP
Skipped acs-mail-lite/ No ADP 
Skipped acs-messaging/ No ADP 
Skipped acs-notification/ No ADP
Skipped acs-reference/ No ADP
** +did acs-service-contract/ cb_vals (-> cb_args)
** +did acs-subsite/ cb_vals
Skipped acs-tcl/ No ADP
Skipped acs-templating/ No ADP (except examples)
Skipped acs-util/
** +did acs-workflow/ cb_vals (-> cb_args) needs testing.
** +did address-book/ cb_vals (-> cb_args) needs testing.
** +did adserver/ cb_vals (-> cb_args) needs testing.
OK attachments/
OK authorize-gateway/
** +did bboard/ cb_args (->cb_vals oops)
Skipped bboard-portlets/ No ADP
** +did bookmarks/ tested
notdone bug-tracker/ since Lars working on it...
** +did bulk-mail/ cb_vals (->cb_args) needs testing
** +did calendar/ cb_args tested (except some broken pages).
** +did chat/ cb_vals (->cb_args) needs testing.
** +did clickthrough/ cb_vals (->cb_args) needs testing.
notdone cms/ swamp+frames ugh.  Kill Karl Now.
notdone cms-news-demo/ ?
** +did cronjob/ cb_vals (->cb_args) tested.
** +did directory/ cb_args tested.  removed markup from master template but retained style sheet.
** +did download/ cb_args tested.  markup still a mess.  found a couple bugs as well (ticketed).
notdone ecommerce/ cb_vals (mailed Bart T. to ask about whether he was
                           doing -- he said he would).
** +did edit-this-page/ cb_vals (->cb_args) tested.  fixed etp-symlink bug.
Skipped email-handler/ No ADP
** +did faq/ cb_args tested.
Skipped file-manager/ No ADP
** +did file-storage/ cb_args needs testing.
** +did forums/ cb_args tested.  references ../master.
Skipped gatekeeper/ No ADP
** +did general-comments/ cb_args tested (excpt uploads).
** +did glossary/ cb_vals tested
Skipped intermedia-driver/
notdone lars-blogger/ cb_vals 
Skipped monitoring/ 
Skipped mp3jukebox/
** +did mp3-jukebox/ cb_args tested.
** +did news/ cb_args tested.
** +did notes/ cb_vals (->cb_args) tested.
** +did notifications/ cb_vals tested.
** +did openfts-driver/ cb_vals (-> cb_args) not tested.
Skipped page/ 
** +did payflowpro/ not tested
Skipped payment-gateway/ (nothing to do)
notdone photo-album/ cb_args (I have butchered it and am not to a
                     point where I can check in).
Skipped photo-album-lite/ cb_vals Swamp (plus version only works on oracle)
Skipped places/
** +did portal/ cb_vals tested mostly.  Need to fix css bit in local master template.
** +did postcard/ added titles and context. tested.
** +did press/ cb_args Not Tested.
Skipped ref-countries/ No ADPs
Skipped ref-currency/ No ADPs
Skipped ref-language/ No ADPs
Skipped ref-timezones/ No ADPs
Skipped ref-us-counties/ No ADPs
Skipped ref-us-states/ No ADPs
Skipped ref-us-zipcodes/ No ADPs
** +did robot-detection/ not tested. trivialish though.
** +did rss-support/ not tested.
** +did sample-gateway/  not tested. trivialish though.
Skipped schema-browser/ Not templated. 
notdone search/ (annoying streaming output to deal with)
Skipped shipping-gateway/ No ADPs
** +did simple-survey/ cb_args (some cb_vals bugs I think) tested.
** +did site-wide-search/ not tested.
Skipped skin/ nothing to do (well, context maybe but save for another day)
** +did spam/ not tested at all
** +did static-pages/
** +did ticket-tracker/
** +did ticket-tracker-lite/
Skipped timezones/
Skipped user-preferences/ 
** +did value-based-shipping/ not tested
Skipped version-control/ No ADPs 
Skipped wap/ No masters.
Skipped webmail/ hard to do without working version.
** +did wf-ticket-tracker/
** +did wp-slim/ cb_vals (->cb_args) tested
Collapse
22: Response to Use of master templates (response to 1)
Posted by Robert Locke on 09/16/02 09:09 AM
Hmmm... maybe this suggestion is arriving a little bit too late, but I think there might be some value to having "package-wide" master templates, and I suspect that Arsdigita structured most of their modules that way for a reason.

However, I would recommend maybe having an extremely stripped-down, bare minimum master template as shown in this example (ie, no <hr>, @context_bar@, etc): 

    foo_package/www/some_page.adp:
        <master src=master>
        ...
        ...
    foo_package/www/master.adp would simply contain:
        <master>

In a recent site, I added a property called "show_collage", which would determine whether or not to show a collage in certain sections of the site (a client requirement). For some packages, I enabled the "collage", and in others, I disabled it (technically, it simply defaulted to 0 when undefined). It was nice to be able to simply edit a single package-wide "master" template to add that property where needed.

I suppose another approach would've been to check the "package_key" in my site-wide master template, but the above seemed "cleaner". There might be other uses as well for package-wide master templates.

Collapse
23: Response to Use of master templates (response to 1)
Posted by Jon Griffin on 09/16/02 04:32 PM
There is no need to distribute package masters. You can always add them yourself.

I don't want to delete package masters for every package I use, and then have to do it again when I upgrade.

Collapse
24: Response to Use of master templates (response to 1)
Posted by Jeff Davis on 09/16/02 04:37 PM
Jon, you are wrong.  If you have something that is persistent across
most if not all pages of a given package you will want a package local
master.  The package local master should include the sitewide master
and make only minimal assumptions about what the sitewide master does
but there is no reason not to have a package local master in that
case.
Collapse
25: Response to Use of master templates (response to 1)
Posted by defunct defunct on 09/16/02 05:17 PM
I disagree.. I think Jon is correct.

99.9% of the time your developing a site for a customer who has their own look and feel.... package masters are a right royal pain the in arse!

Perhaps a simple step would be to name all package masters '<package-name>-master.adp'

In that way developers who *really* wanted them can just do a

mv <package-name>-master.adp master.adp

the master.adp in the package can then contain a reference to the site-wide master and nothing more..

Sound workable?

Collapse
26: Response to Use of master templates (response to 1)
Posted by Dave Bauer on 09/16/02 05:25 PM
Package masters should still defer to the default-master. you can have any number of master/slaves. I don't see this as a problem.

That is every package specific master still calls <master> at the top.

Collapse
27: Response to Use of master templates (response to 1)
Posted by defunct defunct on 09/16/02 05:29 PM
Surely thats going to give a combined master (isn't it?)...

Package masters imply you want some kind of formatting on a package... when of course you're almost always going to want a different master.

Package masters achieve virtually nothing (except a pain removing them)..

Or are you suggesting that each package master should look for a system wide one, ignoring themselves if found?> (a workable scheme also)

Collapse
28: Response to Use of master templates (response to 1)
Posted by Jeff Davis on 09/16/02 05:34 PM
Simon, If you read the thread you will see I already removed the
package local masters from almost all of the packages.  I agree
that most packages should not have them and I edited about half of all the files in openacs-4 to remove them (which is some indication of
how important I think it is).
<p>
What I disagree with is Jon's blanket statement that no packages should ever have local master templates.  If
you have persistent page elements across the package and the alternative
is to reproduce those elements in all the seperate pages then a local
master is a good solution (as are template includes).  Putting it in each page individually is a maintainence disaster.
Collapse
29: Response to Use of master templates (response to 1)
Posted by Dave Bauer on 09/16/02 05:40 PM
Simon, i the case of survey. The is a navigational element on every admin page in the package master. That template also passes context_bar and title up to the default-master for final processing.
Collapse
30: Response to Use of master templates (response to 1)
Posted by Jon Griffin on 09/16/02 05:59 PM
Jeff,

I disagree with you telling me what the hell to put in my clients site.

When I started the thread on template masters I laid out my reasons. Put a parameter in your package and make your package respect it. That way if I want to use that feature I can, I don't need a package template. THEY SUCK.

Collapse
31: Response to Use of master templates (response to 1)
Posted by Jon Griffin on 09/16/02 06:02 PM
Dave,

Admin pages shouldn't really use the master template either. There should be a default (not there yet) admin template. I don't need all the graphics crap on my admin pages. Besides that I don't want your navigation bar.

Do you see that just because the package developer thinks it is cool doesn't mean that the real world (i.e. paying clients) want it.

Collapse
32: Response to Use of master templates (response to 1)
Posted by Dave Bauer on 09/16/02 06:08 PM
John,

Ok, then what I would do is move the elements into an includable template, or repeat the code on every admin page.

There should be a site-wide admin master template. That is a good idea.

Collapse
33: Response to Use of master templates (response to 1)
Posted by Jeff Davis on 09/16/02 06:09 PM
John, should I remove the .adps as well?  They put things on your clients site as well.  Think a little harder about what I said and
perhaps you will understand.
Collapse
34: Response to Use of master templates (response to 1)
Posted by Bart Teeuwisse on 09/16/02 06:42 PM
Jon,

I beg to differ on the use of master templates in admin pages. Often you'd like to give users admin rights to a package at which point I prefer a consistent look for them instead of a (often drastic) change of style.

I agreee with you though on the use of a master template in admin pages so that at the very least admin pages have the same look and feel. With a seperate admin master template one has the option to make the admin pages look similar to regular pages but less graphic intense.

/Bart

Collapse
35: Response to Use of master templates (response to 1)
Posted by Jon Griffin on 09/17/02 03:16 AM
I have been driving all day so I am responding late.

Of course you don't move the adp pages. And I realize that the interim fix is to leave/fix the package masters that are already there. I am not arguing about that.

I use many templates in big sites, and NONE of them are ones that come with OpenACS. Again, this means that I have a major amount of piss ass work when I upgrade a package. There is no need for package templates once the conversions are all done.

I know that I am not the only person who has run into this problem of changing every adp and template in a package because it makes (usually wrong) assumptions about what my client would like.

IRT, admin-masters, you can always have your admin template a cp of your master. Again, It sucks to have to change this and having another parameter for admin pages would solve the problem.

Again, this will mean less work for the majority of sites and if you want some customizations of your own, you can simply add them as templates of your own.

Collapse
36: Response to Use of master templates (response to 1)
Posted by Dave Bauer on 09/17/02 03:45 AM
Here is my "i must have stayed up too late" answer to the partially related issue of customizing packages.

https://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0006G1&topic_id=12&topic=OpenACS%204%2e0%20Design

Collapse
37: Response to Use of master templates (response to 1)
Posted by Robert Locke on 09/17/02 04:56 AM
I don't understand what the problem is with having a 1-line (ie, just "<master>") package-level master.adp that every package page references via "<master src=master>".

In the default case, this is *identical* to simply calling the site-wide master template directly from any given package page (which should keep Jon happy). But it also allows the flexibility to easily do per-package customizations if necessary (see my example above - which should keep others happy).

I like your idea of a site-wide admin template, but I would again advise that there be a simple 1-line per-package admin template.

The basic idea is to standardize on a flexible templating hierarchy: 

    page-level template (/packages/foo/www/bar.adp)
        V
    package-level template (/packages/foo/www/master.adp)
        v
    site-level template (/www/default-master.adp)

I hope you will consider the above (or atleast let me know the error of my ways!)

Collapse
38: Response to Use of master templates (response to 1)
Posted by Jun Yamog on 09/17/02 05:51 AM
Hi Rob,

For me I don't think there is nothing wrong with your ways.  I think what is needed is for someone to come up with a standard how to make use of those templates.

What to put and NOT to put on the page template, package template and site template.  The hard part is convincing the package maintainers why this is beneficial (the new set of standard).

There is also the deeper issue of having the packages make use of some templating wherein no more cutomization will be done on the packages /www and only the design templates (look at the my post on Dave's thread).  But this won't be resolved in the short term.

Collapse
39: Response to Use of master templates (response to 1)
Posted by Jon Griffin on 09/17/02 06:00 AM
Robert,

I don't have any objection to your package master. That seems fairly workable as long as package writers honor the no markup by default.

Doesn't the templating system already look for a file named master.tcl/adp? If it can't be found then it uses the site-wide master. I could be wrong but I seem to remember that was the case. as long as the template was named master. If that is the case you don't need to muck up any adp files with <src master=...>

I like the service contract idea on the other thread, but I don't know how difficult it would be to implement.

Collapse
40: Response to Use of master templates (response to 1)
Posted by Robert Locke on 09/18/02 03:59 AM
<blockquote> Doesn't the templating system already look for a file named master.tcl/adp?
</blockquote>

Just did a simple test, and this does NOT seem to be the case.  But it is an interesting idea!

The only caveat I can think of is: what if you want file A to explicitly use the site-wide master, and file B to use the package-wide master (assuming it exists).  In your suggested scenario, file B could just contain "<master>", but how would file A specify to use the site-wide master?  Setting the full "src" path to the site-wide master seems clunky and a PITA to maintain.

In any case, I think having a standard (or atleast guideline) for templates is something that's worth deciding on and tackling now (kudos to Jon for bringing this up).  There are several options on the table.  How can we decide on this (if it's really worth pursuing)?

Collapse
41: Response to Use of master templates (response to 1)
Posted by Robert Locke on 10/07/02 08:32 AM
Has there been any resolution to the issue of package-level templates with regards to the 4.6 and upcoming 4.7 releases?
Collapse
42: Response to Use of master templates (response to 1)
Posted by Jeff Davis on 10/07/02 10:14 AM
I removed all (well, almost all) package local templates and moved
the title/context bar rendering to the sitewide master.

There are still a few packages with package local masters
and a bunch of pages that are not templated but things are in
much better shape.

One big change was that I added the property "context" which should
be the list of {{url text} ... {url text} {text}} so that ad_context_bar is called in the sitewide master.  This gives
us much more flexibility about how we render context bars.
context_bar still works but it is definitely less desirable
than passing the context list around.

Collapse
43: Response to Use of master templates (response to 1)
Posted by Robert Locke on 10/07/02 10:44 AM
Hi Jeff!  I'm sure it was a Herculean effort... but I thought some people agreed package-level templates were actually A Good Thing, as long as they were kept simple (ie, source the master and maybe set the title and context_bar properties).

I understand that I maybe speaking up a bit late, and that my suggestion may be ignored as a consequence.  But I really think they're important for package-level customizations and all the reasons mentioned above.

Thanks for listening...

Collapse
44: Response to Use of master templates (response to 1)
Posted by Jeff Davis on 10/07/02 11:13 AM
An additional layer of indirection is always makes things more
flexible but the realized consequence of having all these
package local masters was that you could not change the
appearance of the site or a subsite by changing the sitewide master.
Maybe removing them all was a bit drastic but if they remained
what had been a pervasive and quite unpleasant misfeature
of almost all packages would crop up with about the same
frequency as it in the past (I think about 3/4 of the packages
simply got it wrong).

I also think that what people are generally trying to achieve
when they are talking about needing to have package local masters
is better done by changing the behavior of the master tag
so that it first looks to the package instance, then the nearest subsite, and finally to the main site to decide which master
template to use.  If you need a package local master you add it
and change a parameter rather than having the file there essentially
unused as a hook for something in most cases you should not
need.

If you don't do it that way then for each package you must either
use a package local master or not use it on a sitewide basis
and I think the most common use case would be to have a bunch of subsites that you want to have consistent styling and have it be the
subsite which drives which master to use.

Collapse
45: Response to Use of master templates (response to 1)
Posted by Robert Locke on 10/07/02 11:38 AM
> but the realized consequence of having all these
> package local masters was that you could not change the
> appearance of the site or a subsite by changing the sitewide master.

If all the package local masters sourced the main site master, then this would not be the case.

However, I do like your (and Jon's) proposal regarding changing the behavior of the master tag! My only concern is what I mentioned above:

What if you want file A to explicitly use the site-wide master, and file B to use the package-level master (assuming it exists). In your suggested scenario, file B could just contain "<master>", but how would file A specify to use the site-wide master? Setting the full "src" path to the site-wide master seems clunky and a PITA to maintain.

My main interest is preserving the ability to easily do package-level customizations. I hope this issue will be addressed.

Collapse
46: Response to Use of master templates (response to 1)
Posted by Jeff Davis on 10/07/02 11:51 AM
Robert, I think the example you are concerned about is fairly
contrived so I think I would be perfectly happy to have it be
quite clunky to do.  Offhand, the only place I can see that
something like that would be desirable would be in for example
notifications where you should be able to manage your sitewide
notifications and hence might want the sitewide master rather than
the subsite master (and even there most of the time you probably
really want the subsite master template anyway).  I would be more
inclined to add a context="path" to the master tag to have it
look up a different subsite's master template (so your example would
become <master context="/">).

If you can come up with some more concrete examples I am certainly
willing to entertain the idea that I am misguided here.

Collapse
47: Response to Use of master templates (response to 1)
Posted by Robert Locke on 10/07/02 12:21 PM
> If you can come up with some more concrete examples I am certainly
>willing to entertain the idea that I am misguided here.

As stated in my last post, I'm actually in agreement with your idea to have the "<master>" tag first check for a package local master, then a system-wide master. And, now that I think of it, it may want to check for a directory-local master first.

My only concern (and it's admittedly minor) was what I mentioned above. I can't think of any good examples, but I also can't say that a developer won't want to do something similar in the future for reasons unknown. Perhaps your context parameter would solve the issue.

So, we now have a proposal to change the default behavior of the "<master>" tag to check for a package local master (maybe even a directory master first) followed by the system-wide master. Where do we go from here?

Collapse
48: Re: Response to Use of master templates (response to 47)
Posted by Randy O'Meara on 01/03/03 07:18 AM
Has the <master> tag behavior been changed as suggested above (hierarchical search for master) in the 4.6 release?

Randy

Collapse
49: Re: Use of master templates (response to 1)
Posted by Robert Locke on 01/03/03 08:43 AM
Here's the latest thread that discusses this:

https://openacs.org/forums/message-view?message_id=63062

Yikes!  Looks like I volunteered to do this for the 4.7 release.  I'll get working on this as well as a couple of other outstanding items next week.