You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sven Kuenzler <sv...@tzi.de> on 2001/02/27 12:01:27 UTC
[ot] XSLT pain in the *?
Hi,
recently, there were several posts stating that they, well, don't like XSLT
too much.
I personally do like this language, esp. for dealing with semi-structured
data like formated text.
However, I am neither a web artist nor a layouter, so it won't be my job to
write *style*sheets. That's why I'd like to ask for options, article
references, ... pointing out the main difficulties that people may have
dealing with XSLT.
Thanks in advance,
Sven.....
WebWork (was: Re: [ot] XSLT pain in the *?)
Posted by Sven Kuenzler <sv...@gmx.net>.
> To be clarified it is mostly in the context of writing logicsheets. XSP
is
> a cool technology, however trying to write an XSP LogicSheet is a pain in
the
> hind end because of the XSLT semantics.
OK. As I stated in another post, this was not my concern when asking for
XSLT challenges.
But as XSLT on the logic side seems to be considered a problem, I'd like to
take the opportunity to point out to another approach we've been testing
independently from Cocoon. It's an open source project called "Webwork"
(http://sourceforge.net/projects/webwork/), originating from the JBoss
community.
<disclaimer>
I am just starting to understand the problem space called "web apps". The
action pattern used in Webwork is something new to me. However, the Webwork
people often compare their work to Struts. Thus, it's possible that I'm
trying to sell really "old news" to you.
</disclaimer>
Besides other things, WebWork provides a contract between Java Beans and
JSP. For WebWork, "Actions" are JavaBeans with an execute() method. This
execute() is used to populate the beans' properties. Such an Action has
different views associated with it. These are either Actions themselves or
JSPs. Those JSPs are able to access its Actions' properties via the WebWork
tag lib. Additionally, the JSP can instantiate more Action Beans and access
their properties.
<disclaimer>
The Webwork taglib can do more things which esp. you Cocoon2-guys won't like
(include other JSPs, eval boolean expressions, ...). When looking at the
WebWork tutorial, focus on the tags <ww:bean>, <ww:property> and
<ww:iterator>. They provide the functionality I am talking about.
</disclaimer>
My question is whether such a taglib would be a useful thing to have for
Cocoon2. It could serve as contract between logic and content, sparing the
"logic department" from XSL logicsheets. What would be the limitations of
such an approach?
Sven....
WebWork (was: Re: [ot] XSLT pain in the *?)
Posted by Sven Kuenzler <sv...@tzi.de>.
Addenum: The webwork tutorial can be accessed here:
http://viva.informatik.uni-bremen.de/server-docs/webwork/tutorial/index.html
Sven ....
----- Original Message -----
From: ""Sven Kuenzler"" <sv...@tzi.de>
Newsgroups: autopost.cocoon.dev
Sent: Tuesday, February 27, 2001 5:27 PM
Subject: Re: [ot] XSLT pain in the *?
> > To be clarified it is mostly in the context of writing logicsheets. XSP
> is
> > a cool technology, however trying to write an XSP LogicSheet is a pain
in
> the
> > hind end because of the XSLT semantics.
>
> OK. As I stated in another post, this was not my concern when asking for
> XSLT challenges.
>
> But as XSLT on the logic side seems to be considered a problem, I'd like
to
> take the opportunity to point out to another approach we've been testing
> independently from Cocoon. It's an open source project called "Webwork"
> (http://sourceforge.net/projects/webwork/), originating from the JBoss
> community.
>
> <disclaimer>
> I am just starting to understand the problem space called "web apps". The
> action pattern used in Webwork is something new to me. However, the
Webwork
> people often compare their work to Struts. Thus, it's possible that I'm
> trying to sell really "old news" to you.
> </disclaimer>
>
> Besides other things, WebWork provides a contract between Java Beans and
> JSP. For WebWork, "Actions" are JavaBeans with an execute() method. This
> execute() is used to populate the beans' properties. Such an Action has
> different views associated with it. These are either Actions themselves or
> JSPs. Those JSPs are able to access its Actions' properties via the
WebWork
> tag lib. Additionally, the JSP can instantiate more Action Beans and
access
> their properties.
>
> <disclaimer>
> The Webwork taglib can do more things which esp. you Cocoon2-guys won't
like
> (include other JSPs, eval boolean expressions, ...). When looking at the
> WebWork tutorial, focus on the tags <ww:bean>, <ww:property> and
> <ww:iterator>. They provide the functionality I am talking about.
> </disclaimer>
>
> My question is whether such a taglib would be a useful thing to have for
> Cocoon2. It could serve as contract between logic and content, sparing the
> "logic department" from XSL logicsheets. What would be the limitations of
> such an approach?
>
> Sven....
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
Re: [ot] XSLT pain in the *?
Posted by Sven Kuenzler <sv...@tzi.de>.
> To be clarified it is mostly in the context of writing logicsheets. XSP
is
> a cool technology, however trying to write an XSP LogicSheet is a pain in
the
> hind end because of the XSLT semantics.
OK. As I stated in another post, this was not my concern when asking for
XSLT challenges.
But as XSLT on the logic side seems to be considered a problem, I'd like to
take the opportunity to point out to another approach we've been testing
independently from Cocoon. It's an open source project called "Webwork"
(http://sourceforge.net/projects/webwork/), originating from the JBoss
community.
<disclaimer>
I am just starting to understand the problem space called "web apps". The
action pattern used in Webwork is something new to me. However, the Webwork
people often compare their work to Struts. Thus, it's possible that I'm
trying to sell really "old news" to you.
</disclaimer>
Besides other things, WebWork provides a contract between Java Beans and
JSP. For WebWork, "Actions" are JavaBeans with an execute() method. This
execute() is used to populate the beans' properties. Such an Action has
different views associated with it. These are either Actions themselves or
JSPs. Those JSPs are able to access its Actions' properties via the WebWork
tag lib. Additionally, the JSP can instantiate more Action Beans and access
their properties.
<disclaimer>
The Webwork taglib can do more things which esp. you Cocoon2-guys won't like
(include other JSPs, eval boolean expressions, ...). When looking at the
WebWork tutorial, focus on the tags <ww:bean>, <ww:property> and
<ww:iterator>. They provide the functionality I am talking about.
</disclaimer>
My question is whether such a taglib would be a useful thing to have for
Cocoon2. It could serve as contract between logic and content, sparing the
"logic department" from XSL logicsheets. What would be the limitations of
such an approach?
Sven....
Re: [ot] XSLT pain in the *?
Posted by Berin Loritsch <bl...@apache.org>.
Sven Kuenzler wrote:
>
> Hi,
>
> recently, there were several posts stating that they, well, don't like XSLT
> too much.
To be clarified it is mostly in the context of writing logicsheets. XSP is
a cool technology, however trying to write an XSP LogicSheet is a pain in the
hind end because of the XSLT semantics.
XSLT is *EXCELLENT* for writing transformations on XML--but it sucks for trying
to produce a Text file (AKA a Java source file). There are a number of ugly
things that you have to do, and it is hard to follow the logic of a Logicsheet
when written as XSL.
The reason? You have two separate concerns meshed into one. One concern is
the Java code, and how it will look when fully assembled. The other concern
is the XSLT markup. If you have ever tried to follow a Logicsheet like the
xsp.xsl, esql.xsl, or sitemap.xsl you will know first hand what I am talking
about.
That aside, XSLT for transforming XML into HTML or other markup based language
ROCKS.
>
> I personally do like this language, esp. for dealing with semi-structured
> data like formated text.
>
> However, I am neither a web artist nor a layouter, so it won't be my job to
> write *style*sheets. That's why I'd like to ask for options, article
> references, ... pointing out the main difficulties that people may have
> dealing with XSLT.
>
> Thanks in advance,
> Sven.....
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [ot] XSLT pain in the *?
Posted by French Touch <ma...@frenchtouch.net>.
Hi,
XSLT is very powerful but in real world production the problem I faced is no
one want to write stylesheets:
- Developers says this is too restrictive, not a real langage and say it's
not their job.
Sometimes they agree to write an XSP Logicsheet but they are now really
angry about writing *a lot* of text (<,>) instead of just writing beautiful
OO Servlets (yup i know they don't have exactly the same role but..).
- Graphists says they don't want to open an editor, but want to stay in
Phtotoshop or Dreamweaver.
At that point we have decided to drop Cocoon because of this XSL/T problems,
I personaly thinks XSLT is really useful when you have no other choice to
use it (transform a document in an other) but not useful to create content
until Macromedia or someone else doesn't make an XSL editor for graphist.
- martin
-----Original Message-----
From: Sven Kuenzler [mailto:svenk@tzi.de]
Sent: mardi 27 février 2001 12:01
To: cocoon-dev@xml.apache.org
Subject: [ot] XSLT pain in the *?
Hi,
recently, there were several posts stating that they, well, don't like XSLT
too much.
I personally do like this language, esp. for dealing with semi-structured
data like formated text.
However, I am neither a web artist nor a layouter, so it won't be my job to
write *style*sheets. That's why I'd like to ask for options, article
references, ... pointing out the main difficulties that people may have
dealing with XSLT.
Thanks in advance,
Sven.....
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [ot] XSLT pain in the *?
Posted by Berin Loritsch <bl...@apache.org>.
Martin Rogard wrote:
>
> Hi,
>
> XSLT is very powerful but in real world production the problem I faced is no
> one want to write stylesheets:
> - Developers says this is too restrictive, not a real langage and say it's
> not their job.
> Sometimes they agree to write an XSP Logicsheet but they are now really
> angry about writing *a lot* of text (<,>) instead of just writing beautiful
> OO Servlets (yup i know they don't have exactly the same role but..).
> - Graphists says they don't want to open an editor, but want to stay in
> Phtotoshop or Dreamweaver.
There is a method to take the HTML rendered and quickly convert it to a
stylesheet with a couple of include points. The HTML just needs to be
well formed XML (XHTML) which those tools can easily produce.
>
> At that point we have decided to drop Cocoon because of this XSL/T problems,
> I personaly thinks XSLT is really useful when you have no other choice to
> use it (transform a document in an other) but not useful to create content
> until Macromedia or someone else doesn't make an XSL editor for graphist.
>
> - martin
>
> -----Original Message-----
> From: Sven Kuenzler [mailto:svenk@tzi.de]
> Sent: mardi 27 février 2001 12:01
> To: cocoon-dev@xml.apache.org
> Subject: [ot] XSLT pain in the *?
>
> Hi,
>
> recently, there were several posts stating that they, well, don't like XSLT
> too much.
>
> I personally do like this language, esp. for dealing with semi-structured
> data like formated text.
>
> However, I am neither a web artist nor a layouter, so it won't be my job to
> write *style*sheets. That's why I'd like to ask for options, article
> references, ... pointing out the main difficulties that people may have
> dealing with XSLT.
>
> Thanks in advance,
> Sven.....
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [ot] XSLT pain in the *?
Posted by Marcelo Ochoa <mo...@ieee.org>.
>>>>>>>>>>>>>>>>>> Mensaje original <<<<<<<<<<<<<<<<<<
El 27/2/01, 10.58.42, "Sven Kuenzler" <sv...@tzi.de> escribió sobre el tema
Re: [ot] XSLT pain in the *?:
> Hi Martin,
> > XSLT is very powerful but in real world production the problem I faced is
> no
> > one want to write stylesheets:
> In your answer, you are adressing two very different problems, I think.
They
> happen to look alike, because Cocoon is utilizing XSLT in both areas.
> > - Developers says this is too restrictive, not a real langage and say
it's
> > not their job.
> > Sometimes they agree to write an XSP Logicsheet but they are now really
> > angry about writing *a lot* of text (<,>) instead of just writing
> beautiful
> > OO Servlets (yup i know they don't have exactly the same role but..).
> I understood this is an issue that is accepted in the Cocoon community.
In
> order to reduce the amount of XML content a developer in the "logic
> department" has to write, there were plans to create a special language,
> named Silly.
> > - Graphists says they don't want to open an editor, but want to stay in
> > Phtotoshop or Dreamweaver.
> >
> > At that point we have decided to drop Cocoon because of this XSL/T
> problems,
> > I personaly thinks XSLT is really useful when you have no other choice to
> > use it (transform a document in an other) but not useful to create
content
> > until Macromedia or someone else doesn't make an XSL editor for graphist.
> This issue was my original concern: Does anybody know whether there are
> (Semi-)WYSIWYG-XSLT tools in development? What are the key drawbacks of
XSLT
> when your task is
> - to layout a web site?
> - to make page "look nice"?
Look at: http://www.percussion.com/xmlzone/technology.htm
We are using Dreamweaver for designing our web pages and convert it to
XML/XSL with Xsplit.
Xsplit has general tags to be include into the HTML by the designer
which will match with the XML generated by developer.
There are two different philosophy at this point:
- Once, design the XML and DTD by the content provider (developer)
and pass this information to the designer to work with Xsplit. Then,
validates the design with the user.
- Or, Makes the complete design by the designer and makes the XML
examples and DTD which the layout needs. Then, translate this
requirements to the content developer for making the program (XSP or DB
Prism's stored procedures) which generates the expected XML output.
> Sven....
Best regards, Marcelo
--
Do you know DB Prism look @ http://www.plenix.com/dbprism/
More info?
- Chapter 21 Profesional XML Databases at Wrox Press
(http://www.wrox.com/)
- Chapter 8 Oracle & Open Source by O'Reilly (http://www.oreilly.com/)
Marcelo F. Ochoa
Fac. de Cs. Exactas - UNICEN
Paraje Arroyo Seco - Campus Univ.
(7000) Tandil - AR
Tel.: +54-2293-444430
Fax: +54-2293-444431
Re: [ot] XSLT pain in the *?
Posted by Matt Sergeant <ma...@sergeant.org>.
On Tue, 27 Feb 2001, Sven Kuenzler wrote:
> This issue was my original concern: Does anybody know whether there are
> (Semi-)WYSIWYG-XSLT tools in development? What are the key drawbacks of XSLT
> when your task is
> - to layout a web site?
> - to make page "look nice"?
The best looking XSLT editor I've seen from a WYSIWYG point of view is
Whitehill's composer. I can almost see them being bought by Microsoft any
day now :-)
--
<Matt/>
/|| ** Founder and CTO ** ** http://axkit.com/ **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** mod_perl news and resources: http://take23.org **
\\//
//\\
// \\
Re: [ot] XSLT pain in the *?
Posted by Sven Kuenzler <sv...@tzi.de>.
Hi Martin,
> XSLT is very powerful but in real world production the problem I faced is
no
> one want to write stylesheets:
In your answer, you are adressing two very different problems, I think. They
happen to look alike, because Cocoon is utilizing XSLT in both areas.
> - Developers says this is too restrictive, not a real langage and say it's
> not their job.
> Sometimes they agree to write an XSP Logicsheet but they are now really
> angry about writing *a lot* of text (<,>) instead of just writing
beautiful
> OO Servlets (yup i know they don't have exactly the same role but..).
I understood this is an issue that is accepted in the Cocoon community. In
order to reduce the amount of XML content a developer in the "logic
department" has to write, there were plans to create a special language,
named Silly.
> - Graphists says they don't want to open an editor, but want to stay in
> Phtotoshop or Dreamweaver.
>
> At that point we have decided to drop Cocoon because of this XSL/T
problems,
> I personaly thinks XSLT is really useful when you have no other choice to
> use it (transform a document in an other) but not useful to create content
> until Macromedia or someone else doesn't make an XSL editor for graphist.
This issue was my original concern: Does anybody know whether there are
(Semi-)WYSIWYG-XSLT tools in development? What are the key drawbacks of XSLT
when your task is
- to layout a web site?
- to make page "look nice"?
Sven....
RE: [ot] XSLT pain in the *?
Posted by Martin Rogard <ma...@vibes.net>.
Hi,
XSLT is very powerful but in real world production the problem I faced is no
one want to write stylesheets:
- Developers says this is too restrictive, not a real langage and say it's
not their job.
Sometimes they agree to write an XSP Logicsheet but they are now really
angry about writing *a lot* of text (<,>) instead of just writing beautiful
OO Servlets (yup i know they don't have exactly the same role but..).
- Graphists says they don't want to open an editor, but want to stay in
Phtotoshop or Dreamweaver.
At that point we have decided to drop Cocoon because of this XSL/T problems,
I personaly thinks XSLT is really useful when you have no other choice to
use it (transform a document in an other) but not useful to create content
until Macromedia or someone else doesn't make an XSL editor for graphist.
- martin
-----Original Message-----
From: Sven Kuenzler [mailto:svenk@tzi.de]
Sent: mardi 27 février 2001 12:01
To: cocoon-dev@xml.apache.org
Subject: [ot] XSLT pain in the *?
Hi,
recently, there were several posts stating that they, well, don't like XSLT
too much.
I personally do like this language, esp. for dealing with semi-structured
data like formated text.
However, I am neither a web artist nor a layouter, so it won't be my job to
write *style*sheets. That's why I'd like to ask for options, article
references, ... pointing out the main difficulties that people may have
dealing with XSLT.
Thanks in advance,
Sven.....
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org