Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: domain of peter.hunsberger@gmail.com
 designates 64.233.184.197 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=CJlLVB2eeGxCxOCrWW/ilGDHWvi/j+zewLADf4GnxozpnF9cZw5vQMwX+lEdDRZt4lIvKE5vn24UqMlokPyvZVAsy4jh1/ZMWrzibwFQs2j2q9DJOPdK5z7p+5m/g4Ym/p7v/0CjDpsDqs13vG7pUaQTovCfdfEh6OCWD9Meq94=
Message-ID: <cc159a4a041203065230a4323b@mail.gmail.com>
Date: Fri, 3 Dec 2004 08:52:01 -0600
From: Peter Hunsberger <peter.hunsberger@gmail.com>
Reply-To: Peter Hunsberger <peter.hunsberger@gmail.com>
To: dev@cocoon.apache.org
Subject: Re: What do we need taglibs for?
In-Reply-To: <41B050C1.3040100@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <41B050C1.3040100@apache.org>

On Fri, 03 Dec 2004 12:40:49 +0100, Sylvain Wallez <sylvain@apache.org> wrote:

<snip> lots of discussion on taglibs and templates</snips>

> Taglibs are to templates just what factorization in classes and methods
> are to Java code. Taglib features could equally well be provided as
> extension functions to the expression language, but writing them in XML
> (either with tags or attributes) just seems more consistent with the XML
> world of the view layer.

There is another way.  It's sort of weird and in it's simplest
implementation requires modern browsers but you previously asked how
our templating system works, so I might as well fill you in on how we
handle things like this.

First we separate the concept of "screens" (or pages) from templates,
there can be multiple templates per screen.  Each template has a base
type, the two most important for this discussion being "edit" and
"grid".  A edit template allows random positioning of individual
objects anywhere on the screen using relative positioning and XSLT
ordering of the objects (to make the CSS calculation of the relative
positioning easier).  A grid produces a regular table.

Either of these layouts can contain the other. We use iframes to embed
any given template within another. This couples a single URI to any
given template. We have a special form of object known as a "key" that
is used for managing relationships between collections of data and
when you embed a template within another any key values from the first
are automatically passed to the second as request parameters on the
iframe src.  Thus, mapping one to may relationships in the database
has an exact equivalent at screen creation time and you don't end up
denormalizing in you query and then splitting things back apart at
presentation time.

There is a requirement to make sure that the appropriate screen types
are mapped to the correct data producers on the back end.  We have
logic that automatically selects between screen types if multiple
matches are defined, but if all you have is a "edit" screen and the
keys you get passed from your container result in multiple rows being
produced you will see only a single edit screen (though I guess we
could automatically produce the corresponding grid in this case).

I said at the beginning that the simplest implementation requires
appropriate browser support, that being iframes.  However, you could
manage this all on the back end, doing essentially server side
embedding of the templates within each other and still mapping the
population of each portion to the proper URI.  From what I've read I
don't think the result would be much more complex than some of cforms
(or the existing templating proposals for that matter)...

IOW, if you need to refactor templates, allow templates to be
normalized WRT to each other. I don't think you need a new concept....

-- 
Peter Hunsberger