"Kevin A. Burton" wrote:
>
> So just another comment. Look at how I implemented content rendering
> for RSS. I am not using XSL to do this. What I am doing is using an
> XML Schema and then using Castor (castor.exolab.org) do generate an API
> for manipulating the document:
>
> You can do Rss.marshal( Reader) which will bring the object into memory
> and allow you to manipulate it like a bean:
>
> Channel[] Rss.getChannel()
> Item[] Rss.getItem()
>
Yes, castor is cool once you know how to generate the APIs (look at
build\gen_apis.sh) :/
> If you were to write a schema for scripting new (see the example ones I
> have in CVS) then you could generate an API and have a renderer in 15
> minutes.
>
> The really cool thing about doing this is that you can add Items
> progmatically from within JetSpeed. Why? Because I want JetSpeed to
> produce content (and publish an OCS stream) as well as consume it. With
> XSL you can only render content... you can't produce it.
>
> I know it isn't as "hip" or "new" as XSL but there are plenty of other
> places within JetSpeed to put it.
>
Well I don't completely agree with the above statements:
- you can produce content in an XSLT or XSLT-like transformation, this is what
XSP does
in Cocoon and it's the goal of the E-XSLT proposal.
- the advantage of a XSL approach is that it makes it easier (or even just
possible) for Web designers (and not programmers) to create the renderer. A
castor generated API + ECS is a good way for programmers to generate renderers.
XML documents + XSL transformations allow
web desginers to do the same job.
I think JetSpeed should allow both kind of approach to be used, allowing either
programmatic rendition with ECS or XSL rendition (through cocoon most likely) at
3
different levels:
- Portlet
- PortletController
- Home (or equivalent servlet)
The portlet rendition should be skin neutral and context neutral
The portletController rendition should be skin dependent and context dependent
The Home rendition should be navigation dependent and skin dependent
The actual method used (ECS or XSL) should be decided based on the skill mix of
the team
designing the portal. But the interface between each rendition level should
defined either by the API (ECS programmatic model) or the Xschema/DTD (XSL
rendition model)
For my internal pilot, I chose a full Cocoon/XSL approach (and will suffer the
performance hit) because I can delegate some portlet rendition tasks to
designers and and generate
a WML portal.
Comments ?
--
Rapha�l Luta - [EMAIL PROTECTED]
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
