Re: newbies documentation (was: Cocoon is too complex for consumption?)

[Steven Noels]

SAXESS - Hussayn Dabbous wrote:


The major point is to remember, that the newbies wiki is a part of
the cocoon wiki, independent of the underlaying technology, thus
coordinating the content, not the technology.


Sure. My bias is that people should not go for hunting information, and 
that a lot, for various audiences, and from various angles, can be found 
in one place.

Thanks for your cooperation!


--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: newbies documentation (was: Cocoon is too complex for consumption?)

[SAXESS - Hussayn Dabbous]

hy, steven;

you are right: no good idea to create another documentation
source. i remember, i also complained about that when i started
with cocoon: documentation sites all around and uncoordinated.
The point is "uncoordinated" here:

I propose to coordinate the "newbies site" with the existing
cocoon wiki. If this can be done technically within the same
wiki, different layout, different startpage and so on, its ok
for me. if it can be set up as parallel deployed JSPWiki, what
the hell, a link is a link and you can interlink two wikis with
ease... The major point is to remember, that the newbies wiki
is a part of the cocoon wiki, independent of the underlaying
technology, thus coordinating the content, not the technology.


regards, hussayn



Steven Noels wrote:

SAXESS - Hussayn Dabbous wrote:


My *personal* conclusions on this:

1.) Instead of shouting against the developers i started
writing down my experiences within my company wiki.
I did this because i wanted a clear separation from
all the "masters of the art" articles turning up in the
cocoon wiki. Besides this some of the points i tackled
have to give at least little insight into tomcat and
other loosely coupled themes which i didn't want to add
to the ever growing cocoon wiki.



Hussayn,

pardon my insistence, but the idea of starting yet another Cocoon 
documentation resource is troubling me a bit, especially if that means 
setting up another Wiki. Given the easy proliferation of Wiki content, 
people will not know anymore where to submit and retrieve information.

Why not start a section within the existing Wiki? I'd be _very_ willing 
to provide you guys _any_ assistance you might need.

And even if the users would insist in having 'their own Wiki' (although 
I think the existing wiki.cocoondev.org is there for _anybody_), I'd be 
happy in providing hosting for that under the neutral cocoondev.org domain.



--
Dr. Hussayn Dabbous
SAXESS Software Design GmbH
Neuenhöfer Allee 125
50935 Köln
Telefon: +49-221-56011-0
Fax: +49-221-56011-20
E-Mail:  [EMAIL PROTECTED]


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: newbies documentation (was: Cocoon is too complex for consumption?)

[SAXESS - Hussayn Dabbous]

hy, Derek;

what you say makes perfect sense ;-)
only one suggestion for the first two pages:

1.)

"HOWTO setup cocoon in 15 minutes ;-)"
should be easy by condensing the other thread

2.)

"HOWTO setup your intranet with XML in 1 day"
it took me two weeks to figure it out, but i could
give away

2 style sheets
1 document xschema
1 sitemap

that would be sufficient to drive a very basic intranet site
like mine at http://www.saxess.de

simply by taking the files, putting them into cocoon and
then generating your content...

regards, hussayn


Derek Hohls wrote:

A quick addition to what Hussayn suggests - which is well
explained and makes perfect sense - is to take this one step
further - lets have a wiki for people to add/suggest etc BUT
we need to take from it the most polished and relevant material
and make it into a formal and well laid-out website (yes, I do
use wikis and I do host one inside my company - but they are
not always very accessible or well-structured from a newbie
point-of-view) - if we do our design correctly ;-) this should not
require much more than a stylesheet or two for the conversion.
 
Maybe the first topic on the Cocoon Newbie Wiki could be :
"Framework for a Cocoon Newbie Web (non-wiki) Site"??
 
I second Hussayn as editor for the new site (wow, a *real*
volunteer)
Derek

 >>> [EMAIL PROTECTED] 27/01/2003 10:52:47 >>>
Hy;

as a newbie (of three months age ;) ) i'd like to
contribute my thoughts to the documentation area:


1.) From my now 20 years experience in "computer art" i
 learned that the newbies can tell much more about the
 features of a program, than the developers can. Why?
 because the newbie always tries "the wrong pathes" through
 the software therefore detect the weaknesses and strenghts
 of the app and often walk through pathes the developers
 never thought of inventing new use cases , etc.
 In turn the developers always are biased from their
 architectural insights...

2.) In several projects i was faced with the situation of
 lacking or inappropriate "user documentation". One
 strategy for improvement was always to let the users
 start writing down what they think the app does and
 how they would use it. Then the developers had the
 time to start thinking over what they implemented.
 This is an iterative approach that fits better to the
 real world, than "smacking at the developers and force
 them to start documenting" ...

My *personal* conclusions on this:

1.) Instead of shouting against the developers i started
 writing down my experiences within my company wiki.
 I did this because i wanted a clear separation from
 all the "masters of the art" articles turning up in the
 cocoon wiki. Besides this some of the points i tackled
 have to give at least little insight into tomcat and
 other loosely coupled themes which i didn't want to add
 to the ever growing cocoon wiki.

2.) Whoever writes docs for the newbies MUST get
 help from an experienced user or a developer at least
 for review. This could be the start of a productive
 user centric quality assurance. This may eventually
 get all these very interesting but (sorry) unneaded
 explanations of avalon and other base technologies
 out of the docs or at least into separated docs.

3.) Writing docs MUST be made as simple as possible. But it
 should be surveyed from one or a few "editors" who keep
 the docs in right shape, and right organisation.

so i would propose (as Derek does):

1.) Provide a platform separate from the already existing
 documentation areas, which is clearly labeled as the
 "newbies competence center", accessible to everyone
 with most ease (start getting productive in a minute)
2.) I would recommend to use a separate Wiki for this
 purpose.
3.) Instead of letting such a wiki free floating, get
 at least one person into the role of
 the "responsible editor"

And despite any possibly upcoming thoughts like
"this is open source, everyone (thus noone?) is responsible"
i would gladly get into the role of the "responsible editor"
for some time at least. And if it makes sense, i also would
start hosting such a "cocoon CC Wiki".

Meanwhile i will continue writing down my personal insights
and eventually donate all this stuff to whatever
will come up as a newbies documentation infrastructure ...

regards, hussayn

Derek Hohls wrote:
 > Tony
 > 
 > In case you missed my other wandering thought pattern; its my
 > strong feeling we need a SINGLE section of the website -
 > preferably one well-insulated from the ramblings on the other site
 > which is "always under construction" that (including any
 > formal guides) solely addresses ONLY the needs of newbies and
 > has ALL the documents AND faqs AND minimal downloads AND simple
 > sitemaps etc in ONE place - no obscure wikis/mailing list links.
 > (Gee, we are working with a web publishing platform here - ho

Re: newbies documentation (was: Cocoon is too complex for consumption?)

[Steven Noels]

SAXESS - Hussayn Dabbous wrote:


My *personal* conclusions on this:

1.) Instead of shouting against the developers i started
writing down my experiences within my company wiki.
I did this because i wanted a clear separation from
all the "masters of the art" articles turning up in the
cocoon wiki. Besides this some of the points i tackled
have to give at least little insight into tomcat and
other loosely coupled themes which i didn't want to add
to the ever growing cocoon wiki.


Hussayn,

pardon my insistence, but the idea of starting yet another Cocoon 
documentation resource is troubling me a bit, especially if that means 
setting up another Wiki. Given the easy proliferation of Wiki content, 
people will not know anymore where to submit and retrieve information.

Why not start a section within the existing Wiki? I'd be _very_ willing 
to provide you guys _any_ assistance you might need.

And even if the users would insist in having 'their own Wiki' (although 
I think the existing wiki.cocoondev.org is there for _anybody_), I'd be 
happy in providing hosting for that under the neutral cocoondev.org domain.


--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

newbies documentation (was: Cocoon is too complex for consumption?)

[SAXESS - Hussayn Dabbous]

Hy;

as a newbie (of three months age ;) ) i'd like to
contribute my thoughts to the documentation area:


1.) From my now 20 years experience in "computer art" i
learned that the newbies can tell much more about the
features of a program, than the developers can. Why?
because the newbie always tries "the wrong pathes" through
the software therefore detect the weaknesses and strenghts
of the app and often walk through pathes the developers
never thought of inventing new use cases , etc.
In turn the developers always are biased from their
architectural insights...

2.) In several projects i was faced with the situation of
lacking or inappropriate "user documentation". One
strategy for improvement was always to let the users
start writing down what they think the app does and
how they would use it. Then the developers had the
time to start thinking over what they implemented.
This is an iterative approach that fits better to the
real world, than "smacking at the developers and force
them to start documenting" ...

My *personal* conclusions on this:

1.) Instead of shouting against the developers i started
writing down my experiences within my company wiki.
I did this because i wanted a clear separation from
all the "masters of the art" articles turning up in the
cocoon wiki. Besides this some of the points i tackled
have to give at least little insight into tomcat and
other loosely coupled themes which i didn't want to add
to the ever growing cocoon wiki.

2.) Whoever writes docs for the newbies MUST get
help from an experienced user or a developer at least
for review. This could be the start of a productive
user centric quality assurance. This may eventually
get all these very interesting but (sorry) unneaded
explanations of avalon and other base technologies
out of the docs or at least into separated docs.

3.) Writing docs MUST be made as simple as possible. But it
should be surveyed from one or a few "editors" who keep
the docs in right shape, and right organisation.

so i would propose (as Derek does):

1.) Provide a platform separate from the already existing
documentation areas, which is clearly labeled as the
"newbies competence center", accessible to everyone
with most ease (start getting productive in a minute)
2.) I would recommend to use a separate Wiki for this
purpose.
3.) Instead of letting such a wiki free floating, get
at least one person into the role of
the "responsible editor"

And despite any possibly upcoming thoughts like
"this is open source, everyone (thus noone?) is responsible"
i would gladly get into the role of the "responsible editor"
for some time at least. And if it makes sense, i also would
start hosting such a "cocoon CC Wiki".

Meanwhile i will continue writing down my personal insights
and eventually donate all this stuff to whatever
will come up as a newbies documentation infrastructure ...

regards, hussayn

Derek Hohls wrote:

Tony
 
In case you missed my other wandering thought pattern; its my
strong feeling we need a SINGLE section of the website -
preferably one well-insulated from the ramblings on the other site
which is "always under construction" that (including any
formal guides) solely addresses ONLY the needs of newbies and
has ALL the documents AND faqs AND minimal downloads AND simple
sitemaps etc in ONE place - no obscure wikis/mailing list links. 
(Gee, we are working with a web publishing platform here - how hard
can this be to put together *technically*?? ) The trick is writing good,
clear, simple pages - and that's a matter of write - read - edit 
recycle until your target newbie - not your average 
developer/contributor  -
can make sense of it...
 
Derek

 >>> [EMAIL PROTECTED] 27/01/2003 06:29:12 >>>
In light of this ginormous thread, do we need more newbie guides to
getting started with Cocoon?  Obviously the CTWIG or whatever is out of
date, so perhaps there's a demand for something like a Busy Developer's
Guide to getting started with Cocoon?  I'd be more that willing to write
stuff up that for direct inclusion with the Cocoon documentation that is
distributed with the releases.

If so, I'll start writing up a Cocoon BDG (or even a series) in Document
1.1 format.

P.S. Docs team: Perhaps it's time to start assimilating Wiki content into
the distribution docs?


Tony

--
Cocoon: Internet Glue (A Cocoon Weblog)
http://manero.org/weblog/


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>


--
This message has been scanned for viruses and dangerous content by
*MailScanner* , and is believed to be clean.

"The CSIR 

Re: Cocoon is too complex for consumption?

[Derek Hohls]

Tony
 
In case you missed my other wandering thought pattern; its my
strong feeling we need a SINGLE section of the website - 
preferably one well-insulated from the ramblings on the other site
which is "always under construction" that (including any
formal guides) solely addresses ONLY the needs of newbies and
has ALL the documents AND faqs AND minimal downloads AND simple
sitemaps etc in ONE place - no obscure wikis/mailing list links.  

(Gee, we are working with a web publishing platform here - how hard 
can this be to put together *technically*?? ) The trick is writing 
good, 
clear, simple pages - and that's a matter of write - read - edit  

recycle until your target newbie - not your average 
developer/contributor  - 
can make sense of it...
 
Derek>>> [EMAIL PROTECTED] 27/01/2003 06:29:12 
>>>In light of this ginormous thread, do we need more newbie guides 
togetting started with Cocoon?  Obviously the CTWIG or whatever is out 
ofdate, so perhaps there's a demand for something like a Busy 
Developer'sGuide to getting started with Cocoon?  I'd be more that 
willing to writestuff up that for direct inclusion with the Cocoon 
documentation that isdistributed with the releases.If so, I'll start 
writing up a Cocoon BDG (or even a series) in Document1.1 
format.P.S. Docs team: Perhaps it's time to start assimilating Wiki 
content intothe distribution docs?Tony--Cocoon: 
Internet Glue (A Cocoon Weblog)http://manero.org/weblog/-Please 
check that your question  has not already been answered in theFAQ 
before posting. To 
unsubscribe, e-mail: 
<[EMAIL PROTECTED]>For additional commands, 
e-mail:   
<[EMAIL PROTECTED]>-- 
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.

"The CSIR exercises no editorial control over E-mail messages and/or
attachments thereto/links referred to therein originating in the
organisation and the views in this message/attachments thereto are
therefore not necessarily those of the CSIR and/or its employees.
The sender of this e-mail is, moreover, in terms of the CSIR's Conditions
of Service, subject to compliance with the CSIR's internal E-mail and
Internet Policy."

Re: Cocoon is too complex for consumption?

[Derek Hohls]

Tony
 
In case you missed my other wandering thought pattern; its my
strong feeling we need a SINGLE section of the website - 
preferably one well-insulated from the ramblings on the other site
which is "always under construction" that (including any
formal guides) solely addresses ONLY the needs of newbies and
has ALL the documents AND faqs AND minimal downloads AND simple
sitemaps etc in ONE place - no obscure wikis/mailing list links.  

(Gee, we are working with a web publishing platform here - how hard 
can this be to put together *technically*?? ) The trick is writing 
good, 
clear, simple pages - and that's a matter of write - read - edit  

recycle until your target newbie - not your average 
developer/contributor  - 
can make sense of it...
 
Derek>>> [EMAIL PROTECTED] 27/01/2003 06:29:12 
>>>In light of this ginormous thread, do we need more newbie guides 
togetting started with Cocoon?  Obviously the CTWIG or whatever is out 
ofdate, so perhaps there's a demand for something like a Busy 
Developer'sGuide to getting started with Cocoon?  I'd be more that 
willing to writestuff up that for direct inclusion with the Cocoon 
documentation that isdistributed with the releases.If so, I'll start 
writing up a Cocoon BDG (or even a series) in Document1.1 
format.P.S. Docs team: Perhaps it's time to start assimilating Wiki 
content intothe distribution docs?Tony--Cocoon: 
Internet Glue (A Cocoon Weblog)http://manero.org/weblog/-Please 
check that your question  has not already been answered in theFAQ 
before posting. To 
unsubscribe, e-mail: 
<[EMAIL PROTECTED]>For additional commands, 
e-mail:   
<[EMAIL PROTECTED]>-- 
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.

"The CSIR exercises no editorial control over E-mail messages and/or
attachments thereto/links referred to therein originating in the
organisation and the views in this message/attachments thereto are
therefore not necessarily those of the CSIR and/or its employees.
The sender of this e-mail is, moreover, in terms of the CSIR's Conditions
of Service, subject to compliance with the CSIR's internal E-mail and
Internet Policy."

RE: Cocoon is too complex for consumption?

[e nio]

  Imho, yeah the CTWIG is helpful as a starting point for a
newbie. The other tutorial that I thought that was helpful was
from the www.cocooncenter.de  topic auto-mount, except that it
needs a litle change instead of WildcardURIMatcherFactory it
should use WildcardURIMatcher on the sitemap.xmap. I believe
galatea.com have listed the minimum jar files required to make
up a working cocoon environment.  It sure do take lots of
efforts to  know where these goodies resources are.
  Jeremy and Lajos Cocoon Developer's handbook is excellent for
newbies (I am a newbie).  Chapter 11 is very insightful covering
the heart of Cocoon, sitemap.xmap.  The other two books imho is
more for framework designers and cocoon component developers.  I
did not get to read the two in depth but looking at the
samples(as a newbie I like to see lots of working samples) I
would say Jeremy & Lajos is by far the friendliest.

e nio


--- Jeremy Aston <[EMAIL PROTECTED]> wrote:
> There are good reasons why ctwig is hidden now, mainly because
> it fell out
> of step with documentation as that moved on.  I have intended
> for sometime
> to update the stuff so that it can go back into the
> "mainstream" examples
> but it has had to drop down my priority list for various
> reasons.  Having
> said that, IMHO there are a shed load of places (including the
> dist docs)
> that cover basic xml/xslt/xsp handling with Cocoon.  So why is
> it that
> people feel Cocoon is too difficult to get into?  Does ctwig
> still fill a
> gap?  Could we have even more simple examples, wars etc that
> people can just
> pick up and use?
> 
> I am personally very concerned that the perception is still of
> Cocoon as a
> difficult beast to get into.  The recent threads on this are a
> kick up the
> backside for me as far as getting ctwig up to date goes but it
> would be nice
> to know that that is still what is needed.  I promise to work
> on this in the
> very near future so let me know if you think anything else
> needs doing to
> make being a Cocoon newbie as welcoming a prospect as possible
> 
> rgds
> 
> Jeremy
> 
> 
> > -Original Message-----
> > From: e nio [mailto:[EMAIL PROTECTED]]
> > Sent: 25 January 2003 07:22
> > To: [EMAIL PROTECTED]
> > Subject: Re: Cocoon is too complex for consumption?
> >
> >
> >
> >   At one time there was the CTWIG as part of the samples I
> > believed or maybe it was a link on the getting started
> > documentation. Yes it would be nice for us newbies to start
> with
> > that and get acquainted with cocoon.  Anyhow here is the
> link
> > from Jeremy's site:
> > http://www.pigbite.co.uk/ctwig/blddocs/index.html
> >
> > And if you do a search on the humongous cocoon source, you'd
> > find ctwig under documentation/xdocs/ctwig.
> >
> > enio
> >
> > __
> > Do you Yahoo!?
> > Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> > http://mailplus.yahoo.com
> >
> >
>
-
> > Please check that your question  has not already been
> answered in the
> > FAQ before posting.
> <http://xml.apache.org/cocoon/faq/index.html>
> >
> > To unsubscribe, e-mail:
> <[EMAIL PROTECTED]>
> > For additional commands, e-mail:  
> <[EMAIL PROTECTED]>
> >
> 
> 
> __
> Do You Yahoo!?
> Everything you'll ever need on one web page
> from News and Sport to Email and Music Charts
> http://uk.my.yahoo.com
> 
>
-
> Please check that your question  has not already been answered
> in the
> FAQ before posting.
> <http://xml.apache.org/cocoon/faq/index.html>
> 
> To unsubscribe, e-mail:
> <[EMAIL PROTECTED]>
> For additional commands, e-mail:  
> <[EMAIL PROTECTED]>
> 


__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

-
Please check that your question  has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: Cocoon is too complex for consumption?

[Tony Collen]

In light of this ginormous thread, do we need more newbie guides to
getting started with Cocoon?  Obviously the CTWIG or whatever is out of
date, so perhaps there's a demand for something like a Busy Developer's
Guide to getting started with Cocoon?  I'd be more that willing to write
stuff up that for direct inclusion with the Cocoon documentation that is
distributed with the releases.

If so, I'll start writing up a Cocoon BDG (or even a series) in Document
1.1 format.

P.S. Docs team: Perhaps it's time to start assimilating Wiki content into
the distribution docs?


Tony

--
Cocoon: Internet Glue (A Cocoon Weblog)
http://manero.org/weblog/


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

RE: Cocoon is too complex for consumption?

[Geoff Howard]

> On Saturday 25 January 2003 21:05, Jeff Turner wrote:
> > On Sat, Jan 25, 2003 at 06:22:10PM +0800, Niclas Hedhman wrote:
> > > In fact, I think Cocoon is so powerful, that it has kind of
> grown out of
> > > its "servlet" image. It should traverse to the next level (or
> two), and
> > > has its own deployment system. Collect your stuff (sitemap
> and all) into
> > > a JAR and "hand it over". It is almost like that already, and
> should be a
> > > fairly easy addition to make, but the developer community is much more
> > > focused on additional features.
> >
> > http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition
> > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101603335007960&w=2
> > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101732982704553&w=2
>
> Implemented already?? or part of the upcoming 2.1?
>
> Niclas

Upcoming.  There is a beginning of "blocks" implementation in 2.1, but
not nearly the full extent of the vision.  At the moment, non-core code,
documentation, and samples are becoming modularized into separate areas
of the source tree, and the build system will include or exclude any of
these based on build-time parameters.  Features like remote download,
adding blocks to already compiled cocoon, blocks exposing services, etc.
are still in the works (and don't seem likely for even 2.1).  What is
there may not sound like much but it's already a big step forward in
my view.

Those involved in the development so far may wish to add to or correct that
summary but I think it's pretty accurate.

Geoff Howard

>
> -
> Please check that your question  has not already been answered in the
> FAQ before posting. 
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail:   <[EMAIL PROTECTED]>
>
>
>


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: Cocoon is too complex for consumption?

[Niclas Hedhman]

On Saturday 25 January 2003 21:05, Jeff Turner wrote:
> On Sat, Jan 25, 2003 at 06:22:10PM +0800, Niclas Hedhman wrote:
> > In fact, I think Cocoon is so powerful, that it has kind of grown out of
> > its "servlet" image. It should traverse to the next level (or two), and
> > has its own deployment system. Collect your stuff (sitemap and all) into
> > a JAR and "hand it over". It is almost like that already, and should be a
> > fairly easy addition to make, but the developer community is much more
> > focused on additional features.
>
> http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101603335007960&w=2
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101732982704553&w=2

Implemented already?? or part of the upcoming 2.1?

Niclas

-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: Cocoon is too complex for consumption?

[Robert Simmons]

> Robert Simmons wrote:
>
> >GOOD! This is my idea of the right attitude. People seem to fail to
realize that
> >if I didn't see the potential of the product, I wouldn't bother wasting
several
> >hours of my time typing up very long emails on the subject.
> >
> I can see that you do indeed care, but (for example) Slashdot is full of
> long messages from people who don't care about the livelihood of a
> particular project.  This isn't you, I just couldn't resist making that
> point -- no offense intended.  Your statement makes assumptions that we
> already know you as a person.

I don't use slashdot for the very reason that its full of allot of backseat
drivers. You will just have to trust me when I say my internl deadline clock
is cringing at me wasting 2 days typing emails.

> >1) A deployment version with one jar containing all the required CORE
libraries
> >in that jar. This jar would contain avalon and excalibur and the rest but
> >wouldn't bother to mention it. That would stop "jar shock" that the newbie
> >encounters when popping open the web-inf/lib directory. I think my exact
words
> >were, "Holy shit?!?!? What do I really need?"
> >
>
> If you consider a .war as an atomic unit, it's unnecessary.  But it can
> seem intimidating, you're right.  Then again, how often have you gone
> into the lib directories of JBoss or Tomcat?  Those aren't exactly sparse.

Never bothered to look  loooking  nope. Looks nasty. But then notice
the "Ive never bothered looking." Despite using JBoss for near 2 years now.
In cocoon, I HAVE to look.

> On another note, it could well be argued that Cocoon is far more complex
> than Tomcat, so I'd be unsure whether this was a fair comparison.
> Cocoon actually seems to be straddling the line between servlet and
> container.  I think many long-time users and the developers see that,
> but as a newbie, you see the "servlet" moniker and have unrealistic
> expectations.  I don't actually think it's anyone's fault per se; it
> really is quite difficult to explain something that doesn't fit well
> into existing definitions or practices.  Be that as it may, first
> impressions are first impressions.

Peachy. But users dotn really care about what line its stradling. They care
1) does it work?. 2) is it scalable? 3) does it require you to be a developer
to use it? 4) how fast can i get it running. Save the speaches about what
lines its straddling for the developers and the people concerned about
learning its architecture. The users dont care.

> >2) A single built war file with hello world. All it does is spit out hello
world
> >through a little XSLT template. That's it. This is where newbies want to
start.
> >Start small and work your way up.
>
> I believe there are folks working on that particular issue.  It was
> asked for previously on the mailing lists (a skeleton sitemap in a
> relatively bare Cocoon instance) and there are many others that share
> your concern.  It really isn't apathy that you see but a work in
> progress.  There are some who may have taken your statements as
> indictments of their (volunteer) work when it's a known problem on the
> todo list.

Hmm, I find it strange if this isnt just some ant work to accomplish. Why
isnt it there? If it is truly such a time consuming task as to not have been
provided yet (though critical) then you rather prove my point. If the devs
dont have time to get this fired up, how the heck does someone who knows
nothign about it stand a chance?

> >3) Componetize optional features. Give them separate configuration files
and
> >keep them separate.
>
> This is already well underway in the "blocks" concept.  This is a
> relatively young endevour, so you would have to read the developer
> mailing list archives to get specific information.  As a quick preview
> though, if you built a copy of Cocoon CVS and looked in the WEB-INF/lib
> directory of the .war file, you would see quite a few .jar files with
> "block" in the name.  This is the beginnings of what you propose and is
> a work in progress.

Good news there.

> >4) Change the distribution. You get either a minimal (which is required
stuff
> >+hello world) or medium (which contains some samples) or kitchen sink (the
> >current distribution).
> >
>
> Been proposed before and is on the todo list.

Again .. if this isnt a small amount of work, somethign is seriously wrong.
If it is a small amount of work and not a priority than you can see where
newbies are comming from. Focusing on features is all well and good but if
you dont get people to adopt the technology, you are hosed. You can bet
Microsoft is examining cocoon right this mometn and trying to figure out if
they can make an easy to use package that does the same thing.

> >5) Remove anywhere where cocoon user has to know about avalon or
excalibur. Most
> >of us don't much care. When we write a generator we want to implement an
> >interface and say "uhh, my generator is here with this class name" and go
with
> >it. If I need

Re: Cocoon is too complex for consumption?

[Miles Elam]

Robert Simmons wrote:


GOOD! This is my idea of the right attitude. People seem to fail to realize that
if I didn't see the potential of the product, I wouldn't bother wasting several
hours of my time typing up very long emails on the subject.


I can see that you do indeed care, but (for example) Slashdot is full of 
long messages from people who don't care about the livelihood of a 
particular project.  This isn't you, I just couldn't resist making that 
point -- no offense intended.  Your statement makes assumptions that we 
already know you as a person.

1) A deployment version with one jar containing all the required CORE libraries
in that jar. This jar would contain avalon and excalibur and the rest but
wouldn't bother to mention it. That would stop "jar shock" that the newbie
encounters when popping open the web-inf/lib directory. I think my exact words
were, "Holy shit?!?!? What do I really need?"



If you consider a .war as an atomic unit, it's unnecessary.  But it can 
seem intimidating, you're right.  Then again, how often have you gone 
into the lib directories of JBoss or Tomcat?  Those aren't exactly sparse.

On another note, it could well be argued that Cocoon is far more complex 
than Tomcat, so I'd be unsure whether this was a fair comparison.  
Cocoon actually seems to be straddling the line between servlet and 
container.  I think many long-time users and the developers see that, 
but as a newbie, you see the "servlet" moniker and have unrealistic 
expectations.  I don't actually think it's anyone's fault per se; it 
really is quite difficult to explain something that doesn't fit well 
into existing definitions or practices.  Be that as it may, first 
impressions are first impressions.

2) A single built war file with hello world. All it does is spit out hello world
through a little XSLT template. That's it. This is where newbies want to start.
Start small and work your way up.



I believe there are folks working on that particular issue.  It was 
asked for previously on the mailing lists (a skeleton sitemap in a 
relatively bare Cocoon instance) and there are many others that share 
your concern.  It really isn't apathy that you see but a work in 
progress.  There are some who may have taken your statements as 
indictments of their (volunteer) work when it's a known problem on the 
todo list.

3) Componetize optional features. Give them separate configuration files and
keep them separate.



This is already well underway in the "blocks" concept.  This is a 
relatively young endevour, so you would have to read the developer 
mailing list archives to get specific information.  As a quick preview 
though, if you built a copy of Cocoon CVS and looked in the WEB-INF/lib 
directory of the .war file, you would see quite a few .jar files with 
"block" in the name.  This is the beginnings of what you propose and is 
a work in progress.

4) Change the distribution. You get either a minimal (which is required stuff
+hello world) or medium (which contains some samples) or kitchen sink (the
current distribution).



Been proposed before and is on the todo list.


5) Remove anywhere where cocoon user has to know about avalon or excalibur. Most
of us don't much care. When we write a generator we want to implement an
interface and say "uhh, my generator is here with this class name" and go with
it. If I need to mount more than one jar, something is borked. Basically just
facade all the entry points into cocoon with interfaces. its low a low budget
task that goes a LONG way.



Technically you never mount a .jar file;  You only really deploy a .war 
file (or a .ear file in the case of EJB containers).  At any rate, with 
Cocoon in development (many times a state of flux), having each piece 
separate makes debugging and development quicker and easier.

If you need more than one jar, nothing is "borked."  It all works just 
fine as separate files.  This is an aesthetics issue (extending into 
mild intimidation), not a technical one.  Putting everything into a 
single jar won't make Cocoon run better -- it will simply appear 
"neater" to some.

As for Avalon and Excalibur interfaces (and components), the idea was 
that many of these resources are not Cocoon-specific and should be 
shared outside the context of a single webapp.  Weren't you just 
vehemently recommending the use of log4j?  Isn't that including another 
outside package dependency?  I see the issue here as one of 
documentation/education more than technical deficiency.

6) Remove any need to build from CVS. I downloaded the module, all 61 megs of it
and now I expect to spend 20 hours to just get a minimal build working. Users
don't want to have to build the product. Maybe 1% of ant users ever bother to
build it. Same for tomcat and the other popular apache products.



Some of the facilities that you wanted aren't available or as complete 
in the released binary;  That's why some folks pointed you to CVS.  
There are also some speed/efficie

Re: Cocoon is too complex for consumption?

[Robert Simmons]

10 minutes ? Some 30 hours later I still haven't figured out what I need to go
minimal.

-- Robert

- Original Message -
From: "Perry Molendijk" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, January 26, 2003 3:46 AM
Subject: Re: Cocoon is too complex for consumption?


> > The fact is that JSP continues to gather momentum and the era of XML-XSLT
> has all but been forgotten. To what do you attribute this?
> > XML and XSLT and by extension cocoon has a very narrow window to get some
> serious press to make itself live. This window is passing by.
>
> Funny that, I am kind booked out for most of the year with projects that
> need XSLT written for their applications. One of them is cleaning up the
> mess of having HTML and Java code in JSP nicely mixed up together. I don't
> write a line of Java myself but I have observed is that writting "clean"
> webapplications takes a fair bit of discipline that many developers don't
> have, or it is usually simply too hard for them; "this how I always do it".
>
> > If you ask me, the cocoon development effort should refocus itself from
> developing more features to getting the product in a state
> > such as tomcat is in. A state where people say "cocoon? Oh that's easy to
> use. getting hello-world to work is like a 10 minute
> > affair. You only need to worry about all the fancy features if you need to
> use them, give it a shot."
>
> OK the Cocoon doco needs work and the amount of features well out number the
> amount of doco pages. But you can still get Hello World up in 10 minutes.
> Most of the installation problems appear to be typical for all sorts of Java
> applications: wrong, missing or conflicting jar files in various places..
>
> Perry Molendijk
>
>
> -
> Please check that your question  has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail:   <[EMAIL PROTECTED]>
>


-
Please check that your question  has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: Cocoon is too complex for consumption?

[Robert Simmons]

> There are good reasons why ctwig is hidden now, mainly because it fell out
> of step with documentation as that moved on.  I have intended for sometime
> to update the stuff so that it can go back into the "mainstream" examples
> but it has had to drop down my priority list for various reasons.  Having
> said that, IMHO there are a shed load of places (including the dist docs)
> that cover basic xml/xslt/xsp handling with Cocoon.  So why is it that
> people feel Cocoon is too difficult to get into?  Does ctwig still fill a
> gap?  Could we have even more simple examples, wars etc that people can just
> pick up and use?
>
> I am personally very concerned that the perception is still of Cocoon as a
> difficult beast to get into.  The recent threads on this are a kick up the
> backside for me as far as getting ctwig up to date goes but it would be nice
> to know that that is still what is needed.  I promise to work on this in the
> very near future so let me know if you think anything else needs doing to
> make being a Cocoon newbie as welcoming a prospect as possible

GOOD! This is my idea of the right attitude. People seem to fail to realize that
if I didn't see the potential of the product, I wouldn't bother wasting several
hours of my time typing up very long emails on the subject.

What you need in my newbie opinion.

1) A deployment version with one jar containing all the required CORE libraries
in that jar. This jar would contain avalon and excalibur and the rest but
wouldn't bother to mention it. That would stop "jar shock" that the newbie
encounters when popping open the web-inf/lib directory. I think my exact words
were, "Holy shit?!?!? What do I really need?"

2) A single built war file with hello world. All it does is spit out hello world
through a little XSLT template. That's it. This is where newbies want to start.
Start small and work your way up.

3) Componetize optional features. Give them separate configuration files and
keep them separate.

4) Change the distribution. You get either a minimal (which is required stuff
+hello world) or medium (which contains some samples) or kitchen sink (the
current distribution).

5) Remove anywhere where cocoon user has to know about avalon or excalibur. Most
of us don't much care. When we write a generator we want to implement an
interface and say "uhh, my generator is here with this class name" and go with
it. If I need to mount more than one jar, something is borked. Basically just
facade all the entry points into cocoon with interfaces. its low a low budget
task that goes a LONG way.

6) Remove any need to build from CVS. I downloaded the module, all 61 megs of it
and now I expect to spend 20 hours to just get a minimal build working. Users
don't want to have to build the product. Maybe 1% of ant users ever bother to
build it. Same for tomcat and the other popular apache products.

7 and not a priority but would be nice) Change logging to use Log4j. Its won the
race. Even the logging in jdk has been beaten bloody by log4j. The other logging
frameworks might as well concede.




-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: Cocoon is too complex for consumption?

[Perry Molendijk]

> The fact is that JSP continues to gather momentum and the era of XML-XSLT
has all but been forgotten. To what do you attribute this?
> XML and XSLT and by extension cocoon has a very narrow window to get some
serious press to make itself live. This window is passing by.

Funny that, I am kind booked out for most of the year with projects that
need XSLT written for their applications. One of them is cleaning up the
mess of having HTML and Java code in JSP nicely mixed up together. I don't
write a line of Java myself but I have observed is that writting "clean"
webapplications takes a fair bit of discipline that many developers don't
have, or it is usually simply too hard for them; "this how I always do it".

> If you ask me, the cocoon development effort should refocus itself from
developing more features to getting the product in a state
> such as tomcat is in. A state where people say "cocoon? Oh that's easy to
use. getting hello-world to work is like a 10 minute
> affair. You only need to worry about all the fancy features if you need to
use them, give it a shot."

OK the Cocoon doco needs work and the amount of features well out number the
amount of doco pages. But you can still get Hello World up in 10 minutes.
Most of the installation problems appear to be typical for all sorts of Java
applications: wrong, missing or conflicting jar files in various places..

Perry Molendijk


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: Cocoon is too complex for consumption?

[Robert Simmons]

I don't forget that. Nor do I expect everyone to adapt to "my way". Not at all. 
However I know for a fact that I am not the only new
user to cocoon having these issues. I can look at the mailing list archive a long way 
back and see people who have come, posted the
same opinions and then subsequently never posted again. You may say "fine they can go 
to hell." but if you are trying to make a
technology not just be a little niche technology with a little tight club as members 
than you need to change this turnover. People
should come into cocoon, see its power and rapidly get a hello world up and start 
running with it. Only through this can you save
the technology from the heap where all the other failed ones went.

The fact is that JSP continues to gather momentum and the era of XML-XSLT has all but 
been forgotten. To what do you attribute this?
XML and XSLT and by extension cocoon has a very narrow window to get some serious 
press to make itself live. This window is passing
by. Sitting there and saying "those damn newbies don't know anything!" might satisfy 
your sense of self but doesn't promote the
technology. Similarly, replying to a mail such as mine and saying "Don't expect 
everything to be _your_ way the moment you arrive,"
doesn't accomplish anything except getting people to say, "ok fair enough," and 
heading for the door.

In the end, cocoon has two choices. Adapt to the users or die. Its as simple as that. 
If you keep telling us to shut up for whining
about how hard it is to get started, that's fine. The technology will die.

If you ask me, the cocoon development effort should refocus itself from developing 
more features to getting the product in a state
such as tomcat is in. A state where people say "cocoon? Oh that's easy to use. getting 
hello-world to work is like a 10 minute
affair. You only need to worry about all the fancy features if you need to use them, 
give it a shot."

Right now, to the newbie, cocoon only inspires three words. Those are, "What the hell?"

As for me, I don't screw with it any more. I have a book to write and publishing 
schedules to make and the book isn't even remotely
about client side stuff and therefore anything not easy on the client side has to be 
off the shelf.

-- Robert


- Original Message -
From: "Steven Noels" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 25, 2003 7:03 PM
Subject: Re: Cocoon is too complex for consumption?


> Robert Simmons wrote:
>
> > Lastly, flaming is not an option. These are the opinions from a
> > newbie comming into cocoon. Readers of this list can flame all they
> > want but that is just hiding from the very real problems.
>
> Robert, I can only give you one advise: don't forget human beings are
> sitting behind these MUAs. Don't expect everything to be _your_ way the
> moment you arrive.
>
> (ditto for the Jakarta Forums idea).
>
> 
> --
> Steven Noelshttp://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> Read my weblog athttp://blogs.cocoondev.org/stevenn/
> stevenn at outerthought.orgstevenn at apache.org
>
>
> -
> Please check that your question  has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail:   <[EMAIL PROTECTED]>
>


-
Please check that your question  has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: Cocoon is too complex for consumption?

[Steven Noels]

Robert Simmons wrote:


Lastly, flaming is not an option. These are the opinions from a
newbie comming into cocoon. Readers of this list can flame all they 
want but that is just hiding from the very real problems.

Robert, I can only give you one advise: don't forget human beings are 
sitting behind these MUAs. Don't expect everything to be _your_ way the 
moment you arrive.

(ditto for the Jakarta Forums idea).


--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: Cocoon is too complex for consumption?

[Robert Simmons]

Well you are wrong. I know all of those and some of them QUITE well. And still getting 
cocoon going is a major hassle. Yes, I can
deploy the distribution but I mean getting my own application going. Just a 
hello-world app.

-- robert

- Original Message -
From: "Gustavo Nalle Fernandes" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 25, 2003 5:56 PM
Subject: RES: Cocoon is too complex for consumption?


>Cocoon is a powerfull _framework_ used to develop XML applications and
> not an out of the box product. As a framework, Cocoon architecture must be
> well understood in order provide extensions that satisfies a particular
> need.
> IMHO, Cocoon´s leaning curve is not steep, assuming that the -DEVELOPER-
> knows XML, XSL, Namespaces, DTD, SCHEMA, HTTP,Servlets and JAVA/OOP.
>
>
>
> -Mensagem original-
> De: Robert Simmons [mailto:[EMAIL PROTECTED]]
> Enviada em: sábado, 25 de janeiro de 2003 14:13
> Para: [EMAIL PROTECTED]
> Assunto: Re: Cocoon is too complex for consumption?
>
>
> I think you might already be there. Currently the concept of cocoon is a
> great one. I create a piepline and cocoon shunts it from a
> to b, applying the transforms and so on. Great development effort. Pardon
> the language but its a shitty user effort. Just look at
> one of your paragraphs in the linked archive.
>
> 
> "If we don't do this, not only Cocoon will get bigger and bigger (and
> start appearing more as a distribution of technologies, than a
> framework), but users will find it harder and harder to modify it for
> their specific needs."
> 
>
> And that is the crux of the problem. Whoever is heading the project seems a
> bit confused. People dont want to MODIFY cocoon. They
> want to USE cocoon. They want to install cocoon's mechanics, then drop in
> their pipelines and go. Cocoon is now trying to do all
> sorts of things that dont need to be done imho. The number of features is so
> staggering that gettign started is near impossible. But
> as I get more into the product, I find myself saying, petulantly, "But I
> just wanted the pipeline!" And that is all that I wanted.
> To have a pipeline. To be able to say to cocoon, "Yeah, well ... in your
> pipeline whenever someone hits URL x, go to pipeline Z and
> run my custom class (which connects to ejbs and so on) and transform it with
> stylesheet Y and give it back to the user.
>
> "But you arent understanding how cocoon works Robert!" BINGO!! You hit it
> right there on the head. I dont want to understand how it
> works. As a user Im not interested. When reading the JBoss documentation, I
> skip over all the architecture stuff and the development
> stuff. As a user, this stuff is irrelevant to me. Object oriented
> programmign is supposed to guarantee to provide me with an
> interface and then implement some functionality. How? Who the hell cares? Im
> a user of it. My prime computing expertise is in the
> back end side of EJBs and issues that pertain to them. I want to USE cocoon,
> not develop on it.
>
> Possible solutions to this.
>
> 1) Rearchitect cocoon to implement some sort of deployment mechanism, such
> as COB. The problem here is that then you have to get
> that working with application servers and so on. The other problem is
> inertia. Gettign the masses of developers to learn a
> new-unstandardized deployment mechanism.
>
> 2) MERGE it with tomcat in the way JBoss has merged with tomcat. I download
> JBoss and they are like "well tomcat is included." I say
> "cool" and drop in my wars and go. If cocoon had a basic mechanism install
> that could be installed into tomcat than the situation
> would be aleviated. Users of the product drop their wars into tomcat as
> normal with a sitemap file in the WEB-INF directory and
> their special generators an so on in the classes directory. Cocoon magically
> wires together the pipeline. No worrying about how to
> configure cocoon or what properties to give it or so on. Thats left to
> advanced users under the heading of "customizing your
> install".
>
> At any rate I can see the learning curve for this product is steep. And
> cocoon is mainly going o suffer from people like me. People
> whoe would love to use it but dont have a month to blow trying to get a
> technology to work that is merely suppsed to be an EASY way
> to develop a polymorphic presentation layer.
>
> Lastly, flaming is not an option. These are the opinions from a newbie
> comming into cocoon. Readers of this list can flame all they
> want but that is just hiding from the very real problems.
>
> -- Robert
>
> - Original Message -
> From: "Stev

RES: Cocoon is too complex for consumption?

[Gustavo Nalle Fernandes]

   Cocoon is a powerfull _framework_ used to develop XML applications and
not an out of the box product. As a framework, Cocoon architecture must be
well understood in order provide extensions that satisfies a particular
need.
IMHO, Cocoon´s leaning curve is not steep, assuming that the -DEVELOPER-
knows XML, XSL, Namespaces, DTD, SCHEMA, HTTP,Servlets and JAVA/OOP.



-Mensagem original-
De: Robert Simmons [mailto:[EMAIL PROTECTED]]
Enviada em: sábado, 25 de janeiro de 2003 14:13
Para: [EMAIL PROTECTED]
Assunto: Re: Cocoon is too complex for consumption?


I think you might already be there. Currently the concept of cocoon is a
great one. I create a piepline and cocoon shunts it from a
to b, applying the transforms and so on. Great development effort. Pardon
the language but its a shitty user effort. Just look at
one of your paragraphs in the linked archive.


"If we don't do this, not only Cocoon will get bigger and bigger (and
start appearing more as a distribution of technologies, than a
framework), but users will find it harder and harder to modify it for
their specific needs."


And that is the crux of the problem. Whoever is heading the project seems a
bit confused. People dont want to MODIFY cocoon. They
want to USE cocoon. They want to install cocoon's mechanics, then drop in
their pipelines and go. Cocoon is now trying to do all
sorts of things that dont need to be done imho. The number of features is so
staggering that gettign started is near impossible. But
as I get more into the product, I find myself saying, petulantly, "But I
just wanted the pipeline!" And that is all that I wanted.
To have a pipeline. To be able to say to cocoon, "Yeah, well ... in your
pipeline whenever someone hits URL x, go to pipeline Z and
run my custom class (which connects to ejbs and so on) and transform it with
stylesheet Y and give it back to the user.

"But you arent understanding how cocoon works Robert!" BINGO!! You hit it
right there on the head. I dont want to understand how it
works. As a user Im not interested. When reading the JBoss documentation, I
skip over all the architecture stuff and the development
stuff. As a user, this stuff is irrelevant to me. Object oriented
programmign is supposed to guarantee to provide me with an
interface and then implement some functionality. How? Who the hell cares? Im
a user of it. My prime computing expertise is in the
back end side of EJBs and issues that pertain to them. I want to USE cocoon,
not develop on it.

Possible solutions to this.

1) Rearchitect cocoon to implement some sort of deployment mechanism, such
as COB. The problem here is that then you have to get
that working with application servers and so on. The other problem is
inertia. Gettign the masses of developers to learn a
new-unstandardized deployment mechanism.

2) MERGE it with tomcat in the way JBoss has merged with tomcat. I download
JBoss and they are like "well tomcat is included." I say
"cool" and drop in my wars and go. If cocoon had a basic mechanism install
that could be installed into tomcat than the situation
would be aleviated. Users of the product drop their wars into tomcat as
normal with a sitemap file in the WEB-INF directory and
their special generators an so on in the classes directory. Cocoon magically
wires together the pipeline. No worrying about how to
configure cocoon or what properties to give it or so on. Thats left to
advanced users under the heading of "customizing your
install".

At any rate I can see the learning curve for this product is steep. And
cocoon is mainly going o suffer from people like me. People
whoe would love to use it but dont have a month to blow trying to get a
technology to work that is merely suppsed to be an EASY way
to develop a polymorphic presentation layer.

Lastly, flaming is not an option. These are the opinions from a newbie
comming into cocoon. Readers of this list can flame all they
want but that is just hiding from the very real problems.

-- Robert

- Original Message -
From: "Steven Noels" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 25, 2003 3:43 PM
Subject: Re: Cocoon is too complex for consumption?


> Jeff Turner wrote:
>
> > http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition
> > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101603335007960&w=2
> > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101732982704553&w=2
>
> oh, but that is unfair since you are a Cocoon committer and you have
> easier access to such things... not! ;-)
>
> 
> --
> Steven Noelshttp://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> Read my weblog athttp://blogs.cocoondev.org/stevenn/
> stevenn at outerthought.orgstevenn at apache.org
>
>

RE: Cocoon is too complex for consumption?

[Antonio Gallardo]

Alireza Fattahi dijo:
> I think cocoon needs some thing like blank web application( if it does
> not already have, I am new to Coocon:) ). There is one in Struts.

please check:

http://wiki.cocoondev.org/Wiki.jsp?page=Tutorials

It will helps you to understand the USER philosophy behind this incredible
web machine in less than 3 hours! (Sams does not publish a similar book!
lol). And you will after that start to build your own web application.

Best Regards,

Antonio Gallardo



>
> -Original Message-
> From: Steven Noels [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, January 25, 2003 6:14 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Cocoon is too complex for consumption?
>
> Jeff Turner wrote:
>
>> http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition
>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101603335007960&w=2
>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101732982704553&w=2
>
> oh, but that is unfair since you are a Cocoon committer and you have
> easier access to such things... not! ;-)
>
> 
> --
> Steven Noelshttp://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> Read my weblog athttp://blogs.cocoondev.org/stevenn/
> stevenn at outerthought.orgstevenn at apache.org
>
>
> -
> Please check that your question  has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail:   <[EMAIL PROTECTED]>
>
> -
> Please check that your question  has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail:   <[EMAIL PROTECTED]>




-
Please check that your question  has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: Cocoon is too complex for consumption?

[Robert Simmons]

I think you might already be there. Currently the concept of cocoon is a great one. I 
create a piepline and cocoon shunts it from a
to b, applying the transforms and so on. Great development effort. Pardon the language 
but its a shitty user effort. Just look at
one of your paragraphs in the linked archive.


"If we don't do this, not only Cocoon will get bigger and bigger (and
start appearing more as a distribution of technologies, than a
framework), but users will find it harder and harder to modify it for
their specific needs."


And that is the crux of the problem. Whoever is heading the project seems a bit 
confused. People dont want to MODIFY cocoon. They
want to USE cocoon. They want to install cocoon's mechanics, then drop in their 
pipelines and go. Cocoon is now trying to do all
sorts of things that dont need to be done imho. The number of features is so 
staggering that gettign started is near impossible. But
as I get more into the product, I find myself saying, petulantly, "But I just wanted 
the pipeline!" And that is all that I wanted.
To have a pipeline. To be able to say to cocoon, "Yeah, well ... in your pipeline 
whenever someone hits URL x, go to pipeline Z and
run my custom class (which connects to ejbs and so on) and transform it with 
stylesheet Y and give it back to the user.

"But you arent understanding how cocoon works Robert!" BINGO!! You hit it right there 
on the head. I dont want to understand how it
works. As a user Im not interested. When reading the JBoss documentation, I skip over 
all the architecture stuff and the development
stuff. As a user, this stuff is irrelevant to me. Object oriented programmign is 
supposed to guarantee to provide me with an
interface and then implement some functionality. How? Who the hell cares? Im a user of 
it. My prime computing expertise is in the
back end side of EJBs and issues that pertain to them. I want to USE cocoon, not 
develop on it.

Possible solutions to this.

1) Rearchitect cocoon to implement some sort of deployment mechanism, such as COB. The 
problem here is that then you have to get
that working with application servers and so on. The other problem is inertia. Gettign 
the masses of developers to learn a
new-unstandardized deployment mechanism.

2) MERGE it with tomcat in the way JBoss has merged with tomcat. I download JBoss and 
they are like "well tomcat is included." I say
"cool" and drop in my wars and go. If cocoon had a basic mechanism install that could 
be installed into tomcat than the situation
would be aleviated. Users of the product drop their wars into tomcat as normal with a 
sitemap file in the WEB-INF directory and
their special generators an so on in the classes directory. Cocoon magically wires 
together the pipeline. No worrying about how to
configure cocoon or what properties to give it or so on. Thats left to advanced users 
under the heading of "customizing your
install".

At any rate I can see the learning curve for this product is steep. And cocoon is 
mainly going o suffer from people like me. People
whoe would love to use it but dont have a month to blow trying to get a technology to 
work that is merely suppsed to be an EASY way
to develop a polymorphic presentation layer.

Lastly, flaming is not an option. These are the opinions from a newbie comming into 
cocoon. Readers of this list can flame all they
want but that is just hiding from the very real problems.

-- Robert

- Original Message -
From: "Steven Noels" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 25, 2003 3:43 PM
Subject: Re: Cocoon is too complex for consumption?


> Jeff Turner wrote:
>
> > http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition
> > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101603335007960&w=2
> > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101732982704553&w=2
>
> oh, but that is unfair since you are a Cocoon committer and you have
> easier access to such things... not! ;-)
>
> 
> --
> Steven Noelshttp://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> Read my weblog athttp://blogs.cocoondev.org/stevenn/
> stevenn at outerthought.orgstevenn at apache.org
>
>
> -
> Please check that your question  has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail:   <[EMAIL PROTECTED]>
>


-
Please check that your question  has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

RE: Cocoon is too complex for consumption?

[Alireza Fattahi]

I think cocoon needs some thing like blank web application( if it does not
already have, I am new to Coocon:) ). There is one in Struts. 

-Original Message-
From: Steven Noels [mailto:[EMAIL PROTECTED]] 
Sent: Saturday, January 25, 2003 6:14 PM
To: [EMAIL PROTECTED]
Subject: Re: Cocoon is too complex for consumption?

Jeff Turner wrote:

> http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101603335007960&w=2
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101732982704553&w=2

oh, but that is unfair since you are a Cocoon committer and you have 
easier access to such things... not! ;-)


-- 
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org


-
Please check that your question  has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

-
Please check that your question  has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: Cocoon is too complex for consumption?

[Steven Noels]

Jeff Turner wrote:


http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101603335007960&w=2
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101732982704553&w=2


oh, but that is unfair since you are a Cocoon committer and you have 
easier access to such things... not! ;-)


--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

RE: Cocoon is too complex for consumption?

[Geoff Howard]

I think a practical and attainable suggestion that could come out of this
would be to provide a minimal binary distribution along with the "everything
but the kitchen sink" model.  The suggestion for new people would be to
download both, play with the kitchen sink, and then start developing their
app on the stripped down version.

Adding in the few things you need that aren't standard (with a full version
to refer to for examples) is probably going to be easier for new users than
digging through to determine what is not needed.  And obviously some people
don't want to have to build from source, which I understand.  I don't build
apache or tomcat from source unless I have to for some reason, and then I
expect some complexity.

> -Original Message-
> From: Jeff Turner [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, January 25, 2003 8:06 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Cocoon is too complex for consumption?
>
>
> > > So how could cocoon be of use to me and others like me? If I
> could build a
> > > war with simply any special classes I have (generators, etc)
> my XSL pages
> > > and a sitemap. Then I deploy that war and cocoon figures out
> how to wire
> > > things together.
> >



> > In general I agree that Cocoon is too "feature-oriented" and not at all
> > "user-oriented".
> > If you know the product as the back of your hand, yes, you
> think everything is
> > dirt easy, but it is overwhelming to get started. (The good
> news is that it
> > is 10x better now than in the "old days", when you needed ~10
> additional
> > downloads and installations.)
> >
> > In fact, I think Cocoon is so powerful, that it has kind of
> grown out of its
> > "servlet" image. It should traverse to the next level (or two),
> and has its
> > own deployment system. Collect your stuff (sitemap and all)
> into a JAR and
> > "hand it over". It is almost like that already, and should be a
> fairly easy
> > addition to make, but the developer community is much more focused on
> > additional features.
>
> http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101603335007960&w=2
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101732982704553&w=2
>

Of course blocks when finished should (and already do if you're willing to
work from source dist) go a long way to helping identify and exclude
unneeded pieces.

Geoff


-
Please check that your question  has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: Cocoon is too complex for consumption?

[Jeff Turner]

On Sat, Jan 25, 2003 at 06:22:10PM +0800, Niclas Hedhman wrote:
> On Saturday 25 January 2003 14:17, Robert Simmons wrote:
> > That is the impression that I am getting and I'm curious as to feedback
> > from list users.
> 
> I bet you will ;o)
> 
> > So how could cocoon be of use to me and others like me? If I could build a
> > war with simply any special classes I have (generators, etc) my XSL pages
> > and a sitemap. Then I deploy that war and cocoon figures out how to wire
> > things together.
> 
> In general I agree that Cocoon is too "feature-oriented" and not at all 
> "user-oriented".
> If you know the product as the back of your hand, yes, you think everything is 
> dirt easy, but it is overwhelming to get started. (The good news is that it 
> is 10x better now than in the "old days", when you needed ~10 additional 
> downloads and installations.)
> 
> In fact, I think Cocoon is so powerful, that it has kind of grown out of its 
> "servlet" image. It should traverse to the next level (or two), and has its 
> own deployment system. Collect your stuff (sitemap and all) into a JAR and 
> "hand it over". It is almost like that already, and should be a fairly easy 
> addition to make, but the developer community is much more focused on 
> additional features.

http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101603335007960&w=2
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101732982704553&w=2



--Jeff

> Well, well... 
> 
> Niclas
> 

-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

RE: Cocoon is too complex for consumption?

[Jeremy Aston]

There are good reasons why ctwig is hidden now, mainly because it fell out
of step with documentation as that moved on.  I have intended for sometime
to update the stuff so that it can go back into the "mainstream" examples
but it has had to drop down my priority list for various reasons.  Having
said that, IMHO there are a shed load of places (including the dist docs)
that cover basic xml/xslt/xsp handling with Cocoon.  So why is it that
people feel Cocoon is too difficult to get into?  Does ctwig still fill a
gap?  Could we have even more simple examples, wars etc that people can just
pick up and use?

I am personally very concerned that the perception is still of Cocoon as a
difficult beast to get into.  The recent threads on this are a kick up the
backside for me as far as getting ctwig up to date goes but it would be nice
to know that that is still what is needed.  I promise to work on this in the
very near future so let me know if you think anything else needs doing to
make being a Cocoon newbie as welcoming a prospect as possible

rgds

Jeremy


> -Original Message-
> From: e nio [mailto:[EMAIL PROTECTED]]
> Sent: 25 January 2003 07:22
> To: [EMAIL PROTECTED]
> Subject: Re: Cocoon is too complex for consumption?
>
>
>
>   At one time there was the CTWIG as part of the samples I
> believed or maybe it was a link on the getting started
> documentation. Yes it would be nice for us newbies to start with
> that and get acquainted with cocoon.  Anyhow here is the link
> from Jeremy's site:
> http://www.pigbite.co.uk/ctwig/blddocs/index.html
>
> And if you do a search on the humongous cocoon source, you'd
> find ctwig under documentation/xdocs/ctwig.
>
> enio
>
> __
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
>
> -
> Please check that your question  has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail:   <[EMAIL PROTECTED]>
>


__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

-
Please check that your question  has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: Cocoon is too complex for consumption?

[Niclas Hedhman]

On Saturday 25 January 2003 14:17, Robert Simmons wrote:
> That is the impression that I am getting and I'm curious as to feedback
> from list users.

I bet you will ;o)

> So how could cocoon be of use to me and others like me? If I could build a
> war with simply any special classes I have (generators, etc) my XSL pages
> and a sitemap. Then I deploy that war and cocoon figures out how to wire
> things together.

In general I agree that Cocoon is too "feature-oriented" and not at all 
"user-oriented".
If you know the product as the back of your hand, yes, you think everything is 
dirt easy, but it is overwhelming to get started. (The good news is that it 
is 10x better now than in the "old days", when you needed ~10 additional 
downloads and installations.)

In fact, I think Cocoon is so powerful, that it has kind of grown out of its 
"servlet" image. It should traverse to the next level (or two), and has its 
own deployment system. Collect your stuff (sitemap and all) into a JAR and 
"hand it over". It is almost like that already, and should be a fairly easy 
addition to make, but the developer community is much more focused on 
additional features.

Well, well... 

Niclas

-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: Cocoon is too complex for consumption?

[Steven Noels]

Robert Simmons wrote:


Users tell me to go to wiki (which is down allot or just really slow) to 
find information but its like hunting for an needle in a haystack.

This is worrying me. Is that the case? Has anyone experienced 
performance issues with http://wiki.cocoondev.org/ ?



I guess I'm rambling a bit and I'm sorry. Its just frustrating to spend 
several hours on something and essentially get nowhere. Cocoon may be a 
powerful product, but it will never go mainstream in the web, imho, with 
its level of difficulty in understanding it.

... it seems like you are very opinionated, and should thus be a good 
contributor to the Cocoon Documentation effort.


--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: Cocoon is too complex for consumption?

[e nio]

  At one time there was the CTWIG as part of the samples I
believed or maybe it was a link on the getting started
documentation. Yes it would be nice for us newbies to start with
that and get acquainted with cocoon.  Anyhow here is the link
from Jeremy's site:
http://www.pigbite.co.uk/ctwig/blddocs/index.html

And if you do a search on the humongous cocoon source, you'd
find ctwig under documentation/xdocs/ctwig.  

enio

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Cocoon is too complex for consumption?

[Robert Simmons]

That is the impression that I am getting and 
I'm curious as to feedback from list users. 
 
Basically my experience is one of confusion. I 
downloaded the war and deployed it. The samples and stuff deploy fine but now 
where does one go from there? The samples and tutorials are splattered all over 
the net. Users tell me to go to wiki (which is down allot or just really slow) 
to find information but its like hunting for an needle in a haystack. The 
default cocoon war contains thousands of files. What does one do to deploy a new 
application? copy the whole immense framework to a new jar? That seems overly 
complex for a user that just wants to generate some XML and some XSL and leap 
off to the races. Its almost like cocoon is buried under complexity. 

 
Now I am even being told that in order to use the 
product, I need to get it from CVS and do builds and so on. For the end user 
this is just not a viable option. They just want to fire off some XSP pages, 
some XML and drop it in a war and go. Some 12 hours after I started 
investigating this technology,  still have only a vague clue of what I 
would need to actually accomplish something. The content of the war is a big 
part of that problem. The word "overkill" immediately leaps to mind. For the new 
person to this technology, knowing what each thing does, is nearly impossible. 

 
I guess that's what it comes down to for me in the 
end. I started evaluating using cocoon to replace a static servlet that 
generates XML manually. The goal was to simplify things by using cocoon. I 
thought I could just transform that servlet into a cocoon generator, drop it in 
the right place and go. Doing a lengthy build process, configuration, decoding 
of what the MOUNTAIN of values in the MOUNTAIN of configuration files mean is 
just a waste of time for me.
 
In the end, I suppose I'm going to have to stick 
with the servlet strategy. as a professional developer, I don't have 2 weeks to 
waste figuring out how to get something working. You look at tomcat for example. 
The hello world is simple. You drop the minimal 3 class war in tomcat and away 
it goes. Intimate knowledge of tomcat is not necessary. In fact most users of 
tomcat authentically don't care about its implementation. 
 
So how could cocoon be of use to me and others like 
me? If I could build a war with simply any special classes I have (generators, 
etc) my XSL pages and a sitemap. Then I deploy that war and cocoon figures out 
how to wire things together. 
 
I guess I'm rambling a bit and I'm sorry. Its just 
frustrating to spend several hours on something and essentially get nowhere. 
Cocoon may be a powerful product, but it will never go mainstream in the web, 
imho, with its level of difficulty in understanding it. The death of XML 
based web publishing perhaps? Is this why JSP is taking over? Although a flawed 
paradigm, it allows the neophyte to drop a single hello-world.jsp into a tiny 
war with 2 deployment descriptors and go. This is the simplicity that the users 
of the product want. Fiddling around with the base core of the product you are 
using just isn't in the budget. 
 
Well, I will stop babbling now and look forward to 
comments.