Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 54741 invoked from network); 2 Nov 2000 07:39:15 -0000 Received: from unknown (HELO mail.anyware-tech.com) (213.11.20.188) by locus.apache.org with SMTP; 2 Nov 2000 07:39:15 -0000 Received: from anyware-tech.com (anyware1 [10.0.0.1]) by mail.anyware-tech.com (8.9.3/8.8.7) with ESMTP id IAA23830 for ; Thu, 2 Nov 2000 08:38:11 +0100 Message-ID: <3A0119CB.A7E809EE@anyware-tech.com> Date: Thu, 02 Nov 2000 08:37:47 +0100 From: Sylvain Wallez Organization: Anyware Technologies X-Mailer: Mozilla 4.7 [fr] (WinNT; I) X-Accept-Language: fr MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: Comments on XSP 1.1 (long) References: <55834B092A92D411AC6600B0D078395A018A1C@postoffice.anchorsilk.com> <39FF292B.BBC1DD91@apache.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N Stefano Mazzocchi a �crit : > > 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 > > > name="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. > Friedrich Nietzsche > -------------------------------------------------------------------- I totally agree with you. I had the experience in my company of experienced Java programmers that felt very uncomfortable when asking to write a logicsheet for their Java components. And the worst for them was duplicating all these complicated lines of XSLT just to get parameters. This ended up with inconsistencies and bugs due to bad copy/paste of parameter handling. Another problem with current logicsheets is documentation : there is no easy or standard way to document an XSL. So you often have to go back to the logicsheet code to know exactly what it does. It would be good to have a Javadoc like documentation out of logicsheets. I remember someone talking on this list about a "xsp:doc" tag but I couldn't find it back. If SiLLy can just ease and formalize the definition the public interface of taglibs and their documentation, then it's very worth it. If it additionally allow to simply map XML tags to Java static methods calls, then every Java programmer will love it. -Sylvain