You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2004/12/08 18:10:09 UTC
[RT] since we are at it, more irons in the template fire: Xenon
Now, let me tell you a story about templates.
My group here at MIT has the same problem with templates. We are
currently using velocity, but we are moving our metadata browser
(longwell, http://simile.mit.edu/longwell/) to cocoon.
The first (and easy porting) solution would be to keep using velocity,
but in the longer run, it would be much better to use CTemplate.
At the same time, we are in the process of creating a RDF presentation
ontology that we call "Fresnel" (kudos for our friend Mark Butler for
the name). You can think of Fresnel as "CSS for RDF".
Fresnel is supposed to bring some more unity to the force in the space
of RDF visualization, work pioneered by some other projecs like the
Haystack project at MIT (http://haystack.lcs.mit.edu/), the IsaViz
project at W3C (http://www.w3.org/2001/11/IsaViz/), the work by Chris
Bizer and his group at the University of Berlin and Longwell itself.
Recently, a proposal for an RDF template language was put forth by the
original creators of Haystack. It's called Xenon and it's basically
"XSLT for RDF".
Find a copy of the paper here:
http://simile.mit.edu/mail/GetAttachment?listName=General&msgId=2687&attachId=1
WARNING: this will look at your eyes as extremely weird, but there are a
few things inside that I consider valuable, so bear with me.
- o -
First of all, Xenon is an RDF ontology.
If you don't know what that is, you can think at an ontology as a schema
for RDF (even if there is no validation!, it just gives you a list of
classes and properties that belong to a particular namespace).
The above means that, just like XSLT is XML, Xenon is RDF. As a result,
you have to use RDF syntaxes (RDF, unlike XML has more than one) to
write it. How does that look like? Here is with the N3 syntax:
:DefaultNameLens
a xe:LensTemplate ;
xe:role xe:nameLens ;
xe:size xe:inline ;
xe:match () ; # Matches everything
xe:body [
a xhtml:Text ;
xe:body [
a xe:Select ;
xe:singleResult "true" ;
xe:filter "PREFIX xe:
<http://haystack.lcs.mit.edu/schemata/xenon#>
PREFIX dc: <http://purl.org/dc/elements/1.1/>
SELECT ?TARGET WHERE ($xe:target dc:title ?TARGET)"
]
]
It is not important here to discuss Xenon per se (if you are curious,
read my reply below.
http://simile.mit.edu/mail/ReadMsg?listName=General&msgNo=138
but there is definately a few things that are innovative (and came from
the Haystack experience) and might be valuable in our current template
discussion.
- o -
The mental model of Xenon is composed of these elements:
1) a template
2) a query language for RDF models
3) higher-level abstractions: lenses and views
We match on 1 and that's why I'm talking about ithere: Xenon is not
meant to be an 'RDF transformation language' but it's meant to be a way
to describe how you should annotate existing RDF with enough
presentation information to allow visual browsers to display it and
users to interact with it.
We match on 2) also, even if the approaches start to diverge: Xenon uses
SPARQL (the still-working-draft W3C RDF query language. you can think of
it as the alternative of XPath for RDF, since the notion of paths in RDF
doesn't apply very well).
We do match on 2) even if Xenon names it "query language" and we name it
"expression language". Both are a way to "identify" a particular datum
or data in a model (Xenon expects everything to be an RDF model, we
expet it to be either a collection of java beans or an XML DOM tree).
Note how, in this respect, Xenon is more straightforward since it has
only one 'query language' while we have agreed to have at least two (the
java-like and the xpath-like).
On the other hand, we expect our expression languages to be easy enough
for non-programmers to understand, while this is clearly not true for
Xenon where writing a single SPARQL query requires extensive knowledge
of both RDF and the mental model of querying.
In this respect, Xenon is clearly inferior (even with a non-RDF syntax),
since no template designer will be able to write a Xenon template.
The big difference and the main reason why I brought it up is that Xenon
has #3 which is something we might be interested in.
- 0 -
The haystack project soon realized that there are several ways to look
at the same data. They tried to create a model where those "views" could
be reused and applied even to data that was not meant to be displayed
that way.
Example: you have a calendar view and a collection of events. Pretty
straightforward. But then you have a collection of emails, with dates,
and you apply the calendar view: result might be, for example, the
chronological layout of emails, as they were events.
As "views" represent a way to look at a collection of data, they also
realize the need to have single data objects or smaller datasets, as
another form of visual granularity. They call these "lenses".
[The same concepts and terminology of views and lenses is now being used
in Fresnel as well, while Fresnel is a purely declerative language, just
like CSS, therefore nothing useful in our template discussion]
The difference between a view and a lens is rather subdle: since Xenon
does not expect the RDF model to be pre-processed (as we do in our
template system, by having a controlling stage up front before the
pipelined view invocation), it has to perform some data selection to
identify.
Here the two models different entirely: Xenon is a pull model, while our
templates will be a push model (the data population will be performed by
a previous, fully programmatic stage)
So, a Xenon view performs the "population" of the real template data
model. Note how this makes Xenon a "Model 1" language.
Once the population is performed, the lens come in place to decide how
to further present the data that has been selected by the view. This
follows the declarative-matching model of XSLT, only using SPARQL
instead of XPath.
We have agreed to identify this declarative-matching model harmful for
our users, since people seem to be more used to a procedular description
of their pages, even if this ends up being more verbose.
The use of the apply-template "procedular flow black hole"
(anti?)pattern puts Xenon in the same category of XSLT.
- o -
So, it seems that Xenon is just an double-staged RDF-oriented version of
XSLT used ad a template, and we all pretty much agree that those mental
models are too hard for template designers to work with, so why talking
about it?
I like the name (and the concept) of lenses.
We have identified the need to have "isolated and reusable programmatic
artifacts that know how to transform something into SAX events". They
were named 'taglib' because the syntax normally used to identify them is
a namespaced element (a 'tag').
The problem with the name is that it has been used (and abused!) in too
many systems and brings memories of abuse and FS. Like the infamous <if>
tag (also abused by XSLT)
I think we should call our CTemplates taglibs "lenses" instead.
WDYT?
--
Stefano.
Re: [RT] since we are at it, more irons in the template fire: Xenon
Posted by Peter Hunsberger <pe...@gmail.com>.
On Wed, 08 Dec 2004 12:10:09 -0500, Stefano Mazzocchi
<st...@apache.org> wrote:
> Now, let me tell you a story about templates.
As the sound of the theme music from Beverly Hillbillies rises in the
background?
<snip>story</snip>
>
> I like the name (and the concept) of lenses.
>
> We have identified the need to have "isolated and reusable programmatic
> artifacts that know how to transform something into SAX events". They
> were named 'taglib' because the syntax normally used to identify them is
> a namespaced element (a 'tag').
>
> The problem with the name is that it has been used (and abused!) in too
> many systems and brings memories of abuse and FS. Like the infamous <if>
> tag (also abused by XSLT)
>
> I think we should call our CTemplates taglibs "lenses" instead.
>
> WDYT?
For our internal templating system we're currently implementing a
concept we call "filters" that lets one declaratively define
conditional portions of a template/view. As I read your story (:-) I
kept thinking that lenses and filters lined up pretty much the same.
Then I jumped over to the Xenon description and found a "xe:filter" as
part of the lens description. I won't have time to dissect everything
completely, but semantically a lens as used in Xenon seems to be a
filter (and filters as used in Xenon seem to be conditionals). If so,
I think the idea makes perfect sense, at least for our system
However, I'm not quite sure that the lens concept maps exactly to
everything that is being discussed WRT Cocoon? In particular, there
seems to be more of a active modifier role (ie "turn something into
SAX events") to what people are looking for for Cocoon? Then again,
maybe that's part of the problem and why you like the name "lens"?
I'll also note that if you take the optical analogy literally, you
want both lenses and filters working together as separate components
and not mixed together the way Xenon seems to do. I wonder if there's
some SOC in the view model that really remains to be completely
abstracted? I'm not sure "lens" is an abstraction I find completely
understandable...
--
Peter Hunsberger
Re: [RT] since we are at it, more irons in the template fire: Xenon
Posted by Glen Ezkovich <gl...@hard-bop.com>.
On Dec 8, 2004, at 2:55 PM, Leszek Gawron wrote:
> Glen Ezkovich wrote:
>> On Dec 8, 2004, at 11:10 AM, Stefano Mazzocchi wrote:
>>>
>>> I think we should call our CTemplates taglibs "lenses" instead.
> I like it.
>
>> Call them what you will. It doesn't change the core issue. If
>> "lenses" allow you access databases, send emails, invoke business
>> methods, etc. you still are inviting JSP/XSP like abuse, albeit,
>> syntacticly not as ugly. It is not what you want to use them for, but
>> what they can be used for and how they are introduced into the system
>> that lead to potential problems.
> Even right now you can call arbitrary Java code in JXTG by simple
> <jx:set var="ignore" value="${Packages.org.apache.cocoon.Foo.bar()"/>.
> You would have to disallow to reference ANY method. In that case the
> template language would be very restrictive which I am not that great
> fan of.
I know. And that would not be what I want. I can think of ways we can
get around this, but I think it might be going to far; more reflection
would not help performance and I'm not going to suggest that we write
another XML mapping file. At some point you have to trust others.
>
>> That said, "lenses" as a name would at least not encourage anyone to
>> abuse the system. In that sense, it is superior to "taglib".
>> Unfortunately, they would be semantically the same.
>> So here you have my non-voting +1
> +1. Good name which does not raise wrong emotions.
>
>> And another bit about the issue of needing user defined java backed
>> taglibs/lenses:
>> Lenses and views are exactly what I want in order to provide
>> reusability and the building of pages from components. These seem to
>> be micro and mini templates. What is it that you cannot do with a
>> library of jx:macros that causes you to need a full fledged Java
>> object?
> If talking about proper "tag" implemenetation (one that does only
> allowed actions) probably you could switch to macros. JXTG lacks only
> one feature that would make macro system complete: the ability to
> invoke a macro which name is resolved by expression. I will create
> another post about that.
And this could be added. (and now you seem to be doing just this. it
took me to long to get back to this ;-))
>
> Still there is one other this that jx:macro is not that suitable for:
> convertors. See previous threads for the problem description.
>
I recall that thread (or a thread with regard convertors and CForms, if
this is the wrong thread please, let me know). This is one of the
reasons I choose to use JXTG to inject data into a xml template and not
generate the view. This way when it comes time to render the view all I
have are strings. No assumptions about data types are required and no
conversions are required. Granted this is not always the most
satisfying way to do things but it does work.
Now, since obviously a lot of people want to be able to go straight to
rendering, convertors would seem to be a good thing. Convertors for use
in CForms need to be bi-directional, going from type to string and
vice-versa. I can think of domain specific cases where custom
convertors will be more then useful. There is no doubt that within the
CForms framework custom convertors make perfect sense.
Converters in templates only need to convert from type to string.
Granted there is an implicit string to type conversion in something
like <jx;if test="${obj.getAmount()} < 10}">. It seems that the
jx:macro can handle these cases. I don't see the need to add external
libraries in order to render an object.
If you need custom convertors, it seems to me that you would want to
add them to your project where they are needed. In the form definition.
To be fair once this work is done it would be nice if there were a way
to use the convertors from within any template. Convertors are just
java objects they, can be passed from flow. They could be accessed from
the form. Or can be made part of the template framework and accessed by
a tag or attribute.
My point is, for rendering, convertors are not necessary. Once you have
them, you might as well use them.
Am I missing something about the need for Convertors in templates?
Sorry for rambling on tangentially.
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
http://www.hard-bop.com
A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to
worry about answers."
- Thomas Pynchon Gravity's Rainbow
Re: [RT] since we are at it, more irons in the template fire: Xenon
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Glen Ezkovich wrote:
> On Dec 8, 2004, at 11:10 AM, Stefano Mazzocchi wrote:
>
>>
>> I think we should call our CTemplates taglibs "lenses" instead.
I like it.
>
> Call them what you will. It doesn't change the core issue. If "lenses"
> allow you access databases, send emails, invoke business methods, etc.
> you still are inviting JSP/XSP like abuse, albeit, syntacticly not as
> ugly. It is not what you want to use them for, but what they can be used
> for and how they are introduced into the system that lead to potential
> problems.
Even right now you can call arbitrary Java code in JXTG by simple
<jx:set var="ignore" value="${Packages.org.apache.cocoon.Foo.bar()"/>.
You would have to disallow to reference ANY method. In that case the
template language would be very restrictive which I am not that great
fan of.
> That said, "lenses" as a name would at least not encourage anyone to
> abuse the system. In that sense, it is superior to "taglib".
> Unfortunately, they would be semantically the same.
>
> So here you have my non-voting +1
+1. Good name which does not raise wrong emotions.
> And another bit about the issue of needing user defined java backed
> taglibs/lenses:
> Lenses and views are exactly what I want in order to provide reusability
> and the building of pages from components. These seem to be micro and
> mini templates. What is it that you cannot do with a library of
> jx:macros that causes you to need a full fledged Java object?
If talking about proper "tag" implemenetation (one that does only
allowed actions) probably you could switch to macros. JXTG lacks only
one feature that would make macro system complete: the ability to invoke
a macro which name is resolved by expression. I will create another post
about that.
Still there is one other this that jx:macro is not that suitable for:
convertors. See previous threads for the problem description.
--
Leszek Gawron lgawron@mobilebox.pl
Project Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [RT] since we are at it, more irons in the template fire: Xenon
Posted by Glen Ezkovich <gl...@hard-bop.com>.
On Dec 8, 2004, at 2:22 PM, Ralph Goers wrote:
> Glen Ezkovich said:
>> On Dec 8, 2004, at 11:10 AM, Stefano Mazzocchi wrote:
>>>
>>> I think we should call our CTemplates taglibs "lenses" instead.
>>
>> Call them what you will. It doesn't change the core issue. If "lenses"
>> allow you access databases, send emails, invoke business methods, etc.
>> you still are inviting JSP/XSP like abuse, albeit, syntacticly not as
>> ugly. It is not what you want to use them for, but what they can be
>> used for and how they are introduced into the system that lead to
>> potential problems.
>
> Actually, I always thought that taglibs were the "good part" of JSPs.
> It
> is the fact that you can code Java in them that makes them dangerous.
I stand corrected. Its the html that is the bad part. ;-) Tags are good
in the sense that they offer encapsulation and thus promote
reusability. What exactly is the difference if I encapsulate my java
code in a tag or in a method? Mainly usability. It is easier for a
non-programer to use tags then invoke methods. Ultimately it comes down
to a method invocation. There is just one more level of indirection.
The point I attempted to make was that a template should be a template
and not a controller or an entryway for model manipulation. JSP is MV
and C. A template engine should just fill in the blanks with provided
data with the assistance of metadata if necessary. As a bonus it would
be nice to have some form of encapsulation where a template could be
built out of other templates.
> If
> one can control what tag libraries are available and not allow java
> code
> in the template then SOC is possible.
unfortunately if we want to get data out of java objects we have to
allow some code.
> Of course, a tag library that
> allows you to code a select statement as a parameter would be awful,
> but
> you can't control everything in life.
And again you are right, you can't control everything. What you can do
is limit how tags are introduced into the system. If taglibs are
introduced by just adding a declaration in the template they are more
likely to be abused then requiring them to be part of component
configuration. They would be even fewer cases of abuse if one had to
add the taglibs at compile time. I think it is reasonable to ask who is
making the decisions on including the libraries and how easy does it
have to be to add the libraries.
I really don't have a problem with taglibs. I don't even have a problem
with the name. ;-)
All I would like is for the community to consider the ramifications. I
know that no one who works with me will get away with doing something
so egregious as using a taglib that allows select statements as a
parameter. In the end that is all I care about. On a large project, I
would like some way other then threats, to prevent my people from using
such a library.
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
http://www.hard-bop.com
A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to
worry about answers."
- Thomas Pynchon Gravity's Rainbow
Re: [RT] since we are at it, more irons in the template fire: Xenon
Posted by Ralph Goers <Ra...@dslextreme.com>.
Glen Ezkovich said:
> On Dec 8, 2004, at 11:10 AM, Stefano Mazzocchi wrote:
>>
>> I think we should call our CTemplates taglibs "lenses" instead.
>
> Call them what you will. It doesn't change the core issue. If "lenses"
> allow you access databases, send emails, invoke business methods, etc.
> you still are inviting JSP/XSP like abuse, albeit, syntacticly not as
> ugly. It is not what you want to use them for, but what they can be
> used for and how they are introduced into the system that lead to
> potential problems.
Actually, I always thought that taglibs were the "good part" of JSPs. It
is the fact that you can code Java in them that makes them dangerous. If
one can control what tag libraries are available and not allow java code
in the template then SOC is possible. Of course, a tag library that
allows you to code a select statement as a parameter would be awful, but
you can't control everything in life.
Ralph
Re: [RT] since we are at it, more irons in the template fire: Xenon
Posted by Glen Ezkovich <gl...@hard-bop.com>.
On Dec 8, 2004, at 11:10 AM, Stefano Mazzocchi wrote:
>
> I think we should call our CTemplates taglibs "lenses" instead.
Call them what you will. It doesn't change the core issue. If "lenses"
allow you access databases, send emails, invoke business methods, etc.
you still are inviting JSP/XSP like abuse, albeit, syntacticly not as
ugly. It is not what you want to use them for, but what they can be
used for and how they are introduced into the system that lead to
potential problems.
That said, "lenses" as a name would at least not encourage anyone to
abuse the system. In that sense, it is superior to "taglib".
Unfortunately, they would be semantically the same.
So here you have my non-voting +1
Using "taglibs" in the implementation of expression languages makes
sense until you start with attribute based languages. Using "lenses" in
the implementation just sounds weird.
And here you have my non-voting -1
And another bit about the issue of needing user defined java backed
taglibs/lenses:
Lenses and views are exactly what I want in order to provide
reusability and the building of pages from components. These seem to be
micro and mini templates. What is it that you cannot do with a library
of jx:macros that causes you to need a full fledged Java object?
Glen Ezkovich -- who has to much time on his hands at the moment.
HardBop Consulting
glen at hard-bop.com
http://www.hard-bop.com
A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to
worry about answers."
- Thomas Pynchon Gravity's Rainbow