You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Adrian Petru Dimulescu <ad...@free.fr> on 2003/12/02 10:28:14 UTC
coping with XSLT
Hello,
this may not be exactly the best place to talk about general XSLT issues
but I'll do it anyway, you'll see in a second why.
I think Cocoon is one of the coolest pieces of software around and I
would like to use it more; I do see a problem though, which is more
connected to XSLT than to Cocoon itself.
How do you make Cocoon largely used say, in a software team, when the
main transfomation language is XSLT ? That ugly, difficult to write,
close to impossible to read, XML-based functional language? I honestly
find myself almost inconsciently trying to avoid XSLT. When I have an
XSLT task, I find something else to do, it's almost freudian....
The ability of a technology to become mainstream depends to a large
extent to its ease of use, perhaps even more than to its sheer power. Is
there a little secret you have, Cocoon people, when working with XSLT?
Some IDE, perhaps? I have tried, in order, emacs with slide but Lisp is
not my thing and having to learn it in order to customize the slightest
aspect of Emacs is not my idea of productivity; jEdit's XSLT plugin
helps a little but not much, it remains just an editor. Xmlspy is better
but I'm not much of a Windows person; In fact Xmlspy proves to me that
only having an advanced and expensive IDE is it possible to decently
program XSLT.
I found some projects on the net, Cduce and XDuce which are apparently
based on functional languages (ocaml) and could replace XSLT. Do you
know of any other alternatives to XSLT which might replace the
XsltTransformer ?
Thanks for your opinions,
Adrian.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: coping with XSLT
Posted by Oleg Dulin <du...@olegdulin.com>.
Adrian, Bertrandt:
I've been following this thread, and posted some notes on my blog at
http://www.olegdulin.com/index.php?p=53&c=1 .
In summary:
* If you really wanted to, you could write a custom transformer. To
make the job is easier, Cocoon lets you extend AbstractDOMTransformer so
you can manipulate on DOM, rather than SAX events. However, if you are
transforming XML form one form to another and you are not making complex
business logic decisions and you are not communicating with backend
system, then XSLT is the easiest, most documented approach there is to
XML transformations.
* XML is way too verbose for large complex XSLTs. I am hoping to see
Groovy included into BSF as a standard bundle. I've been following the
Groovy project and I think it can serve as an alternative way of writing
markup. Groovy let's you describe tree structures without the mess of
XML tags and there are ways to convert Groovy scripts into XML. So,
Groovy can potentially be used to write XSLTs.
Groovy: http://wiki.codehaus.org/groovy/FrontPage
Oleg
Adrian Petru Dimulescu wrote:
> Hello,
>
> this may not be exactly the best place to talk about general XSLT issues
> but I'll do it anyway, you'll see in a second why.
>
> I think Cocoon is one of the coolest pieces of software around and I
> would like to use it more; I do see a problem though, which is more
> connected to XSLT than to Cocoon itself.
>
> How do you make Cocoon largely used say, in a software team, when the
> main transfomation language is XSLT ? That ugly, difficult to write,
> close to impossible to read, XML-based functional language? I honestly
> find myself almost inconsciently trying to avoid XSLT. When I have an
> XSLT task, I find something else to do, it's almost freudian....
>
> The ability of a technology to become mainstream depends to a large
> extent to its ease of use, perhaps even more than to its sheer power. Is
> there a little secret you have, Cocoon people, when working with XSLT?
> Some IDE, perhaps? I have tried, in order, emacs with slide but Lisp is
> not my thing and having to learn it in order to customize the slightest
> aspect of Emacs is not my idea of productivity; jEdit's XSLT plugin
> helps a little but not much, it remains just an editor. Xmlspy is better
> but I'm not much of a Windows person; In fact Xmlspy proves to me that
> only having an advanced and expensive IDE is it possible to decently
> program XSLT.
>
> I found some projects on the net, Cduce and XDuce which are apparently
> based on functional languages (ocaml) and could replace XSLT. Do you
> know of any other alternatives to XSLT which might replace the
> XsltTransformer ?
>
> Thanks for your opinions,
> Adrian.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: coping with XSLT
Posted by Adrian Petru Dimulescu <ad...@free.fr>.
Hi Jorg,
Jorg Heymans wrote:
> well xslt is very procedural-alike.. If you've spent too much time on
> object oriented languages then it takes a while to get into this frame
> of mind - this can be a big pain (trust me, been there done that)
>
I have no particular problem with functional languages; in fact I'd like
to have more time to spend on ocaml kind of stuff. My problem is with
the general illisibility and difficulty of development with XSLT. While
I am surely no expert, I am not really a beginner in XSLT neither, I've
been using it for one or two years now from time to time...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: coping with XSLT
Posted by Jorg Heymans <jh...@domek.be>.
well xslt is very procedural-alike.. If you've spent too much time on
object oriented languages then it takes a while to get into this frame
of mind - this can be a big pain (trust me, been there done that)
i can recommend the oreilly book on xslt, the cookbook is too advanced
for beginners
Adrian Petru Dimulescu wrote:
> Hello,
>
> this may not be exactly the best place to talk about general XSLT issues
> but I'll do it anyway, you'll see in a second why.
>
> I think Cocoon is one of the coolest pieces of software around and I
> would like to use it more; I do see a problem though, which is more
> connected to XSLT than to Cocoon itself.
>
> How do you make Cocoon largely used say, in a software team, when the
> main transfomation language is XSLT ? That ugly, difficult to write,
> close to impossible to read, XML-based functional language? I honestly
> find myself almost inconsciently trying to avoid XSLT. When I have an
> XSLT task, I find something else to do, it's almost freudian....
>
> The ability of a technology to become mainstream depends to a large
> extent to its ease of use, perhaps even more than to its sheer power. Is
> there a little secret you have, Cocoon people, when working with XSLT?
> Some IDE, perhaps? I have tried, in order, emacs with slide but Lisp is
> not my thing and having to learn it in order to customize the slightest
> aspect of Emacs is not my idea of productivity; jEdit's XSLT plugin
> helps a little but not much, it remains just an editor. Xmlspy is better
> but I'm not much of a Windows person; In fact Xmlspy proves to me that
> only having an advanced and expensive IDE is it possible to decently
> program XSLT.
>
> I found some projects on the net, Cduce and XDuce which are apparently
> based on functional languages (ocaml) and could replace XSLT. Do you
> know of any other alternatives to XSLT which might replace the
> XsltTransformer ?
>
> Thanks for your opinions,
> Adrian.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: coping with XSLT
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Bertrand Delacretaz dijo:
> I have collected a few links to interesting stuff about this, see
> http://codeconsult.ch/bertrand/archives/000188.html
Hi Bertrand:
I read the link above. It is interesting the Linus opinion (as he also
said he does not know XML at all). I think Linux needs a discussion about
this topic with Mr. Michael Kay to him. :-D
I will write on the XSL list about this. I want to see what the XSL gurus
has to said. :-D
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: coping with XSLT
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Mardi, 2 déc 2003, à 14:40 Europe/Zurich, Joerg Heinicke a écrit :
> ...Blasphemy! ;-)
...your punishment will be to write 1043 XSLT templates using vi, on an
international keyboard where you need a three-finger cluster to write
an angle bracket ;-)
just kidding - there's no way everybody can agree on such things, but
I'd be very happy if Cocoon could provide options beside having to
write straight XSLT.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: coping with XSLT
Posted by Joerg Heinicke <jo...@gmx.de>.
On 02.12.2003 11:20, Bertrand Delacretaz wrote:
>> this may not be exactly the best place to talk about general XSLT issues
>> but I'll do it anyway, you'll see in a second why....
>
>
> It could be seen as off-topic but I think you make an interesting point:
> for many people working on publishing stuff, XSLT is an often
> unnecessary barrier to productivity.
>
>> ...How do you make Cocoon largely used say, in a software team, when the
>> main transfomation language is XSLT ? That ugly, difficult to write,
>> close to impossible to read, XML-based functional language? I honestly
>> find myself almost inconsciently trying to avoid XSLT. When I have an
>> XSLT task, I find something else to do, it's almost freudian....
>
>
> I've been doing a lot of XSLT in the last few years, and although it is
> a real pain to *write* I like its power a lot. Or rather, the power of
> XPath, which IMO is the key to being efficient with XSLT.
>
> I think there are two problems with XSLT:
> a) the XML-based syntax is a pain
>
> b) the tree-based processing model is foreign to a lot of people, who
> then try to write procedural code in XSLT, with lots of xsl:for-each and
> xsl:choice constructs. They might get there eventually but it's painful
> and slow, and often way too complicated.
>
> For me there's not much to do about b), someone willing to take
> advantage of XSLT has to learn the processing model and how to use it
> properly. But simpler scriptable transforms could be interesting as a
> starting point.
>
> About a), something could be done for sure: there are some attempts at
> simplified syntaxes for XSLT, which could make it a *lot* easier and
> more fun to work with.
>
> This has been discussed here previously, cannot find the references ATM
> but anyway nothing concrete has happened yet.
>
> I've been (wild-)thinking about combining Tim Larson's EffectTransformer
> (http://wiki.cocoondev.org/Wiki.jsp?page=TimLarson) with interpreted
> code to make it easier to write scriptable transforms but it's just a
> wild dream at this point.
>
> I have collected a few links to interesting stuff about this, see
> http://codeconsult.ch/bertrand/archives/000188.html
>
> -Bertrand
Blasphemy! ;-)
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Caching remote URL's
Posted by Matthew Langham <ml...@s-und-n.de>.
Hi Paul,
> time. From the limited documentation on this I think
> only local files are ever cached by using the timestamp, but
> URL's are not.
>
The caching of URLs depends on the Last-Modified timestamp. For this the
connection to the remote source needs to be opened.
If you need a different caching strategy (say dependent on some information
in the data or on a "per hour" basis) then you would need to adapt a
component like the FileGenerator to do this.
We have done this several times and it it the correct way to integrate to
the Cocoon caching strategy.
Let me know if this helps.
Matthew
--
Open Source Group { Consulting, Training, Projects }
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 mlangham@s-und-n.de - http://www.s-und-n.de
-----------------------------------------------------------------
Orixo, the XML business alliance: http://www.orixo.com
-----------------------------------------------------------------
=================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Caching remote URL's
Posted by Paul Bowler <pa...@www.aventix.co.uk>.
Our sitemap has a number of pipelines that get content from remote XML resources (news feeds etc) and, even with
avalon caching enabled, the remote connection is opened every time. From the limited documentation on this I think
only local files are ever cached by using the timestamp, but URL's are not.
I have cached the whole pipeline so that the final HTML is cached but this can be overridden by clicking the browser
refresh button. This is not enough for us as each remote connection slows the response times significantly for the
user.
I need a way to ALWAYS cache content from a remote URL for a specified period of time. Has anyone any idea how I can
do this?
Paul.
--
Paul Bowler
Aventix Associates Ltd
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: coping with XSLT
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Hi Bertrand:
As promised:
Here is the thread on XSL list:
http://www.biglist.com/lists/xsl-list/archives/200312/msg00071.html
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: coping with XSLT
Posted by Adrian Petru Dimulescu <ad...@free.fr>.
Here is Linus' preferred way:
>
> # This is an example
> myhost.com
> passwd Make1Up
> timeout 50
>
> What is the password?
>
> <passwd>Make1Up</passwd>
>
> <passwd>Make1Up </passwd>
>
> <passwd>Make1Up
> </passwd>
>
> -Rob
>
Well, while I personally do not agree with Linus on the whole anti-XML
issue, I think that if you use
# This is an example
myhost.com
passwd " Make1Up "
timeout 50
that particular problem is solved :)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: coping with XSLT
Posted by Robert Koberg <ro...@koberg.com>.
Adrian Petru Dimulescu wrote:
> Thank you, very informative links. I didn't know about XSLScript, it
> looks pretty interesting.
>
> I also read the discussions linked on your page. The pro-XML syntax
> arguments seem to be:
>
> * entites as cool including mechanisms -- like there is at least one
> scripting technology that doesn't allow simple includes!
> * you get for free the existing XML encodings mechanisms -- fair enough
> * you can transform stylesheets themselves -- I'll appreciate that when
> I'll need it ;)
> * in XSLT you can have lots of unstructured text, unlike, say, servlets
> where you have to quote them. What about Perl-like qq{} ?
> * the most interesting point that I didn't understand: without XML
> syntax you can't describe treelike structure because you don't have tags
> ?? I picked this argument here:
> http://www.biglist.com/lists/xsl-list/archives/200210/msg00411.html
Here is Linus' preferred way:
# This is an example
myhost.com
passwd Make1Up
timeout 50
What is the password?
<passwd>Make1Up</passwd>
<passwd>Make1Up </passwd>
<passwd>Make1Up
</passwd>
-Rob
>
> Regards,
> Adrian.
>
> Bertrand Delacretaz wrote:
>
>>
>> I have collected a few links to interesting stuff about this, see
>> http://codeconsult.ch/bertrand/archives/000188.html
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: coping with XSLT
Posted by Adrian Petru Dimulescu <ad...@free.fr>.
Yes, yes !!! :))
Geoff Howard wrote:
> Just quickly looking at XSLScript it looks interesting - if it's
> compatible with our license it may be worth trying to stick some
> samples in Cocoon's cvs?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: coping with XSLT
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Mardi, 2 déc 2003, à 14:45 Europe/Zurich, Geoff Howard a écrit :
> Bertrand Delacretaz wrote:
>
>> Le Mardi, 2 déc 2003, à 14:26 Europe/Zurich, Geoff Howard a écrit :
>>> ...Just quickly looking at XSLScript it looks interesting - if it's
>>> compatible with our license it may be worth trying to stick some
>>> samples in Cocoon's cvs?
>> why not - in the scratchpad then?
>
> Sure - I guess. I can't find any license at all except the statement
> that it is 100% free. This leaves redistribution an open question it
> seems to me. It may be worth contacting the author to confirm/get
> some kind of redist license to include in LEGAL/.
go for it!
> Also, he's apparently a ZOPE convert but maybe we can turn him to the
> dark side...
Now this becomes interesting in terms of potential religious debates:
angle bracketers, structured texters, Zopers and Cocoonistas all
together ;-)
- Bertrand, who likes this thread but needs to go back to seriously
less fun stuff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: coping with XSLT
Posted by Geoff Howard <co...@leverageweb.com>.
Bertrand Delacretaz wrote:
>
> Le Mardi, 2 déc 2003, à 14:26 Europe/Zurich, Geoff Howard a écrit :
>
>> ...Just quickly looking at XSLScript it looks interesting - if it's
>> compatible with our license it may be worth trying to stick some
>> samples in Cocoon's cvs?
>
>
> why not - in the scratchpad then?
Sure - I guess. I can't find any license at all except the statement
that it is 100% free. This leaves redistribution an open question it
seems to me. It may be worth contacting the author to confirm/get some
kind of redist license to include in LEGAL/.
Also, he's apparently a ZOPE convert but maybe we can turn him to the
dark side...
Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: coping with XSLT
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Mardi, 2 déc 2003, à 14:26 Europe/Zurich, Geoff Howard a écrit :
> ...Just quickly looking at XSLScript it looks interesting - if it's
> compatible with our license it may be worth trying to stick some
> samples in Cocoon's cvs?
why not - in the scratchpad then?
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: coping with XSLT
Posted by Geoff Howard <co...@leverageweb.com>.
Bertrand Delacretaz wrote:
> Le Mardi, 2 déc 2003, à 12:30 Europe/Zurich, Adrian Petru Dimulescu a
> écrit :
>
>> ...* the most interesting point that I didn't understand: without XML
>> syntax you can't describe treelike structure because you don't have
>> tags ?? I picked this argument here:
>> http://www.biglist.com/lists/xsl-list/archives/200210/msg00411.html
>
>
> I think what he means is that to describe literal output elements (for
> templates) you need angle brackets.
>
> That's fine with me, XSLScript is not completely devoid of angle
> brackets either. For me what's a pain is having to write *every*
> statement in XML.
Just quickly looking at XSLScript it looks interesting - if it's
compatible with our license it may be worth trying to stick some samples
in Cocoon's cvs?
Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: coping with XSLT
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Mardi, 2 déc 2003, à 12:30 Europe/Zurich, Adrian Petru Dimulescu a
écrit :
> ...* the most interesting point that I didn't understand: without XML
> syntax you can't describe treelike structure because you don't have
> tags ?? I picked this argument here:
> http://www.biglist.com/lists/xsl-list/archives/200210/msg00411.html
I think what he means is that to describe literal output elements (for
templates) you need angle brackets.
That's fine with me, XSLScript is not completely devoid of angle
brackets either. For me what's a pain is having to write *every*
statement in XML.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: coping with XSLT
Posted by Adrian Petru Dimulescu <ad...@free.fr>.
Thank you, very informative links. I didn't know about XSLScript, it
looks pretty interesting.
I also read the discussions linked on your page. The pro-XML syntax
arguments seem to be:
* entites as cool including mechanisms -- like there is at least one
scripting technology that doesn't allow simple includes!
* you get for free the existing XML encodings mechanisms -- fair enough
* you can transform stylesheets themselves -- I'll appreciate that when
I'll need it ;)
* in XSLT you can have lots of unstructured text, unlike, say, servlets
where you have to quote them. What about Perl-like qq{} ?
* the most interesting point that I didn't understand: without XML
syntax you can't describe treelike structure because you don't have tags
?? I picked this argument here:
http://www.biglist.com/lists/xsl-list/archives/200210/msg00411.html
Regards,
Adrian.
Bertrand Delacretaz wrote:
>
> I have collected a few links to interesting stuff about this, see
> http://codeconsult.ch/bertrand/archives/000188.html
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: coping with XSLT
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Mardi, 2 déc 2003, à 15:03 Europe/Zurich, Timothy Larson a écrit :
> --- Bertrand Delacretaz <bd...@apache.org> wrote:
>> I've been (wild-)thinking about combining Tim Larson's
>> EffectTransformer (http://wiki.cocoondev.org/Wiki.jsp?page=TimLarson)
>> with interpreted code to make it easier to write scriptable transforms
>> but it's just a wild dream at this point.
>
> Intriguing idea. Let me know if you make any progress on this (ideas
> or
> code). I have no time to experiment with it right now, but this looks
> like an interesting direction. Eventually the EffectTransformer will
> be
> used for other structured data besides XML, and this scripting idea may
> be just the ticket.
The basic idea (again, not tested at all) would be to have your
EffectTransformer call pieces of scriptable code, instead of inner
classes (IIRC) to handle the various elements. This should be doable
using the BSF (Bean Scripting Framework) which is present in the bsf
block.
I also have no time to look at this now, but it might be worth trying.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: coping with XSLT
Posted by Timothy Larson <ti...@yahoo.com>.
--- Bertrand Delacretaz <bd...@apache.org> wrote:
> I've been (wild-)thinking about combining Tim Larson's
> EffectTransformer (http://wiki.cocoondev.org/Wiki.jsp?page=TimLarson)
> with interpreted code to make it easier to write scriptable transforms
> but it's just a wild dream at this point.
Intriguing idea. Let me know if you make any progress on this (ideas or
code). I have no time to experiment with it right now, but this looks
like an interesting direction. Eventually the EffectTransformer will be
used for other structured data besides XML, and this scripting idea may
be just the ticket.
--Tim Larson
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: coping with XSLT
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Mardi, 2 déc 2003, à 10:28 Europe/Zurich, Adrian Petru Dimulescu a
écrit :
> this may not be exactly the best place to talk about general XSLT
> issues
> but I'll do it anyway, you'll see in a second why....
It could be seen as off-topic but I think you make an interesting
point: for many people working on publishing stuff, XSLT is an often
unnecessary barrier to productivity.
> ...How do you make Cocoon largely used say, in a software team, when
> the
> main transfomation language is XSLT ? That ugly, difficult to write,
> close to impossible to read, XML-based functional language? I honestly
> find myself almost inconsciently trying to avoid XSLT. When I have an
> XSLT task, I find something else to do, it's almost freudian....
I've been doing a lot of XSLT in the last few years, and although it is
a real pain to *write* I like its power a lot. Or rather, the power of
XPath, which IMO is the key to being efficient with XSLT.
I think there are two problems with XSLT:
a) the XML-based syntax is a pain
b) the tree-based processing model is foreign to a lot of people, who
then try to write procedural code in XSLT, with lots of xsl:for-each
and xsl:choice constructs. They might get there eventually but it's
painful and slow, and often way too complicated.
For me there's not much to do about b), someone willing to take
advantage of XSLT has to learn the processing model and how to use it
properly. But simpler scriptable transforms could be interesting as a
starting point.
About a), something could be done for sure: there are some attempts at
simplified syntaxes for XSLT, which could make it a *lot* easier and
more fun to work with.
This has been discussed here previously, cannot find the references ATM
but anyway nothing concrete has happened yet.
I've been (wild-)thinking about combining Tim Larson's
EffectTransformer (http://wiki.cocoondev.org/Wiki.jsp?page=TimLarson)
with interpreted code to make it easier to write scriptable transforms
but it's just a wild dream at this point.
I have collected a few links to interesting stuff about this, see
http://codeconsult.ch/bertrand/archives/000188.html
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org