You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@cocoon.apache.org by Jeremy Aston <je...@yahoo.co.uk> on 2003/01/25 13:59:14 UTC
RE: Cocoon is too complex for consumption?
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:enio721@yahoo.com]
> Sent: 25 January 2003 07:22
> To: cocoon-users@xml.apache.org
> 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: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
>
__________________________________________________
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
Re: Cocoon is too complex for consumption?
Posted by Robert Simmons <de...@arcor.de>.
> 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 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.
When Im talkign development, Im not talking about development OF cocoon. Im
talking about devloping of my custom generators and so on to be sitting on
top of cocoon. In which case, in order to compile, Id nee to mount some jar
into my netbeans project forthe imports to work. That or stuff it in an ant
build.
> 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.
Yep. WOAH!!! My answer is "YEP." Thats got to floor ya. But you see what you
see as aesthetics, the newbies to cocoon see as a vicious growling dog with
sharp teeth. Does it matter that this dog is just playing and has no
intention to bite? Nope. You just run. HIDE EVERYTHING the user shouldnt be
screwing with.
> 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.
Avalon and Excalibur are primarily used in jakarta projects. For one reason
or another they havent hit mainstream. In addition they are both very old
java libraries going back at leat 4 JDKs and I can immagine some of it is now
in the JDK. At any rate, Im a cocoon user, not an avalon user. One technology
at a time. should I decide to pick up avalon, I can download it and start
learning it as well. Dont try and pull a Microsoft here. Microsoft uses the
strategy, "well now that you are using one of our products, you need to use
them all." Open source cant pull off that trick. in fact only a monopoly can.
> >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;
Like what? All I wanted was to drop a static XML and XSL hello world and see
a server side transform. That feature isnt in the release?
> That's why some folks pointed you to CVS.
CVS isnt always an option. Convincing management to put up a beta in
production is hard enough. Tellign them you are goign to deploy a
protentially unstable bleeding edge application to serve their sales site
witll prolly get you fired.
> There are also some speed/efficiency wins. There isn't much anyone can
> do about that unfortunately. You want it "right now" and some things
> simply aren't ready for release. If all you want is a simple Hello
> World example in Cocoon 2.0.4, I can give you a barebones sitemap if you
> like. It requires that you unpack the .war, erase the content, plug in
> a few files, and repackage the .war file.
Ohers have offered this. I appreciate it. However it should be somethign
generally available.
> Alternatively, because Tomcat
> can access webapps by directory as well as by .war file, you wouldn't
> necessarily have to repackage the .war file in order to test and fiddle
> around a bit. It's not a perfect solution, but I don't know if you will
> get a perfect solution according to your criteria right now. :-/
I use JBoss. Tomcat is merged with it in ways that I dont particularly care
about. End of story. Many potential users of cocoon will be people like me
who are looking to deploy powerful polymorphic fron ends to sophisticated
back-end distributed software. EJB is a REVOLUTION in server side
engineering. Thanks to it and JDO, Id have to go fish around for a SQL manual
to write a search. I dont bother with SQL anymore.
> >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.
>
> Unlikely to change at this point. Most of the time, you don't have to
> write Java code anyway (eg. LogTranformer) so you wouldn't necessarily
> see it. When accessing logging as a component, it's not clear that you
> are using Logkit (or any other package by name). In addition, many of
> the same constructs are there so if you are familiar with log4j, the
> logging API used in Cocoon should pose no challenges. But after all is
> said and done, there is absolutely nothing stopping you from using log4j
> in your own components if you are set on that goal.
Possibly but people now have huge production systems using Log4j. They like
to have one framework in whihc everythign is logged. Log4j has won the race
so brutally that the logging in JDK 1.4 was basically laughed out the door.
>
> Bear in mind, I am not a committer. I am only a user. I speak only for
> myself. I understand where you are coming from and I truly sympathize
> with your difficulties, but your tone carries expectations that these
> things will be solved in the timeframe you have deemed necessary. This
> is unlikely not because of lack of caring or because of any overt
> animosity; This is because even though many people agree with a good
> portion of your statements and suggestions, the work needs to get done
> by people. People need time. The things you have asked for are things
> that others have asked for and are things that people have taken an
> honest interest in improving.
>
> Also bear in mind that many people on these lists don't speak English as
> their first language. Just as acidic sarcasm comes off as ridiculously
> rude in many other countries/languages, some other languages have a
> fatalistic tone to them and translate to English as "that's just how
> things are." Americans hug and the French kiss -- substitution is often
> taken as an invasion of personal space. There needs to be a little
> flexibility taking this into account.
>
> And please believe that if I didn't care, I wouldn't have bothered
> writing this long email. ;-)
>
> - Miles
>
>
>
> ---------------------------------------------------------------------
> 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: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Cocoon is too complex for consumption?
Posted by Miles Elam <mi...@pcextremist.com>.
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/efficiency wins. There isn't much anyone can
do about that unfortunately. You want it "right now" and some things
simply aren't ready for release. If all you want is a simple Hello
World example in Cocoon 2.0.4, I can give you a barebones sitemap if you
like. It requires that you unpack the .war, erase the content, plug in
a few files, and repackage the .war file. Alternatively, because Tomcat
can access webapps by directory as well as by .war file, you wouldn't
necessarily have to repackage the .war file in order to test and fiddle
around a bit. It's not a perfect solution, but I don't know if you will
get a perfect solution according to your criteria right now. :-/
>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.
>
Unlikely to change at this point. Most of the time, you don't have to
write Java code anyway (eg. LogTranformer) so you wouldn't necessarily
see it. When accessing logging as a component, it's not clear that you
are using Logkit (or any other package by name). In addition, many of
the same constructs are there so if you are familiar with log4j, the
logging API used in Cocoon should pose no challenges. But after all is
said and done, there is absolutely nothing stopping you from using log4j
in your own components if you are set on that goal.
Bear in mind, I am not a committer. I am only a user. I speak only for
myself. I understand where you are coming from and I truly sympathize
with your difficulties, but your tone carries expectations that these
things will be solved in the timeframe you have deemed necessary. This
is unlikely not because of lack of caring or because of any overt
animosity; This is because even though many people agree with a good
portion of your statements and suggestions, the work needs to get done
by people. People need time. The things you have asked for are things
that others have asked for and are things that people have taken an
honest interest in improving.
Also bear in mind that many people on these lists don't speak English as
their first language. Just as acidic sarcasm comes off as ridiculously
rude in many other countries/languages, some other languages have a
fatalistic tone to them and translate to English as "that's just how
things are." Americans hug and the French kiss -- substitution is often
taken as an invasion of personal space. There needs to be a little
flexibility taking this into account.
And please believe that if I didn't care, I wouldn't have bothered
writing this long email. ;-)
- Miles
---------------------------------------------------------------------
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Cocoon is too complex for consumption?
Posted by Robert Simmons <de...@arcor.de>.
> 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. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Creating a CocoonBook review page ?
Posted by SAXESS - Hussayn Dabbous <da...@saxess.com>.
Hy e nio, Antonio and all the other readers of the
cocoon printed literatur
For me it would make sense to create a CocoonBookReview
page in the wiki. May i tear all infos about the available
books from this mailing list and make a start ?
regards, hussayn
e nio wrote:
> 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
>
--
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: dabbous@saxess.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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
RE: Cocoon is too complex for consumption?
Posted by e nio <en...@yahoo.com>.
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 <je...@yahoo.co.uk> 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:enio721@yahoo.com]
> > Sent: 25 January 2003 07:22
> > To: cocoon-users@xml.apache.org
> > 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:
> <co...@xml.apache.org>
> > For additional commands, e-mail:
> <co...@xml.apache.org>
> >
>
>
> __________________________________________________
> 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:
> <co...@xml.apache.org>
> For additional commands, e-mail:
> <co...@xml.apache.org>
>
__________________________________________________
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>