Re: Vote: to unify, or not to unify - results

[JD Daniels <jd...@datatrio.com>]

Nacho Jimenez wrote:

>
>> Other than the CPA, we would show other options. For example, if a 
>> newbie
>> were reading up on JXTemplates, rather than saying that you can use 
>> Jexl or
>> JXPath, we would choose our CPA (for example, JXPath), but have a 
>> link to a
>> homologous page that explains the same things, but for Jexl. This would
>> reduce one more variable, and thus one more possible source of delay or
>> confusion to a newbie. So new users will be able to get up and 
>> running much
>> faster, and once they have more experience, will be able to go over the
>> alternative approaches.
>>  
>>
>    This is just an example of what I think we should avoid... The 
> average user does not give a shiling about JXTemplates, JXPath, JEXL 
> or whatever load of letters we decide to acronymize today.
>
>    The user wants to know how can he set up his ubercool website 
> accessing XML documents and SQL data with the mimimum of fuss, and 
> hence, the document he is looking for is a step by step guide to do that.
>
>    In one of those steps, he's shown how to get a needed parameter  
> from the context, using our recommended method (JXTemplateTransformer, 
> through a JXPath expression). There, on a side note, you can have an 
> overview on what JXTemplateTranformer is, why is it our preferred 
> method to access the parameter he needs and wich alternatives he could 
> use, and pointers to the wikiPages of the related tecnologies for a 
> deeper study if he needs it.
>
I have to disagree a bit here....

When I started with cocoon, I wanted to load a simple result set from a 
database into an xml file and transform it. simple enough. I wanted to 
use jxtemplate .. it was what everyone suggested. but no one it seemed, 
could tell me why both ${var} and #{var} both worked.. and in fact in my 
use case, one didn't. So I was faced with learning 2 expression 
syntaxes, with a deadline facing me. This was a week long agony for me 
and I ended up using xsp because there was a n00b tutorial up and I 
could make it work. Now, most of my stuff is based on xsp for the 
datbase queries. I have moved into other advancements since then like 
woody and flow, but now I have to look at refactoring from xsp if I want 
to keep up with cocoon develpment. ( Don't get me wrong here, basically 
xsp exists to use esql in my mind.. the rumblings of change there are a 
good idea )

JD


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: Vote: to unify, or not to unify - results

[go...@osmosis.gr]

On Tue, 4 May 2004, JD Daniels wrote:

> Nacho Jimenez wrote:
> 
> >
> >> Other than the CPA, we would show other options. For example, if a 
> >> newbie
> >> were reading up on JXTemplates, rather than saying that you can use 
> >> Jexl or
> >> JXPath, we would choose our CPA (for example, JXPath), but have a 
> >> link to a
> >> homologous page that explains the same things, but for Jexl. This would
> >> reduce one more variable, and thus one more possible source of delay or
> >> confusion to a newbie. So new users will be able to get up and 
> >> running much
> >> faster, and once they have more experience, will be able to go over the
> >> alternative approaches.
> >>  
> >>
> >    This is just an example of what I think we should avoid... The 
> > average user does not give a shiling about JXTemplates, JXPath, JEXL 
> > or whatever load of letters we decide to acronymize today.
> >
> >    The user wants to know how can he set up his ubercool website 
> > accessing XML documents and SQL data with the mimimum of fuss, and 
> > hence, the document he is looking for is a step by step guide to do that.
> >
> >    In one of those steps, he's shown how to get a needed parameter  
> > from the context, using our recommended method (JXTemplateTransformer, 
> > through a JXPath expression). There, on a side note, you can have an 
> > overview on what JXTemplateTranformer is, why is it our preferred 
> > method to access the parameter he needs and wich alternatives he could 
> > use, and pointers to the wikiPages of the related tecnologies for a 
> > deeper study if he needs it.
> >
> I have to disagree a bit here....
> 
> When I started with cocoon, I wanted to load a simple result set from a 
> database into an xml file and transform it. simple enough. I wanted to 
> use jxtemplate .. it was what everyone suggested. but no one it seemed, 
> could tell me why both ${var} and #{var} both worked.. and in fact in my 
> use case, one didn't. So I was faced with learning 2 expression 
> syntaxes, with a deadline facing me. This was a week long agony for me 
> and I ended up using xsp because there was a n00b tutorial up and I 
> could make it work. Now, most of my stuff is based on xsp for the 
> datbase queries. I have moved into other advancements since then like 
> woody and flow, but now I have to look at refactoring from xsp if I want 
> to keep up with cocoon develpment. ( Don't get me wrong here, basically 
> xsp exists to use esql in my mind.. the rumblings of change there are a 
> good idea )
> 
> JD
let me put here  my two cents

for select queries xsp/esql is great and the perfect _in_most_cases_ way
in most cases we create pipelines that make select queries and return the 
content in xml format. then we call this pipelines in most cases internal.


--stavros


> 
> 
> ---------------------------------------------------------------------
> 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