You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Lally Singh <la...@gmail.com> on 2007/05/15 11:47:56 UTC
Sitemap patterns dead?
Hey all, here's a thinker for you.
I have two sitemap entries, both based off the example block. One, an
empty pattern, displays the 1 line of text I want. The second gives
me an error 500:
javax.servlet.ServletException: No block for /qgenerator/test
at org.apache.cocoon.servletservice.DispatcherServlet.service(DispatcherServlet.java:89)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:459)
...
I have the simplest sitemap.xmap I can imagine:
<map:sitemap xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://apache.org/cocoon/sitemap/1.0
http://cocoon.apache.org/schema/sitemap/cocoon-sitemap-1.0.xsd"
xmlns:map="http://apache.org/cocoon/sitemap/1.0">
<map:flow language="javascript">
<map:script src="survey.js" />
</map:flow>
<map:pipelines>
<map:pipeline id="demo">
<map:match pattern="">
<map:call function="beginSurvey" />
</map:match>
<map:match pattern="screens/demo">
<map:generate src="demo.xml" type="jx"/>
<map:serialize type="xml"/>
</map:match>
<map:match pattern="test">
<map:call function="beginSurvey" />
</map:match>
</map:pipeline>
</map:pipelines>
</map:sitemap>
Just tested it on SVN:Head. Any ideas?
--
H. Lally Singh
Ph.D. Candidate, Computer Science
Virginia Tech
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap patterns dead?
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Lally Singh pisze:
> Hey all, here's a thinker for you.
>
> I have two sitemap entries, both based off the example block. One, an
> empty pattern, displays the 1 line of text I want. The second gives
> me an error 500:
> javax.servlet.ServletException: No block for /qgenerator/test
> at
> org.apache.cocoon.servletservice.DispatcherServlet.service(DispatcherServlet.java:89)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
> at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:459)
> ...
>
> I have the simplest sitemap.xmap I can imagine:
> <map:sitemap xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://apache.org/cocoon/sitemap/1.0
> http://cocoon.apache.org/schema/sitemap/cocoon-sitemap-1.0.xsd"
> xmlns:map="http://apache.org/cocoon/sitemap/1.0">
> <map:flow language="javascript">
> <map:script src="survey.js" />
> </map:flow>
> <map:pipelines>
> <map:pipeline id="demo">
> <map:match pattern="">
> <map:call function="beginSurvey" />
> </map:match>
> <map:match pattern="screens/demo">
> <map:generate src="demo.xml" type="jx"/>
> <map:serialize type="xml"/>
> </map:match>
> <map:match pattern="test">
> <map:call function="beginSurvey" />
> </map:match>
> </map:pipeline>
> </map:pipelines>
> </map:sitemap>
>
> Just tested it on SVN:Head. Any ideas?
What you describe is really odd, I'll look into it tomorrow. It may be that you just have found bug in servlet-service-fw. Thanks for giving
really simple example, it really helps debugging the problem.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon Productivity
Posted by Dev at weitling <de...@weitling.net>.
> 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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon Productivity
Posted by Tim Williams <wi...@gmail.com>.
On 5/22/07, Reinhard Poetz <re...@apache.org> 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: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Reinhard Poetz wrote:
> I don't want to say that we should focus on this non-Maven Cocoon 2.2
> archetyp - at least I won't and probably won't do much more than the
> prototyp already does - but providing alternatives to our ours is a good
> thing IMO.
As long as we state in docs that this way of building applications is
not that actively tracked and maintained as maven there is no harm in
showing users the alternative.
--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Reinhard Poetz <re...@apache.org>.
Leszek Gawron wrote:
> Hello,
>
> Reinhard Poetz wrote:
>>
>> I've started with a prototyp of a non-Maven Cocoon 2.2 archetype. It
>> should be useful to people that want to avoid Maven 2 as build system
>> for their Cocoon based projects. The mail below, that I sent to the
>> users list, explains in more detail how this prototyp is supposed to
>> work.
>>
>> Feedback would be much appreciated.
>
> My first question is: why would people want to avoid maven as a build
> system if they get from us everything on the plate?: standard structure,
> archetypes. You do not have to know maven at all and be able to run
> cocoon app in under 10 minutes.
I agree with you but there are people with different opinions that I can
understand to some point.
> Once cocoon libs (especially plugins and archetypes) are uploaded on
> public maven repo where is no easier way to start.
right, but see above
> Custom build will always get outdated some time which will bring confusion.
Agreed, maintaining a non-Maven based build is more difficult but the difference
is that this build system was invented and developed by the developer himself
and updating libraries can be done in the same way as usual. He doesn't have to
learn something new. He also knows how to do all the other things like
releasing, adding e.g. source generation tools, etc.
Additionally there are tools like Ivy or the Maven Ant tasks which can make your
life a lot easier.
I don't want to say that we should focus on this non-Maven Cocoon 2.2 archetyp -
at least I won't and probably won't do much more than the prototyp already does
- but providing alternatives to our ours is a good thing IMO.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Hello,
Reinhard Poetz wrote:
>
> I've started with a prototyp of a non-Maven Cocoon 2.2 archetype. It
> should be useful to people that want to avoid Maven 2 as build system
> for their Cocoon based projects. The mail below, that I sent to the
> users list, explains in more detail how this prototyp is supposed to work.
>
> Feedback would be much appreciated.
My first question is: why would people want to avoid maven as a build
system if they get from us everything on the plate?: standard structure,
archetypes. You do not have to know maven at all and be able to run
cocoon app in under 10 minutes.
Once cocoon libs (especially plugins and archetypes) are uploaded on
public maven repo where is no easier way to start.
Custom build will always get outdated some time which will bring confusion.
--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Reinhard Poetz <re...@apache.org>.
I've started with a prototyp of a non-Maven Cocoon 2.2 archetype. It should be
useful to people that want to avoid Maven 2 as build system for their Cocoon
based projects. The mail below, that I sent to the users list, explains in more
detail how this prototyp is supposed to work.
Feedback would be much appreciated.
Reinhard Poetz wrote:
> Carsten Ziegeler wrote:
>> If someone can document the steps (which we should do anyway) I can
>> try and come up with the ant script.
>
> I've started with a prototyp of a non-Maven Cocoon 2.2 archetype. You
> can download it from
> http://people.apache.org/~reinhard/cocoon-22-bootstrap.zip.
>
> It contains a build.xml that has two targets:
>
> - webapp
> Build a web application
> - run
> Starts the webapp using Jetty
>
> Some words to the directory structure:
>
> [root]
> +-src
> | +-webapp The Cocoon web application
> | +-block1 A Cocoon demo block
> +-lib All required libraries and Cocoon blocks
> +-jetty Minimum files to run a Jetty 6.1.3 instance
> +-build.xml The Ant build script
>
> The Ant build is only a starting point but it shows how things are
> supposed to work together. It works well for me but it misses two
> important things in order to be useful for others:
>
> 1) make it simple to add just another _own_ block
> (adding a third-party block only means copying the libs into ./lib)
>
> 2) create a properties file that configures all servlet services to use the
> src/block1/src/main/resources/COB-INF files as block contexts
>
> Having this feature allows working on the sources with support for
> hot reload.
>
> I think the build script shouldn't do much more because if people prefer
> to use Ant, they have their own way of building/deploying their Java
> applications anyway. Using this build script as template for that
> purpose, should give them a enough ideas to integrate it into their own
> build and deployment architectures.
>
> WDYT? Feedback, not only from Carsten, is much appreciated!
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Reinhard Poetz <re...@apache.org>.
I've started with a prototyp of a non-Maven Cocoon 2.2 archetype. It should be
useful to people that want to avoid Maven 2 as build system for their Cocoon
based projects. The mail below that I sent to the users lists explains in more
detail how this prototyp is supposed to work.
Feedback would be much appreciated.
Reinhard Poetz wrote:
> Carsten Ziegeler wrote:
>> If someone can document the steps (which we should do anyway) I can
>> try and come up with the ant script.
>
> I've started with a prototyp of a non-Maven Cocoon 2.2 archetype. You
> can download it from
> http://people.apache.org/~reinhard/cocoon-22-bootstrap.zip.
>
> It contains a build.xml that has two targets:
>
> - webapp
> Build a web application
> - run
> Starts the webapp using Jetty
>
> Some words to the directory structure:
>
> [root]
> +-src
> | +-webapp The Cocoon web application
> | +-block1 A Cocoon demo block
> +-lib All required libraries and Cocoon blocks
> +-jetty Minimum files to run a Jetty 6.1.3 instance
> +-build.xml The Ant build script
>
> The Ant build is only a starting point but it shows how things are
> supposed to work together. It works well for me but it misses two
> important things in order to be useful for others:
>
> 1) make it simple to add just another _own_ block
> (adding a third-party block only means copying the libs into ./lib)
>
> 2) create a properties file that configures all servlet services to use the
> src/block1/src/main/resources/COB-INF files as block contexts
>
> Having this feature allows working on the sources with support for
> hot reload.
>
> I think the build script shouldn't do much more because if people prefer
> to use Ant, they have their own way of building/deploying their Java
> applications anyway. Using this build script as template for that
> purpose, should give them a enough ideas to integrate it into their own
> build and deployment architectures.
--
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> If someone can document the steps (which we should do anyway) I can try
> and come up with the ant script.
I've started with a prototyp of a non-Maven Cocoon 2.2 archetype. You can
download it from http://people.apache.org/~reinhard/cocoon-22-bootstrap.zip.
It contains a build.xml that has two targets:
- webapp
Build a web application
- run
Starts the webapp using Jetty
Some words to the directory structure:
[root]
+-src
| +-webapp The Cocoon web application
| +-block1 A Cocoon demo block
+-lib All required libraries and Cocoon blocks
+-jetty Minimum files to run a Jetty 6.1.3 instance
+-build.xml The Ant build script
The Ant build is only a starting point but it shows how things are supposed to
work together. It works well for me but it misses two important things in order
to be useful for others:
1) make it simple to add just another _own_ block
(adding a third-party block only means copying the libs into ./lib)
2) create a properties file that configures all servlet services to use the
src/block1/src/main/resources/COB-INF files as block contexts
Having this feature allows working on the sources with support for
hot reload.
I think the build script shouldn't do much more because if people prefer to use
Ant, they have their own way of building/deploying their Java applications
anyway. Using this build script as template for that purpose, should give them a
enough ideas to integrate it into their own build and deployment architectures.
WDYT? Feedback, not only from Carsten, is much appreciated!
--
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz schrieb:
>> What about creating a zip containing the result of the cocoon
>> archetype run? People could use this as a starting point for own
>> projects without maven.
>
> I guess that you mean the result in ./target/webapp which is created by
> "mvn install", don't you?
>
Ah, yes, you're right. Yepp.
>> Adding blocks should then just be adding the jar which is available
>> for download.
>
> yep
>
>> The final step would be a document how to build your own block without
>> maven, perhaps someone could come up with an ant script doing this stuff.
>
> good idea, shouldn't be that difficult.
>
If someone can document the steps (which we should do anyway) I can try
and come up with the ant script.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Reinhard Poetz wrote:
>> How can we help our upcoming 2.2 users? IMO there are two approaches
>> which should be followed in parallel:
>>
>> 1) make the usage of Maven 2 as simple as possible
>> - the tutorials take this into account
>> - we provide different archetypes
>>
>> 2) offer an alternative to Maven 2
>>
>> Option one is clear and is nearly finsihed. My question is regarding
>> to option 2: What do you expect, when you download Cocoon 2.2 in order
>> to get your new Cocoon 2.2 project started?
>>
>> Keep in mind that Cocoon 2.2 is split into a core and several blocks
>> (template, forms, etc.). All of them are separate release artifacts
>> and in contrast to Cocoon 2.1 they can and will be shipped as binaries
>> again. (Note that I'm not talking about samples, that's something
>> different.)
>>
> Just some unstructured thoughts:
>
> What about creating a zip containing the result of the cocoon archetype
> run? People could use this as a starting point for own projects without
> maven.
I guess that you mean the result in ./target/webapp which is created by "mvn
install", don't you?
> Adding blocks should then just be adding the jar which is
> available for download.
yep
> The final step would be a document how to build your own block without
> maven, perhaps someone could come up with an ant script doing this stuff.
good idea, shouldn't be that difficult.
--
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
> Joerg Heinicke wrote:
>> 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.
>
> yes, Maven 2 is IMHO an even more complex beast than Cocoon (and I mean
> 2.1 here!). Since I've been involved in two big projects (Cocoon 2.2 and
> one commercial project) that migrated to Maven 2, I've learnt to
> appreciate the power of Maven 2 but I remember how difficult it was to
> learn how Maven 2 works and how to solve real-world problems.
>
> How can we help our upcoming 2.2 users? IMO there are two approaches
> which should be followed in parallel:
>
> 1) make the usage of Maven 2 as simple as possible
> - the tutorials take this into account
> - we provide different archetypes
>
> 2) offer an alternative to Maven 2
>
> Option one is clear and is nearly finsihed. My question is regarding to
> option 2: What do you expect, when you download Cocoon 2.2 in order to
> get your new Cocoon 2.2 project started?
>
> Keep in mind that Cocoon 2.2 is split into a core and several blocks
> (template, forms, etc.). All of them are separate release artifacts and
> in contrast to Cocoon 2.1 they can and will be shipped as binaries
> again. (Note that I'm not talking about samples, that's something
> different.)
>
Just some unstructured thoughts:
What about creating a zip containing the result of the cocoon archetype
run? People could use this as a starting point for own projects without
maven. Adding blocks should then just be adding the jar which is
available for download.
The final step would be a document how to build your own block without
maven, perhaps someone could come up with an ant script doing this stuff.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Carsten Ziegeler <cz...@apache.org>.
Ralph Goers wrote:
> Carsten Ziegeler wrote:
>> Reinhard Haller schrieb:
>>
>>> Is there a design decision to use maven as a base or not? If so then
>>> go ahead and use it. If you want to get a new design decision, wait
>>> until the next version is in the design phase.
>>>
>> The decision was to use maven for developing cocoon itself and to not
>> require maven for cocoon based projects.
>>
> Maybe, but I'd push Cocoon 2.2 out the door before worrying about this.
> It's been in the oven long enough.
>
Oh, yes - definitly; it is possible to use 2.2 without maven; you just
have to figure out how...when it's released we can update the docs and
give help.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Ralph Goers <Ra...@dslextreme.com>.
Carsten Ziegeler wrote:
> Reinhard Haller schrieb:
>
>> Is there a design decision to use maven as a base or not? If so then
>> go ahead and use it. If you want to get a new design decision, wait
>> until the next version is in the design phase.
>>
> The decision was to use maven for developing cocoon itself and to not
> require maven for cocoon based projects.
>
Maybe, but I'd push Cocoon 2.2 out the door before worrying about this.
It's been in the oven long enough.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Haller schrieb:
> Is there a design decision to use maven as a base or not? If so then
> go ahead and use it. If you want to get a new design decision, wait
> until the next version is in the design phase.
>
The decision was to use maven for developing cocoon itself and to not
require maven for cocoon based projects.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Reinhard Poetz <re...@apache.org>.
Martin Heiden wrote:
> What do you think of a web application that does it for the users? It
> could be a simple list of blocks and core components with description and
> a nice cocoon app that reads the actual poms and zips all important jars
> before deliviring them to the user.
The problem with this idea is that is is difficult to integrate this with your
build system. If you need Ant with dependency management, I'd have a look into Ivy.
--
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Martin Heiden <ma...@netcologne.de>.
On Thu, May 24, 2007 8:07 am, Reinhard Haller wrote:
>
> sounds like we need a kind of installer to hide the complexity of maven
> from the user. This way we reduce complexity without adding options with
> the need of further support.
>
I switched to use maven for all my projects after evaluating cocoon 2.2.
It was a steep learning curve, but it was definitly worth doing it.
Please correct me if I'm wrong, but with cocoon 2.2 the only thing one
needs, to write custom applications, are jars from core and used blocks.
What maven does, is managing the dependencies for the user. If one opts
for not using maven, he/she would have to manage this complex task on
his/her own. This is the point where help is needed.
What do you think of a web application that does it for the users? It
could be a simple list of blocks and core components with description and
a nice cocoon app that reads the actual poms and zips all important jars
before deliviring them to the user.
This could even be included as a sample app.
Martin.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Reinhard Haller <re...@interactive-net.de>.
Hi,
Carsten Ziegeler schrieb:
> Grzegorz Kossakowski wrote:
>> To sum up, if you really want to put effort into it could it be
>> assumed as only temporary solution that aims to make it easier to
>> migrate?
>>
> Hmm, no I don't think so :)
> Personally, I really love maven 2 and it works very well for a lot of
> our projects. It makes sense to use it for developing cocoon itself, but
> we should not force everyone who wants to do a cocoon project to use
> maven 2. This ain't gonna work.
sounds like we need a kind of installer to hide the complexity of maven
from the user. This way we reduce complexity without adding options with
the need of further support.
>
> You're right that we should not maintain all possible different ways,
> but we spend a lot of energy into 2.2 to make it independent from m2.
Is there a design decision to use maven as a base or not? If so then
go ahead and use it. If you want to get a new design decision, wait
until the next version is in the design phase.
Greetings
Reinhard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Carsten Ziegeler pisze:
> Grzegorz Kossakowski wrote:
> Hmm, no I don't think so :)
> Personally, I really love maven 2 and it works very well for a lot of
> our projects. It makes sense to use it for developing cocoon itself, but
> we should not force everyone who wants to do a cocoon project to use
> maven 2. This ain't gonna work.
>
> You're right that we should not maintain all possible different ways,
> but we spend a lot of energy into 2.2 to make it independent from m2.
> For example that's the reason why we extract blocks at runtime through
> cocoon itself and not at build time. So if someone wants to use
> something different than m2, all he has to do is to create a block. A
> block is just a jar with a special format. We have to document this
> format anyway and that's all we have to do for other build systems.
> Nothing more but also nothing less.
> But as a proof that the docs are correct and our ideas work, we should
> just come up with one additional solution like an ant script. My idea is
> to put this script into the documentation and not into our svn. The
> script would act as a starting point.
Carsten, thanks for your clarification. Now I'm fine with the proposal and our current view on this issue.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Carsten Ziegeler <cz...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz pisze:
>>
>> 2) offer an alternative to Maven 2
>>
>> Option one is clear and is nearly finsihed. My question is regarding
>> to option 2: What do you expect, when you download Cocoon 2.2 in order
>> to get your new Cocoon 2.2 project started?
>>
>> Keep in mind that Cocoon 2.2 is split into a core and several blocks
>> (template, forms, etc.). All of them are separate release artifacts
>> and in contrast to Cocoon 2.1 they can and will be shipped as binaries
>> again. (Note that I'm not talking about samples, that's something
>> different.)
>
> To be honest I would not like to see option 2 implemented. I believe
> that diversity is important but we must also be aware of the costs that
> come along with more options.
> First, I really think that we should focus on the other things like
> documenting, testing, polishing and releasing stuff we already have.
> Of course, if someone wants to put his effort into developing Ant
> scripts I won't stop him, it's always better than not doing anything.
>
> The second argument is stronger in my opinion. Even though introducing
> more options is usually not so difficult, we must remember that it's our
> (as community) responsibility to maintain these more options for a long
> time.
> More options means that possible refactorings and serious changes are
> much more difficult to carry out and providing migration guides is also
> much more troublesome because you hardly can assume something about
> readers setup.
>
> I would not really like to see situation like I can't help someone on
> the list only because I don't want to dig through his very own
> Ant-driven setup.
>
> Now I really like situation with Cocoon 2.2 where I can say this: mate,
> use archetypes for your blocks and for assembling your webapp and if you
> encounter some problems/bugs just extract bits related to the problem
> and send us an ad-hoc created block showing the problem. Then, I can
> just write mvn cocoon:rcl and start helping this person being sure that
> we both talk about the same thing and problem.
> Sounds encouraging, doesn't it? :-)
>
> To sum up, if you really want to put effort into it could it be assumed
> as only temporary solution that aims to make it easier to migrate?
>
Hmm, no I don't think so :)
Personally, I really love maven 2 and it works very well for a lot of
our projects. It makes sense to use it for developing cocoon itself, but
we should not force everyone who wants to do a cocoon project to use
maven 2. This ain't gonna work.
You're right that we should not maintain all possible different ways,
but we spend a lot of energy into 2.2 to make it independent from m2.
For example that's the reason why we extract blocks at runtime through
cocoon itself and not at build time. So if someone wants to use
something different than m2, all he has to do is to create a block. A
block is just a jar with a special format. We have to document this
format anyway and that's all we have to do for other build systems.
Nothing more but also nothing less.
But as a proof that the docs are correct and our ideas work, we should
just come up with one additional solution like an ant script. My idea is
to put this script into the documentation and not into our svn. The
script would act as a starting point.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz pisze:
>
> 2) offer an alternative to Maven 2
>
> Option one is clear and is nearly finsihed. My question is regarding to
> option 2: What do you expect, when you download Cocoon 2.2 in order to
> get your new Cocoon 2.2 project started?
>
> Keep in mind that Cocoon 2.2 is split into a core and several blocks
> (template, forms, etc.). All of them are separate release artifacts and
> in contrast to Cocoon 2.1 they can and will be shipped as binaries
> again. (Note that I'm not talking about samples, that's something
> different.)
To be honest I would not like to see option 2 implemented. I believe that diversity is important but we must also be aware of the costs that
come along with more options.
First, I really think that we should focus on the other things like documenting, testing, polishing and releasing stuff we already have.
Of course, if someone wants to put his effort into developing Ant scripts I won't stop him, it's always better than not doing anything.
The second argument is stronger in my opinion. Even though introducing more options is usually not so difficult, we must remember that it's
our (as community) responsibility to maintain these more options for a long time.
More options means that possible refactorings and serious changes are much more difficult to carry out and providing migration guides is
also much more troublesome because you hardly can assume something about readers setup.
I would not really like to see situation like I can't help someone on the list only because I don't want to dig through his very own
Ant-driven setup.
Now I really like situation with Cocoon 2.2 where I can say this: mate, use archetypes for your blocks and for assembling your webapp and if
you encounter some problems/bugs just extract bits related to the problem and send us an ad-hoc created block showing the problem. Then, I
can just write mvn cocoon:rcl and start helping this person being sure that we both talk about the same thing and problem.
Sounds encouraging, doesn't it? :-)
To sum up, if you really want to put effort into it could it be assumed as only temporary solution that aims to make it easier to migrate?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Reinhard Poetz <re...@apache.org>.
Joerg Heinicke wrote:
> 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.
yes, Maven 2 is IMHO an even more complex beast than Cocoon (and I mean 2.1
here!). Since I've been involved in two big projects (Cocoon 2.2 and one
commercial project) that migrated to Maven 2, I've learnt to appreciate the
power of Maven 2 but I remember how difficult it was to learn how Maven 2 works
and how to solve real-world problems.
How can we help our upcoming 2.2 users? IMO there are two approaches which
should be followed in parallel:
1) make the usage of Maven 2 as simple as possible
- the tutorials take this into account
- we provide different archetypes
2) offer an alternative to Maven 2
Option one is clear and is nearly finsihed. My question is regarding to option
2: What do you expect, when you download Cocoon 2.2 in order to get your new
Cocoon 2.2 project started?
Keep in mind that Cocoon 2.2 is split into a core and several blocks (template,
forms, etc.). All of them are separate release artifacts and in contrast to
Cocoon 2.1 they can and will be shipped as binaries again. (Note that I'm not
talking about samples, that's something different.)
--
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon Productivity
Posted by Joerg Heinicke <jo...@gmx.de>.
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-users&m=117977535912773&w=4
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon Productivity
Posted by ypomonh <yp...@freemail.gr>.
(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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Cocoon and multimedia
Posted by "J.D. Williams" <jd...@austin.rr.com>.
I would like to include some multimedia in some HTML created by Cocoon.
Specifically, I would like for visitors to be able to play an mp3.\
I included the XML transformed to produce the following in the result
HTML.
<object classid="clsid:02bf25d5-8c17-4b23-bc80-d3488abddc6b"
codebase="http://www.apple.com/qtactivex/qtplugin.cab" height="26"
type="audio/mpeg" width="90">
<param name="src" value="foo.mp3" />
<param name="autoplay" value="false" />
<param name="controller" value="true" />
</object>
<object data="foo.mp3" height="26" type="audio/mpeg" width="90">
<param name="autoplay" value="false" />
<param name="controller" value="true" />
</object>
The player appears, and when you click the play button, the browser appears to respond, but never plays.
I included a matcher in the root sitemap, with the same result.
<!-- mp3 -->
<map:match pattern="**.mp3">
<map:read mime-type="audio/mpeg" src="mp3/{1}.mp3"/>
</map:match>
I noticed the site, www.nouvo.ch, among the live sites
(cocoon.apache.org/link/livesites-2.1.html) but of course I cannot see
their XML or sitemap to see how they do it.
Has anyone successfully done something like this, someone who would like to share a clue?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon Productivity
Posted by Reinhard Poetz <re...@apache.org>.
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon Productivity
Posted by Derek Hohls <DH...@csir.co.za>.
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 <re...@apache.org> 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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
--
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
CallCentre@csir.co.za.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon Productivity [was Re: Sitemap patterns dead?]
Posted by Carsten Ziegeler <cz...@apache.org>.
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon Productivity
Posted by Niels van Kampenhout <n....@hippo.nl>.
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon Productivity
Posted by Derek Hohls <DH...@csir.co.za>.
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
CallCentre@csir.co.za.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Cocoon Productivity
Posted by Christian Schlichtherle <ch...@schlichtherle.de>.
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
Re: Cocoon Productivity
Posted by Reinhard Haller <re...@interactive-net.de>.
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
Re: Cocoon Productivity
Posted by Derek Hohls <DH...@csir.co.za>.
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 <re...@interactive-net.de> 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
CallCentre@csir.co.za.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon Productivity
Posted by Niels van Kampenhout <n....@hippo.nl>.
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon Productivity
Posted by Reinhard Haller <re...@interactive-net.de>.
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
Re: Cocoon Productivity
Posted by Reinhard Poetz <re...@apache.org>.
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Cocoon Productivity
Posted by Robin Rigby <ro...@gondolier.org.uk>.
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:reinhard.haller@interactive-net.de]
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon Productivity
Posted by Reinhard Haller <re...@interactive-net.de>.
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
Re: Cocoon Productivity
Posted by Joerg Heinicke <jo...@gmx.de>.
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=121344884400001&r=1&w=4
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon Productivity
Posted by Niels van Kampenhout <n....@hippo.nl>.
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon Productivity
Posted by Derek Hohls <DH...@csir.co.za>.
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 - waaaay 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 <jr...@googlemail.com> 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
> 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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
--
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
CallCentre@csir.co.za.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon Productivity
Posted by Jonathan Hipkiss <jr...@googlemail.com>.
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon Productivity
Posted by Fergus McMenemie <fe...@twig.demon.co.uk>.
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:fergus@twig.demon.co.uk.
Techmore Ltd Phone:(UK) 07721 376021
Unix/Mac/Intranets Analyst Programmer
===============================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon Productivity
Posted by Reinhard Poetz <re...@apache.org>.
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon Productivity
Posted by Niels van Kampenhout <n....@hippo.nl>.
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon Productivity
Posted by Reinhard Poetz <re...@apache.org>.
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Cocoon Productivity [was Re: Sitemap patterns dead?]
Posted by Derek Hohls <DH...@csir.co.za>.
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??
Derek
>>> Grzegorz Kossakowski <gk...@apache.org> 2007/05/21 09:48:10
PM >>>
Lally Singh pisze:
> On 5/19/07, Grzegorz Kossakowski <gk...@apache.org> wrote:
>
> Thanks for all the help you've been giving me, but I've given up.
It was my pleasure all the time to give a help. Being a Cocoon
developer it's always sad moment to hear that kind of news but I
understand
you. Cocoon 2.2 just in between process of stabilization and you were
on the bleeding edge. I guess that it always hurts, independently from
the project.
> Finding documentation, debugging Maven setups, moving dependencies
and
> archetypes, were all too much. An app I could've spat out in
> WebObjects in 2 weeks is stillborn after 5 months. I ported it to
> Struts 2 in a day and got productive in that immediately.
>
> Thanks again for all your help,
No problem. Thanks for your response.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
--
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
CallCentre@csir.co.za.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap patterns dead?
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Lally Singh pisze:
> On 5/19/07, Grzegorz Kossakowski <gk...@apache.org> wrote:
>
> Thanks for all the help you've been giving me, but I've given up.
It was my pleasure all the time to give a help. Being a Cocoon developer it's always sad moment to hear that kind of news but I understand
you. Cocoon 2.2 just in between process of stabilization and you were on the bleeding edge. I guess that it always hurts, independently from
the project.
> Finding documentation, debugging Maven setups, moving dependencies and
> archetypes, were all too much. An app I could've spat out in
> WebObjects in 2 weeks is stillborn after 5 months. I ported it to
> Struts 2 in a day and got productive in that immediately.
>
> Thanks again for all your help,
No problem. Thanks for your response.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap patterns dead?
Posted by Lally Singh <la...@gmail.com>.
On 5/19/07, Grzegorz Kossakowski <gk...@apache.org> wrote:
> Lally Singh pisze:
> > Hey all, here's a thinker for you.
> >
> > I have two sitemap entries, both based off the example block. One, an
> > empty pattern, displays the 1 line of text I want. The second gives
> > me an error 500:
> > <snip/>
> > Just tested it on SVN:Head. Any ideas?
>
> I've tried to reproduce it but without any success. Could you try to change "test" pattern to something else like "foo" and try again?
>
> I'm really clueless what can be happening. Make sure that there is no typo somewhere.
Thanks for all the help you've been giving me, but I've given up.
Finding documentation, debugging Maven setups, moving dependencies and
archetypes, were all too much. An app I could've spat out in
WebObjects in 2 weeks is stillborn after 5 months. I ported it to
Struts 2 in a day and got productive in that immediately.
Thanks again for all your help,
-Lally
--
H. Lally Singh
Ph.D. Candidate, Computer Science
Virginia Tech
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap patterns dead?
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Lally Singh pisze:
> Hey all, here's a thinker for you.
>
> I have two sitemap entries, both based off the example block. One, an
> empty pattern, displays the 1 line of text I want. The second gives
> me an error 500:
> <snip/>
> Just tested it on SVN:Head. Any ideas?
I've tried to reproduce it but without any success. Could you try to change "test" pattern to something else like "foo" and try again?
I'm really clueless what can be happening. Make sure that there is no typo somewhere.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org