portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <sg...@hisitech.com>
Subject Re: Velocity / JSP / XML & XSLT : Why ???
Date Fri, 19 Oct 2001 09:52:42 GMT
Raphaƫl Luta wrote:

> Norman Schoneich wrote:
>> Jetspeed supports different template engines.
>> But in the moment, the default template layout engine is velocity and 
>> it'is
>> the most supported engine by the jetspeed developers.
>> The previous default engine was jsp, but the support (or development
>> process) of the jsp layout seems to be stopped.
>> I can understand that some people prefer velocity. But every layout 
>> engine
>> has it's own advantages and disadvanteges. I think Jetspeed
>> has to support multiple layout engines, but they must be handled 
>> equally.
> Agreed on the multiple support, as for the *equal* support it depends 
> a all
> on finding people that make sure any given layout system is up to date 
> with
> the engine features...
> I personnally use Velocity so this is the layout on which I'll work most.
>> What's about an XML & XSLT based approach ? Is it possible (or 
>> better) to
>> render the portlets by the different controllers and then render the 
>> result
>> with an XSLT file (the portlets use themself xml/xsl, which i use). I 
>> like
>> this approach the most, because it' s based on open standards unlike
>> velocity.
I work with a company that has developed a product based on Jetspeed 
that does all rendering using a SAX event chain, using a 
SAXXSLTtemplating system. If you notice the PortletAPI, there is a 
provision for SAXPortlet, which are portlets that "write" content as a 
chain of SAX events. This was agreed after discussing that "character 
streaming" portlets (jsp,vm,...) are different from "event streaming" 
portlets, and it would be hard to need parsing/serialization at every 
point in the rendering loop.

We are making Jetspeed evolve so that it supports both byte-stream 
portlets (be them java-class-portlets, jsp, vm,...), and 
sax-event-stream portlets (be them XSLT based or generated). You are 
welcome to help here. ;-)

> It's possible to use XML & XSLT but not necessarily very easy to manage:
> - if each portlet outputs a specific XML dialect/namespace, it's very 
> difficult
>   to write an engine that transfoms all these dialects into the target 
> type
>   without a complete foreknowledge of the supported XML dialects.
> - if each portlet outputs a standard media independent, layout 
> oriented XML
>  dialect (FO anybody ?) you can actually post-process the output 
> correctly

We are aware of the problems that you are outlining. I think that FO is 
too oriented to positioning to be useful here. I would prefer a more 
abstract markup for the interface description, more like (parts of) 
XHTML, so that it can be styled to several final markups, including 
FO/pdf, Applets code, HTML (in several variants), text, Flash, ...

XSLT is very useful here as a transformation tool, but I agree that we 
should look for a standard high level set of namespaces to describe how 
output should look like.

>   but you need to carefully select your intermediate layout language 
> so that
>  it's not to complex/costly to transform.

Yes. I think that XHTML Basic (http://www.w3.org/TR/xhtml-basic/) could 
be a reasonable subset for portlet markup. It is expressive enough to 
represent "paragraph" markup in abstract form, and basic form handling 
capabilities. Complex display and styling can then be left to the PSML 
rendering mechanism and the style sheets applied. What do you think?

> Also Velcoity is definitely an "open" format since its specification is
> publicly available and anybody can write an alternate implementation.
> It's just not recognized by an industry committe yet. But then if it fits
> your need better, who cares ?
I'm very happy with Velocity. I'm just starting to hack it, and I think 
that Velocity with good tools is definitely going in the right 
direction. I prefer it over jsp, even with taglibs. YMMV.

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

View raw message