You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by David Leangen <dl...@canada.com> on 2004/05/04 09:56:29 UTC
Vote: to unify, or not to unify (Was "RE: Business Logic in Cocoon Applications?")
[I don't want to barge in on things here or step on anybody's toes. My
intention is only to get some direction so I can help contribute to the
Cocoon documentation. Although I am a relative newbie any my Cocoon skills
are 1/1000th of the vets lingering around on this list, I think that's
exactly what qualifies me to help contribute to the user documentation.]
The first thing that we need to decide on is: do we aim for a unified
approach, or should the platform continue to be a testing ground? Or rather,
what is the "face" of Cocoon that we want to show to its users?
There are good arguments for either case, but until we decide on which path
to take, it is difficult to get started with any useful tutorial or other
that explains how to program biz logic in Cocoon.
In my view, regardless of what's happening internally, the user doc should
show a simple and unified approach to using Cocoon. Otherwise, it's just too
long and difficult to get a real project up and running, especially for the
non-seasoned developer. Anything else can (and should) be reserved for more
advanced users.
If there's anything I learned in the commercial world, it's that the message
must be simple and easily understood, even if it's not perfect from a
theoretical standpoint. I therefore strongly suggest orienting user
documentation with simplicity and user centricity in mind.
However, we still need to reach consensus on what such a unified
approach(es) should be.
I would like to take a poll (probably the first of many):
***********************************************************
[ ] A. I think that we should show users the "best" way
to get up and running with Cocoon.
[ ] B. I think that we should show users all the options
possible and let them decide the best approach.
[ ] C. Yeah, whatever. Either way is good for me.
Peace, man!
Poll results so far:
A. - 1
B. - 0
C. - 0
***********************************************************
---------------------------------------------------------------------
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 (Was "RE: Business Logic in Cocoon
Applications?")
Posted by Nacho Jimenez <na...@ya.com>.
Tim Larson wrote:
>>David Leangen wrote:
>>[X ] A. I think that we should show users the "best" way
>> to get up and running with Cocoon.
>>
>>[X ] B. I think that we should show users all the options
>> possible and let them decide the best approach.
>>
>>[ ] C. Yeah, whatever. Either way is good for me.
>> Peace, man!
>>
>>
>
>Have a track that shows the "best" way(s) depending on the
>context where they are used, but also link to docs for all
>the other options. This way we give clear guidance while
>also documenting everything we have. Remember that a new
>context could develop where what is "best" changes to one
>of the other options.
>
>
If you really want cocoon to catch up on usage numbers, then you
***have*** to keep it simple for begginers, and simple means not a
myriad of options: Right now, starting with our beloved framework is a
a big headache .
Both the wiki and the userdocs are tecnology oriented, not user
oriented. It's quite normal, because they are written by developes for
developers, but we have to try an place a red carpet on the door so
unexperienced java and web developers, and people who just don't have
the time can learn what a great technology this is.
Some people, those who need it or simply like tinkering arround,
will want to keep on learning new tricks and ways once they understand
the basics, and they should have the docs and samples available, just as
they are now.. but that would be a second phase of the learning curve..
Right now is so steep I think we should break it in two parts.
I just don't want cocoon to suffer the betamax curse. I owned a Sony
Betamax, an Amiga, an Apple.. maybe It's just that I want to be on the
winners side for once. :)
---------------------------------------------------------------------
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 (Was "RE: Business Logic in Cocoon Applications?")
Posted by Tim Larson <ti...@keow.org>.
> David Leangen wrote:
> [X ] A. I think that we should show users the "best" way
> to get up and running with Cocoon.
>
> [X ] B. I think that we should show users all the options
> possible and let them decide the best approach.
>
> [ ] C. Yeah, whatever. Either way is good for me.
> Peace, man!
Have a track that shows the "best" way(s) depending on the
context where they are used, but also link to docs for all
the other options. This way we give clear guidance while
also documenting everything we have. Remember that a new
context could develop where what is "best" changes to one
of the other options.
--Tim Larson
---------------------------------------------------------------------
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 (Was "RE: Business Logic in Cocoon
Applications?")
Posted by Ugo Cei <u....@cbim.it>.
David Leangen wrote:
> [ ] A. I think that we should show users the "best" way
> to get up and running with Cocoon.
>
> [X ] B. I think that we should show users all the options
> possible and let them decide the best approach.
>
> [ ] C. Yeah, whatever. Either way is good for me.
> Peace, man!
Ugo
---------------------------------------------------------------------
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
Posted by Leon Widdershoven <qa...@dds.nl>.
I fully agree that the needs of users are seldom the same. So if we're
talking an experienced user I'd say a bunch of examples on all possible
ways is ok.
But this topic, as I understand it, is focussed on starting users. So I
think that it's not so much important how many examples and ways are shown,
but more that those ways are documented. And the differences between the
various methodologies is explained.
For a newby, a 1000 line example with a 1 line explanation is not that
usefull, for someone familiar with cocoon it can be a revalation.
Which is why I think a combination between A and B is best; identify
some common cases (Antonio just did that:) and document a recommended
way for those, or maybe even two possible ways with a reference to each
other and a few lines in which the difference between the methods (when and
why to prefer X to Y, and when not).
As an example (shamelessly stolen and adapted from this list):
1. Complex SQL data structures/queries: O/R
2. Simple, Updates, Inserts (and selects), Flowscript
3. Simple Select-only: XSP and ESQL
(I'm not saying the above is an absolute truth, but it makes sense to
me - and it's an example).
And a well-documented, Wiki'd example of all three cases would be sufficient
to give starting users a good idea of the various database-access technologies
in Cocoon. And who doesn't use a database in one way or the other? :)
Leon
Antonio Gallardo wrote:
> David Leangen dijo:
>
>>***********************************************************
>>
>> [ ] A. I think that we should show users the "best" way
>> to get up and running with Cocoon.
>>
>
> [ X ] B. I think that we should show users all the options
>
>> possible and let them decide the best approach.
>>
>> [ ] C. Yeah, whatever. Either way is good for me.
>> Peace, man!
>
>
> Because we cannot have a one size shirt for all people ie:
>
> If someone need Cocoon as:
>
> 1- a publisher framework + 1 feedback form + 1 host book (or whatever).
> 2- a webapp framework for a small-medium size company
> 3- a webapp framework for a medium-large (enterprise) size company
> .... etc.
>
> Then you can make diferents configurations and the best practices are
> diferent for each one. Some questions are in place before choosing the
> right tools:
>
> What if the user already have implemented or want to use J2EE?
> What if there is already some work on PHP?
> Will be the application scalable or not?
> How easy the scalability will be?
> Will be deployed on an Application server or just on a Servlet container?
> ....And we can continue puting question on the list.
>
> From a 1 server bundle all to a full distributed system using J2EE. Then
> the question is:
>
> "What is the best practices at all?"
>
> I prefer to see Cocoon as is on the Website:
>
> "web glue for your web application development needs"
>
> That is Cocoon and every one can use it as he need.
>
> Best Regards,
>
> Antonio Gallardo
>
> ---------------------------------------------------------------------
> 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: Vote: to unify, or not to unify - results
Posted by Antonio Gallardo <ag...@agssa.net>.
David Leangen dijo:
> ***********************************************************
>
> [ ] A. I think that we should show users the "best" way
> to get up and running with Cocoon.
>
[ X ] B. I think that we should show users all the options
> possible and let them decide the best approach.
>
> [ ] C. Yeah, whatever. Either way is good for me.
> Peace, man!
Because we cannot have a one size shirt for all people ie:
If someone need Cocoon as:
1- a publisher framework + 1 feedback form + 1 host book (or whatever).
2- a webapp framework for a small-medium size company
3- a webapp framework for a medium-large (enterprise) size company
.... etc.
Then you can make diferents configurations and the best practices are
diferent for each one. Some questions are in place before choosing the
right tools:
What if the user already have implemented or want to use J2EE?
What if there is already some work on PHP?
Will be the application scalable or not?
How easy the scalability will be?
Will be deployed on an Application server or just on a Servlet container?
....And we can continue puting question on the list.
>From a 1 server bundle all to a full distributed system using J2EE. Then
the question is:
"What is the best practices at all?"
I prefer to see Cocoon as is on the Website:
"web glue for your web application development needs"
That is Cocoon and every one can use it as he need.
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
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
Posted by 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
Re: Vote: to unify, or not to unify - results
Posted by 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
Posted by Nacho Jimenez <na...@ya.com>.
Bertrand Delacretaz wrote:
> Le 4 mai 04, à 18:39, Nacho Jimenez a écrit :
>
>> ... 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....
>
>
> What you're describing is only one of the many use-cases of Cocoon.
> The beauty of this framework (which is also what can make it difficult
> to grasp) is that there are so many different ways to use it.
>
> Ask five people what Cocoon is, you might well get six answers ;-)
I know that, of course, but for new users to learn about cocoon, a
guided tour of a bunch of common cases would make life a lot easier.
Once they learn their way arround they can use all the flexibility of
this framework, but I think many people finds too step a learning curve
and leaves before even trying.
---------------------------------------------------------------------
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
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le 4 mai 04, à 18:39, Nacho Jimenez a écrit :
> ... 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....
What you're describing is only one of the many use-cases of Cocoon. The
beauty of this framework (which is also what can make it difficult to
grasp) is that there are so many different ways to use it.
Ask five people what Cocoon is, you might well get six answers ;-)
-Bertrand
---------------------------------------------------------------------
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
Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2004-05-04 at 18:39, 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).
(unrelated to the main topic, but couldn't resist)
I wouldn't recommend to use the JXTemplateTransformer (unless you have
good reasons to), as it is a fake generator, which has the disadvantage
that templates can't be cached but need to be compiled on each use.
> 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.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
---------------------------------------------------------------------
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
Posted by Nacho Jimenez <na...@ya.com>.
>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.
---------------------------------------------------------------------
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
Posted by David Leangen <dl...@canada.com>.
Thank you for your input! Some excellent comments have been made and all are
noted.
So far, the poll results show that there is no unanimity (see below). I
think that it would be pretty unscientific to reach any firm conclusions
based on such a small sample, but I think that some "trends" can be
established.
First, I think it is clear, not only from this poll but from the many
messages that have been posted lately, that the general opinion is that work
needs to be done on the user docs to be more user-centric, use case
oriented, and less confusing.
However, there is some fear (for lack of a better word) that we will be
taking freedom away from more experienced developers who may resent being
forced down a certain path. There is also the concern that whatever we cite
as the "preferred" approach may not be the best choice for a particular use
case, or that the "best practice" may change.
Generally, based on your comments, it appears that a good approach may be to
choose a "currently preferred approach". This recognises that what is often
called "best practices" may change over time. This makes sense to me. So the
CPA method allows for future changes (without loss of face), while still
allowing us to focus on one particular approach for beginners.
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 seems to me a good compromise and, hopefully, a means of reaching
consenus.
Questions? Comments? Insults?
It's not too late to chime in if you still want to vote or have other
comments to add. The above is not a conclusion, just a proposition.
***********************************************************
[ ] A. I think that we should show users the "best" way
to get up and running with Cocoon.
[ ] B. I think that we should show users all the options
possible and let them decide the best approach.
[ ] C. Yeah, whatever. Either way is good for me.
Peace, man!
Poll results so far:
A. - 6
B. - 3
C. - 0
A
Dave L.
Derek H.
Tim L.
JDD
Nacho J.
Joel M.
B
Ugo C.
Stavros K.
Ralph G.
***********************************************************
Dave L.
---------------------------------------------------------------------
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 (Was "RE: Business Logic in Cocoon Applications?")
Posted by Joel McConaughy <jo...@displayware.com>.
[XX] A. I think that we should show users the "best" way
to get up and running with Cocoon.
[ ] B. I think that we should show users all the options
possible and let them decide the best approach.
[ ] C. Yeah, whatever. Either way is good for me.
Peace, man!
Joel McConaughy
Managing Partner
Displayware LLC
800 Fifth Ave., #101-316
Seattle, WA 98104-3191
206-300-4732 Direct
206-382-2188 Fax
joel@displayware.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org