RE: Giving up! Cocoon too big, slow and confusing
Anthony Aldridge wrote: Hurrah! You're a brick! Like 'another brick in the wall'? Hmm, I already knew this, because many people called me this in the past 30 years (because of my last name, you can figure it out yourself why). Sorry, but my english is not good enough to figure out what you exactly mean by this. Can you enlighten me? PS: I hope it's a compliment! Thanks Carsten - 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: Giving up! Cocoon too big, slow and confusing
According to Babylon (usefull windows dictionnary wich work with onscreen OCR) : Brick = Chic type (mmm, something like cool guy) -Message d'origine- De: Carsten Ziegeler [mailto:[EMAIL PROTECTED]] Date: lundi 1 juillet 2002 08:52 À: [EMAIL PROTECTED] Objet: RE: Giving up! Cocoon too big, slow and confusing Anthony Aldridge wrote: Hurrah! You're a brick! Like 'another brick in the wall'? Hmm, I already knew this, because many people called me this in the past 30 years (because of my last name, you can figure it out yourself why). Sorry, but my english is not good enough to figure out what you exactly mean by this. Can you enlighten me? PS: I hope it's a compliment! Thanks Carsten - 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: Giving up! Cocoon too big, slow and confusing
thusly spake David Crossley: It amazes me that people have the time to compose email to the mailing list to tell us that they are too busy, and then have the hide to tell us that documentation is poor. Writing can be fast but submission + acceptance + check-in is not so straightforward. how about a model more like some kind of production line ? If someone volunteered to accept (and critique) (and organise) small submissions of a page or two, then non-core people could take some notes whilst teach themselves things, and so ease that learning curve for the next person. email: [EMAIL PROTECTED] These minidocs could be folded into the mainline docs, or turned into FAQ items, or How-To's, or whatever. I think that this decision, i.e. where to file new minidocs, should be the decision of a core doc person. it is not up to _me_ to decide whether the thing I'm writing a FAQ or a How-To, because (a) I don't have the big picture, and (b) the doc base already is sprawling and needs reorganisation, starting with the top-level menus... IMHO. very simply, I could email this minidoc coördinator asking if (s)he has Doc X, for example Directing servlet output into a Cocoon pipeline using Tomcat 4.x Filters. If such a minidoc does not yet exist, then I whip it up; if it does already exist, the minidoc coördinator emails it to me for my additions / comments. there could be a web page of existing minidoc titles. call it Pending Cocoon Documentation Fragments (WIP). this is where that PHP doc system (that someone provided a pointer to) seems to excel. man pages that can be annotated by the community. (hey won't someone implement this in Cocoon ? ;-) then there should also be a person to periodically incorporate the annotations into the main text. hth, fred -- fbaube @ welho.com + 358 41 536 8192 - 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: Giving up! Cocoon too big, slow and confusing
From: Per Kreipke [mailto:[EMAIL PROTECTED]] Stop suggesting that the people who are complaining contribute = I don't have a beef with the people exhorting people to contribute, but there is a chicken and egg problem of getting to the point where 1) it's worth my time to learn it 2) what I contribute is worthwhile to others. The gist of the first 10 replies to John's original post was for people like him to write the missing docs. He was talking about _starting up_ with the project and you're asking him to write documentation already? He barely got it running and much less committed to using it. We're really talking about getting people committed enough to contribute. They won't do the second without the first. And there are 1000's of other open source projects looking for contributions as well. Are we supposed to contribute to all of them to use them? I don't mind people not writing a full FAQ, but sometimes just asking for a _question_ (without them supplying the corresponding answer) would result in a very good FAQ document IMHO. J. PS, sorry for having only just caught up with this thread - I'm only subscribed to user at work. === Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other commitment through the use of this email. Experian Limited (registration number 653331). Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF - 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: Giving up! Cocoon too big, slow and confusing
Robert S. Koberg wrote: For example: - why is xsl:include and xsl:import bad - how should it be done - why is XPath's document() bad - how should it be done Guesses: - Check for changes of included and imported XSLT files was implemented only recently (in 2.0.3, don't try this with 2.0.2) - Using gets simply gets NPE for the second page hit in 2.0.2, (fixed in 2.0.3, at least for me) - Check for changes of documents referenced by document() still not implemented in 2.0.3. Actually, using document() in 2.0.3 results in an NPE because the CVS code fixing point one above cannot cope with this. - how do you reuse XML data that can be used for tabs, the nav, snailtrails and links throughout the content (so you basically have a lookup table as opposed to hard coding links) Hehe. Of course, I use xsl:import and document() quite extensively... With the possibility to refer to a variety of generators through internal pipelines you get a lot of power. Caching is the only promlem, I declared everything trivially as unchanging and cacheable, changes currently require a server shutdown and clearing the work directory. I hope Cocoon will have improved in this area once the issue becomes pressing for me. J.Pietschmann - 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]
Samples as tools for learning and development (Was: Giving up!Cocoon too big, slow and confusing)
Argyn Kuketayev wrote: I don't think that Cocoon is complex. I blame the very poor documentation. When you know how it works, it's simple. So, you have to get very familiar with the source codes to use Cocoon. I don't like it. I'd rather look under the hood only when I have non-trivial problems. Unfortunately, with Cocoon you have to do it all the time. E.g., Cocoon's samples are just to say hey, we have samples!. Not so. They are there as a learning tool for you. Yet they more than that. They provide the basis for you to create your own applications (copy-and-extend). Please read the following snippet from http://xml.apache.org/cocoon/overview.html#samples It will greatly assist your understanding of Cocoon to investigate behind-the-scenes, to find out how each sample is processed. Do this by looking at the actual XML documents provided in the distribution at webapp/docs/samples/ and by consulting the sitemap to see the processing steps that are defined. Please contribute other new samples as you see fit. I am interested to know how you propose to build a reliable finely-tuned publishing system using Cocoon without looking under the hood. I did not realise that we had reached that stage of automation yet. We certainly are aiming for that. In HEAD branch, the Samples are being re-organised into a set of clean, reliable, informative, individually-packaged samples. This makes it easy to use them as template apps. Eventually, high-level tools can utilise them. I hear that sitemap editing tools are starting to emerge too. For the moment you must look under the hood. Anyway, i find that getting my hands dirty is the best way to learn. Please follow the samples that others have tried to provide. You say that you need to get familiar with the source code in order to understand. Well, i do not touch any java code. I just copy and tweak the samples' xml/xsl files and sitemaps. --David - 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]
Elephants and Mavericks (Re: Giving up! Cocoon too big, slow and confusing)
Thanks for the honest words, instead of silence. I am reminded of the following definition: second-system effect n. When one is designing the successor to a relatively small, elegant, and successful system, there is a tendency to become grandiose in one's success and design an elephantine feature-laden monstrosity. The term was first used by Fred Brooks in his classic The Mythical Man-Month: Essays on Software Engineering. It described the jump from a set of nice, simple operating systems on the IBM 70xx series to OS/360 on the 360 series. A similar effect can also happen in an evolving system; see Brooks's Law, creeping elegance, creeping featurism. http://www.tuxedo.org/~esr/jargon/html/entry/second-system-effect.html The choice is to stick around and help fix things (if indeed they are broken), or jump to a lighter alternative like Maverick: Maverick is a minimalist web publishing framework which combines the best features of Struts and Cocoon and yet is far simpler than either. http://marc.theaimsgroup.com/?l=velocity-userm=102387923624439w=2 --Jeff On Wed, Jun 26, 2002 at 10:41:14PM -0400, John Austin wrote: I'm back from a short vacation in beautiful Chicago (it really is much nicer than Toronto or Montreal) and have waded back in to Cocoon for a couple of days. After just a few hours of poking around I have decided that it will be much simpler for me to simply hand-code a whole hat-full of servlets than to try and pull any meaning out of Cocoon and it's documentation. Fifteen hours on the Interstate wasn't as challenging as trying to figure out how one should check a Web Form this month but I didn't have that feeling of travelling backwards half of the time. I was also able to predict and achieve forward progress (for a change). Thanks guys, but no thanks. Maybe I'm getting old, but I really don't understand the need for all of the complexity and the lack of documentation in this product. On the other hand, I used to feel the same way about the mind-numbing complexity of a certain thirty-year-old mainframe operating system (MVS) produced by IBM back in the sixties and it's patching system (SMP4). So it can't just be my age. Anyway, Cocoon has cost me far morte (a typo that's better than the original word) time than it was worth. The chief problems appear to have been endlessly re-invented terminology for an overwhelming number of 'new concepts' and a complete lack of consistency between different components (i.e. functional code, non-functional examples, unbuildable documentation and a website that doesn't match up with any single released version of the project). I have a lot of respect for the ability of the people who have built this project, but I want them to know that their project appears to be out-of-control and could become very difficult to manage. If experienced developers (like myself) can't figure out how to use enough features in the product to make it worth using, then penetration will be limited and all of your efforts will be wasted. There is more to this business than stuffing in features at the expense of documentation and testing. You have a lot of very good ideas, but the execution of the project as a whole seems to be suffering. I know that I will often look at my JSP and servlet code and think 'XSP and Cocoon were sooo much better!' until I remember that I wasn't ever able to use enough of Cocoon to make a profit. Oh, well, at least all of my test systems have bags of memory now! - 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: Giving up! Cocoon too big, slow and confusing
To be fair, the documentation has greatly improved since I started with Cocoon (almost a year ago). I sent out an email earlier with specific comments (thank you Nicola for noticing:)), both the good and the bad.. and while I was looking through the existing documentation, I noticed a few things I hadn't noticed before. Here are the best answers for the specific questions that I've been able to come up with, hopefully they're helpful. Ricardo Trindade wrote: Ok. Where is the documentation for Pipeline Components ? Where is an in-depth description of each type of G enerator ? By pipeline components, do you mean sitemap components? You can find that (as well as in-depth descriptions of most Generators) at http://xml.apache.org/cocoon/userdocs/index.html. From the front page, you can just click on User Guide on the left and you'll get there. You might want to take a look at the Internal Pipeline snippet http://xml.apache.org/cocoon/snippet/snippet-internal-pipeline.html from the Snippets section, or the Sitemap documentation http://xml.apache.org/cocoon/userdocs/concepts/sitemap.html located in the Concepts section of the User's guide. (I think because the sitemap is so central, you might want to think about taking it outside of the concepts section and moving it into the main User Docs section? I don't intuitively look in the Concepts section for the sitemap documentation, that might just be me, though.) There is no depth to the documentation. One doesn't have to go very far to run out of documentation. In my mind, that's what this process is for; to find out the trouble areas and fix them. And as you've pointed out, depth is one of those trouble areas. One of my problems was the consistency; some docs really explained both the problem and the solution extremely well, while others just gave me a fully qualified classname, a one-sentence description, and whether or not it's cacheable (sometimes with a number of ?'s instead). But in the near future, if I can fully wrap my mind around some of these concepts enough to consider myself worthy of doc writing, I'll do so. The Tutorial. How do I write a simple data-base backed application ? One of the problems in the doc that I just noticed now is how hard it can be find something that you're looking for. I was just 12 hours ago that I had looked over the entire site, and I saw a really nice cocoon-specific database article. But now I can't remember if it was a how-to, a faq, or a tutorial. I think that's a problem... and my only suggestion on how to fix that is to either change the wording or make it really clear what goes in each, as well as edit gray areas. Taking a quick look through the site, however, I found the following: Dev Guide - Using Databases in Apache Cocoon (I thought the Dev Guide was for those who were developing Cocoon, not developing with Cocoon? the line seems blurry to me.. I find the javadoc from the Dev Guide useful, however I find the docs in the Users Guide useful as well.. I don't see the need for a seperation, and I find the seperation both confusing and time-consuming to repeatedly move from one section to the other.) http://xml.apache.org/cocoon/developing/datasources.html Users Guide - Concepts - Database Access (This one's a bit hard to find, I think; I ended up looking three times in the How-To, FAQ, Tutorial or Performance section. The concepts section doesn't stick out so well in my mind.) http://xml.apache.org/cocoon/userdocs/concepts/databases.html I can't promise that these are what you're looking for, but hopefully it's a start. And hopefully, if they're not what you're looking for, the questions that get raised will become questions posed to the list. all the best, Liam Morley - 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: Giving up! Cocoon too big, slow and confusing
Robert S. Koberg wrote: I (and probably many other XSLT-heavy folk) would very interested to know the best practices for cocoon shown in way that takes an XSLT based site and produces a best-practices cocoon based app. (I would love to see how Jorge Pietschman builds cocoon apps) It's interesting, because most of my work with cocoon has been java-based.. giving an object layer above a database schema, and assigning a transformer to look for certain xml elements, which then hands off the element and any sub-elements/attributes to another class, which takes care of spitting out the database-specific SAX elements into the stream. Are we violating best practice, or is this just another approach? We kind of like it:) For example: - why is xsl:include and xsl:import bad - how should it be done this is bad? hrm. There was another thread about how included/imported stylesheets don't get refreshed right away, but that bug has been fixed by Carsten apparently in the 2.0.3 code (or so says a recent thread). Are there other reasons this is bad? Are there other more desired solutions (other than sticking everything in the same XSL doc, or making multiple entries in the sitemap)? I'm interested. I've always used XML as a template of sorts (I'm currently trying to minimize the number of XML docs so that there are less changes to be made in updating them, and from what I read, I don't think aggregates will do it for me, nor am I sure I agree with the philosophy). Liam Morley - 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: Samples as tools for learning and development (Was: Giving up! Cocoon too big, slow and confusing)
-Original Message- From: David Crossley [mailto:[EMAIL PROTECTED]] Sent: Saturday, June 29, 2002 2:50 AM To: [EMAIL PROTECTED] Subject: Samples as tools for learning and development (Was: Giving up! Cocoon too big, slow and confusing) For the moment you must look under the hood. Anyway, i find that getting my hands dirty is the best way to learn. Please follow the samples that others have tried to provide. I always look at samples and docs. The issue is that there's not enough of them. And some people deny the very existance of this issue. However the docs are improving, and the message of this topic has been gotten, at least by few developers. Others are still in denial mode, but it's Ok. - 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: Samples as tools for learning and development (Was: Giving up! Cocoon too big, slow and confusing)
I always look at samples and docs. The issue is that there's not enough of them. And some people deny the very existance of this issue. I have never heard anyone deny that. However the docs are improving, and the message of this topic has been gotten, at least by few developers. Others are still in denial mode, but it's Ok. No, the bulk of the message I tried to deliver is: everyone is aware of it, people are working on it, if it truely bothers you, pay for your opensource software and be one of those people. - 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: Samples as tools for learning and development (Was: Giving up ! Cocoon too big, slow and confusing)
-Original Message- From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] Sent: Saturday, June 29, 2002 9:11 AM To: [EMAIL PROTECTED] Subject: Re: Samples as tools for learning and development (Was: Giving up ! Cocoon too big, slow and confusing) However the docs are improving, and the message of this topic has been gotten, at least by few developers. Others are still in denial mode, but it's Ok. No, the bulk of the message I tried to deliver is: everyone is aware of it, people are working on it, if it truely bothers you, pay for your opensource software and be one of those people. Andrew, that message was hidden in the noise. Trolling references, cathedral and bazaar mentions and other off-topic subjects did not help you, guys, to deliver the message. I'm left with the mixed feeling. At the end, I see that people recognize the issue and think of solutions, but at the same time the first reaction (He's giving up? Let him go.) is shocking. Also, repeating theme from many developers is MONEY, every other message advises me to pay MONEY. It's all off-topic. I'm amazed how experienced USENET, FIDO people were lost in off-topic. Forget Cathedral..., there's an issue. Solve it. We are not Free Software Prophets, we are programmers. Let's be pragmatic. I'm not complaining, it's just my poor English :) - 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: Samples as tools for learning and development (Was: Giving up ! Cocoon too big, slow and confusing)
On Saturday, June 29, 2002, at 10:04 AM, Argyn Kuketayev wrote: Also, repeating theme from many developers is MONEY, every other message advises me to pay MONEY. It's all off-topic. I'm amazed how experienced USENET, FIDO people were lost in off-topic. Forget Cathedral..., there's an issue. Solve it. We are not Free Software Prophets, we are programmers. Let's be pragmatic. I didn't interpret Andrew's message that way. I think he was suggesting you should pay (figuratively speaking) by helping (in *pragmatic* ways) to improve the docs. As for Free Software Prophets, we should be careful not to generalize or make broad assumptions about what motivates the people who participate on this list. People are here for different reasons, and IMHO that's a Good Thing. The beauty of it all is that in spite of our differences we can still work together and help to produce something truly amazing. -- Diana - 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: Giving up! Cocoon too big, slow and confusing
This is a VERY interesting thread because it shows that Cocoon has left the
developer-guru level and is now expanding into areas where normal
users/developers are trying to grasp exactly what Cocoon is and what it can
do for you.
So we need to take the criticsm seriously - even though those that have been
around Cocoon for longer may not understand why the person is having those
problems. Just as a native English speaker may not understand why others
find it hard to learn the language.
I will comment on a couple of points in new threads.
Matthew
--
Open Source Group Cocoon { Consulting, Training, Projects }
=
Matthew Langham, SN AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 [EMAIL PROTECTED] - http://www.s-und-n.de
-
Cocoon book:
http://www.amazon.com/exec/obidos/ASIN/0735712352/needacake-20
=
-
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: Giving up! Cocoon too big, slow and confusing
On Thursday 27 June 2002 05:26 pm, you wrote: I understand the complaints and agree with many of them, but I think that they are somewhat abstract or ambiguous. may you detail them so that they can be solved? Ok. Where is the documentation for Pipeline Components ? Where is an in-depth description of each type of G enerator ? it would be very helpful for all of us. Thanks to all the contributors to the cocoon project, it is a great product, but remember that one of the principles of programming is being humble to accept that things can be improved. Regards for example Documentation is scarce [ what part is scarce? all of it? There is no depth to the documentation. One doesn't have to go very far to run out of documentation. XSP? ] Documentation is outdated [the same] few examples [which functionality needs more examples urgently?] The Tutorial. How do I write a simple data-base backed application ? stabilization [any comments? ] etc As I said earlier, it feels like there is a stampede to generate features and no discipline to complete the existing project. I suspect that this is due to personality traits and intellectual capabilities of some of the developers. In my career, I have encountered many superlative individuals. A small number of these have immense capacities for rote memorization. This is a distinct ability of some individuals and is as great a gift as abstact reasoning and other intellectual skills. Unfortunately, gifted individuals often fail to realize that half of us are below average in everything ;-). Hell, we're all below average in something. Anyway, I have seen a lot of code written by genius-level people who fail to understand that many of us do not memorize well. The documentation is as important as (more important than) the code because nothing gets widely accepted unless it is understandable. Look at Perl as an example. Larry had some weird ideas and implemented them. These didn't hold the language back BECAUSE the documentation was excellent. Now Cocoon has lots of new ideas but it lacks explanation through documentation. The FAQ ... lets not go there ... I can never even FIND an FAQ ... The slope of the learning curve is steep and there is nothing to hold on to. When you do find a hand-hold, it breaks off! - 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: Giving up! Cocoon too big, slow and confusing
A few comments on various raised points:
3) Serious problems (hours lost) upgrading from 2.0 to 2.0.2 - looking
at the change logs for potential hints at what was necessary was a
non-starter.
Changes between releases must be documented so that the migration is a
painless as _possible_. But if 2.0 provides what is needed then perhaps
upgrading is not always the best idea. We don't upgrade all our production
installations of Cocoon each time there is a new release. We have Cocoon
based sites that are happily running a pre-2.0 version of Cocoon.
this will be since there have been significant changes (forms and
authentication system to just name a few at the feature level) since
those books have gone to publishing.
Unfortunately this is _always_ the case. We finished our book in March (!)
and the printing process is such that it just takes that long before the
book hits the shelves. There is nothing we (as the authors) can do about it
(apart from preventing new Cocoon releases :-)). On the other hand we
decided to include a CD containing a defined version of Cocoon so that the
details in the book match the software. The concepts have not changed
between 2.0 and 2.0.x - but things have been added.
Matthew
--
Open Source Group Cocoon { Consulting, Training, Projects }
=
Matthew Langham, SN AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 [EMAIL PROTECTED] - http://www.s-und-n.de
-
Cocoon book:
http://www.amazon.com/exec/obidos/ASIN/0735712352/needacake-20
=
-
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: Giving up! Cocoon too big, slow and confusing
We give help. *Not* complete solutions. We are not paid for it, it's
all free help.
Yes. If you want commecial support for Cocoon, get commecial support
for cocoon.
We provide commercial support for Cocoon - and guess what happens when
people contact us:
Them: We are interested in support for Cocoon
Us: We can provide that at xxx ?/$
Them: You mean I will have to pay? But Cocoon is open source!
Them: click.
I am not saying this is always the case - but it is quite common.
Matthew
--
Open Source Group Cocoon { Consulting, Training, Projects }
=
Matthew Langham, SN AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 [EMAIL PROTECTED] - http://www.s-und-n.de
-
Cocoon book:
http://www.amazon.com/exec/obidos/ASIN/0735712352/needacake-20
=
-
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: Giving up! Cocoon too big, slow and confusing
This is both a serious problem in terms of documantation/tools etc.. But
also in terms of cocoon itself. Some of the points are valid, not just in
terms of whether it's documented or not, but in terms of the actual system.
You know how much most people on this list love and respect cocoon, but
sometimes it does seem over complex and dense - even to those who have been
around the project for some time.
I know I started a thread talking about developing a front end content
management app (really a cocoon management app) and didn't have the
time/resources to properly follow up - but without serious consideration to
how end-users sre going to use the product, it's almost inevitable that
Cocoon will end up being a specialist product mainly for the people who
have been involved increating it.
I reckon either:
1/ Cocoon config (sitemap etc) is radically simplified
2/ Tools are created to create the config
Otherwise the great potential of the project may end up unfulfilled.
Re: a previous mail on this subject:
Genius level people not understanding other's inability to memorise
aspects of the project! RUBBISH, people who have inside knowledge often
appear to be geniuses and magicians, it's a mirage! True genius
communicates - which is precisely the problem highlighted on this thread -
the relatively poor documentation/tools regarding Cocoon against the
fabulous technology.
Once someone said: UNIX is not NOT user-friendly, it's just choosy about
its friends!
I reckon the time has past when we can be choosy - otherwise .NET rubbish
will start becoming another cross we all have to bear (as developers), when
properly presented, Cocoon could provide a real way forwards to the web-app
community!
Regards
Anthony Aldridge
Application Development
Managed Intranet Hosting
JPMorganChase
PS I've developed an alternative way to use cocoon, based on what I call
'JBXSP' (JavaBeanExtensibleServerPages). ALL the logic, and the xml is
generated via introspection from pure java (no embedding java logic in
xml-style files). All that's required then is the xslt stylesheets to
translate, and a single xml file to call the basic java system. Ultimtely I
want to keep the xslt files as fragments in a database to be called by the
JBXSP system as required.
For me (as a java programmer) this is perfect - it may not suit everyone's
needs but I'll be happy to share the ideas with the community, if anyone's
interested.
Matthew Langham [EMAIL PROTECTED] on 06/28/2002 07:45:14 AM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: RE: Giving up! Cocoon too big, slow and confusing
A few comments on various raised points:
3) Serious problems (hours lost) upgrading from 2.0 to 2.0.2 - looking
at the change logs for potential hints at what was necessary was a
non-starter.
Changes between releases must be documented so that the migration is a
painless as _possible_. But if 2.0 provides what is needed then perhaps
upgrading is not always the best idea. We don't upgrade all our production
installations of Cocoon each time there is a new release. We have Cocoon
based sites that are happily running a pre-2.0 version of Cocoon.
this will be since there have been significant changes (forms and
authentication system to just name a few at the feature level) since
those books have gone to publishing.
Unfortunately this is _always_ the case. We finished our book in March (!)
and the printing process is such that it just takes that long before the
book hits the shelves. There is nothing we (as the authors) can do about it
(apart from preventing new Cocoon releases :-)). On the other hand we
decided to include a CD containing a defined version of Cocoon so that the
details in the book match the software. The concepts have not changed
between 2.0 and 2.0.x - but things have been added.
Matthew
--
Open Source Group Cocoon { Consulting, Training, Projects }
=
Matthew Langham, SN AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 [EMAIL PROTECTED] - http://www.s-und-n.de
-
Cocoon book:
http://www.amazon.com/exec/obidos/ASIN/0735712352/needacake-20
=
-
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: Giving up! Cocoon too big, slow and confusing (Blocks will help for sure)
On Friday 28 June 2002 10:22, Anthony Aldridge wrote: . . . You know how much most people on this list love and respect cocoon, but sometimes it does seem over complex and dense - even to those who have been around the project for some time. . . . I think the core developers are fully aware of this fact, and the Cocoon Blocks [1] concept will make a big difference here. Trimming down the core and making most or all components pluggable will help a lot in differentiating between stable/well-known and experimental/mysterious components. -Bertrand [1] (rather technical and probably not final): http://marc.theaimsgroup.com/?l=xml-cocoon-devm=101862084628687w=2 - 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: Giving up! Cocoon too big, slow and confusing
The documentation should follow the learning curve. May be each doc should have a requirement section, which lists all the notions that must be well known to understand the current topic. And docs should be rated under a system of Beginner, Intermediate and Advanced topics. In fact, i think everybody should use wikiLand : http://www.anyware-tech.com/wikiland I promise that if someone else than me posts something on wikiLand, I code the XSLT to export to xdocs :-) That's a deal, dudes! The second thing that makes Cocoon obscure is the lack of intuitive debugging system. An intuitive debugging system allows the user to _see_ the behaviour of the program. I think that a Cocoon app which could display on the client how the sitemap resolved for a given URI, which could allow to browse between a sitemap resolving report and XML/XSL files involved in the resulting pipeline, all that would make newbies get into Cocoon more easily. The first step should be an easy step. And last thing, error management should be heavily handled in Cocoon. No more strange messages on the client side. My humble 2 cents. - 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: Giving up! Cocoon too big,slow and confusing (Blocks will he lp for sure)
I think the core developers are fully aware of this fact, and the Cocoon Blocks [1] concept will make a big difference here. Trimming down the core and making most or all components pluggable will help a lot in differentiating between stable/well-known and experimental/mysterious components. -Bertrand With dependencies management, administration/upgrading interface, rights management and debugging facilities? And docs? Wow :-) - 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: Giving up! Cocoon too big, slow and confusing
Everyone stop, take a breathe, get a cup of coffee and go read The Cathedral and the Bazaar http://tuxedo.org/~esr/writings/cathedral-bazaar/ or similar writings about how Open Source Software operates. It seems that many people here are missing the point. It amazes me that people have the time to compose email to the mailing list to tell us that they are too busy, and then have the hide to tell us that documentation is poor. If each of us add one FAQ to the document collection, then the lack will be addressed very quickly. That is OSS. If you see an issue, the onus is on you to help remedy that. Everyone benefits from the work of each one. There is no such separate thing as they, the developers. Rather it is we the community. Anyone who contributes a patch (code or doc) is instantly transformed from being a user into a developer. Users use, contributers build projects. Thanks for raising this topic. I do sympathise with you about the complexities and inadequacies. We have all been though that and still do. None of us know all of Cocoon capabilities and would all benefit from doc contributions. Please help. --David - 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: Giving up! Cocoon too big, slow and confusing
Well said indeed. I guess that's the reason I've never complained about Cocoon documentation; I don't feel I have the right to ;-) -Original Message- From: David Crossley [mailto:[EMAIL PROTECTED]] Sent: Friday, June 28, 2002 12:13 PM To: [EMAIL PROTECTED] Subject: Re: Giving up! Cocoon too big, slow and confusing Everyone stop, take a breathe, get a cup of coffee and go read The Cathedral and the Bazaar http://tuxedo.org/~esr/writings/cathedral-bazaar/ or similar writings about how Open Source Software operates. It seems that many people here are missing the point. It amazes me that people have the time to compose email to the mailing list to tell us that they are too busy, and then have the hide to tell us that documentation is poor. If each of us add one FAQ to the document collection, then the lack will be addressed very quickly. That is OSS. If you see an issue, the onus is on you to help remedy that. Everyone benefits from the work of each one. There is no such separate thing as they, the developers. Rather it is we the community. Anyone who contributes a patch (code or doc) is instantly transformed from being a user into a developer. Users use, contributers build projects. Thanks for raising this topic. I do sympathise with you about the complexities and inadequacies. We have all been though that and still do. None of us know all of Cocoon capabilities and would all benefit from doc contributions. Please help. --David - 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: Giving up! Cocoon too big, slow and confusing
Absolutely! BUT, the point isn't that everyone's dissing Cocoon, it's that a weakness has been identified, and is being discussed. No need to be defensive about it - that's what will drive people to amend the situation. Regards Anthony Aldridge Application Development Managed Intranet Hosting JPMorganChase David Crossley [EMAIL PROTECTED] on 06/28/2002 10:12:54 AM Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Re: Giving up! Cocoon too big, slow and confusing Everyone stop, take a breathe, get a cup of coffee and go read The Cathedral and the Bazaar http://tuxedo.org/~esr/writings/cathedral-bazaar/ or similar writings about how Open Source Software operates. It seems that many people here are missing the point. It amazes me that people have the time to compose email to the mailing list to tell us that they are too busy, and then have the hide to tell us that documentation is poor. If each of us add one FAQ to the document collection, then the lack will be addressed very quickly. That is OSS. If you see an issue, the onus is on you to help remedy that. Everyone benefits from the work of each one. There is no such separate thing as they, the developers. Rather it is we the community. Anyone who contributes a patch (code or doc) is instantly transformed from being a user into a developer. Users use, contributers build projects. Thanks for raising this topic. I do sympathise with you about the complexities and inadequacies. We have all been though that and still do. None of us know all of Cocoon capabilities and would all benefit from doc contributions. Please help. --David - 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: Giving up! Cocoon too big, slow and confusing
From: Luca Morandini [mailto:[EMAIL PROTECTED]] o The entry How do I hide cocoon in the URL's once I integrate using mod_jk as shown above? could be improved, as I did not find it helpful. I could make specific suggestions, but I think that would be outside the context of this list. Ok, ok, I've just improved it, and it'll be posted very soon by Diana. BTW, does anyone know whether setting /cocoon as default Docbase works for servlets containers other than Tomcat ? Yes. Only sometimes it is called not default Docbase but webapp to URI mapping :) For resin, this will be: web-app id='/' ... /web-app For WebLogic (IIRC): WebServer DefaultWebApp=cocoon ... / Etc. PS: 143 emails to go :( Vadim Best regards, - Luca Morandini GIS Consultant [EMAIL PROTECTED] http://utenti.tripod.it/lmorandini/index.html - - 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: Giving up! Cocoon too big, slow and confusing
Hello John, On Thursday 27 June 2002 04:41, John Austin wrote: . . . After just a few hours of poking around I have decided that it will be much simpler for me to simply hand-code a whole hat-full of servlets than to try and pull any meaning out of Cocoon and it's documentation. . . . First thanks for expressing yourself on this mailing list, many people might have just quit without saying anything! As is the case with many open-source projects (or any project during its construction phase), I think understanding Cocoon is possible in a few hours, but requires some help from the community. You're right that the documentation is far from perfect at this time, but I think the level of support that you might get by asking focused questions on the mailing lists is way superior to many commercial support offerings. This will usually make up for the lack of consistency or depth of the documentation, although your mileage may vary depending on what components you're asking about (which might also tell you which components are most well-known and/or stable). There also a few books coming out, notably Matthew Langham and Carsten Ziegeler's excellent one [1], which should be available now or shortly. That doesn't answer your concern today but should do so soon. I don't think Cocoon is out-of-control today, it's just being evolved at an incredibly quick pace by a great but loosely-coupled team of developers. Not being able to contribute code today, I'm watching what's going on in amazement and learning a few lessons about why some projects (like Cocoon IMHO) work and others don't.. Keeping up with the pace is hard and you're right that it is hard to find out what you can reasonably use today and what are still moving targets, among the many available components. Hopefully the current documentation effort will make this better, but in the meantime I'm confident that with a little help from the community it is very possible to get a lot of productive work done today with Cocoon! Regards, -- Bertrand Delacrétaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding. disclaimer: eternity is very long. mostly towards the end. get ready. [1 ] http://www.amazon.com/exec/obidos/ASIN/0735712352/needacake-20 - 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: Giving up! Cocoon too big, slow and confusing
Probably you will appreciate to know that several books will be available VERY soon about Cocoon. BTW, several companies offers trainings about Cocoon. If it sounds too costy to learn it by yourself, you can be helped by professionnals. I agree that the best tool is the one you master. I have a different opinion: To me, the best tool is the one you master and are paid to use. My 2 cents :-) PS: the first time I launched Vim, I could not type anything and couldn't find any way to quit this nasty program. -Message d'origine- De: John Austin [mailto:[EMAIL PROTECTED]] Date: jeudi 27 juin 2002 04:41 À: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Objet: Giving up! Cocoon too big, slow and confusing I'm back from a short vacation in beautiful Chicago (it really is much nicer than Toronto or Montreal) and have waded back in to Cocoon for a couple of days. After just a few hours of poking around I have decided that it will be much simpler for me to simply hand-code a whole hat-full of servlets than to try and pull any meaning out of Cocoon and it's documentation. Fifteen hours on the Interstate wasn't as challenging as trying to figure out how one should check a Web Form this month but I didn't have that feeling of travelling backwards half of the time. I was also able to predict and achieve forward progress (for a change). Thanks guys, but no thanks. Maybe I'm getting old, but I really don't understand the need for all of the complexity and the lack of documentation in this product. On the other hand, I used to feel the same way about the mind-numbing complexity of a certain thirty-year-old mainframe operating system (MVS) produced by IBM back in the sixties and it's patching system (SMP4). So it can't just be my age. Anyway, Cocoon has cost me far morte (a typo that's better than the original word) time than it was worth. The chief problems appear to have been endlessly re-invented terminology for an overwhelming number of 'new concepts' and a complete lack of consistency between different components (i.e. functional code, non-functional examples, unbuildable documentation and a website that doesn't match up with any single released version of the project). I have a lot of respect for the ability of the people who have built this project, but I want them to know that their project appears to be out-of-control and could become very difficult to manage. If experienced developers (like myself) can't figure out how to use enough features in the product to make it worth using, then penetration will be limited and all of your efforts will be wasted. There is more to this business than stuffing in features at the expense of documentation and testing. You have a lot of very good ideas, but the execution of the project as a whole seems to be suffering. I know that I will often look at my JSP and servlet code and think 'XSP and Cocoon were sooo much better!' until I remember that I wasn't ever able to use enough of Cocoon to make a profit. Oh, well, at least all of my test systems have bags of memory now! - 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: Giving up! Cocoon too big, slow and confusing
After just a few hours of poking around I have decided that it will be much simpler for me to simply hand-code a whole hat-full of servlets than to try and pull any meaning out of Cocoon and it's documentation. Fifteen hours on the Interstate wasn't as challenging as trying to figure out how one should check a Web Form this month but I didn't have that feeling of travelling backwards half of the time. I was also able to predict and achieve forward progress (for a change). I hope you had a nice trip. Web Form stuff is a bit beta at the moment, so you'll need to excercise patience and a willingness to help. Thanks guys, but no thanks. Maybe I'm getting old, but I really don't understand the need for all of the complexity and the lack of documentation in this product. Perhaps its not a product at all, maybe its a software development community and a project all wrapped up into one. On the other hand, I used to feel the same way about the mind-numbing complexity of a certain thirty-year-old mainframe operating system (MVS) produced by IBM back in the sixties and it's patching system (SMP4). So it can't just be my age. Anyway, Cocoon has cost me far morte (a typo that's better than the You seem lively to me. original word) time than it was worth. The chief problems appear to have been endlessly re-invented terminology for an overwhelming number of 'new concepts' and a complete lack of consistency between different components (i.e. functional code, non-functional examples, unbuildable documentation and a website that doesn't match up with any single released version of the project). So did you fix them? Did you raise these points and offer to help? I have a lot of respect for the ability of the people who have built this project, but I want them to know that their project appears to be out-of-control and could become very difficult to manage. If experienced developers (like myself) can't figure out how to use enough features in the product to make it worth using, then penetration will be limited and all of your efforts will be wasted. There is more to this business than stuffing in features at the expense of documentation and testing. You have a lot of very good ideas, but the execution of the project as a whole seems to be suffering. I'm significantly less experienced and I figured a large amount of it out. You: Oh I can't figure it out I'm leaving Me: How do I? What is a? And I'm working on creating an example webapp (http://www.superlinksoftware.com/cocoon/samples/bringmethis/index.html) that utilizes forms, etc. I'll accompany it (NOT RIGHT AWAY) with explanations and documentation (written in plain English). I know that I will often look at my JSP and servlet code and think 'XSP and Cocoon were sooo much better!' until I remember that I wasn't ever able to use enough of Cocoon to make a profit. I run Cocoon in fairly low amount of memory. Certainly more than JSP and a Servlet, but then again when I load the Connection pooling, caching, and other services a serious JSP application would require, I'm not so sure it comes that far ahead While I agree with many of your criticisms, especially the Avalonian (language of the Avalon- Cocoon developers) and lack of meaningful documentation, I adamntly believe that the problem here lies within you. This is participatory software. You didn't pay for it. You don't get to call up Microsoft support and scream at them and wonder why they come back at you 2 weeks later with the wrong answer and wait for service pack 2 for a fix. You fix it. If you're lucky, you fix it in collaboration with others! Next, as I get older I get more patient. I'd hate to see how impatient you were at my age or Wow. There are MULTIPLE books coming out on Cocoon, some by its very developers others by great folks like Conrad D'Cruz. In the next few months, such things will be clearer. Personally, I think if you have this attitude If I can't figure it out it must suck and I'll take my cookies and go home then I think you're contributing to this software development community in the best possible way you ever could.leaving it before you break something. If you're perhaps new to opensource community-based development, maybe you should ask for help and take some more time to read up on the subject. You'll find if you expend the effort, folks can be downright friendly and helpful. Of course its up to you. And psychological theory indicates you'll read this and disregard it. So I'm more writing it for the next person that comes along. Hope this helps! -Andy Oh, well, at least all of my test systems have bags of memory now! - 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
Re: Giving up! Cocoon too big, slow and confusing
Good words Andrew. Andrew C. Oliver wrote: After just a few hours of poking around I have decided that it will be much simpler for me to simply hand-code a whole hat-full of servlets than to try and pull any meaning out of Cocoon and it's documentation. Fifteen hours on the Interstate wasn't as challenging as trying to figure out how one should check a Web Form this month but I didn't have that feeling of travelling backwards half of the time. I was also able to predict and achieve forward progress (for a change). I hope you had a nice trip. Web Form stuff is a bit beta at the moment, so you'll need to excercise patience and a willingness to help. Thanks guys, but no thanks. Maybe I'm getting old, but I really don't understand the need for all of the complexity and the lack of documentation in this product. Perhaps its not a product at all, maybe its a software development community and a project all wrapped up into one. On the other hand, I used to feel the same way about the mind-numbing complexity of a certain thirty-year-old mainframe operating system (MVS) produced by IBM back in the sixties and it's patching system (SMP4). So it can't just be my age. Anyway, Cocoon has cost me far morte (a typo that's better than the You seem lively to me. original word) time than it was worth. The chief problems appear to have been endlessly re-invented terminology for an overwhelming number of 'new concepts' and a complete lack of consistency between different components (i.e. functional code, non-functional examples, unbuildable documentation and a website that doesn't match up with any single released version of the project). So did you fix them? Did you raise these points and offer to help? I have a lot of respect for the ability of the people who have built this project, but I want them to know that their project appears to be out-of-control and could become very difficult to manage. If experienced developers (like myself) can't figure out how to use enough features in the product to make it worth using, then penetration will be limited and all of your efforts will be wasted. There is more to this business than stuffing in features at the expense of documentation and testing. You have a lot of very good ideas, but the execution of the project as a whole seems to be suffering. I'm significantly less experienced and I figured a large amount of it out. You: Oh I can't figure it out I'm leaving Me: How do I? What is a? And I'm working on creating an example webapp (http://www.superlinksoftware.com/cocoon/samples/bringmethis/index.html) that utilizes forms, etc. I'll accompany it (NOT RIGHT AWAY) with explanations and documentation (written in plain English). I know that I will often look at my JSP and servlet code and think 'XSP and Cocoon were sooo much better!' until I remember that I wasn't ever able to use enough of Cocoon to make a profit. I run Cocoon in fairly low amount of memory. Certainly more than JSP and a Servlet, but then again when I load the Connection pooling, caching, and other services a serious JSP application would require, I'm not so sure it comes that far ahead While I agree with many of your criticisms, especially the Avalonian (language of the Avalon- Cocoon developers) and lack of meaningful documentation, I adamntly believe that the problem here lies within you. This is participatory software. You didn't pay for it. You don't get to call up Microsoft support and scream at them and wonder why they come back at you 2 weeks later with the wrong answer and wait for service pack 2 for a fix. You fix it. If you're lucky, you fix it in collaboration with others! Next, as I get older I get more patient. I'd hate to see how impatient you were at my age or Wow. There are MULTIPLE books coming out on Cocoon, some by its very developers others by great folks like Conrad D'Cruz. In the next few months, such things will be clearer. Personally, I think if you have this attitude If I can't figure it out it must suck and I'll take my cookies and go home then I think you're contributing to this software development community in the best possible way you ever could.leaving it before you break something. If you're perhaps new to opensource community-based development, maybe you should ask for help and take some more time to read up on the subject. You'll find if you expend the effort, folks can be downright friendly and helpful. Of course its up to you. And psychological theory indicates you'll read this and disregard it. So I'm more writing it for the next person that comes along. Hope this helps! -Andy Oh, well, at least all of my test systems have bags of memory now! - Please check that your question has not already
RE: Giving up! Cocoon too big, slow and confusing
Andrew et al. Andrew ... thanks for the kind words ... and yes I am co-authoring a book on Cocoon 2 due out on October 18. http://www.netswirl.com/publications.htm for details. John Austin's message that triggered this thread was exactly what I felt and experienced when I started working on Cocoon. His message expressed very effectively what I felt and thought ... however I could not put down what my words on the mailing list, because I can cuss and swear in three different languages!!! :-) and I did not want to offend users on the list ... I am quite sure no one wanted to read that kind of feedback on this mailing list. The reason I got into Cocoon was solely to co-author this book. If it was not the goal of the project then who knows I may have given up many months ago. I have worked on many projects (software enhancements and code maintenance) where there were absolutely no documentation and the original developers were not around anymore. The Cocoon project does have documentation that has evolved over time so I did not consider this an unsurmountable challenge. The configuration files have sufficient examples and notes for anyone with enough of years of experience (and the time and motivation) to dig deeper, connect the dots and understand the system. Someone of John Austin's calibre and work experience should not have much trouble after climbing the initial hump of the learning curve. My motivation was moving forward in my understanding of Cocoon and fulfilling my obligations to the publisher. Having spent the last 5 months finding my way around, I can truly say that with the proper nuturing, support and documentation, Cocoon 2 will be adopted widely and make inroads into the developer community. We tried to make the coverage of the topics a chronicle of our experiences learning Cocoon for the first time. It is a stepwise documentation of the steps we took to understand Cocoon from a very high level and it's place in the grand scheme of web publishing and content/document management. Subsequent chapters by myself and my co-authors went through the stages of systematically building examples to target common software projects. Our book can be used as a primer to help users get started in Cocoon and then use the blocks like a leggo set and their own experience and maturity in the field to extrapolate and build more complex systems. At last count there were four books to be released in the next few months. These books from my understanding be adequate documentation of the Cocoon 2 sytems. There will no doubt be advanced books written once the initial wave of books help developers find their bearings and mature in their understanding of the system. I can also vouche for the excellent support and encouragement from experts on this list. Their insight and support helped me along the way. If I named everyone this message would go out of bounds. Even if you don't have a specific question, just following along with any thread will help you understand specific topics that you can then use to experiment with and expand to create your own functioning system. Subject to me finding sometime, I will try and volunteer to expand some of the Cocoon documentation on the Apache web site. There was a request for assistance a few months back when I was overwhelmed with my work, and I will try and find the person who had put out the message and offer some kind of help. John, I hope the feedback helps to put things into perspective. I can truly say Cocoon is not that difficult to understand. Perhaps you can revisit the testing of the system when the books have hit the market. Best wishes to all and keep Cocooning !! Conrad D'Cruz Original Message: - From: Andrew C. Oliver [EMAIL PROTECTED] Date: Thu, 27 Jun 2002 07:18:29 -0400 To: [EMAIL PROTECTED] Subject: Re: Giving up! Cocoon too big, slow and confusing After just a few hours of poking around I have decided that it will be much simpler for me to simply hand-code a whole hat-full of servlets than to try and pull any meaning out of Cocoon and it's documentation. Fifteen hours on the Interstate wasn't as challenging as trying to figure out how one should check a Web Form this month but I didn't have that feeling of travelling backwards half of the time. I was also able to predict and achieve forward progress (for a change). I hope you had a nice trip. Web Form stuff is a bit beta at the moment, so you'll need to excercise patience and a willingness to help. Thanks guys, but no thanks. Maybe I'm getting old, but I really don't understand the need for all of the complexity and the lack of documentation in this product. Perhaps its not a product at all, maybe its a software development community and a project all wrapped up into one. On the other hand, I used to feel the same way about the mind-numbing complexity of a certain thirty-year-old mainframe operating system (MVS) produced by IBM back in the sixties and it's
RE: Giving up! Cocoon too big, slow and confusing
After just a few hours of poking around I have decided that it will be much simpler for me to simply hand-code a whole hat-full of servlets than to try and pull any meaning out of Cocoon and it's documentation. John, it took me almost 2 weeks to go from 0 to 60 using Tomcat, JBoss, and Cocoon (with the 1.4 SDK complicating matters), our previous environment was IIS and Websphere. Having built many servlet based systems I can tell you that the learning curve was worth it. The servlet based version of our current system took over 4 person years to build and has about half as much functionality as what we are currently aiming for with the Cocoon based system in about twice as much code. A complete rewrite using Cocoon was simpler than extending the current system. Cocoon has already shaved probably 6 person months or more off of what would otherwise have been a 2.5 person year project (4 people on the current project, 6 on the original version). Yes things are disorganized at the moment, but the solution is simple: don't try and understand everything up front. Instead, take it one step at a time and research each gotcha with the multitude of resources that are available (the mail list archive and Google are your friends). Subscribe to the mailing list and watch the messages go by. By the time you get to the point where you need a certain feature there will most likely have been enough discussion on the mailing list that you already know what to look for. Of course your mileage may vary, if you're trying to build a couple of simple web pages with no requirement for reusability or multiple data transforms then the learning curve may not save you anything (this time around). But then again, I always preferred VM over MVS...:-) - 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: Giving up! Cocoon too big, slow and confusing
Good post :) Wake up, guys! John raised a real issue. You can't simply say Don't give up, be patient, read mailing-list, look into sources... and so on. If you want this framework to catch the train, then there must be better support and better documentation. I'm not complaining, by the way. I'd love Cocoon become a mainstream framework. -Original Message- From: John Austin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 26, 2002 10:41 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Giving up! Cocoon too big, slow and confusing I'm back from a short vacation in beautiful Chicago (it really is much nicer than Toronto or Montreal) and have waded back in to Cocoon for a couple of days. After just a few hours of poking around I have decided that it will be much simpler for me to simply hand-code a whole hat-full of servlets than to try and pull any meaning out of Cocoon and it's documentation. Two days is absolutely not enough to get a grasp of Cocoon, definitely. Unless, you are a twin brother of Stephano :) - 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: Giving up! Cocoon too big, slow and confusing
From: Argyn Kuketayev [mailto:[EMAIL PROTECTED]] Good post :) Wake up, guys! John raised a real issue. You can't simply say Don't give up, be patient, read mailing-list, look into sources... and so on. If you want this framework to catch the train, then there must be better support What do you mean by better support? and better documentation. I'm not complaining, by the way. I'd love Cocoon become a mainstream framework. So, help us make it better. If you have ideas on how to improve Cocoon iself then welcome to cocoon-dev mail list, if you are willing to have/provide suggestions on making the docs better or write some then join the Forrest project. Konstantin -Original Message- From: John Austin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 26, 2002 10:41 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Giving up! Cocoon too big, slow and confusing I'm back from a short vacation in beautiful Chicago (it really is much nicer than Toronto or Montreal) and have waded back in to Cocoon for a couple of days. After just a few hours of poking around I have decided that it will be much simpler for me to simply hand-code a whole hat-full of servlets than to try and pull any meaning out of Cocoon and it's documentation. Two days is absolutely not enough to get a grasp of Cocoon, definitely. Unless, you are a twin brother of Stephano :) - 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: Giving up! Cocoon too big, slow and confusing
-Original Message- From: Piroumian Konstantin [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 27, 2002 9:41 AM To: '[EMAIL PROTECTED]' Subject: RE: Giving up! Cocoon too big, slow and confusing From: Argyn Kuketayev [mailto:[EMAIL PROTECTED]] Good post :) Wake up, guys! John raised a real issue. You can't simply say Don't give up, be patient, read mailing-list, look into sources... and so on. If you want this framework to catch the train, then there must be better support What do you mean by better support? Maybe I'm suffering from dislexia, but reading the docs in xml.apache.org/cocoon helped me only to understand the highest level concepts. There were lots of tiny little issues which are not covered anywhere in the documentation. What's the best way to do this and this?. No answers anywhere but here, in the mailing list. Ok, I have a habit to look into sources when I've time, but sometimes there's no time. You came here and ask a question, hopefully soon you get an answer. Then comes another issue, then another and so on. Finally, you spend whole day on some stupid problem which could be resolved with good FAQ. I have to admit that things are improving with docs. FAQs are becoming real FAQs, not those short read mailing list as they were before. IBM's tutorials are a very positive step, I recommend them to everybody. They help a lot. Again, I'm not complaining I just want to say that there's an issue, and I'm glad that the situation with documentation is improving. I think that the biggest issue with Cocoon is its docs. and better documentation. I'm not complaining, by the way. I'd love Cocoon become a mainstream framework. So, help us make it better. raising the issue is my help :) - 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: Giving up! Cocoon too big, slow and confusing
-Original Message- From: Argyn Kuketayev [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 27, 2002 9:32 AM To: '[EMAIL PROTECTED]' Subject: RE: Giving up! Cocoon too big, slow and confusing Good post :) Wake up, guys! John raised a real issue. You can't simply say Don't give up, be patient, read mailing-list, look into sources... and so on. If you want this framework to catch the train, then there must be better support and better documentation. I'm not complaining, by the way. I'd love Cocoon become a mainstream framework. I agree as well. It's nice when you have time to tinker, wait for useful replies from the mailling list or search the archives and wade through messages that most likely talk about version you're not using. It's nice to have time to look at source code and hope what you learn will still hold in the next version. Unfortunately, a lot of developers have very little time and don't want to spend all of their well wasted time on Cocoon. This is not about open-source vs closed-source, this about making Cocoon usefull to everyone. Yes, I know I can help by pathching, writing docs, answering questions on mailing lists (I sometimes do the last one), but that requires time that I, and many other developers, don't have. New features/design is nice but I'm already affraid I will have to go through same HELL moving from 2.0.2 to 2.1 as I did when moving from 1.8.x to 2.0.2. Please tell me that I'm crazy and that all I'll have to do is drop in a new jar(s) and edit my cocoon.xconf. I'm not crazy and I'll probably have to do a lot more and there wont be a migration guide to tell me what to do. Cocoon is great, cocoon developers/community is great, but I'm tired of explaining to VPs and clinets that Cocoon's benefits outweights its lack of documentation and API stability. These people would like to know that it will not cost them 3 months of extra development time, because their in house Cocoon expret was hit by a bus. So, IMO if you want Cocoon to succeed in medium/big business all you have to do is write lots of helpful docs. The upcoming books are a good start, but thinks like API JavaDocs with actual comments for each package/class/method and installation migration and user docs need to be released with each version. Artur... -- All I want is to use Cocoon. -Original Message- From: John Austin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 26, 2002 10:41 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Giving up! Cocoon too big, slow and confusing I'm back from a short vacation in beautiful Chicago (it really is much nicer than Toronto or Montreal) and have waded back in to Cocoon for a couple of days. After just a few hours of poking around I have decided that it will be much simpler for me to simply hand-code a whole hat-full of servlets than to try and pull any meaning out of Cocoon and it's documentation. Two days is absolutely not enough to get a grasp of Cocoon, definitely. Unless, you are a twin brother of Stephano :) - 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: Giving up! Cocoon too big, slow and confusing
I completely agree with Argyn's and John's comments here. But, I don't think the sentiments expressed are unique to the cocoon project. I'm a big proponent of open source software. I try to use it and recommend it whenever I can. However, I can't spend two weeks just getting up to speed on something. I have to be productive quite soon after picking it up. I'm busying 50 to 60 hours a week doing what my job demands of me, so I don't have a lot of extra time to devote to learning how to use a product, much less debugging or coding one. I still want to stay ahead of the curve, and learn new things and use new technologies. But, many open source projects make this very difficult. So if I could be presumptuous, here are some suggestions I'll offer to make life a little easier on us early adopters: (1) Don't create a new nomenclature, language or jargon to describe your project. The world has enough acronyms, marketing-speak and inpenetrable software descriptions. Don't add to it. When describing your project, compare and contrast it with other products the reader may be familiar with. (2) Don't assume the people who use a product or ask questions on a mailing list are the second coming of James Gosling or Bill Joy. If you answer a question posed on the list, go a little bit more in depth so that others who may be reading the threads might be able to learn something. (3) Don't skimp on documentation, and in doing so, be mindful of (1) and (2). When providing examples, do something a bit more useful than yet another Hello, World example. Provide more than one example, and make them progessively more complex, building on previous examples as you go. (4) Don't get overly defensive when responding to criticism. And, don't respond with the typical open source developer knee-jerk reaction of Why don't you help out? Not everyone is in a position to provide the time and effort necessary for a meaningful contribution. Don't dismiss the concerns of those who don't or can't participate. (5) Beware of the warning signs, like those expressed in John's message. He obviously isn't an idiot, and has invested some time and effort trying to learn and use cocoon. Yet, he's having trouble making cocoon useful. That should be a wake up call. (6) Don't assume that everyone should use a product because it's open source, and that it's better than closed source or commercial products because it's open. If a product doesn't perform well or is difficult to learn, use or implement, what good does being open source? Before answering, refer to (4). These points are based on observations of the Apache project I've made over the last several years. I applaud the efforts of those who've invested the time and effort on the various subprojects. Many are among the most useful pieces of software in my arsenal, like ant, log4j and struts. Others have finally come around, like tomcat which I found unusable until v3. Cocoon is an intriguing product. But, who will use it if they can't understand how? Eric -- On Thu, 27 Jun 2002 17:41:18 Piroumian Konstantin wrote: From: Argyn Kuketayev [mailto:[EMAIL PROTECTED]] Good post :) Wake up, guys! John raised a real issue. You can't simply say Don't give up, be patient, read mailing-list, look into sources... and so on. If you want this framework to catch the train, then there must be better support What do you mean by better support? and better documentation. I'm not complaining, by the way. I'd love Cocoon become a mainstream framework. So, help us make it better. If you have ideas on how to improve Cocoon iself then welcome to cocoon-dev mail list, if you are willing to have/provide suggestions on making the docs better or write some then join the Forrest project. Konstantin -Original Message- From: John Austin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 26, 2002 10:41 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Giving up! Cocoon too big, slow and confusing I'm back from a short vacation in beautiful Chicago (it really is much nicer than Toronto or Montreal) and have waded back in to Cocoon for a couple of days. After just a few hours of poking around I have decided that it will be much simpler for me to simply hand-code a whole hat-full of servlets than to try and pull any meaning out of Cocoon and it's documentation. Two days is absolutely not enough to get a grasp of Cocoon, definitely. Unless, you are a twin brother of Stephano :) - 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
RE: Giving up! Cocoon too big, slow and confusing
Hi, Just a small comment but I feel that a lot of the problem issues, and especially some of the complexity might be tied to where and how Cocoon sets the the interface between Java and XSLT. I have many examples in mind but in general I feel that more of the framework should be in xslt and that if every time you need to do something, you have to go back and forth between java and xslt, you will be duplicating data structures and adding overhead and logic issues, apart from tricky technological and mind frame switching issues. Both Java and XSLT are important and they are complementary but this complementarity requires a design interface, not just an API (or a set of APIs). Still Cocoon is very interesting and a dynamic collaboration. Thank you, Regards, ac -Message d'origine- De : Argyn Kuketayev [mailto:[EMAIL PROTECTED]] Envoye : 27 juin, 2002 09:57 A : '[EMAIL PROTECTED]' Objet : RE: Giving up! Cocoon too big, slow and confusing -Original Message- From: Piroumian Konstantin [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 27, 2002 9:41 AM To: '[EMAIL PROTECTED]' Subject: RE: Giving up! Cocoon too big, slow and confusing From: Argyn Kuketayev [mailto:[EMAIL PROTECTED]] Good post :) Wake up, guys! John raised a real issue. You can't simply say Don't give up, be patient, read mailing-list, look into sources... and so on. If you want this framework to catch the train, then there must be better support What do you mean by better support? Maybe I'm suffering from dislexia, but reading the docs in xml.apache.org/cocoon helped me only to understand the highest level concepts. There were lots of tiny little issues which are not covered anywhere in the documentation. What's the best way to do this and this?. No answers anywhere but here, in the mailing list. Ok, I have a habit to look into sources when I've time, but sometimes there's no time. You came here and ask a question, hopefully soon you get an answer. Then comes another issue, then another and so on. Finally, you spend whole day on some stupid problem which could be resolved with good FAQ. I have to admit that things are improving with docs. FAQs are becoming real FAQs, not those short read mailing list as they were before. IBM's tutorials are a very positive step, I recommend them to everybody. They help a lot. Again, I'm not complaining I just want to say that there's an issue, and I'm glad that the situation with documentation is improving. I think that the biggest issue with Cocoon is its docs. and better documentation. I'm not complaining, by the way. I'd love Cocoon become a mainstream framework. So, help us make it better. raising the issue is my help :) - 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: RE: Giving up! Cocoon too big, slow and confusing
Eric, You have made some good points. A long time ago I read a book Crossing the Chasm ... by Geoffrey A. Moore in which he talks about how projects get off to a good start and often go awry because of various factors. http://www.testing.com/writings/reviews/moore-chasm.html I think Cocoon 2 is slightly beyond the early adopter/visionary phase and probably standing just on the edge of the chasm. The early adopters and visionaries in any field or technology, will invest the time and effort to surmount all types of barriers to reach their goal. There are several working Cocoon 2 active livesites which are testimony to the fact that it can be done. A lot of work still remains to be done for the pragmatists, conservatives and skeptics to come on board and take a closer look at Cocoon 2. You have listed some of the drawbacks that are preventing this from happening at a faster pace. Time is the limitation that keeps all the developers from creating good docs in pace with the changes in the system. Occasionally promising open source projects get adopted by a big sponsor corporation which helps to make it easier to cross the chasm. Conrad D'Cruz Original Message: - From: Eric Sheffer [EMAIL PROTECTED] Date: Thu, 27 Jun 2002 11:13:43 -0400 To: [EMAIL PROTECTED] Subject: RE: Giving up! Cocoon too big, slow and confusing I completely agree with Argyn's and John's comments here. But, I don't think the sentiments expressed are unique to the cocoon project. I'm a big proponent of open source software. I try to use it and recommend it whenever I can. However, I can't spend two weeks just getting up to speed on something. I have to be productive quite soon after picking it up. I'm busying 50 to 60 hours a week doing what my job demands of me, so I don't have a lot of extra time to devote to learning how to use a product, much less debugging or coding one. I still want to stay ahead of the curve, and learn new things and use new technologies. But, many open source projects make this very difficult. So if I could be presumptuous, here are some suggestions I'll offer to make life a little easier on us early adopters: (1) Don't create a new nomenclature, language or jargon to describe your project. The world has enough acronyms, marketing-speak and inpenetrable software descriptions. Don't add to it. When describing your project, compare and contrast it with other products the reader may be familiar with. (2) Don't assume the people who use a product or ask questions on a mailing list are the second coming of James Gosling or Bill Joy. If you answer a question posed on the list, go a little bit more in depth so that others who may be reading the threads might be able to learn something. (3) Don't skimp on documentation, and in doing so, be mindful of (1) and (2). When providing examples, do something a bit more useful than yet another Hello, World example. Provide more than one example, and make them progessively more complex, building on previous examples as you go. (4) Don't get overly defensive when responding to criticism. And, don't respond with the typical open source developer knee-jerk reaction of Why don't you help out? Not everyone is in a position to provide the time and effort necessary for a meaningful contribution. Don't dismiss the concerns of those who don't or can't participate. (5) Beware of the warning signs, like those expressed in John's message. He obviously isn't an idiot, and has invested some time and effort trying to learn and use cocoon. Yet, he's having trouble making cocoon useful. That should be a wake up call. (6) Don't assume that everyone should use a product because it's open source, and that it's better than closed source or commercial products because it's open. If a product doesn't perform well or is difficult to learn, use or implement, what good does being open source? Before answering, refer to (4). These points are based on observations of the Apache project I've made over the last several years. I applaud the efforts of those who've invested the time and effort on the various subprojects. Many are among the most useful pieces of software in my arsenal, like ant, log4j and struts. Others have finally come around, like tomcat which I found unusable until v3. Cocoon is an intriguing product. But, who will use it if they can't understand how? Eric -- On Thu, 27 Jun 2002 17:41:18 Piroumian Konstantin wrote: From: Argyn Kuketayev [mailto:[EMAIL PROTECTED]] Good post :) Wake up, guys! John raised a real issue. You can't simply say Don't give up, be patient, read mailing-list, look into sources... and so on. If you want this framework to catch the train, then there must be better support What do you mean by better support? and better documentation. I'm not complaining, by the way. I'd love Cocoon become a mainstream framework. So, help us make it better. If you have ideas on how to improve Cocoon iself
Re: Giving up! Cocoon too big, slow and confusing
My .02, Thanks to Eric, Argyn and John for their honesty. And thanks to all of the Cocoon developers for their hard work and vision. I would like to add my comments to the reality check that is going on. I have over 17 years experience in the industry and have led developer teams working on commercial software projects. I am an expert Java programmer as well as C/C++ and others. I have worked on multiple operating systems. I love a challenge. I'm not bragging (believe me I don't think any of this stuff is anything to brag about in the REAL world :) ), but I want to do a level-set as to who is doing the talking. I embraced this project because: 1) It had the Apache stamp of approval 2) It said it was version 2.0 3) The technological vision and approach seemed (and still seem) to be the correct one. What I wanted: 1) To get a simple web site up fast and lay the groundwork for subsequent versions (see www.vsolano.us). 2) To use open source for all the right reasons. What I experienced: 1) An incredibly steep learning curve that has no end in sight. I have NEVER worked on a project where I spent a hard 6 weeks slogging through a technology and had NO IDEA when it was going to end. 2) Documentation is not usefull - sorry. I've tried and tried. The closest it has come to being useful is that after I've spent hours on something and asked questions on the mail lists I have been able to go back to it and say oh.. that's what they meant 3) Serious problems (hours lost) upgrading from 2.0 to 2.0.2 - looking at the change logs for potential hints at what was necessary was a non-starter. 4) Generally helpful but inconsistant responses from the mail lists. You should seriously consider joining the two lists as all it is doing right now is making me have to search both lists for everything that i'm looking for. Many of the questions were answered in a way which built character but were much too cryptic to be helpful to anyone who comes later. (I'm sure this is because the really knowledgeable people are spending too much time answering e-mails). My conclusions: 1) Almost by definition this should not be a released product - sorry but true. Someone should define what is meant by alpha, beta and released software - also the meaning of point releases. 2) I don't have time to read the source code - not because I can't or won't from some misplaced belief that it shouldn't be necessary - because I don't believe it would be time well spent - too much of a lack of basic doco to make it worth the time. 3) I will continue to maintain the current web site in Cocoon while I research alternatives. I am going to keep an open mind and hope that the forthcoming books will be of assistance - however I don't see how this will be since there have been significant changes (forms and authentication system to just name a few at the feature level) since those books have gone to publishing. Also - please see my comments inline below - Eric Sheffer wrote: I completely agree with Argyn's and John's comments here. But, I don't think the sentiments expressed are unique to the cocoon project. I'm a big proponent of open source software. I try to use it and recommend it whenever I can. However, I can't spend two weeks just getting up to speed on something. I have to be productive quite soon after picking it up. I'm busying 50 to 60 hours a week doing what my job demands of me, so I don't have a lot of extra time to devote to learning how to use a product, much less debugging or coding one. Big agreement - I see my involvement as learning what I can, writing the occasional FAQ and helping out on the mailing lists. I still want to stay ahead of the curve, and learn new things and use new technologies. But, many open source projects make this very difficult. So if I could be presumptuous, here are some suggestions I'll offer to make life a little easier on us early adopters: (1) Don't create a new nomenclature, language or jargon to describe your project. The world has enough acronyms, marketing-speak and inpenetrable software descriptions. Don't add to it. When describing your project, compare and contrast it with other products the reader may be familiar with. Most developers believe that they are doing something new. You generally are not. When you think you are you need to very carefully explain the motivations for what you are doing, define your terms and describe, in detail, your approach. (2) Don't assume the people who use a product or ask questions on a mailing list are the second coming of James Gosling or Bill Joy. If you answer a question posed on the list, go a little bit more in depth so that others who may be reading the threads might be able to learn something. Ditto - see my comments above - I'm pretty sure that the terseness of the responses is due to the overwhelming number of basic questions that are getting asked over and over -
RE: Giving up! Cocoon too big, slow and confusing
Title: RE: Giving up! Cocoon too big, slow and confusing Out of all of the posts in this thread I haven't heard anyone say that no matter what 3rd party software you use you will have to figure it out. At least with Cocoon you can get good support and fixes quickly for free! Buy someone else's stuff and they may or may not be willing to include your needs and if they do you'll have to pay to upgrade. As far as the help goes all of my problems have been solved without the lovely common tech support answer of 1st reboot the machine, then reinstall :) -Original Message- From: daniel robinson [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 27, 2002 11:23 AM To: [EMAIL PROTECTED] Subject: Re: Giving up! Cocoon too big, slow and confusing My .02, Thanks to Eric, Argyn and John for their honesty. And thanks to all of the Cocoon developers for their hard work and vision. I would like to add my comments to the reality check that is going on. I have over 17 years experience in the industry and have led developer teams working on commercial software projects. I am an expert Java programmer as well as C/C++ and others. I have worked on multiple operating systems. I love a challenge. I'm not bragging (believe me I don't think any of this stuff is anything to brag about in the REAL world :) ), but I want to do a level-set as to who is doing the talking. I embraced this project because: 1) It had the Apache stamp of approval 2) It said it was version 2.0 3) The technological vision and approach seemed (and still seem) to be the correct one. What I wanted: 1) To get a simple web site up fast and lay the groundwork for subsequent versions (see www.vsolano.us). 2) To use open source for all the right reasons. What I experienced: 1) An incredibly steep learning curve that has no end in sight. I have NEVER worked on a project where I spent a hard 6 weeks slogging through a technology and had NO IDEA when it was going to end. 2) Documentation is not usefull - sorry. I've tried and tried. The closest it has come to being useful is that after I've spent hours on something and asked questions on the mail lists I have been able to go back to it and say oh.. that's what they meant 3) Serious problems (hours lost) upgrading from 2.0 to 2.0.2 - looking at the change logs for potential hints at what was necessary was a non-starter. 4) Generally helpful but inconsistant responses from the mail lists. You should seriously consider joining the two lists as all it is doing right now is making me have to search both lists for everything that i'm looking for. Many of the questions were answered in a way which built character but were much too cryptic to be helpful to anyone who comes later. (I'm sure this is because the really knowledgeable people are spending too much time answering e-mails). My conclusions: 1) Almost by definition this should not be a released product - sorry but true. Someone should define what is meant by alpha, beta and released software - also the meaning of point releases. 2) I don't have time to read the source code - not because I can't or won't from some misplaced belief that it shouldn't be necessary - because I don't believe it would be time well spent - too much of a lack of basic doco to make it worth the time. 3) I will continue to maintain the current web site in Cocoon while I research alternatives. I am going to keep an open mind and hope that the forthcoming books will be of assistance - however I don't see how this will be since there have been significant changes (forms and authentication system to just name a few at the feature level) since those books have gone to publishing. Also - please see my comments inline below - Eric Sheffer wrote: I completely agree with Argyn's and John's comments here. But, I don't think the sentiments expressed are unique to the cocoon project. I'm a big proponent of open source software. I try to use it and recommend it whenever I can. However, I can't spend two weeks just getting up to speed on something. I have to be productive quite soon after picking it up. I'm busying 50 to 60 hours a week doing what my job demands of me, so I don't have a lot of extra time to devote to learning how to use a product, much less debugging or coding one. Big agreement - I see my involvement as learning what I can, writing the occasional FAQ and helping out on the mailing lists. I still want to stay ahead of the curve, and learn new things and use new technologies. But, many open source projects make this very difficult. So if I could be presumptuous, here are some suggestions I'll offer to make life a little easier on us early adopters: (1) Don't create a new nomenclature, language or jargon to describe your project. The world has enough acronyms, marketing-speak and inpenetrable software descriptions. Don't add to it. When describing your project, compare and contrast it with other
Re: Giving up! Cocoon too big, slow and confusing
On Thursday, June 27, 2002, at 11:32 AM, [EMAIL PROTECTED] wrote: Time is the limitation that keeps all the developers from creating good docs in pace with the changes in the system. Occasionally promising open source projects get adopted by a big sponsor corporation which helps to make it easier to cross the chasm. But this may suggest to users that doc problems can only be solved by developers, book authors, and corporations. This isn't necessarily true. Or, it doesn't have to be true. I'll be the first to admit writing Cocoon documentation is difficult. You get all excited, start down a path, and -- BAM -- you hit a road block. You take a detour, e.g., to read more about Avalon or about Ant. Then you come back to continue with your effort. BAM. The cvs HEAD branch has changed. What worked yesterday doesn't work today. Did you do something wrong? Maybe. To be safe (who wants to confuse future users) you start over. BAM. You can't figure out the meaning of a component parameter. It's not even defined in the source code. Need to run it by Vadim on cocoon-users. BAM. etc. etc. etc. Sounds pretty frustrating, eh? Well. the reward is you learn a *ton,* and you will advance your abilities as a Cocoon user unlike any other available option. For example, I just finished a new How-To, but now I feel I can write a How-To on about ten other Cocoon topics, just from the knowledge I gained in this single writing experience. Granted, this kind of job isn't for everyone, but I don't know of a better way to learn for intermediate users. And in my short experience, developers have been unbelievably responsive to my technical questions. What a great learning opportunity for the taking! I think intermediate Cocoon users can make a *big* difference with docs, if they can find the time to write. Do users realize this? I personally didn't know I could even help out with an open source project with doc writing until very recently -- and I've been using Cocoon since version 1.0. I know, it's hard to find the time to do lots of things, but if you are invested in Cocoon, you may really enjoy and benefit from the writing experience -- no matter how small a contribution you make. I also believe it's important for *users* to write some docs because they are in a better position to understand the challenges other users face. This won't solve the problem overnight, but it's has a positive feedback loop, i.e. more docs - more knowledge - more authors w/knowledge - more docs ... I know this response doesn't satisfy all of the concerns raised in this thread. Nevertheless, if users want to write docs, please check out the How-Tos that are available for documentation at http://xml.apache.org/cocoon/howto/ . If you want to work on existing docs, contact me to talk about it. Interested in editing? There's a lot for you to do. Want to work on architectural doc issues? Check out Forrest. http://xml.apache.org/forrest/ If you don't have time to provide structured text for your work, simply post the content to this list. Given time, I'm sure someone will find a way to migrate useful content to an official Cocoon document. Quality open source docs may take time, and the results may seem incremental at first, but that doesn't mean it can't or it won't happen... it may just not happen on *your* time frame. -- Diana - 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: Giving up! Cocoon too big, slow and confusing
daniel robinson wrote: My .02, Thanks to Eric, Argyn and John for their honesty. And thanks to all of the Cocoon developers for their hard work and vision. I would like to add my comments to the reality check that is going on. I have over 17 years experience in the industry and have led developer teams working on commercial software projects. I am an expert Java programmer as well as C/C++ and others. I have worked on multiple operating systems. I love a challenge. I'm not bragging (believe me I don't think any of this stuff is anything to brag about in the REAL world :) ), but I want to do a level-set as to who is doing the talking. You don't mention programming in the XML field. This is paramount. I embraced this project because: 1) It had the Apache stamp of approval 2) It said it was version 2.0 3) The technological vision and approach seemed (and still seem) to be the correct one. What I wanted: 1) To get a simple web site up fast and lay the groundwork for subsequent versions (see www.vsolano.us). The example webapp. Full of prebuilt parts. What's the problem? 2) To use open source for all the right reasons. What are they? What I experienced: 1) An incredibly steep learning curve that has no end in sight. I have NEVER worked on a project where I spent a hard 6 weeks slogging through a technology and had NO IDEA when it was going to end. Too generic. What don't you understand? What do you expect and doesn't work as you expect? 2) Documentation is not usefull - sorry. I've tried and tried. The closest it has come to being useful is that after I've spent hours on something and asked questions on the mail lists I have been able to go back to it and say oh.. that's what they meant What documents were not helpful in what cases? What couldn't you find? How did you search for it? 3) Serious problems (hours lost) upgrading from 2.0 to 2.0.2 - looking at the change logs for potential hints at what was necessary was a non-starter. What were the serious problems? (hours lost is not a problem, it's the result of the problem) 4) Generally helpful but inconsistant responses from the mail lists. You should seriously consider joining the two lists as all it is doing right now is making me have to search both lists for everything that i'm looking for. Many of the questions were answered in a way which built character but were much too cryptic to be helpful to anyone who comes later. (I'm sure this is because the really knowledgeable people are spending too much time answering e-mails). We give help. *Not* complete solutions. We are not paid for it, it's all free help. My conclusions: 1) Almost by definition this should not be a released product - sorry but true. Someone should define what is meant by alpha, beta and released software - also the meaning of point releases. This is not a shrink-wrapped software. 2) I don't have time to read the source code - not because I can't or won't from some misplaced belief that it shouldn't be necessary - because I don't believe it would be time well spent - too much of a lack of basic doco to make it worth the time. Sorry but I don't get it. We have *tons* of documentation. But you just gotta learn ;-) 3) I will continue to maintain the current web site in Cocoon while I research alternatives. I am going to keep an open mind and hope that the forthcoming books will be of assistance - however I don't see how this will be since there have been significant changes (forms and authentication system to just name a few at the feature level) since those books have gone to publishing. Forms and authentication systems are not changed. We have new ones. Did you ever think that nio is a change to io package? What you wrote is completely useless to me, sorry. If you really want to help us, and it seems you do, please explain the real problems in terms of - what you want to achieve. - how you did it - what you assumed correct and don't see working - where-how you searched for a solution - how you tried solving the problem - what you would have wanted to see-find All these *concrete* examples would really help us. Thank you. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - 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: Giving up! Cocoon too big, slow and confusing
I understand the complaints and agree with many of them, but I think that they are somewhat abstract or ambiguous. may you detail them so that they can be solved? it would be very helpful for all of us. Thanks to all the contributors to the cocoon project, it is a great product, but remember that one of the principles of programming is being humble to accept that things can be improved. Regards for example Documentation is scarce [ what part is scarce? all of it? XSP? ] Documentation is outdated [the same] few examples [which functionality needs more examples urgently?] stabilization [any comments? ] etc - Original Message - From: daniel robinson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 27, 2002 11:23 AM Subject: Re: Giving up! Cocoon too big, slow and confusing My .02, Thanks to Eric, Argyn and John for their honesty. And thanks to all of the Cocoon developers for their hard work and vision. I would like to add my comments to the reality check that is going on. I have over 17 years experience in the industry and have led developer teams working on commercial software projects. I am an expert Java programmer as well as C/C++ and others. I have worked on multiple operating systems. I love a challenge. I'm not bragging (believe me I don't think any of this stuff is anything to brag about in the REAL world :) ), but I want to do a level-set as to who is doing the talking. I embraced this project because: 1) It had the Apache stamp of approval 2) It said it was version 2.0 3) The technological vision and approach seemed (and still seem) to be the correct one. What I wanted: 1) To get a simple web site up fast and lay the groundwork for subsequent versions (see www.vsolano.us). 2) To use open source for all the right reasons. What I experienced: 1) An incredibly steep learning curve that has no end in sight. I have NEVER worked on a project where I spent a hard 6 weeks slogging through a technology and had NO IDEA when it was going to end. 2) Documentation is not usefull - sorry. I've tried and tried. The closest it has come to being useful is that after I've spent hours on something and asked questions on the mail lists I have been able to go back to it and say oh.. that's what they meant 3) Serious problems (hours lost) upgrading from 2.0 to 2.0.2 - looking at the change logs for potential hints at what was necessary was a non-starter. 4) Generally helpful but inconsistant responses from the mail lists. You should seriously consider joining the two lists as all it is doing right now is making me have to search both lists for everything that i'm looking for. Many of the questions were answered in a way which built character but were much too cryptic to be helpful to anyone who comes later. (I'm sure this is because the really knowledgeable people are spending too much time answering e-mails). My conclusions: 1) Almost by definition this should not be a released product - sorry but true. Someone should define what is meant by alpha, beta and released software - also the meaning of point releases. 2) I don't have time to read the source code - not because I can't or won't from some misplaced belief that it shouldn't be necessary - because I don't believe it would be time well spent - too much of a lack of basic doco to make it worth the time. 3) I will continue to maintain the current web site in Cocoon while I research alternatives. I am going to keep an open mind and hope that the forthcoming books will be of assistance - however I don't see how this will be since there have been significant changes (forms and authentication system to just name a few at the feature level) since those books have gone to publishing. Also - please see my comments inline below - Eric Sheffer wrote: I completely agree with Argyn's and John's comments here. But, I don't think the sentiments expressed are unique to the cocoon project. I'm a big proponent of open source software. I try to use it and recommend it whenever I can. However, I can't spend two weeks just getting up to speed on something. I have to be productive quite soon after picking it up. I'm busying 50 to 60 hours a week doing what my job demands of me, so I don't have a lot of extra time to devote to learning how to use a product, much less debugging or coding one. Big agreement - I see my involvement as learning what I can, writing the occasional FAQ and helping out on the mailing lists. I still want to stay ahead of the curve, and learn new things and use new technologies. But, many open source projects make this very difficult. So if I could be presumptuous, here are some suggestions I'll offer to make life a little easier on us early adopters: (1) Don't create a new nomenclature, language or jargon to describe your project. The world has enough
Re: Giving up! Cocoon too big, slow and confusing
I'm not saying there aren't issues. I'm saying his attitude is wrong. You pay for this by participating. If the issue was unknown this would be valuable, but this issue is known. Help fix it or accept it. Or fund someone else to help fix it. If you see a nail sticking up, grab a hammer. Don't whine, and take you cookies and go home. If this were a commercial piece of software, that would be your best course of action as a customer. Thats not the case here. -Andy What do you mean by better support? Maybe I'm suffering from dislexia, but reading the docs in xml.apache.org/cocoon helped me only to understand the highest level concepts. There were lots of tiny little issues which are not covered anywhere in the documentation. What's the best way to do this and this?. No answers anywhere but here, in the mailing list. Ok, I have a habit to look into sources when I've time, but sometimes there's no time. You came here and ask a question, hopefully soon you get an answer. Then comes another issue, then another and so on. Finally, you spend whole day on some stupid problem which could be resolved with good FAQ. I have to admit that things are improving with docs. FAQs are becoming real FAQs, not those short read mailing list as they were before. IBM's tutorials are a very positive step, I recommend them to everybody. They help a lot. Again, I'm not complaining I just want to say that there's an issue, and I'm glad that the situation with documentation is improving. I think that the biggest issue with Cocoon is its docs. and better documentation. I'm not complaining, by the way. I'd love Cocoon become a mainstream framework. So, help us make it better. raising the issue is my help :) - 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: Giving up! Cocoon too big, slow and confusing
2) Documentation is not usefull - sorry. I've tried and tried. The closest it has come to being useful is that after I've spent hours on something and asked questions on the mail lists I have been able to go back to it and say oh.. that's what they meant What documents were not helpful in what cases? What couldn't you find? How did you search for it? I disagree, the documentation is in fact inadequate. 4) Generally helpful but inconsistant responses from the mail lists. You should seriously consider joining the two lists as all it is doing right now is making me have to search both lists for everything that i'm looking for. Many of the questions were answered in a way which built character but were much too cryptic to be helpful to anyone who comes later. (I'm sure this is because the really knowledgeable people are spending too much time answering e-mails). We give help. *Not* complete solutions. We are not paid for it, it's all free help. Yes. If you want commecial support for Cocoon, get commecial support for cocoon. 2) I don't have time to read the source code - not because I can't or won't from some misplaced belief that it shouldn't be necessary - because I don't believe it would be time well spent - too much of a lack of basic doco to make it worth the time. Sorry but I don't get it. We have *tons* of documentation. But you just gotta learn ;-) You're both wrong. From his part he must realize this is participatory software. Understand your role, you're not a customer, you're a: 1. Beta Tester 2. Developer 3. Documentor of the software. And ken is wrong, the documentation is in fact VERY lacking. If you'd rather have a black box where you make phone calls and someone jumps, then you can pay someone and use Cocoon, or you can just blow some serious coin and get a commercial solution. -Andy - 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]
Giving up! Cocoon too big, slow and confusing
I'm back from a short vacation in beautiful Chicago (it really is much nicer than Toronto or Montreal) and have waded back in to Cocoon for a couple of days. After just a few hours of poking around I have decided that it will be much simpler for me to simply hand-code a whole hat-full of servlets than to try and pull any meaning out of Cocoon and it's documentation. Fifteen hours on the Interstate wasn't as challenging as trying to figure out how one should check a Web Form this month but I didn't have that feeling of travelling backwards half of the time. I was also able to predict and achieve forward progress (for a change). Thanks guys, but no thanks. Maybe I'm getting old, but I really don't understand the need for all of the complexity and the lack of documentation in this product. On the other hand, I used to feel the same way about the mind-numbing complexity of a certain thirty-year-old mainframe operating system (MVS) produced by IBM back in the sixties and it's patching system (SMP4). So it can't just be my age. Anyway, Cocoon has cost me far morte (a typo that's better than the original word) time than it was worth. The chief problems appear to have been endlessly re-invented terminology for an overwhelming number of 'new concepts' and a complete lack of consistency between different components (i.e. functional code, non-functional examples, unbuildable documentation and a website that doesn't match up with any single released version of the project). I have a lot of respect for the ability of the people who have built this project, but I want them to know that their project appears to be out-of-control and could become very difficult to manage. If experienced developers (like myself) can't figure out how to use enough features in the product to make it worth using, then penetration will be limited and all of your efforts will be wasted. There is more to this business than stuffing in features at the expense of documentation and testing. You have a lot of very good ideas, but the execution of the project as a whole seems to be suffering. I know that I will often look at my JSP and servlet code and think 'XSP and Cocoon were sooo much better!' until I remember that I wasn't ever able to use enough of Cocoon to make a profit. Oh, well, at least all of my test systems have bags of memory now! - 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]
