Re: Cocoon Productivity
On 31.05.2007 09:20, Niels van Kampenhout wrote: I have not seen anyone else pointing it out, but after a day or two I was really struck by the fact that conceptually pipelines are not pipelines in any common understanding of the term; rather matchers are the pipelines! I know what you mean, here in our office everyone call matchers pipelines too :-) But that's actually not correct, matchers are just not pipelines. I explained it recently on the dev list because somebody asked if he can change this in the documentation [1]. I guess I should add my explanation to the official documentation. Joerg [1] http://marc.info/?t=12134488441r=1w=4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Productivity
Reinhard Poetz schrieb: Reinhard Haller wrote: Reinhard Poetz schrieb: I have been working on http://cocoon.zones.apache.org/daisy/cdocs/g2/g1/1370.html. I hope that it helps. said first I have no knowlwedge of maven or cocoon2.2. Your tutorials for me are typical examples of the problems regarding the current cocoon documentation. It's very valuable if you already know why and how to do what you want. It helps for nothing if you are a real beginner. What can we expect from a beginner, when we write documentation? - Does he know how the request-response-cycle of the http protocol works? - Does he know what XML is? - Is he able to read (and write) XSLT? - Does he know what a servlet container is? - etc. Cocoon started as an XML-based publishing system. XML and XSL are the basics to start with, servlet and other Java related technologies are implementation specific for cocoon, http is also a base technology for a web framework (I suppose this is the most common use). Compare this to tutorials for Netbeans, Eclipse or the JBoss IDE. hmm, those pieces of software are GUIs and not server-side applications. agreed. I referred to the style how the tutorials are organized and presented. Instead of showing what you do and possibly why you do it, you choose a set of very simple unrelated topics to achieve a very short and pregnant documentation for people which already know what they do. I wouldn't say that they are unrelated but I agree with you that there is no use case behind them. Simply put the screenshots of your Eclipse in the documentation, this explains much more than your text. Document your example (your first Cocoon application ...) from the very beginning, i.e. installation and setup within eclipse (from svn/from distribution) including the setup for the application server if needed. What's missing? Where did you get stuck? I didn't get stuck, my problem is the resolution of the monitor. It takes much more time to switch between 5 windows than with 2, i.e. if the tutorial contains all needed stuff to proceed you switch only between your IDE and the tutorial. In all other cases you open dozens of additional windows with doumentation stuff, try to combine all and are still insecure if you are on the right track (even a simple typing error may be a fatal one). Don't forget: most of the users want to publish their XML-content and not discover the wonderful world of JAVA IDE's, AS's, J2EE etc. Choose a real production application server instead of the bundled Jetty. Explain if it works with Plugins (WTP/JBoss IDE) and how. IMO that's out of the scope of Cocoon. If we start to explain the deployment in a Bea weblogic server someone will ask, how those things work in IBM websphere, etc. Cocoon is a web applications and we produce web archives (.war) that can be deployed into any complient servlt container. Having a war, you can use one of the illustrated tutorials of those containers to deploy your stuff there. Good argument. If the deployment for all compliant servlet container is identical, what's the problem to show it for a specific one? Providing the community with a non trivial tutorial that covers a website with structured templates for content, navigation and metadata, combined with a real world error handling would help to get new users an impression of the developement cycle and the structure of a cocoon application. If you also explain how to manage the different versions (cocoon, the cocoon application i.e. sitemap, the website templates and the web content) in one or more svn repositories then we have a sound base to start with and additional documentation can refer to this tutorial. That's an awful lot of work, believe me. I know it. Nonetheless I believe it's better to document 1 tutorial that way than publish a bunch of insider tutorials. The acceptance of first time cocoon users is the reward for the work. With a screenshot based documentation everyone is able to see if there is a difference between the tutorial and his own computer and check out why there is a difference (other versions etc.). For the reasons explained above I don't think it is a good idea to put IDE screenshots into the tutorials. Maybe putting in the result screens is helpful. One of the cocoon problems to gain more users is the difficulty to fit into the mainstream IDE/framework scheme. Showing how it fits into an IDE is the first step to do it better. It would be great if some native-speaker could do a screencast of the 4 tutorials. That would be even better than putting in screenshots IMO. Let's start. Maybe this is also an answer to the work needeed documenting with screenshots. Reinhard begin:vcard fn:Reinhard Haller n:Haller;Reinhard org:INTERACTIVE Computer Systems GmbH adr;quoted-printable:;;Hermann-Hesse-Str. 5;Kirchheim b. M=C3=BCnchen;Bayern;85551;Deutschland email;internet:[EMAIL PROTECTED]
Re: Cocoon Productivity
Reinhard I agree that the tutorial is more a barebones walkthrough of some key features - but it serves its purpose for that. I also think that the approach you outline needs to be taken in distinct steps: 1. Install and configure Cocoon (might differ by environment or OS) 2. Server-specific steps 3. Eclipse integration (or alternatives) 4. Working with Maven 5. Case study for some type of website (arguably anything you pick here will be limited from any one person's perspective) 6. Extra options (plug-ins?? related technologies) This is because in a team environment, not everyone does everything and handling these things in steps allows for separation of concerns. So we arrive back at the usual question of so this is a nice idea, but who will actually do it?? Derek PS I think its a little unfair to Jetty to imply its not production capable - see: http://docs.codehaus.org/display/JETTY/Jetty+Powered Reinhard Haller [EMAIL PROTECTED] 2007/06/01 10:09:27 AM Reinhard Poetz schrieb: I have been working on http://cocoon.zones.apache.org/daisy/cdocs/g2/g1/1370.html. I hope that it helps. said first I have no knowlwedge of maven or cocoon2.2. Your tutorials for me are typical examples of the problems regarding the current cocoon documentation. It's very valuable if you already know why and how to do what you want. It helps for nothing if you are a real beginner. Compare this to tutorials for Netbeans, Eclipse or the JBoss IDE. Instead of showing what you do and possibly why you do it, you choose a set of very simple unrelated topics to achieve a very short and pregnant documentation for people which already know what they do. Simply put the screenshots of your Eclipse in the documentation, this explains much more than your text. Document your example (your first Cocoon application ...) from the very beginning, i.e. installation and setup within eclipse (from svn/from distribution) including the setup for the application server if needed. Choose a real production application server instead of the bundled Jetty. Explain if it works with Plugins (WTP/JBoss IDE) and how. Providing the community with a non trivial tutorial that covers a website with structured templates for content, navigation and metadata, combined with a real world error handling would help to get new users an impression of the developement cycle and the structure of a cocoon application. If you also explain how to manage the different versions (cocoon, the cocoon application i.e. sitemap, the website templates and the web content) in one or more svn repositories then we have a sound base to start with and additional documentation can refer to this tutorial. With a screenshot based documentation everyone is able to see if there is a difference between the tutorial and his own computer and check out why there is a difference (other versions etc.). Greetings Reinhard -- This message is subject to the CSIR's copyright, terms and conditions and e-mail legal notice. Views expressed herein do not necessarily represent the views of the CSIR. CSIR E-mail Legal Notice http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html CSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.html For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal Notice send a blank message with REQUEST LEGAL in the subject line to [EMAIL PROTECTED] This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Cocoon Productivity
IMHO, as one who started cocoon earlier this year, the greatest need is for 'meta-documentation'. May I call it that? The simple things are clear and elegant. For the rest, there are hundreds of samples and masses of good documentation but it is all in little bits in separate places. Even within the official documentation, the bits for a simple form-flow-database project come from many different pages. There must be a dozen or more block / component sets that can work but perhaps only three or four that an up to date, experienced developer would recommend. Cocoon is big enough and complex enough now to need its own search engine. Something that + knows where all the documents and samples are and which software environments they work in (or not). + knows about all the blocks and components; how they overlap; how they compete or cooperate with each other; which are new, stable, deprecated, etc. + maintains a list of tasks that developers may be asked to carry out in the real world; how to glue the little bits together to make something really useful. + links it all together in a Perl sort of way [There is more than one way to do it.] with some kind of discussion of why one way may be better than another in a particular context (otherwise there is no learning). + helps sort out keyword conflicts, for example where a technical word is also a word in common use, or is used with different meanings by different blocks. Someone wrote about a 'wizard' but that may offer a single solution based on criteria that may not be general enough. As a beginner and a serious student, I would like to see the options, understand the pros and cons, choose one for myself. Robin Rigby -Original Message- From: Reinhard Haller [mailto:[EMAIL PROTECTED] Sent: 01 June 2007 09:09 To: users@cocoon.apache.org Subject: Re: Cocoon Productivity Reinhard Poetz schrieb: I have been working on http://cocoon.zones.apache.org/daisy/cdocs/g2/g1/1370.html. I hope that it helps. said first I have no knowlwedge of maven or cocoon2.2. Your tutorials for me are typical examples of the problems regarding the current cocoon documentation. It's very valuable if you already know why and how to do what you want. It helps for nothing if you are a real beginner. Compare this to tutorials for Netbeans, Eclipse or the JBoss IDE. Instead of showing what you do and possibly why you do it, you choose a set of very simple unrelated topics to achieve a very short and pregnant documentation for people which already know what they do. Simply put the screenshots of your Eclipse in the documentation, this explains much more than your text. Document your example (your first Cocoon application ...) from the very beginning, i.e. installation and setup within eclipse (from svn/from distribution) including the setup for the application server if needed. Choose a real production application server instead of the bundled Jetty. Explain if it works with Plugins (WTP/JBoss IDE) and how. Providing the community with a non trivial tutorial that covers a website with structured templates for content, navigation and metadata, combined with a real world error handling would help to get new users an impression of the developement cycle and the structure of a cocoon application. If you also explain how to manage the different versions (cocoon, the cocoon application i.e. sitemap, the website templates and the web content) in one or more svn repositories then we have a sound base to start with and additional documentation can refer to this tutorial. With a screenshot based documentation everyone is able to see if there is a difference between the tutorial and his own computer and check out why there is a difference (other versions etc.). Greetings Reinhard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Productivity
Reinhard Poetz schrieb: I have been working on http://cocoon.zones.apache.org/daisy/cdocs/g2/g1/1370.html. I hope that it helps. said first I have no knowlwedge of maven or cocoon2.2. Your tutorials for me are typical examples of the problems regarding the current cocoon documentation. It's very valuable if you already know why and how to do what you want. It helps for nothing if you are a real beginner. Compare this to tutorials for Netbeans, Eclipse or the JBoss IDE. Instead of showing what you do and possibly why you do it, you choose a set of very simple unrelated topics to achieve a very short and pregnant documentation for people which already know what they do. Simply put the screenshots of your Eclipse in the documentation, this explains much more than your text. Document your example (your first Cocoon application ...) from the very beginning, i.e. installation and setup within eclipse (from svn/from distribution) including the setup for the application server if needed. Choose a real production application server instead of the bundled Jetty. Explain if it works with Plugins (WTP/JBoss IDE) and how. Providing the community with a non trivial tutorial that covers a website with structured templates for content, navigation and metadata, combined with a real world error handling would help to get new users an impression of the developement cycle and the structure of a cocoon application. If you also explain how to manage the different versions (cocoon, the cocoon application i.e. sitemap, the website templates and the web content) in one or more svn repositories then we have a sound base to start with and additional documentation can refer to this tutorial. With a screenshot based documentation everyone is able to see if there is a difference between the tutorial and his own computer and check out why there is a difference (other versions etc.). Greetings Reinhard begin:vcard fn:Reinhard Haller n:Haller;Reinhard org:INTERACTIVE Computer Systems GmbH adr;quoted-printable:;;Hermann-Hesse-Str. 5;Kirchheim b. M=C3=BCnchen;Bayern;85551;Deutschland email;internet:[EMAIL PROTECTED] title:Dipl. Inform. tel;work:+49 89 904885-13 tel;fax:+49 89 904885-22 tel;cell:+49 171 8022551 x-mozilla-html:FALSE url:http://www.interactive-net.de version:2.1 end:vcard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Productivity
Hi Derek, Derek Hohls schrieb: PS I think its a little unfair to Jetty to imply its not production agreed. My point about Jetty is the integration within the cocoon distribution. Since most people curently are working with an IDE (Eclipse ...), in a basic tutorial we need also a chapter regarding the setup of a Servlet Container for debugging, testing and deployment of our cocoon apps within this environment. If the tutorial describes how to do it with Jetty as with any other application server I've no problems. Greetings Reinhard begin:vcard fn:Reinhard Haller n:Haller;Reinhard org:INTERACTIVE Computer Systems GmbH adr;quoted-printable:;;Hermann-Hesse-Str. 5;Kirchheim b. M=C3=BCnchen;Bayern;85551;Deutschland email;internet:[EMAIL PROTECTED] title:Dipl. Inform. tel;work:+49 89 904885-13 tel;fax:+49 89 904885-22 tel;cell:+49 171 8022551 x-mozilla-html:FALSE url:http://www.interactive-net.de version:2.1 end:vcard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Cocoon Productivity
Hi, Since most people curently are working with an IDE (Eclipse ...), in a basic tutorial we need also a chapter regarding the setup of a Servlet Container for debugging, testing and deployment of our cocoon apps within this environment. If the tutorial describes how to do it with Jetty as with any other application server I've no problems. I do not know if this is already addressed in 2.2, but for easier integration in JEE web apps, it would also be required to have a Cocoon Servlet which does not take any parameters, just like Sprint for example. At current (2.1), the Cocoon Servlet takes lots of scary parameters which may or may not change between versions. This is a burden when upgrading a web app to a newer version. Kind regards, Christian smime.p7s Description: S/MIME cryptographic signature
Re: Cocoon Productivity
Reinhard Haller wrote:
Reinhard Poetz schrieb:
I have been working on
http://cocoon.zones.apache.org/daisy/cdocs/g2/g1/1370.html. I hope
that it helps.
said first I have no knowlwedge of maven or cocoon2.2.
Your tutorials for me are typical examples of the problems regarding
the current cocoon documentation.
It's very valuable if you already know why and how to do what you want.
It helps for nothing if you are a real beginner.
What can we expect from a beginner, when we write documentation?
- Does he know how the request-response-cycle of the http protocol
works?
- Does he know what XML is?
- Is he able to read (and write) XSLT?
- Does he know what a servlet container is?
- etc.
Compare this to tutorials for Netbeans, Eclipse or the JBoss IDE.
hmm, those pieces of software are GUIs and not server-side applications.
Instead of showing what you do and possibly why you do it, you choose a
set of very simple unrelated topics to achieve a very short and pregnant
documentation for people which already know what they do.
I wouldn't say that they are unrelated but I agree with you that there is no use
case behind them.
Simply put the screenshots of your Eclipse in the documentation, this
explains much more than your text. Document your example (your first
Cocoon application ...) from the very beginning, i.e. installation and
setup within eclipse (from svn/from distribution) including the setup
for the application server if needed.
What's missing? Where did you get stuck?
Choose a real production
application server instead of the bundled Jetty. Explain if it works
with Plugins (WTP/JBoss IDE) and how.
IMO that's out of the scope of Cocoon. If we start to explain the deployment in
a Bea weblogic server someone will ask, how those things work in IBM websphere,
etc.
Cocoon is a web applications and we produce web archives (.war) that can be
deployed into any complient servlt container. Having a war, you can use one of
the illustrated tutorials of those containers to deploy your stuff there.
Providing the community with a non trivial tutorial that covers a
website with structured templates for content, navigation and metadata,
combined with a real world error handling would help to get new users an
impression of the developement cycle and the structure of a cocoon
application. If you also explain how to manage the different versions
(cocoon, the cocoon application i.e. sitemap, the website templates and
the web content) in one or more svn repositories then we have a sound
base to start with and additional documentation can refer to this tutorial.
That's an awful lot of work, believe me.
With a screenshot based documentation everyone is able to see if there
is a difference between the tutorial and his own computer and check out
why there is a difference (other versions etc.).
For the reasons explained above I don't think it is a good idea to put IDE
screenshots into the tutorials. Maybe putting in the result screens is helpful.
It would be great if some native-speaker could do a screencast of the 4
tutorials. That would be even better than putting in screenshots IMO.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Productivity
Yes, he does, though I disagree on some of the finer points e.g Cocoon is not a leading edge application any more and, no, its not always intuitive (such a fuzzy and subjective term); simply because a number of its concepts differ sharply from many other web development frameworks. I would also not suggest to rewrite the existing examples - wy too much work! - but simply to add template applications which each standalone and can be repurposed or extended to users' specific needs. Some input from the community would help rapidly identify good case studies. To my mind - and this reflects my experience in the workplace - as well as other 'voluntary' organisations - nothing actually happens without a champion to drive it. That person has a passion for the task at hand, and sees it through to completion. In this case, such a champion would have to have a good working knowledge of Cocoon (although not necessarily as a developer), with strong English writing and conceptual skills. This person would need to look at synthesising all the docs on the wiki and on the main/official site. Older stuff needs to be carefully hidden away and deprecated stuff marked clearly as such. Links to key outside resources (e.g. tutorials or introductory articles) could also be gathered in one place and annotated as needed. A one stop Cocoon shop. I would actually suggest that the project adopts one single platform for its documentation and this would likely have to be a wiki. The advantages of this are: * reduce scatter and where do I find this? syndrome * ability to do very rapid updates * allow only developer access to key pages, while still letting users add their own - *anyone* can add comments on discussion tabs and this will help the official pages to be brought up to speed. (It would be cool if official pages could be colour coded in some way to highlight them...) [Side note: I have a feeling that wiki design has evolved since the Cocoon wiki was chosen. While its adequate for the basics, many other software projects have chosen the wikipedia-style wiki as it allows for a lot of extra flexibility and options eg. navigation; ability to have discussions on each page; categories etc.] Jonathan Hipkiss [EMAIL PROTECTED] 2007/05/30 11:48:29 PM I think Fergus has it spot on here. Most developers operate by first copying another example of something that works, then they modify it to their own use. As a fall back, complete technical documentation of the technology is then needed to detail how it operates and what its syntax, grammar etc. are. Lastly, for the more complex techniques it can be useful if a very simple example is shown in a step by step approach to grasp the concepts before delving into the deeper all sing all dancing examples. Jonathan Fergus McMenemie wrote: As a new adopter of cocoon, I beg to differ from some of what I have read regarding documentation. Referring to cocoon version 2.1, it comes with lots and lots docs and examples. I really do not think we are dealing with a lack of documentation or examples. Rather it's a case of knocking what already exists into shape. Especially the examples. IMHO the examples need to be rewritten so that they function at two levels. Firstly, they should be shiny examples of cocoon functionality when played with via the browser. Secondly, each example should be totally standalone in its own sitemap, suitable for lifting from cocoon distribution and used as a template for new users getting started with cocoon. Individually the examples do fine at the first point, although cumulatively they are a rather disorganised mish-mash. At the second level it is a significant task for a new user to disentangle a demo application, that almost does what they need, from other related demos that share sitemaps, resources and other dependencies. I also suspect that a number of examples reflect practices which are now deprecated. Deprecated examples should be removed, there's nothing worse than getting your head around one method only to be told it's a dead technique and something else should be used instead. The coverage of documentation is patchy, some bits are quite well covered other bits rather poorly. When it is good it is very good. The general overviews, concepts and simple stuff is fine, but the detail of serializers, generators, generators and actions etc is where major problems really start to appear. Far to vague and in some cases unintuitive. I have not seen anyone else pointing it out, but after a day or two I was really struck by the fact that conceptually pipelines are not pipelines in any common understanding of the term; rather matchers are the pipelines! This sort of thing is very counter intuitive. Systems that are intuitive require a lot less documentation. On another level, and this is my experience of other leading edge technologies, I think we/you need to consider what it is your users
Re: Cocoon Productivity
Fergus McMenemie wrote: snip/ I have not seen anyone else pointing it out, but after a day or two I was really struck by the fact that conceptually pipelines are not pipelines in any common understanding of the term; rather matchers are the pipelines! I know what you mean, here in our office everyone call matchers pipelines too :-) snip/ I think there is a second way and that is tons of complete working, and documented examples. Such examples should at the same time be examples of the leading edge and best practice. Yep, that's more or less what I meant in my earlier post: good usable examples or use cases. In my trainings I always point my 'students' to the Cocoon samples, and those who take that advice seem to get up and running with the training exercises much faster. Niels - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Productivity
bart remmerie pisze: I've been a 'jojo' cocoon user for some years now and a convinced addict. The learning curve is rather steep, but with nices 'plateaus': repeated steps of steep learning followed by rather easy mass-production. snip/ Upgrading to a next version has never been a smooth process so far. I'm currently using 2.1.10 and the YourCocoonBasedProject ant scripts from the wiki. One day, I'll shift to 2.2, but so far, trying to set it up out of curiosity has brought me nothing but frustration. Could you share your experiences? I would like to know what caused the frustration. As a cocoon user, learning yet another framework (Maven) is not what I'm looking for. If is can make development easier, I'm interested to learn, but please explain the benefits basics to get people going before pushing them into a direction (they didn't ask for in the first place). Or replace the 'easy to use' by 'easy to use, ... if you are an experienced user of spring, maven and other related frameworks like hibernate, ...) Even I'm Cocoon developer I don't think about myself like a Maven or Spring guru. After switching to Maven 2.0.6 I'm really happy with it because most of annoying bugs has been resolved and working with Maven is really straightforward. Thanks to archetypes and quite good Cocoon's documentation on this topic (kudos to Reinhard) you really don't need to know Maven inside out. If cocoon has the ambition to be used, please pay attention to what the (potential) user wants (and documentation might be just one of the priorities). Our aim is to pay the attention but it's good if users provide some feedback. Thanks for your thoughts. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Productivity
Grzegorz Kossakowski wrote: bart remmerie pisze: Upgrading to a next version has never been a smooth process so far. I'm currently using 2.1.10 and the YourCocoonBasedProject ant scripts from the wiki. One day, I'll shift to 2.2, but so far, trying to set it up out of curiosity has brought me nothing but frustration. Could you share your experiences? I would like to know what caused the frustration. I share frustration and experiences. I tried several snapshots as well as direct svn checkout. The first error was due to undersized memory for mvn - corrected that. Build was nearly all the time ok. But running the stuff resulted several times in some obscure (my novice point of view) build error. When I managed to start Jetty either calls resulted in a 503 http error, the samples were not working or (my greatest success) my own webapp threw errors for didn't find this base component or didn't find that transformer. Still sticking to Cocoon like a fly to the trap ;-) Florian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Cocoon Productivity
Original Message Subject: Re: Cocoon Productivity From: Grzegorz Kossakowski [EMAIL PROTECTED] Date: Wed, May 30, 2007 7:15 am To: users@cocoon.apache.org [...] Even I'm Cocoon developer I don't think about myself like a Maven or Spring guru. After switching to Maven 2.0.6 I'm really happy with it because most of annoying bugs has been resolved and working with Maven is really straightforward. Thanks to archetypes and quite good Cocoon's documentation on this topic (kudos to Reinhard) you really don't need to know Maven inside out. Quite good Cocoon documentation on this topic, which is located at...? Also, Better Builds with Maven 2 seems like a very good maven tutorial. I found that at http://www.mergere.com/m2book_download.jsp . J. Toman http://lillibilli.com Web Hosting, Domain Names, more! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Productivity
[EMAIL PROTECTED] pisze: Original Message Subject: Re: Cocoon Productivity From: Grzegorz Kossakowski [EMAIL PROTECTED] Date: Wed, May 30, 2007 7:15 am To: users@cocoon.apache.org [...] Even I'm Cocoon developer I don't think about myself like a Maven or Spring guru. After switching to Maven 2.0.6 I'm really happy with it because most of annoying bugs has been resolved and working with Maven is really straightforward. Thanks to archetypes and quite good Cocoon's documentation on this topic (kudos to Reinhard) you really don't need to know Maven inside out. Quite good Cocoon documentation on this topic, which is located at...? http://cocoon.zones.apache.org/daisy/cdocs/g2/g2/g1/1159.html and from this document. Instructions in this tutorial rely on RC versions that has *NOT* been released yet so they will not work *NOW*. However, it will give you an idea how you will be able to do things as soon as artifacts are officialy released. This will happen really soon, see: http://article.gmane.org/gmane.text.xml.cocoon.devel/73456 -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Cocoon Productivity
Hi, sounds exciting. please allow to me ask the following as a seasoned NetBeans user and Cocoon newby: What will I lose if I want to use Cocoon 2.2 in NetBeans 5.5.1? Will I still be able to follow the instructions or do I need to figure everything myself? Kind regards, Christian Schlichtherle -Original Message- From: Grzegorz Kossakowski [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 30, 2007 7:29 PM To: users@cocoon.apache.org Subject: Re: Cocoon Productivity [EMAIL PROTECTED] pisze: Original Message Subject: Re: Cocoon Productivity From: Grzegorz Kossakowski [EMAIL PROTECTED] Date: Wed, May 30, 2007 7:15 am To: users@cocoon.apache.org [...] Even I'm Cocoon developer I don't think about myself like a Maven or Spring guru. After switching to Maven 2.0.6 I'm really happy with it because most of annoying bugs has been resolved and working with Maven is really straightforward. Thanks to archetypes and quite good Cocoon's documentation on this topic (kudos to Reinhard) you really don't need to know Maven inside out. Quite good Cocoon documentation on this topic, which is located at...? http://cocoon.zones.apache.org/daisy/cdocs/g2/g2/g1/1159.html and from this document. Instructions in this tutorial rely on RC versions that has *NOT* been released yet so they will not work *NOW*. However, it will give you an idea how you will be able to do things as soon as artifacts are officialy released. This will happen really soon, see: http://article.gmane.org/gmane.text.xml.cocoon.devel/73456 -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: Cocoon Productivity
Christian Schlichtherle pisze: Hi, sounds exciting. please allow to me ask the following as a seasoned NetBeans user and Cocoon newby: What will I lose if I want to use Cocoon 2.2 in NetBeans 5.5.1? Will I still be able to follow the instructions or do I need to figure everything myself? I have almost no experience with Netbeans so treat my answer lightly. The only Eclipse-specific step is generating eclipse's project description file by using 'eclipse' plugin: mvn eclipse:eclipse There is a similar plug-in mentioned here: http://mojo.codehaus.org/netbeans-freeform-maven-plugin/. It mentions that it works with Netbeans 4.x but it may work with Netbeans 5.5.1, you must just try it. Even if you don't find necessary plug-in you can always set up project in Netbeans manually but it will involve some tedious work of adding all dependencies by hand. The question should be directed more to Netbeans/Maven lists to find out if Netbeans IDE is supported by Maven. From Cocoon's point of view it doesn't matter what kind of IDE/editor you use. The rest of instructions will work even if you use basic text editor. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Cocoon Productivity
Original Message Subject: Re: Cocoon Productivity From: Grzegorz Kossakowski [EMAIL PROTECTED] Date: Wed, May 30, 2007 10:29 am To: users@cocoon.apache.org [EMAIL PROTECTED] pisze: Original Message Subject: Re: Cocoon Productivity From: Grzegorz Kossakowski [EMAIL PROTECTED] Date: Wed, May 30, 2007 7:15 am To: users@cocoon.apache.org [...] Even I'm Cocoon developer I don't think about myself like a Maven or Spring guru. After switching to Maven 2.0.6 I'm really happy with it because most of annoying bugs has been resolved and working with Maven is really straightforward. Thanks to archetypes and quite good Cocoon's documentation on this topic (kudos to Reinhard) you really don't need to know Maven inside out. Quite good Cocoon documentation on this topic, which is located at...? http://cocoon.zones.apache.org/daisy/cdocs/g2/g2/g1/1159.html and from this document. Instructions in this tutorial rely on RC versions that has *NOT* been released yet so they will not work *NOW*. However, it will give you an idea how you will be able to do things as soon as artifacts are officialy released. This will happen really soon, see: http://article.gmane.org/gmane.text.xml.cocoon.devel/73456 Actually, I found this from an automated message on the docs list, but this explains why it failed on me when I tried it this morning. Thanks, J. Toman http://lillibilli.com Web Hosting, Domain Names, more! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Productivity
As a new adopter of cocoon, I beg to differ from some of what I have read regarding documentation. Referring to cocoon version 2.1, it comes with lots and lots docs and examples. I really do not think we are dealing with a lack of documentation or examples. Rather it's a case of knocking what already exists into shape. Especially the examples. IMHO the examples need to be rewritten so that they function at two levels. Firstly, they should be shiny examples of cocoon functionality when played with via the browser. Secondly, each example should be totally standalone in its own sitemap, suitable for lifting from cocoon distribution and used as a template for new users getting started with cocoon. Individually the examples do fine at the first point, although cumulatively they are a rather disorganised mish-mash. At the second level it is a significant task for a new user to disentangle a demo application, that almost does what they need, from other related demos that share sitemaps, resources and other dependencies. I also suspect that a number of examples reflect practices which are now deprecated. Deprecated examples should be removed, there's nothing worse than getting your head around one method only to be told it's a dead technique and something else should be used instead. The coverage of documentation is patchy, some bits are quite well covered other bits rather poorly. When it is good it is very good. The general overviews, concepts and simple stuff is fine, but the detail of serializers, generators, generators and actions etc is where major problems really start to appear. Far to vague and in some cases unintuitive. I have not seen anyone else pointing it out, but after a day or two I was really struck by the fact that conceptually pipelines are not pipelines in any common understanding of the term; rather matchers are the pipelines! This sort of thing is very counter intuitive. Systems that are intuitive require a lot less documentation. On another level, and this is my experience of other leading edge technologies, I think we/you need to consider what it is your users really need. A well done body of documentation will always lag behind any rapidly moving software development activity. Documentation that is out of date is next to useless. So what do you do? Slow down the developers and force them to support or wait for those doing the documentation? Or accept that documentation will never catch up with the leading edge and find another way. I think there is a second way and that is tons of complete working, and documented examples. Such examples should at the same time be examples of the leading edge and best practice. A good clear and relevant example will always get you 70% of where you need to be. Having got that far you can generally figure out the rest using the wiki and other resources. Regards Fergus. -- === Fergus McMenemie Email:[EMAIL PROTECTED] Techmore Ltd Phone:(UK) 07721 376021 Unix/Mac/Intranets Analyst Programmer === - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Productivity
I think Fergus has it spot on here. Most developers operate by first copying another example of something that works, then they modify it to their own use. As a fall back, complete technical documentation of the technology is then needed to detail how it operates and what its syntax, grammar etc. are. Lastly, for the more complex techniques it can be useful if a very simple example is shown in a step by step approach to grasp the concepts before delving into the deeper all sing all dancing examples. Jonathan Fergus McMenemie wrote: As a new adopter of cocoon, I beg to differ from some of what I have read regarding documentation. Referring to cocoon version 2.1, it comes with lots and lots docs and examples. I really do not think we are dealing with a lack of documentation or examples. Rather it's a case of knocking what already exists into shape. Especially the examples. IMHO the examples need to be rewritten so that they function at two levels. Firstly, they should be shiny examples of cocoon functionality when played with via the browser. Secondly, each example should be totally standalone in its own sitemap, suitable for lifting from cocoon distribution and used as a template for new users getting started with cocoon. Individually the examples do fine at the first point, although cumulatively they are a rather disorganised mish-mash. At the second level it is a significant task for a new user to disentangle a demo application, that almost does what they need, from other related demos that share sitemaps, resources and other dependencies. I also suspect that a number of examples reflect practices which are now deprecated. Deprecated examples should be removed, there's nothing worse than getting your head around one method only to be told it's a dead technique and something else should be used instead. The coverage of documentation is patchy, some bits are quite well covered other bits rather poorly. When it is good it is very good. The general overviews, concepts and simple stuff is fine, but the detail of serializers, generators, generators and actions etc is where major problems really start to appear. Far to vague and in some cases unintuitive. I have not seen anyone else pointing it out, but after a day or two I was really struck by the fact that conceptually pipelines are not pipelines in any common understanding of the term; rather matchers are the pipelines! This sort of thing is very counter intuitive. Systems that are intuitive require a lot less documentation. On another level, and this is my experience of other leading edge technologies, I think we/you need to consider what it is your users really need. A well done body of documentation will always lag behind any rapidly moving software development activity. Documentation that is out of date is next to useless. So what do you do? Slow down the developers and force them to support or wait for those doing the documentation? Or accept that documentation will never catch up with the leading edge and find another way. I think there is a second way and that is tons of complete working, and documented examples. Such examples should at the same time be examples of the leading edge and best practice. A good clear and relevant example will always get you 70% of where you need to be. Having got that far you can generally figure out the rest using the wiki and other resources. Regards Fergus. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Productivity
Niels van Kampenhout wrote:
Reinhard Poetz wrote:
snip/
Of course all the software engineering principles apply as much to
Cocoon applications as to any other, but most people find it difficult
to abstract away from the traditional frameworks for which they
learned their patterns, and apply their knowledge to Cocoon. And that's
no surprise, because Cocoon is so big, you can do so much with it, and
you can do it in so many ways. There are some best practices that are
known in the community, about which we speak at the GetTogether, but
that's pretty much it. You really have to learn everything about Cocoon
from the bottom up to find out how a particular type of application is
best set up in Cocoon. Getting up and running with your first Cocoon
project, and this is why this discussion started, is therefor really
difficult. Even the best documentation about how sitemaps and pipelines
work will not solve this!
I have been working on
http://cocoon.zones.apache.org/daisy/cdocs/g2/g1/1370.html. I hope that it helps.
What really works in my experience is turning the learning curve upside
down and providing people with patterns and components that simply work,
and work transparently, so that at first they don't have to think about
it. For example, Ard put a lot of work in making a website skeleton
generator, which basically does that whole first step of deciding how to
set up the application for you. The generated skeleton is preconfigured
with subsitemaps, caching and everything, and it contains many little
components that do things like paging of lists, mounting subsitemaps
based on our specific navigation concept, etc. This skeleton generator
meant a giant leap in productivity for our implementation partners.
Getting up and running is no longer a problem, and through the pre set
up skeleton the developers seem to get better at working with the Cocoon
concepts much faster. At some point they might even discover that things
could be done in a better way than in the skeleton!
could be a great enhancement for the Cocoon Maven 2 plugin
Of course we have our very specific use case of a web site presenting
content from a certain CMS/Repository and our patterns may not work for
other situations, but what I am trying to say is that in my opinion the
missing link between Cocoon as a brilliant framework and Cocoon as a
widely accepted framework is the lack of a mapping between the bare
concepts and actual real-life application development.
Filling this gap is of course more difficult for Cocoon than for web
sites based on a specific CMS, but a first step could be describing how
some common use cases (there's a user list out there == use cases!)
could be implemented with Cocoon, or even better, providing reference
implementations that go much further than the current samples. In my
dream I even see a wizard through which one can generate a preconfigured
application skeleton for a number of different cases. These things exist
for other frameworks you know!
(Blocks and Maven 2 archetypes might be a small first step towards this
dream, I don't know, I haven't been able to check it out yet.)
The archetypes yes but blocks solve a different but somehow related problem.
Anyway, these are just my 2 cents (needed a lot of words for those 2
cents though), I hope it is a useful contribution to this discussion. :-)
Thanks Niels. What I learn from your response is that it would be great to have
an equivalent to the RoR scaffolding command. What skeleton apps would you like
to generate?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Productivity
Derek Hohls wrote: Is there anyway you would consider making this generator - well documented, of course :-) - available to the community? Actually it is available from our public SVN repository. It is a Hippo Cocoon project so it is not directly usable for everyone. Currently I have someone working on a wizard-like GUI for it, and I will work on the documentation myself. As soon as the complete package is available I will announce it. Niels - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Productivity
Reinhard Poetz wrote: I have been working on http://cocoon.zones.apache.org/daisy/cdocs/g2/g1/1370.html. I hope that it helps. Looks good, this is indeed the direction I am thinking in. Thanks Niels. What I learn from your response is that it would be great to have an equivalent to the RoR scaffolding command. What skeleton apps would you like to generate? I have never done anything with RoR but from what I have heard about this scaffolding thing, yes that's probably what I mean. Exactly what kind of skeleton apps would be good I don't really know, apart of course from my own use case, a website :-) But since this is a user list, users what are your use cases? What apps do you build with Cocoon? Regards, Niels - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Cocoon Productivity
Niels van Kampenhout wrote: But I just have a strong feeling that for someone without years of Cocoon experience it is too easy to screw up. It depends a lot on what you want to do. Cocoon is brilliant at simple stuff. My problem when learning Cocoon was that the documentation on the website discussed XSP, Actions and dozens of other things that you simply shouldn't use. Cocoon is all about generator-transformer-serializer, and everything that fits into that model is easy to learn, once you realise that this is actually what it's all about. Some people get it, some need a little longer to understand, others possibly never will. This is OK I guess. But once they see it, the difficulties really start. Where to go from here? How to develop a real, complex application with Cocoon? I think the most important thing to realise about Cocoon is that it's a framework of Java components. Cocoon is great at the simple generator/aggregator-transformer-serializer pipeline, but I think all the really complex stuff should be done in Java components as much as possible. In too many projects I've seen people trying to do complex stuff in XSLT, or using flowscript to do all the stuff that the pipeline can't. The problem is that while flowscript is very powerful, it doesn't quite fit in the pipeline way of working, and that makes lots of things more complex than they should be. Of course all the software engineering principles apply as much to Cocoon applications as to any other, but most people find it difficult to abstract away from the traditional frameworks for which they learned their patterns, and apply their knowledge to Cocoon. And that's no surprise, because Cocoon is so big, you can do so much with it, and you can do it in so many ways. And many of those ways are IMO too complex and too inefficient. I think the basic pipeline is really easy to understand, as are the basics of how XSLT should be used (i.e: not for logic and calculations, but only for changing the structure of the XML). Everything more complex than that should be done in Java, which immediately makes more use of traditional programming experience. mcv. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Productivity
I've been a 'jojo' cocoon user for some years now and a convinced addict. The learning curve is rather steep, but with nices 'plateaus': repeated steps of steep learning followed by rather easy mass-production. What has frustrated me the most are 2 things: lack of evident documentation upgrading With lack of evident documentation, I basically mean the existence of docs that go just that one step further. for example, in CForms, explaining the insert-bean stuff just a little bit more than just a couple of lines in the documentation. Now you have to combine a lot of sources: mailing lists, wiki, docs, api-docs, ... It's true that the user who persists learns a lot about cocoon when trying to find out everything by her/himself, ... but 'easy to use' should be replaced by something like 'satisfying to learn on your own'. Upgrading to a next version has never been a smooth process so far. I'm currently using 2.1.10 and the YourCocoonBasedProject ant scripts from the wiki. One day, I'll shift to 2.2, but so far, trying to set it up out of curiosity has brought me nothing but frustration. As a cocoon user, learning yet another framework (Maven) is not what I'm looking for. If is can make development easier, I'm interested to learn, but please explain the benefits basics to get people going before pushing them into a direction (they didn't ask for in the first place). Or replace the 'easy to use' by 'easy to use, ... if you are an experienced user of spring, maven and other related frameworks like hibernate, ...) If cocoon has the ambition to be used, please pay attention to what the (potential) user wants (and documentation might be just one of the priorities). Bart 2007/5/29, Martijn C. Vos [EMAIL PROTECTED]: Niels van Kampenhout wrote: But I just have a strong feeling that for someone without years of Cocoon experience it is too easy to screw up. It depends a lot on what you want to do. Cocoon is brilliant at simple stuff. My problem when learning Cocoon was that the documentation on the website discussed XSP, Actions and dozens of other things that you simply shouldn't use. Cocoon is all about generator-transformer-serializer, and everything that fits into that model is easy to learn, once you realise that this is actually what it's all about. Some people get it, some need a little longer to understand, others possibly never will. This is OK I guess. But once they see it, the difficulties really start. Where to go from here? How to develop a real, complex application with Cocoon? I think the most important thing to realise about Cocoon is that it's a framework of Java components. Cocoon is great at the simple generator/aggregator-transformer-serializer pipeline, but I think all the really complex stuff should be done in Java components as much as possible. In too many projects I've seen people trying to do complex stuff in XSLT, or using flowscript to do all the stuff that the pipeline can't. The problem is that while flowscript is very powerful, it doesn't quite fit in the pipeline way of working, and that makes lots of things more complex than they should be. Of course all the software engineering principles apply as much to Cocoon applications as to any other, but most people find it difficult to abstract away from the traditional frameworks for which they learned their patterns, and apply their knowledge to Cocoon. And that's no surprise, because Cocoon is so big, you can do so much with it, and you can do it in so many ways. And many of those ways are IMO too complex and too inefficient. I think the basic pipeline is really easy to understand, as are the basics of how XSLT should be used (i.e: not for logic and calculations, but only for changing the structure of the XML). Everything more complex than that should be done in Java, which immediately makes more use of traditional programming experience. mcv. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Bart Remmerie
Re: Cocoon Productivity
Bart I am not sure what a 'jojo' is... but otherwise * for your post (5 star grading). I have a feeling this reflects what most of the 'typical' Cocoon users feel (not the power users who even dream in Java... :-) bart remmerie [EMAIL PROTECTED] 2007/05/29 12:14:28 PM I've been a 'jojo' cocoon user for some years now and a convinced addict. The learning curve is rather steep, but with nices 'plateaus': repeated steps of steep learning followed by rather easy mass-production. What has frustrated me the most are 2 things: lack of evident documentation upgrading With lack of evident documentation, I basically mean the existence of docs that go just that one step further. for example, in CForms, explaining the insert-bean stuff just a little bit more than just a couple of lines in the documentation. Now you have to combine a lot of sources: mailing lists, wiki, docs, api-docs, ... It's true that the user who persists learns a lot about cocoon when trying to find out everything by her/himself, ... but 'easy to use' should be replaced by something like 'satisfying to learn on your own'. Upgrading to a next version has never been a smooth process so far. I'm currently using 2.1.10 and the YourCocoonBasedProject ant scripts from the wiki. One day, I'll shift to 2.2, but so far, trying to set it up out of curiosity has brought me nothing but frustration. As a cocoon user, learning yet another framework (Maven) is not what I'm looking for. If is can make development easier, I'm interested to learn, but please explain the benefits basics to get people going before pushing them into a direction (they didn't ask for in the first place). Or replace the 'easy to use' by 'easy to use, ... if you are an experienced user of spring, maven and other related frameworks like hibernate, ...) If cocoon has the ambition to be used, please pay attention to what the (potential) user wants (and documentation might be just one of the priorities). Bart 2007/5/29, Martijn C. Vos [EMAIL PROTECTED]:Niels van Kampenhout wrote: But I just have a strong feeling that for someone without years of Cocoon experience it is too easy to screw up. It depends a lot on what you want to do. Cocoon is brilliant at simple stuff. My problem when learning Cocoon was that the documentation on the website discussed XSP, Actions and dozens of other things that you simply shouldn't use. Cocoon is all about generator-transformer-serializer, and everything that fits into that model is easy to learn, once you realise that this is actually what it's all about. Some people get it, some need a little longer to understand, others possibly never will. This is OK I guess. But once they see it, the difficulties really start. Where to go from here? How to develop a real, complex application with Cocoon? I think the most important thing to realise about Cocoon is that it's a framework of Java components. Cocoon is great at the simple generator/aggregator-transformer-serializer pipeline, but I think all the really complex stuff should be done in Java components as much as possible. In too many projects I've seen people trying to do complex stuff in XSLT, or using flowscript to do all the stuff that the pipeline can't. The problem is that while flowscript is very powerful, it doesn't quite fit in the pipeline way of working, and that makes lots of things more complex than they should be. Of course all the software engineering principles apply as much to Cocoon applications as to any other, but most people find it difficult to abstract away from the traditional frameworks for which they learned their patterns, and apply their knowledge to Cocoon. And that's no surprise, because Cocoon is so big, you can do so much with it, and you can do it in so many ways. And many of those ways are IMO too complex and too inefficient. I think the basic pipeline is really easy to understand, as are the basics of how XSLT should be used ( i.e: not for logic and calculations, but only for changing the structure of the XML). Everything more complex than that should be done in Java, which immediately makes more use of traditional programming experience. mcv. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Bart Remmerie -- This message is subject to the CSIR's copyright, terms and conditions and e-mail legal notice. Views expressed herein do not necessarily represent the views of the CSIR. CSIR E-mail Legal Notice http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html CSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.html For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal Notice send a blank message with REQUEST LEGAL in the subject line to [EMAIL PROTECTED] This message has been scanned for viruses and dangerous content by
RE: Cocoon Productivity
Martijn What you say may be true; but the fact is that those of us who come to Cocoon without a Java background tend to use it in the way you describe below. For me, XSLT and Javascript (flowscript) are a powerful combination that lets almost anything be done in a Cocoon framework without the need to roll our own generators or transformers. Java is too much of a heavyweight language to use for casual web development. Now if it was possible to write generators or transformers in other languages and plug them in via a common API - then all of us could start laying down some really sweet patterns of behaviour without a second thought! Martijn C. Vos [EMAIL PROTECTED] 2007/05/29 11:32:45 AM I think all the really complex stuff should be done in Java components as much as possible. In too many projects I've seen people trying to do complex stuff in XSLT, or using flowscript to do all the stuff that the pipeline can't. The problem is that while flowscript is very powerful, it doesn't quite fit in the pipeline way of working, and that makes lots of things more complex than they should be. Of course all the software engineering principles apply as much to Cocoon applications as to any other, but most people find it difficult to abstract away from the traditional frameworks for which they learned their patterns, and apply their knowledge to Cocoon. And that's no surprise, because Cocoon is so big, you can do so much with it, and you can do it in so many ways. And many of those ways are IMO too complex and too inefficient. I think the basic pipeline is really easy to understand, as are the basics of how XSLT should be used (i.e: not for logic and calculations, but only for changing the structure of the XML). Everything more complex than that should be done in Java, which immediately makes more use of traditional programming experience. mcv. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- This message is subject to the CSIR's copyright, terms and conditions and e-mail legal notice. Views expressed herein do not necessarily represent the views of the CSIR. CSIR E-mail Legal Notice http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html CSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.html For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal Notice send a blank message with REQUEST LEGAL in the subject line to [EMAIL PROTECTED] This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Productivity
Hello everyone, Very interesting topic, would have answered earlier if I was not on holidays (NYC is great BTW ;) ) As a very new cocoon user (less than 3 months) and an early junior programmer (ending my final study year in august), I think my opinion has it's place here. Being a fresh programmer reduce a lot the already has another way of thinking factor and migration issue. I agree on the lack of documentation on several points : First of all, information is scattered a bit. You got to know some google practices to find all you need. I used cocoon main site, daisy, wiki, Anyware 2003 formation, several introductions to cocoon, cocoon GT pdf and mailing list. And co-worker advice. Knowing google's filetype: or site: parameters was really handy as I found very decent docs on cocoon. And deprecated ones too ;) Asking for up-to-date docs on 2.1 is obviously silly with the upcoming 2.2 release, but it would have been great to have GT pdf linked or integrated. About overview of cocoon, I may be writing nonsense as MVC is one implementation of more generic OOP patterns (SOC...), but it was quite hard for me to clearly see the MVC/PAC-like architecture of sitemap-FS-java. The overview page talks about XSPs and the FS part deals a lot with continuations, hiding the advantages of having FS as control layer. Showing the new user known patterns helps him to understand faster. So the first page of the documentation should always be updated and attractive to the new user (linear reading of the docs...). The documentation is quite big, but not enough IMHO for such a huge framework. What I miss the most is some trivial examples on details, I have to guess or dig in the docs/samples to find the answers. Ultimately, this leads to questions on the mailing list already documented (although this creates more answers on google later :) ) Quite messy mail, as was and still is my way of learning Cocoon. - Baptiste PS : I'd like to know if something like Raccoon is still worked on ! ( http://cocoongt.hippo12.castaserver.com/cocoongt/andrew-savory.pdf and http://www.andrewsavory.com/blog/archives/000803.html if you wonder what it is) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Productivity
Niels You say: For example, Ard put a lot of work in making a website skeleton generator, which basically does that whole first step of deciding how to set up the application for you. The generated skeleton is preconfigured with subsitemaps, caching and everything, and it contains many little components that do things like paging of lists, mounting subsitemaps based on our specific navigation concept, etc. This skeleton generator meant a giant leap in productivity for our implementation partners. Getting up and running is no longer a problem, and through the pre set up skeleton the developers seem to get better at working with the Cocoon concepts much faster. At some point they might even discover that things could be done in a better way than in the skeleton! Is there anyway you would consider making this generator - well documented, of course :-) - available to the community? It might inspire some of us to adopt a similar approach and, who knows, may lead to a whole, new, better way of doing things. It seems most people agree that getting started with Cocoon is a big leap and, while I do not agree that you need to know *everything* before you start (not for simpler use cases, anyway), anything that maximisers the ability to get going straight out of the box is surely of great help? Cheers Derek (Who is now wondering how he can do something similar for his simple flow-based database app...) -- This message is subject to the CSIR's copyright, terms and conditions and e-mail legal notice. Views expressed herein do not necessarily represent the views of the CSIR. CSIR E-mail Legal Notice http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html CSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.html For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal Notice send a blank message with REQUEST LEGAL in the subject line to [EMAIL PROTECTED] This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Productivity
Reinhard Poetz wrote: Derek Hohls wrote: Grzegorz Do you think this a valid criticism - are WebObjects (whatever those are) or Struts (Java coded framework) really that more productive and easy to use than Cocoon?? no, but they come with better documentation. I have been following this discussion from the sideline, and I have not worked with Cocoon 2.2 yet, but as someone who regularly trains and guides other developers in working with Cocoon (2.1), I'd like to add some thoughts about this. It is true that Cocoon's documentation is not good enough, and this *must* improve for Cocoon ever to achieve wide acceptance, but in my opinion a bigger problem is that Cocoon itself is not good enough. Don't get me wrong, I think Cocoon is a great framework and I do believe in it. But I just have a strong feeling that for someone without years of Cocoon experience it is too easy to screw up. Something essential is missing in Cocoon. Making the mental transition from traditional thinking to the Cocoon way of thinking (you know what I mean) will always be a requirement for a developer to be able to write sensible Cocoon applications, and this is what I focus on in my introductory Cocoon trainings. Some people get it, some need a little longer to understand, others possibly never will. This is OK I guess. But once they see it, the difficulties really start. Where to go from here? How to develop a real, complex application with Cocoon? Of course all the software engineering principles apply as much to Cocoon applications as to any other, but most people find it difficult to abstract away from the traditional frameworks for which they learned their patterns, and apply their knowledge to Cocoon. And that's no surprise, because Cocoon is so big, you can do so much with it, and you can do it in so many ways. There are some best practices that are known in the community, about which we speak at the GetTogether, but that's pretty much it. You really have to learn everything about Cocoon from the bottom up to find out how a particular type of application is best set up in Cocoon. Getting up and running with your first Cocoon project, and this is why this discussion started, is therefor really difficult. Even the best documentation about how sitemaps and pipelines work will not solve this! What really works in my experience is turning the learning curve upside down and providing people with patterns and components that simply work, and work transparently, so that at first they don't have to think about it. For example, Ard put a lot of work in making a website skeleton generator, which basically does that whole first step of deciding how to set up the application for you. The generated skeleton is preconfigured with subsitemaps, caching and everything, and it contains many little components that do things like paging of lists, mounting subsitemaps based on our specific navigation concept, etc. This skeleton generator meant a giant leap in productivity for our implementation partners. Getting up and running is no longer a problem, and through the pre set up skeleton the developers seem to get better at working with the Cocoon concepts much faster. At some point they might even discover that things could be done in a better way than in the skeleton! Of course we have our very specific use case of a web site presenting content from a certain CMS/Repository and our patterns may not work for other situations, but what I am trying to say is that in my opinion the missing link between Cocoon as a brilliant framework and Cocoon as a widely accepted framework is the lack of a mapping between the bare concepts and actual real-life application development. Filling this gap is of course more difficult for Cocoon than for web sites based on a specific CMS, but a first step could be describing how some common use cases (there's a user list out there == use cases!) could be implemented with Cocoon, or even better, providing reference implementations that go much further than the current samples. In my dream I even see a wizard through which one can generate a preconfigured application skeleton for a number of different cases. These things exist for other frameworks you know! (Blocks and Maven 2 archetypes might be a small first step towards this dream, I don't know, I haven't been able to check it out yet.) Anyway, these are just my 2 cents (needed a lot of words for those 2 cents though), I hope it is a useful contribution to this discussion. :-) Regards, Niels - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Productivity [was Re: Sitemap patterns dead?]
Derek Hohls wrote: Grzegorz Do you think this a valid criticism - are WebObjects (whatever those are) or Struts (Java coded framework) really that more productive and easy to use than Cocoon?? Just for reference, imho WebObjects (http://www.apple.com/webobjects/) is one of the best frameworks for web applications. Unfortunately it wasn't able to attract the masses over a longer time. (Hmm, sounds somehow familiar?) Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Productivity
Derek Hohls wrote:
Grzegorz
Do you think this a valid criticism - are WebObjects (whatever
those are) or Struts (Java coded framework) really that more
productive and easy to use than Cocoon??
no, but they come with better documentation.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Productivity
Reinhard
I have been with Cocoon since the late '90s and as will continue
to use it unless forced otherwise... but is it really fair to say
that Cocoon is easy to use unless it (one day?) gets better
docs. I know this a FAC (frequently occurring complaint) - and
if I ever come into an IT fortune such as Mark Shuttleworth's
this will be the first area I will invest in!
Reinhard Poetz [EMAIL PROTECTED] 2007/05/22 09:49 AM
Derek Hohls wrote:
Grzegorz
Do you think this a valid criticism - are WebObjects (whatever
those are) or Struts (Java coded framework) really that more
productive and easy to use than Cocoon??
no, but they come with better documentation.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
This message is subject to the CSIR's copyright, terms and conditions and
e-mail legal notice. Views expressed herein do not necessarily represent the
views of the CSIR.
CSIR E-mail Legal Notice
http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html
CSIR Copyright, Terms and Conditions
http://mail.csir.co.za/CSIR_Copyright.html
For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR
Legal Notice send a blank message with REQUEST LEGAL in the subject line to
[EMAIL PROTECTED]
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Productivity
Derek Hohls wrote:
Reinhard
I have been with Cocoon since the late '90s and as will continue
to use it unless forced otherwise... but is it really fair to say
that Cocoon is easy to use unless it (one day?) gets better
docs.
Compared with JSF and Struts Cocoon is very different. This means that you have
to learn to think in Cocoon (btw, the same is true for frameworks like Tapestry
or Wicket). Without good documentation it is very difficult to learn this way of
thinking and hence my reasoning that we need better docs.
Additionally, Cocoon 2.0 and 2.1 are huge frameworks and give you the impression
that you have to learn everything before you can even start. It is also
difficult to start your own Cocoon project and integrate it into your
development process, to configure it for different deployment environments and
to modularize it. Cocoon 2.2 will solve these problems and IMHO 2.2 will become
competitive again.
Furtunatly Cocoon 2.2 isn't far anymore (the release of the first release
candidate should happen next week) and some of us are working on a relaunch of
the Cocoon website which will come together with a major overhaul of our
documentation. Then we will see if our diagnosis concerning the technical
problems and my assessment of the importance of documentation was correct.
I know this a FAC (frequently occurring complaint) - and
if I ever come into an IT fortune such as Mark Shuttleworth's
this will be the first area I will invest in!
You're welcome :-)
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Productivity
On 5/22/07, Reinhard Poetz [EMAIL PROTECTED] wrote:
Derek Hohls wrote:
Reinhard
I have been with Cocoon since the late '90s and as will continue
to use it unless forced otherwise... but is it really fair to say
that Cocoon is easy to use unless it (one day?) gets better
docs.
Compared with JSF and Struts Cocoon is very different. This means that you have
to learn to think in Cocoon (btw, the same is true for frameworks like Tapestry
or Wicket). Without good documentation it is very difficult to learn this way of
thinking and hence my reasoning that we need better docs.
Additionally, Cocoon 2.0 and 2.1 are huge frameworks and give you the impression
that you have to learn everything before you can even start. It is also
difficult to start your own Cocoon project and integrate it into your
development process, to configure it for different deployment environments and
to modularize it. Cocoon 2.2 will solve these problems and IMHO 2.2 will become
competitive again.
Furtunatly Cocoon 2.2 isn't far anymore (the release of the first release
candidate should happen next week) and some of us are working on a relaunch of
the Cocoon website which will come together with a major overhaul of our
documentation. Then we will see if our diagnosis concerning the technical
problems and my assessment of the importance of documentation was correct.
FWIW, more documentation won't necessarily help Cocoon I think.
Cocoon suffers, if you can call it that, from just being different as
you say. That means that if the intent is to bring new people to
Cocoon - which I assume is the purpose of portraying it as easy to use
- then the type of documentation that's necessary is different.
Cocoon docs need to:
o) Bridge the gap between what people currently know/are comfortable
with (e.g. typical MVC - s2/spring mvc).
o) Make the case why the technical approach is better/more elegant [in
all or certain situations].
o) Close the sell with some ultra-simple examples. (e.g. one or more
simple war's that can be dropped on tomcat to demonstrate its
elegance).
Anyway, just some quick thoughts from a distance...
--tim
I know this a FAC (frequently occurring complaint) - and
if I ever come into an IT fortune such as Mark Shuttleworth's
this will be the first area I will invest in!
You're welcome :-)
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Productivity
FWIW, more documentation won't necessarily help Cocoon I think. Cocoon suffers, if you can call it that, from just being different as you say. That means that if the intent is to bring new people to Cocoon - which I assume is the purpose of portraying it as easy to use - then the type of documentation that's necessary is different. Cocoon docs need to: o) Bridge the gap between what people currently know/are comfortable with (e.g. typical MVC - s2/spring mvc). o) Make the case why the technical approach is better/more elegant [in all or certain situations]. o) Close the sell with some ultra-simple examples. (e.g. one or more simple war's that can be dropped on tomcat to demonstrate its elegance). Everything full ack. But: Honour to the developers but their work is only done when the docs are finished not when there is a green bar (or whatever). Since I know Cocoon (summer 2005) I appreciate its power but still have to dig in the docs (on the website mixed up with 2.1, 2.0, 2.2-daisy), the source, this mailing-list and the net. I could give lots of examples. I know it's a little bit impudent but this just *has to become better* or Cocoon's power will ever be unrealized and people will still be suffer with other frameworks ! Florian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Productivity
(note: just started using cocoon 3 months ago) Reinhard Poetz wrote: Without good documentation it is very difficult to learn this way of thinking and hence my reasoning that we need better docs. Although the basic concepts of cocoon seem appealing, the learning curve was/is very hard for me: - Books were written before flow and many of the described patterns of usage may not be advisable anymore. - Online documentation scarce (only cocoon site+wiki, no third-party) - Even for elementary stuff I have to bother the list (btw thanks everybody!). Furtunatly Cocoon 2.2 isn't far anymore (the release of the first release candidate should happen next week) and some of us are working on a relaunch of the Cocoon website which will come together with a major overhaul of our documentation. IMHO some efforts towards new tooling would be helpful. There is an old eclipse plugin for sitemap editing somewhere out there. Then we will see if our diagnosis concerning the technical problems and my assessment of the importance of documentation was correct. I strongly support your assesment :) Regards, ypomonh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Productivity
On 22.05.2007 13:55, Reinhard Poetz wrote: Compared with JSF and Struts Cocoon is very different. This means that you have to learn to think in Cocoon (btw, the same is true for frameworks like Tapestry or Wicket). Without good documentation it is very difficult to learn this way of thinking and hence my reasoning that we need better docs. The annoying in the original post [1] is that the main reason for his frustration seems to be Maven and not necessarily Cocoon itself. Joerg [1] http://marc.info/?l=xml-cocoon-usersm=117977535912773w=4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
