cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Comments on XSP 1.1 (long)
Date Tue, 31 Oct 2000 20:18:51 GMT
Joel Hawkins wrote:
> 
> I think the fundamental question here is who is the SiLLy's intended
> audience?

This is indeed the key question.

Matt is right: logicsheets are written by programmers.

And Matt is right again: not everybody likes Java's strong typing and
extreme abstraction capabilities, just like not everybody likes Perl's
super-flexibility.

There is one problem, though: not many find it easy to mix procedural
programming logic with declarative markup languages.

Also, it's pretty easy to come up with a mapping between, say, util:date
and java.util.Date but not so for netsted taglibs... for example

 <sql:query>
  <xsp:variable name="query"><request:param
name="query"/></xsp:variable>
  <cookie:param name="{query}">
 </sql:query>

(stupid example, I agree, but gives you the idea)

We do not want to define a marked-up procedural language to abstract
from the logic programming languages, no, but the goal is to clone
tag-based macro declarative languages (like coldfusion) and provide an
easy way to extend them at need.

Today, a few people write logicsheets because it's a PITA to come up
with a uniform way to pass parameters around, allow taglib nesting and
so on. SLL provides an abstraction that helps in this case, but doesn't
force you to use it for your taglibs.

In fact, XSP doesn't rule "how" you come up with the XSP code that is
then transformed into pure logic: you can use XSLT, SLL, or even your
favorite Perl script directly... it's up to you.

Probably Perl (being *way* better than java at handling and transforming
text) is already a great choice for writing logicsheets, but for Java,
well, XSLT+Java don't go very well together, this is why Ricardo wanted
to hide all the logicsheet machineries down below the SLL level by
abstracting everything that can be possibly abstracted.

This is very "Java-ish" from our part: overlap means duplication,
duplication means more costs and polymorphism and abstraction are the
very heart of the Java language (unlike Perl in which polymorphism is
rarely used)

Anyway, XSP and SLL are two different things and we do not want to
mandate the use of SLL if you have a better way to come up with the code
that implements your taglibs. Unfortunately, for Java, hooking markup
and code is extremely painful given the complete orthogonality of the
two approaches, SLL tries to help in that direction providing a way to
express highly OO java logic into taglibs and using OO features at
nesting level.

True, logicsheets are written by programmers, but how many programmers
are confortable with inlining code into XSLT stylesheets? how many
programmers like to write their own SAX filter to create code that is
futher compiled?

SLL glues markup and OO code. If you think you don't need it for Perl,
well, no problem, but are you sure all your joe perl programmers are
able to handle nested taglibs with no hassle?

If so, well, I can't wait for Perl 6 to come out so that I can compile
it on a JVM and use it inside my XSP :)

But, for now, I believe SiLLy (despite its name) is a very clever
approach for markup-java logic connection.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



Mime
View raw message