MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <4A8986E9.5090209@morningstar2.co.uk>
Message-ID:  <19083.50144.758672.59081@morse.mittelbach-online.de>
Date:         Wed, 19 Aug 2009 11:20:32 +0200
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Frank Mittelbach <frank.mittelbach@LATEX-PROJECT.ORG>
Subject: Re: template
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <4A8986E9.5090209@morningstar2.co.uk>
Precedence: list
Status: R

Joseph

now that I missed out every on the xparse discussion due to being away (and
not yet having been able to review it properly) I hope that to contribute at
least to the template discussion in time.

 > The idea of template is that it lets you separate out design from code,
 > and to pre-set various parts of the design so that they do not have to
 > be evaluated at every use.  I'm still not clear on the
 > \DeclareTemplateType concept, so I'll go with what I can understand. (If
 > anyone can show where this extra division is useful, please do tell.)

I'll hope I will be able to do this (in a separate message)

 > You start by declaring a template, which is a generalised form for a
 > design function. For example, you might have a template called
 > "division" that is a generalised chapter/section. The template has a
 > number of keys, which will set variables later. The trunk template
 > implementation uses a modified keyval method for setting these up, but
 > in my template-alt version I've used the same concept as is now present
 > in l3keys.  Something like (very simplified, of course):
 >
 > [...]
 >
 > You'll notice the number: this is used to allow the template to take a
 > number of arguments.

One important point to note here is that a template takes a fixed (!) number
of mandatory (!) arguments and no (!) optional ones and that tese argument are
supposed to receive content from the input stream of the document.

The user level presentation (which might involve optional arguments etc. is
moved to a different layer (xparse and the like) to provide for different kind
of user presentations without burden on the functionality.

 > The next part of the process is to create an "instance". The idea here
 > is to fix particular parameters of the template with a given name.  So
 > pursuing the very simple example, we might have one instance for chapters:
 > 
 > \DeclareInstance { chapter } { division } {
 >   font-name    = Helvetica,
 >   font-size    = 20 pt,
 >   ...
 > }
 > 
 > and so on. The point is that the keys are set "now", so that when we use
 > the instance there is less to do.

correct. however the parameter settings of a template (turning it into an
instance) is not only restricted to preset values: the template implementation
also allows for keys to be evaluated and set at run-time if needed.

The conceptual point being that template parameters are receiving values
specified by the designer to define layout an general hehavior, while the
mandatory arguments of a template receive document input to be processed
according to the design. For reasons of processing speed there has been a
decision to make the latter argument direct TeX argument (thus imposing a
limit of 9) rather than offering a key/val interface on that level as well. In
our opinion such an interface, if desired, should live one layer up as it
would be a document syntax feature.

 > [...]
 
 > At present, there are various bells and whistles to this in template, of
 > which only some are implemented in template-alt as I don't follow all of
 > them. So there are various questions:
 >  - Does this broadly make sense to other people?
 >  - Does the current interface provide enough flexibility?

if by current interface you mean the functionality offered by the original
template implementation then my biased take is yes :-) if you mean a
restricted subset of features I doubt it. That is not to say that some of the
functionality we implemented should be done differently or should be offered
differently so sorting this out and reevaluating them one by one is important
as we agreed earlier

frank