You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by H....@MI.unimaas.nl on 2004/12/17 10:13:30 UTC
RE: Orbeon vs Cocoon? - Live version available?
Hi Bertrand,
I've looked at their site a few days ago and saw something mentioned about
their code being open source. Haven't looked at it further (yet).
I can't help but mention that the documentation on their website looks much
better and much more coherent than Cocoon. So this is a challenge: to get
our documentation up to speed. What I do like as well, and this might be
easier (as in quicker) to accomplish is the fact that they have live samples
on their website.
I often want to have a quick look at the samples, but since I've set up my
project along the YourCocoonProjectAnt16 instructions, my "distro" is as
lean as possible and lacking all samples. That would mean I need a second
build for the entire distribution.
It would be nice if there was a place where the latest release would be
running, so everyone could check it out. I know this requires cleaning up
the crap that some people think they should enter, but that might be done
through some simple scripts.
It would also give future users the change to have a look at Cocoon before
doing the actual download. And newbies can verify if they have done things
correctly because they can compare their own version with "THE" live
version.
I know server hosting will be a problem, but maybe it's running somewhere
already which could be made available to "the world"?
WDYT?
Bye, Helma
-----Original Message-----
From: Bertrand Delacretaz [mailto:bdelacretaz@apache.org]
Sent: Friday, 17 December, 2004 09:42
To: dev@cocoon.apache.org
Subject: Re: Orbeon vs Cocoon?
Hi Helma,
> ...Has anyone of you looked at Orbeon (www.orbeon.com)?..
There have been discussions here from time to time, search for OXF in
the mailing lists archives.
I've talked to one of their head developers a while ago (hmm....two
years I think, time flies ;-) and my impression was that they were
trying to cover more or less the same needs than Cocoon, but from a
"we're a commercial company" perspective, which IIUC they believed
would be more likely to be accepted by Fortune 500 folks.
As we know, this is not the case, Fortune 500 companies prefer open
source ;-)
Only half-kidding here. I don't know where Orbeon as a company stands
now (and I wish them all the best, honest), but it seems like companies
which have gone the open source route have been very happy in 2004. It
is my case (as a micro-company of one ;-), and I'm certainly not alone
given the kind of success stories that we heard at the GT2004.
Dunno what the OXF license is today, at the time it was closed. The Wayback
Machine helps if their website is down:
http://web.archive.org/web/*/http://www.orbeon.com
-Bertrand
Re: Orbeon vs Cocoon? - Live version available?
Posted by Sylvain Wallez <sy...@apache.org>.
H.vanderLinden@MI.unimaas.nl wrote:
>Hi Bertrand,
>
>I've looked at their site a few days ago and saw something mentioned about
>their code being open source. Haven't looked at it further (yet).
>
>I can't help but mention that the documentation on their website looks much
>better and much more coherent than Cocoon. So this is a challenge: to get
>our documentation up to speed.
>
Agree.
>What I do like as well, and this might be
>easier (as in quicker) to accomplish is the fact that they have live samples
>on their website.
>
>
FYI, in their live site, they have a section that allows visitors to
type in some XSLT. As I'm a curious person, I wanted to see if/how they
protected themselves from malicious code in the XSLT. So I added a
simple call to System.exit() and... crashed their whole website!!!
As I did not expected such a result, I promptly sent them an email with
my apologizes, and they told me they would close that door. Maybe they
finally forgot to?
>I often want to have a quick look at the samples, but since I've set up my
>project along the YourCocoonProjectAnt16 instructions, my "distro" is as
>lean as possible and lacking all samples. That would mean I need a second
>build for the entire distribution.
>
>It would be nice if there was a place where the latest release would be
>running, so everyone could check it out. I know this requires cleaning up
>the crap that some people think they should enter, but that might be done
>through some simple scripts.
>
>It would also give future users the change to have a look at Cocoon before
>doing the actual download. And newbies can verify if they have done things
>correctly because they can compare their own version with "THE" live
>version.
>
>I know server hosting will be a problem, but maybe it's running somewhere
>already which could be made available to "the world"?
>
>
Googling for "welcome to apache cocoon" shows quite a few ones :-)
Seriously, that's true that we should be have a live showcase of the
latest release. This has been discussed a while ago in relation with the
VMWare installation here at Apache, but as Bertrand, I don't have any
further info on this.
For those who can read french, there has been a discussion a few weeks
ago on a list dedicated to the development of the XMLfr.org website [1].
Some experiments have been made to migrate it to Cocoon (it's currently
based on a servlet + the XT xslt processor) and OXF has been studied
also. An interesting discussion happended then between Erik Bruchez, one
of OXF's devs and myself.
Sylvain
[1] http://xmlfr.org/communautes/dev/listes/dev/2004/09/date.html
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Orbeon vs Cocoon? - Live version available?
Posted by Sylvain Wallez <sy...@apache.org>.
Steven Noels wrote:
> On 17 Dec 2004, at 10:13, H.vanderLinden@MI.unimaas.nl wrote:
>
>> It would be nice if there was a place where the latest release would be
>> running, so everyone could check it out. I know this requires
>> cleaning up
>> the crap that some people think they should enter, but that might be
>> done
>> through some simple scripts.
>>
>> It would also give future users the change to have a look at Cocoon
>> before
>> doing the actual download. And newbies can verify if they have done
>> things
>> correctly because they can compare their own version with "THE" live
>> version.
>>
>> I know server hosting will be a problem, but maybe it's running
>> somewhere
>> already which could be made available to "the world"?
>
>
> FWIW, this has been running on cocoon.cocoondev.org for more than two
> years, but I pulled it down due to lack of hits. Similarly, I will be
> dropping the webmail.cocoondev.org demo soonish.
Well, lack of hits doesn't meen lack of interest, but maybe more lack of
advertising (AFAIK, these demos weren't mentioned on the Apache website).
The problem is that we've always been more or less reluctant to link
from the ASF cocoon website to resources hosted "elsewhere". Even the
wiki. That's something we should fix, and a live demo with due
advertising on the website front page would certainly have more visitors.
Now for sure it would be good if it could be hosted by the ASF
infrastructure.
> I had a Cocoon BOF two days ago at JavaPolis. I spoke to quite a few
> folks during the conference as well, which know how we (as a company)
> have been pushing people to use Cocoon over the past three years.
>
> With all due respect, I think there's only a few things we should care
> to work on to give Cocoon more chances for success. I know there were
> many success stories lately, but we should be realistic as well: the
> world is looking into a shift from Struts to JSF, and that's about all
> they care. People still perceive Cocoon as a big, complicated, scary
> beast.
Funnily, I recently had a private chat after my recent blog entry about
Struts [1] with Stephane Bailliez (Ant & Maven committer) which told me
more or less the same.
> Some recurring complaints were:
>
> * documentation (oh well)
> * cohesive direction (as in: _only_ explain folks about things like
> the power trio, and make sure these things work flawlessly, and stop
> being hesitant about deprecation and removal of alternatives)
> * prune, prune, prune: make blocks separately downloadable, and drop
> blocks which aren't supported nor used
> * make sure people don't need a bit of everything to build a decent
> Cocoon app (as in: some Actions, some Input modules, some Javascript,
> some Java, a bit of CForms, a choice over various O/R efforts, some
> Springkles here and there, and so on and so forth)
>
> The last one doesn't mean people shouldn't use all this, it's just
> that all this is now perceived as totally separated, isolated,
> unrelated and incohesively documented stuff.
I can only agree with this.
> The JBoss folks were right when they told me over drinks that Cocoon
> is too much of a research project.
Yes, but that's also because of its we-don't-have-to-respect-a-JSR
nature which allows more creativity.
> Just to give an example: JXTG isn't even used massively (too many
> folks still stuck with XSPs), and already we start chatting about
> JXTG-NG. How should users believe we actually care about them? (=
> literal remark I got yesterday!)
Mmmh... JXTG-NG has a dual purpose:
- refactor the complicated code we have today into something more
maintainable. Similar to what happened in the CForms transformer
- pave the way for *the* dynamic template generator, just as CForms
deprectated XMLForm.
> end-of-rant
Thanks for it :-)
Sylvain
[1] http://www.anyware-tech.com/blogs/sylvain/archives/000153.html
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Orbeon vs Cocoon? - Live version available?
Posted by Steven Noels <st...@outerthought.org>.
On 17 Dec 2004, at 17:07, Stefano Mazzocchi wrote:
<snip/>
Uhm, like, yeah, like... sigh. Oh whatever. I've grown out of this.
> --
> Stefano, wondering what is Steven's special talent that allows him to
> piss me off in just three paragraphs ;-)
Reading your reply? No idea, actually.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Orbeon vs Cocoon? - Live version available?
Posted by Stefano Mazzocchi <st...@apache.org>.
Steven Noels wrote:
> On 17 Dec 2004, at 10:13, H.vanderLinden@MI.unimaas.nl wrote:
>
>> It would be nice if there was a place where the latest release would be
>> running, so everyone could check it out. I know this requires cleaning up
>> the crap that some people think they should enter, but that might be done
>> through some simple scripts.
>>
>> It would also give future users the change to have a look at Cocoon
>> before
>> doing the actual download. And newbies can verify if they have done
>> things
>> correctly because they can compare their own version with "THE" live
>> version.
>>
>> I know server hosting will be a problem, but maybe it's running somewhere
>> already which could be made available to "the world"?
>
>
> FWIW, this has been running on cocoon.cocoondev.org for more than two
> years, but I pulled it down due to lack of hits. Similarly, I will be
> dropping the webmail.cocoondev.org demo soonish.
>
> I had a Cocoon BOF two days ago at JavaPolis. I spoke to quite a few
> folks during the conference as well, which know how we (as a company)
> have been pushing people to use Cocoon over the past three years.
>
> With all due respect, I think there's only a few things we should care
> to work on to give Cocoon more chances for success. I know there were
> many success stories lately, but we should be realistic as well: the
> world is looking into a shift from Struts to JSF, and that's about all
> they care. People still perceive Cocoon as a big, complicated, scary beast.
>
> Some recurring complaints were:
>
> * documentation (oh well)
> * cohesive direction (as in: _only_ explain folks about things like the
> power trio, and make sure these things work flawlessly, and stop being
> hesitant about deprecation and removal of alternatives)
> * prune, prune, prune: make blocks separately downloadable, and drop
> blocks which aren't supported nor used
> * make sure people don't need a bit of everything to build a decent
> Cocoon app (as in: some Actions, some Input modules, some Javascript,
> some Java, a bit of CForms, a choice over various O/R efforts, some
> Springkles here and there, and so on and so forth)
>
> The last one doesn't mean people shouldn't use all this, it's just that
> all this is now perceived as totally separated, isolated, unrelated and
> incohesively documented stuff.
I consider myself a researcher, at times a scientists, at times I
considered myself an artist wanna-be (but then I go to museums and
realize how much there is to get ther), but I never ever thought I was a
project manager. Nor I want to become one.
The day cocoon stops being what it is and starts to go after J2EE and
.NET is the day I kiss you goodbye.
Can we have better docs? sure.
Can we prune and deprecate? you bet.
Can we make separate module available externally? yeah! Should we? most
definately!
> The JBoss folks were right when they told me over drinks that Cocoon
> is too much of a research project.
You say this as all the above lacks were a *result* of the fact that we
are not afraid of innovate.
I'm sorry but this is just pure and ultimate bullshit.
> Just to give an example: JXTG isn't even used massively (too many '
> folks still stuck with XSPs), and already we start chatting about
> JXTG-NG. How should users believe we actually care about them? (=
> literal remark I got yesterday!)
JXTG isn't used massively because we were not sure *which one* of the
various template systems we have should become *the one* since there is
no one that has all the benefits and none of the drawbacks.
What we are doing, Steven, is not screwing people over a silly itch to
change where there is no need to it... we don't change interfaces around
because their names are not polished (like avalon did, several times)...
what we are doing is not JXTG-NG but it's an agreement on the road to a
unified, coherent, documented and community-proposed CTemplates
solution, that would solve all the above issues.
I don't know what you answered to that guy (nor I care, honestly) but
blaming lack of coherence on the fact that cocoon is a research project
is pure nonsense.
You can say that cocoon behaves differently from other projects... and
you would be true (there will be social studies published that show
this!) and that the rate of turn-over and innovation in cocoon is unseen
in the majority of the projects out there (and might result in a sense
of "moving target", this is correct).
But if any of you think that the nature of the above is *harming* rather
than helping, I think you are not only blind but you're biting the hands
that feeds you.
--
Stefano, wondering what is Steven's special talent that allows him to
piss me off in just three paragraphs ;-)
Re: Splitting cocoon.xconf (was Re: Cocoon, a Huge, Scary Beast?)
Posted by Sylvain Wallez <sy...@apache.org>.
Stefano Mazzocchi wrote:
> Sylvain Wallez wrote:
<snip/>
>> After doing some internal support on our projects here last week, I
>> saw once again how difficult it is for people, even experienced ones,
>> to strip down Cocoon to their needs.
>>
>> The problem is that you have to know beforehand what blocks we want
>> to use, compile them and -- here comes the real problem -- generate a
>> cocoon.xconf. If you ever want to add or remove a block later on, you
>> have to strip down the project's cocoon.xconf or merge it with the
>> one that resulted from a new build with more blocks.
>>
>> Sooo complicated and painful when there are so many components you
>> don't even know what their use is. Result: all blocks are included in
>> every project, which effectively makes Cocoon scary (not talking also
>> of the slow startup).
>>
>> So, enough is enough, I started this week-end to scracth something
>> that has been itching me for long: being able to have one xconf
>> snippet per block (including the core block), the main cocoon.xconf
>> being just a set of imports of block-specific xconf snippets.
>>
>> The result is that to activate/deactivate a block, you'll simply have
>> to decomment/comment a line in the main cocoon.xconf. Example:
>> <cocoon>
>> <!-- block-specific components -->
>> <import src="cocoon-pdf-block.xconf"/>
>> <import src="cocoon-portal-block.xconf"/>
>> <import src="cocoon-svg-block.xconf"/>
>>
>> <!-- the core cocoon components (parser, cache, pipelines, etc) -->
>> <import src="cocoon-core.xconf"/>
>> </cocoon>
>>
>> The biggest problem is not related to the actual inclusion, but that
>> some selectors can be fed by multiple blocks (e.g. source protocols
>> provided by core, xmldb and databases blocks or taglibs provided by
>> taglib and faces blocks).
>>
>> So I started refactoring ECM++ so that a selector doesn't manage
>> components itself but adds them to its service manager, and also
>> delegates select() to this manager. This actually "flattens" the
>> component space, thus allowing variations of a given role (what
>> normally goes into selectors) to come from different sources. This is
>> nearly done (still some problems for selectors nested in selectors),
>> and <import> should come soon after.
>>
>> WDYT?
>
>
> AWESOME!!! You are my new hero :-) [well, you are in my hero list
> already but your plaque was getting rusty now I'm off to shine it up
> again ;-)]
Kewl, but please wait for it to actually work before shining my plaque ;-)
Sylvai
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Splitting cocoon.xconf (was Re: Cocoon, a Huge, Scary Beast?)
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> Marc Portier wrote:
>
>>
>>
>> Reinhard Poetz wrote:
>>
>>> Tony Collen wrote:
>>>
>>>
>>> as said in my previos mail: we *have to* reach a common understanding
>>> on what Cocoon *core* is.
>>>
>>
>> it seems logic to me there would be something as 'minimal' and
>> 'typical' as opposed to the current 'full'
>>
>> More categories would probably be just a waste of energy?
>>
>> And yeah, I sense somewhat your fear for some long-winding discussion
>> on the outer-boundaries of those (including room for quite some
>> surmising mails eloquently brought as the new testament)...
>>
>> Now, being really pragmatic, and somewhat inline with Daniel's
>> suggestion of moving out the blocks on the svn-repo (sounded quite
>> ok), there seems to be an easy win based on the build-system we
>> already have
>>
>> - provide sample local.*.properties files for the various categories
>> - opt for one of those to become the default one (I guess deciding
>> will depend on what is actually in those, or else content discussions
>> will be fueled by this upfront decission)
>>
>> all of which should at least ensure:
>>
>> - that new blocks added do _not_ get automatically added to the build?
>
>
>
> After doing some internal support on our projects here last week, I saw
> once again how difficult it is for people, even experienced ones, to
> strip down Cocoon to their needs.
>
> The problem is that you have to know beforehand what blocks we want to
> use, compile them and -- here comes the real problem -- generate a
> cocoon.xconf. If you ever want to add or remove a block later on, you
> have to strip down the project's cocoon.xconf or merge it with the one
> that resulted from a new build with more blocks.
>
> Sooo complicated and painful when there are so many components you don't
> even know what their use is. Result: all blocks are included in every
> project, which effectively makes Cocoon scary (not talking also of the
> slow startup).
>
> So, enough is enough, I started this week-end to scracth something that
> has been itching me for long: being able to have one xconf snippet per
> block (including the core block), the main cocoon.xconf being just a set
> of imports of block-specific xconf snippets.
>
> The result is that to activate/deactivate a block, you'll simply have to
> decomment/comment a line in the main cocoon.xconf. Example:
> <cocoon>
> <!-- block-specific components -->
> <import src="cocoon-pdf-block.xconf"/>
> <import src="cocoon-portal-block.xconf"/>
> <import src="cocoon-svg-block.xconf"/>
>
> <!-- the core cocoon components (parser, cache, pipelines, etc) -->
> <import src="cocoon-core.xconf"/>
> </cocoon>
>
> The biggest problem is not related to the actual inclusion, but that
> some selectors can be fed by multiple blocks (e.g. source protocols
> provided by core, xmldb and databases blocks or taglibs provided by
> taglib and faces blocks).
>
> So I started refactoring ECM++ so that a selector doesn't manage
> components itself but adds them to its service manager, and also
> delegates select() to this manager. This actually "flattens" the
> component space, thus allowing variations of a given role (what normally
> goes into selectors) to come from different sources. This is nearly done
> (still some problems for selectors nested in selectors), and <import>
> should come soon after.
>
> WDYT?
AWESOME!!! You are my new hero :-) [well, you are in my hero list
already but your plaque was getting rusty now I'm off to shine it up
again ;-)]
--
Stefano.
RE: Splitting cocoon.xconf (was Re: Cocoon, a Huge, Scary Beast?)
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
> <SNIP/>
>
> The result is that to activate/deactivate a block, you'll
> simply have to decomment/comment a line in the main
> cocoon.xconf. Example:
> <cocoon>
> <!-- block-specific components -->
> <import src="cocoon-pdf-block.xconf"/>
> <import src="cocoon-portal-block.xconf"/>
> <import src="cocoon-svg-block.xconf"/>
>
> <!-- the core cocoon components (parser, cache, pipelines, etc) -->
> <import src="cocoon-core.xconf"/>
> </cocoon>
>
> The biggest problem is not related to the actual inclusion,
Yes, the inclusion could be done by using entities although the explicit
import statement looks nicer to be.
I like the idea, but I would love to extend it a little bit:
<import src="configs/*.xconf"/>
This would import all files ending with ".xconf" from the configs directory.
So a little support for patterns would be great. An alternative would be:
<import dir="configs"/> which simply imports all files in the configs
directory.
WDYT?
Carsten
Re: app skeleton based on YourCocoonBasedProjectAnt16?
Posted by Sylvain Wallez <sy...@apache.org>.
Bertrand Delacretaz wrote:
> Le 20 déc. 04, à 14:39, Sylvain Wallez a écrit :
>
>> ...Sorry, but I still find this too much complicated. 12 steps,
>> involving ant, command-line, xpatch are way too much complex compared
>> to my proposal which simply consists in moving files around and
>> modifying <import> elements in a centralized file...
>
>
> Ok, let's see your proposal in the flesh.
> We're probably seing the problem from different perspectives here.
Sure, we have the same problem: assembling a Cocoon suited to our
project's need in the most simple way.
>> ...We must come back to a binary distro which can be stripped down
>> easily and started without having to open a console window. That will
>> make Cocoon less scary...
>
>
> Hmm...I still think people need to be comfortable with a command-line
> to be efficient with Cocoon. you'd lose too much by sticking to point
> and click. But having such a distro wouldn't hurt for training or
> initial contact with Cocoon.
Well, here is what I need to type on the command line as a user (not
talking of developing Cocoon):
- build.sh webapp
- cocoon.sh servlet
Provide a binary distro and have cocoon.sh/bat start as servlet by
default and you can develop your entire project without ever using a
commandline prompt.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: app skeleton based on YourCocoonBasedProjectAnt16?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 20 déc. 04, à 14:39, Sylvain Wallez a écrit :
> ...Sorry, but I still find this too much complicated. 12 steps,
> involving ant, command-line, xpatch are way too much complex compared
> to my proposal which simply consists in moving files around and
> modifying <import> elements in a centralized file...
Ok, let's see your proposal in the flesh.
We're probably seing the problem from different perspectives here.
> ...We must come back to a binary distro which can be stripped down
> easily and started without having to open a console window. That will
> make Cocoon less scary...
Hmm...I still think people need to be comfortable with a command-line
to be efficient with Cocoon. you'd lose too much by sticking to point
and click. But having such a distro wouldn't hurt for training or
initial contact with Cocoon.
-Bertrand
Re: app skeleton based on YourCocoonBasedProjectAnt16?
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Sylvain Wallez wrote:
> During trainings, many people are trying to start Cocoon by
> double-clicking on cocoon.bat and tell me "it fails to start" simply
> because this file expects an argument. Windows users are really not used
> to using the commandline.
lenya solved this by making servlet the default target.
Re: app skeleton based on YourCocoonBasedProjectAnt16?
Posted by Sylvain Wallez <sy...@apache.org>.
Bertrand Delacretaz wrote:
> Le 20 déc. 04, à 12:23, Sylvain Wallez a écrit :
>
>> ...The problem is that you have to know beforehand what blocks we
>> want to use, compile them and -- here comes the real problem --
>> generate a cocoon.xconf. If you ever want to add or remove a block
>> later on, you have to strip down the project's cocoon.xconf or merge
>> it with the one that resulted from a new build with more blocks...
>
>
> Taking a slightly different perspective here, I think both things can
> be parallel: for several (rather small) recent projects I've been
> using an application skeleton based on
> http://wiki.apache.org/cocoon/YourCocoonBasedProjectAnt16, and I've
> found it relatively easy to add and remove blocks as needed, by
> editing one file, and also easy to add my own components by putting
> xconf files in the appropriate directory (I've also started to use
> hivemind as the application component manager to be decoupled from the
> Cocoon internals at the app level but that's another story).
>
> I was thinking that we could add an "application seed" to SVN (in a
> new "contrib" directory maybe), a skeleton that allows people to build
> their own apps based on Cocoon, with minimal interference with
> Cocoon's build and blocks system. In this structure, the relevant
> parts of Cocoon are "pulled into" the application as needed, based on
> a simple configuration file which is itself built from Cocoon's configs.
>
> IMHO this is very good for small to medium projects, and it requires
> little knowledge about Cocoon internals to be productive.
Sorry, but I still find this too much complicated. 12 steps, involving
ant, command-line, xpatch are way too much complex compared to my
proposal which simply consists in moving files around and modifying
<import> elements in a centralized file.
During trainings, many people are trying to start Cocoon by
double-clicking on cocoon.bat and tell me "it fails to start" simply
because this file expects an argument. Windows users are really not used
to using the commandline.
We must come back to a binary distro which can be stripped down easily
and started without having to open a console window. That will make
Cocoon less scary.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
app skeleton based on YourCocoonBasedProjectAnt16? (was: Splitting cocoon.xconf)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 20 déc. 04, à 12:23, Sylvain Wallez a écrit :
> ...The problem is that you have to know beforehand what blocks we want
> to use, compile them and -- here comes the real problem -- generate a
> cocoon.xconf. If you ever want to add or remove a block later on, you
> have to strip down the project's cocoon.xconf or merge it with the one
> that resulted from a new build with more blocks...
Taking a slightly different perspective here, I think both things can
be parallel: for several (rather small) recent projects I've been using
an application skeleton based on
http://wiki.apache.org/cocoon/YourCocoonBasedProjectAnt16, and I've
found it relatively easy to add and remove blocks as needed, by editing
one file, and also easy to add my own components by putting xconf files
in the appropriate directory (I've also started to use hivemind as the
application component manager to be decoupled from the Cocoon internals
at the app level but that's another story).
I was thinking that we could add an "application seed" to SVN (in a new
"contrib" directory maybe), a skeleton that allows people to build
their own apps based on Cocoon, with minimal interference with Cocoon's
build and blocks system. In this structure, the relevant parts of
Cocoon are "pulled into" the application as needed, based on a simple
configuration file which is itself built from Cocoon's configs.
IMHO this is very good for small to medium projects, and it requires
little knowledge about Cocoon internals to be productive.
I'd be happy to commit a stripped-down app skeleton if people think
this is useful.
WDYT?
Re: Splitting cocoon.xconf (was Re: Cocoon, a Huge, Scary Beast?)
Posted by Sylvain Wallez <sy...@apache.org>.
Reinhard Poetz wrote:
> Sylvain Wallez wrote:
>
>> The result is that to activate/deactivate a block, you'll simply have
>> to decomment/comment a line in the main cocoon.xconf. Example:
>> <cocoon>
>> <!-- block-specific components -->
>> <import src="cocoon-pdf-block.xconf"/>
>> <import src="cocoon-portal-block.xconf"/>
>> <import src="cocoon-svg-block.xconf"/>
>>
>> <!-- the core cocoon components (parser, cache, pipelines, etc) -->
>> <import src="cocoon-core.xconf"/>
>> </cocoon>
>
>
> two thoughts:
> 1. once on icq we chatted about implicit .xconf files to enable
> blocks. this goes into the same direction, doesn't it? Imean if i
> deploay a block inzo WEB-INF/blocks, it isn't necessary to make an
> explicit import.
Well, WEB-INF/blocks isn't there yet, but yes, there could be some
implicit imports from deployed blocks. I finally chose an explicit
<import> statement for the main cocoon.xconf rather than loading
WEB-INF/*.xconf in order for this feature to work in the less magical
and therefore the more predictible and understandable way.
> 2. how does this relate to carsten's proposal, that we are voting on?
<import> will come for free in <map:components> also. We may want to
keep a uniform syntax between xconf and xmap or have a different one
with <map:components src="blah.xconf"/>, which actually easily
translates to an xconf with a single <import>. I have no particular
preference for one syntax or the other ATM...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Splitting cocoon.xconf (was Re: Cocoon, a Huge, Scary Beast?)
Posted by Reinhard Poetz <re...@apache.org>.
Sylvain Wallez wrote:
> The result is that to activate/deactivate a block, you'll simply have to
> decomment/comment a line in the main cocoon.xconf. Example:
> <cocoon>
> <!-- block-specific components -->
> <import src="cocoon-pdf-block.xconf"/>
> <import src="cocoon-portal-block.xconf"/>
> <import src="cocoon-svg-block.xconf"/>
>
> <!-- the core cocoon components (parser, cache, pipelines, etc) -->
> <import src="cocoon-core.xconf"/>
> </cocoon>
two thoughts:
1. once on icq we chatted about implicit .xconf files to enable blocks. this
goes into the same direction, doesn't it? Imean if i deploay a block inzo
WEB-INF/blocks, it isn't necessary to make an explicit import.
2. how does this relate to carsten's prposal, that we are voting on?
--
Reinhard
RE: Splitting cocoon.xconf (was Re: Cocoon, a Huge, Scary Beast?)
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
>
> So I started refactoring ECM++ so that a selector doesn't
> manage components itself but adds them to its service
> manager, and also delegates select() to this manager. This
> actually "flattens" the component space, thus allowing
> variations of a given role (what normally goes into
> selectors) to come from different sources. This is nearly
> done (still some problems for selectors nested in selectors),
> and <import> should come soon after.
>
Sounds great. ECM++ did already part of it, or more precisly
it did it the other way round: you could lookup a component
using the fortress syntax and this was delegated to the
appropriate selector.
Carsten
Splitting cocoon.xconf (was Re: Cocoon, a Huge, Scary Beast?)
Posted by Sylvain Wallez <sy...@apache.org>.
Marc Portier wrote:
>
>
> Reinhard Poetz wrote:
>
>> Tony Collen wrote:
>>
>>
>> as said in my previos mail: we *have to* reach a common understanding
>> on what Cocoon *core* is.
>>
>
> it seems logic to me there would be something as 'minimal' and
> 'typical' as opposed to the current 'full'
>
> More categories would probably be just a waste of energy?
>
> And yeah, I sense somewhat your fear for some long-winding discussion
> on the outer-boundaries of those (including room for quite some
> surmising mails eloquently brought as the new testament)...
>
> Now, being really pragmatic, and somewhat inline with Daniel's
> suggestion of moving out the blocks on the svn-repo (sounded quite
> ok), there seems to be an easy win based on the build-system we
> already have
>
> - provide sample local.*.properties files for the various categories
> - opt for one of those to become the default one (I guess deciding
> will depend on what is actually in those, or else content discussions
> will be fueled by this upfront decission)
>
> all of which should at least ensure:
>
> - that new blocks added do _not_ get automatically added to the build?
After doing some internal support on our projects here last week, I saw
once again how difficult it is for people, even experienced ones, to
strip down Cocoon to their needs.
The problem is that you have to know beforehand what blocks we want to
use, compile them and -- here comes the real problem -- generate a
cocoon.xconf. If you ever want to add or remove a block later on, you
have to strip down the project's cocoon.xconf or merge it with the one
that resulted from a new build with more blocks.
Sooo complicated and painful when there are so many components you don't
even know what their use is. Result: all blocks are included in every
project, which effectively makes Cocoon scary (not talking also of the
slow startup).
So, enough is enough, I started this week-end to scracth something that
has been itching me for long: being able to have one xconf snippet per
block (including the core block), the main cocoon.xconf being just a set
of imports of block-specific xconf snippets.
The result is that to activate/deactivate a block, you'll simply have to
decomment/comment a line in the main cocoon.xconf. Example:
<cocoon>
<!-- block-specific components -->
<import src="cocoon-pdf-block.xconf"/>
<import src="cocoon-portal-block.xconf"/>
<import src="cocoon-svg-block.xconf"/>
<!-- the core cocoon components (parser, cache, pipelines, etc) -->
<import src="cocoon-core.xconf"/>
</cocoon>
The biggest problem is not related to the actual inclusion, but that
some selectors can be fed by multiple blocks (e.g. source protocols
provided by core, xmldb and databases blocks or taglibs provided by
taglib and faces blocks).
So I started refactoring ECM++ so that a selector doesn't manage
components itself but adds them to its service manager, and also
delegates select() to this manager. This actually "flattens" the
component space, thus allowing variations of a given role (what normally
goes into selectors) to come from different sources. This is nearly done
(still some problems for selectors nested in selectors), and <import>
should come soon after.
WDYT?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Cocoon, a Huge, Scary Beast?
Posted by Reinhard Poetz <re...@apache.org>.
Marc Portier wrote:
>
>
> Reinhard Poetz wrote:
>
>> Tony Collen wrote:
>>
>>
>> as said in my previos mail: we *have to* reach a common understanding
>> on what Cocoon *core* is.
>>
>
> it seems logic to me there would be something as 'minimal' and 'typical'
> as opposed to the current 'full'
>
> More categories would probably be just a waste of energy?
>
> And yeah, I sense somewhat your fear for some long-winding discussion on
> the outer-boundaries of those (including room for quite some surmising
> mails eloquently brought as the new testament)...
or even the old testament ;-)
>
> Now, being really pragmatic, and somewhat inline with Daniel's
> suggestion of moving out the blocks on the svn-repo (sounded quite ok),
> there seems to be an easy win based on the build-system we already have
>
> - provide sample local.*.properties files for the various categories
> - opt for one of those to become the default one (I guess deciding will
> depend on what is actually in those, or else content discussions will be
> fueled by this upfront decission)
>
> all of which should at least ensure:
>
> - that new blocks added do _not_ get automatically added to the build?
yes, a good first step. pls, whoever is able to, just do it IN 2.2! but if we
want to write new docs that's not enough, because we need a (at least pragmatic)
understanding about the message of those new docs, imho.
--
Reinhard
Re: Cocoon, a Huge, Scary Beast?
Posted by Marc Portier <mp...@outerthought.org>.
Reinhard Poetz wrote:
> Tony Collen wrote:
>
>
> as said in my previos mail: we *have to* reach a common understanding on
> what Cocoon *core* is.
>
it seems logic to me there would be something as 'minimal' and 'typical'
as opposed to the current 'full'
More categories would probably be just a waste of energy?
And yeah, I sense somewhat your fear for some long-winding discussion on
the outer-boundaries of those (including room for quite some surmising
mails eloquently brought as the new testament)...
Now, being really pragmatic, and somewhat inline with Daniel's
suggestion of moving out the blocks on the svn-repo (sounded quite ok),
there seems to be an easy win based on the build-system we already have
- provide sample local.*.properties files for the various categories
- opt for one of those to become the default one (I guess deciding will
depend on what is actually in those, or else content discussions will be
fueled by this upfront decission)
all of which should at least ensure:
- that new blocks added do _not_ get automatically added to the build?
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: Cocoon, a Huge, Scary Beast?
Posted by Reinhard Poetz <re...@apache.org>.
Tony Collen wrote:
> Reinhard Poetz wrote:
>
> [snip]
>
>> this has to be cleared - our first step.
>>
>> next step:
>> imo we should strip down Cocoon to a minimum:
>
>
> I was having this thought as well recently....
>
>>
>> - cocoon servlet env
>> - basic pipeline components: fileGen, traxTrans, wildcMatcher,
>> htmlSer, xmlSer, cachingPipe, noncachingPipe
>> - flowscript
>> - jxtemplate
>> - cforms
>
>
> My ideas were simple. Currently, (practically) every block is included
> by default. For ages, people ask how to build a minimal Cocoon. IMO we
> should give it to them by default. Obviously, excluding all the blocks
> by default won't result in a maximal, "demo" build of Cocoon. This
> could be worked around by including a couple sample blocks.properties
> files. Perhaps the default one could be minimal (The stuff you listed
> above, basic components, FS, JXTG, etc..), and we can include a
> sample-full.blocks.properties in the repository.
>
> The problem about having a default "minimal" build is that we won't have
> sample apps. We need some good sample apps (perhaps built from the
> Supersonic-Tour) up front that aren't buried.
>
>> everything else should be factored out to other places. based on this
>> micro Cocoon we can start to write docs & beginner tutorials only for
>> this *from the scratch* - every single existing doc should be
>> evaluated, missing docs newly written.
>
>
> +10000. Supersonic Tour should be the "premiere" tutorial for Cocoon.
> Installation and building docs need to be completely overhauled. It's
> really hard to even just find the SVN repository URL, and the fact that
> we aren't using CVS anymore.
>
> I'm all for having the docs in Document-v.whatever, but I'm also not
> afraid to just start writing and organizing docs with MSWord or GVim.
>
> IMO the docs have a few major areas that need to be addressed:
>
> Intro: What is Cocoon, etc.
> Tutorials/General Documentation: Supersonic Tour. How to build apps and
> publish with Cocoon
> Reference Docs: API Docs, Component Reference, SVN repo, mailing lists,
> etc.
as said in my previos mail: we *have to* reach a common understanding on what
Cocoon *core* is.
--
Reinhard
Re: Cocoon, a Huge, Scary Beast?
Posted by Tony Collen <co...@umn.edu>.
Reinhard Poetz wrote:
[snip]
> this has to be cleared - our first step.
>
> next step:
> imo we should strip down Cocoon to a minimum:
I was having this thought as well recently....
>
> - cocoon servlet env
> - basic pipeline components: fileGen, traxTrans, wildcMatcher,
> htmlSer, xmlSer, cachingPipe, noncachingPipe
> - flowscript
> - jxtemplate
> - cforms
My ideas were simple. Currently, (practically) every block is included
by default. For ages, people ask how to build a minimal Cocoon. IMO we
should give it to them by default. Obviously, excluding all the blocks
by default won't result in a maximal, "demo" build of Cocoon. This
could be worked around by including a couple sample blocks.properties
files. Perhaps the default one could be minimal (The stuff you listed
above, basic components, FS, JXTG, etc..), and we can include a
sample-full.blocks.properties in the repository.
The problem about having a default "minimal" build is that we won't have
sample apps. We need some good sample apps (perhaps built from the
Supersonic-Tour) up front that aren't buried.
> everything else should be factored out to other places. based on this
> micro Cocoon we can start to write docs & beginner tutorials only for
> this *from the scratch* - every single existing doc should be evaluated,
> missing docs newly written.
+10000. Supersonic Tour should be the "premiere" tutorial for Cocoon.
Installation and building docs need to be completely overhauled. It's
really hard to even just find the SVN repository URL, and the fact that
we aren't using CVS anymore.
I'm all for having the docs in Document-v.whatever, but I'm also not
afraid to just start writing and organizing docs with MSWord or GVim.
IMO the docs have a few major areas that need to be addressed:
Intro: What is Cocoon, etc.
Tutorials/General Documentation: Supersonic Tour. How to build apps and
publish with Cocoon
Reference Docs: API Docs, Component Reference, SVN repo, mailing lists, etc.
Tony
Re: Cocoon, a Huge, Scary Beast?
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Reinhard Poetz wrote:
> <snip/>
>
>> before my accident
>
>
> Havn't heard anything about that, what happended? Hope you are well again.
>
>> I held a 3-days training on Cocoon. the feedback was very
>> positive but there was one thing that made me think: after the third
>> day they
>> told me that really like cForms, flow and pipelines but they didn't
>> find this
>> information in the docs in the way I told them. as bertrand said, we
>> have much more docs than we think but they do not *reflect* Cocoon in
>> 2004. you might also say that I have a different view on Cocoon than
>> others.
>
>
> I did a lot of teaching before. Among other things I gave several
> courses in C++. The first couple of times I used course materials
> developed of others, following the traditional idea that the more
> language constructs you learn the better. And that newly added language
> features are more advanced and are taught later in the course or not at
> all (probably reflecting the teachers layzyness in learning new stuff).
> Anyway, even if that was what people expected and that they where happy
> with it, I more and more realized that such a teaching methodology sucks
> and even is destructive.
>
> If you think about it, real competence in using a programming language
> of course involves familarity with basic language constructs, but whats
> more important is a number of idioms for expressing basic things, design
> patterns for more advanced stuff, thought patterns for how to think
> about programming, mental state control so that you don't approach
> debuging, testing and brain storming e.g. with the same mind set.
>
> So IMO a good programing course progress through a number of well
> choosen examples, that shows how you do typical stuff of increasing
> complexity. And during these examples you not only learn the most
> important subset of the language needed to solve the problems at hand,
> but you also learn the more implicit stuff. ideoms, design patterns,
> thought patterns, efficient attitudes etc.
can't agree more!
>
> --- o0o ---
>
> So why am I telling about this? While browsing
> http://www.orbeon.com/ois/ (Sylvain, please stop cracking their page so
> that people can have look ;) ), I suddenly realized that this is whats
> missing for Cocoon, a user guide that shows how you solve the basic
> tasks that more complicted webapps are built uppon.The current
> documentation is focused on describing so many features as possible and
> based on the implicit assumption that it is good to learn as many
> features as possible.
>
> What we, IMO, need is a list of basic use cases with a description of
> how to implement them in Cocoon, using preferably a small set of tools.
>
>> we should make our understanding of Cocoon explicit before we
>> move on with writing new docs or start to clean up blocks:
>>
>> The real question is:
>>
>> +-------------------------------------+
>> | WHAT IS APACHE COCOON CORE? |
>> +-------------------------------------+
>>
>> I try to give an answer in technical terms:
>>
>> - sitemap & side-effect-free pipelines
>> - continuation based controller
>> - xml templating
>> - forms framewrok
>>
>> based on the concepts of soc and ioc.
>
>
> Agree
>
>> i know this may sound controversial for some of you but we shouldn't
>> confuse our
>> users with old ways of doing things like xsp or pipelines that
>> generate content
>> by directly accessing datasources without an explicit controller.
>>
>> this has to be cleared - our first step.
>
>
>
> Yes, and it should IMO be based on a list of basic use cases, that in
> turn could be used as a base for a user guide as described above. From
> such a list we will, IMO, see that the components that you listed above
> needs some polishing, and some small aditions to really be enough for
> the basic use cases. And this is what I believe we should focus on:
> making our basic tools coherent and good enough for making them easy to
> learn force full enough for solving all basic use cases with. I'm
> working on such a use case list, and I think it is a good exercie for
> all of us to do.
as being said, we should make the tour block following the way how you teach
sftware development + docs explaining the base concepts (pipelines, flow, forms,
xml temlating) to the central point of the docs.
>
>> next step:
>> imo we should strip down Cocoon to a minimum:
>>
>> - cocoon servlet env
>> - basic pipeline components: fileGen, traxTrans, wildcMatcher,
>> htmlSer, xmlSer, cachingPipe, noncachingPipe
>> - flowscript
>> - jxtemplate
>> - cforms
>>
>> everything else should be factored out to other places. based on this
>> micro Cocoon we can start to write docs & beginner tutorials only for
>> this *from the scratch* - every single existing doc should be
>> evaluated, missing docs newly written.
>
>
> Exactly!
>
>> third step: reorganizing the rest.
>
>
> Involving a lot of pruning, (don't worry we don't need to throw away all
> of it and create incompabillity, but things that in practice is
> unsupported by the community, and that is quite a few components, should
> be marked as such).
yes
>
>>
>> (following this path also makes blocks dev easier).
--
Reinhard
Re: Cocoon, a Huge, Scary Beast?
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz wrote:
<snip/>
> before my accident
Havn't heard anything about that, what happended? Hope you are well again.
> I held a 3-days training on Cocoon. the feedback was very
> positive but there was one thing that made me think: after the third
> day they
> told me that really like cForms, flow and pipelines but they didn't
> find this
> information in the docs in the way I told them. as bertrand said, we
> have much more docs than we think but they do not *reflect* Cocoon in
> 2004. you might also say that I have a different view on Cocoon than
> others.
I did a lot of teaching before. Among other things I gave several
courses in C++. The first couple of times I used course materials
developed of others, following the traditional idea that the more
language constructs you learn the better. And that newly added language
features are more advanced and are taught later in the course or not at
all (probably reflecting the teachers layzyness in learning new stuff).
Anyway, even if that was what people expected and that they where happy
with it, I more and more realized that such a teaching methodology sucks
and even is destructive.
If you think about it, real competence in using a programming language
of course involves familarity with basic language constructs, but whats
more important is a number of idioms for expressing basic things, design
patterns for more advanced stuff, thought patterns for how to think
about programming, mental state control so that you don't approach
debuging, testing and brain storming e.g. with the same mind set.
So IMO a good programing course progress through a number of well
choosen examples, that shows how you do typical stuff of increasing
complexity. And during these examples you not only learn the most
important subset of the language needed to solve the problems at hand,
but you also learn the more implicit stuff. ideoms, design patterns,
thought patterns, efficient attitudes etc.
--- o0o ---
So why am I telling about this? While browsing
http://www.orbeon.com/ois/ (Sylvain, please stop cracking their page so
that people can have look ;) ), I suddenly realized that this is whats
missing for Cocoon, a user guide that shows how you solve the basic
tasks that more complicted webapps are built uppon.The current
documentation is focused on describing so many features as possible and
based on the implicit assumption that it is good to learn as many
features as possible.
What we, IMO, need is a list of basic use cases with a description of
how to implement them in Cocoon, using preferably a small set of tools.
> we should make our understanding of Cocoon explicit before we
> move on with writing new docs or start to clean up blocks:
>
> The real question is:
>
> +-------------------------------------+
> | WHAT IS APACHE COCOON CORE? |
> +-------------------------------------+
>
> I try to give an answer in technical terms:
>
> - sitemap & side-effect-free pipelines
> - continuation based controller
> - xml templating
> - forms framewrok
>
> based on the concepts of soc and ioc.
Agree
> i know this may sound controversial for some of you but we shouldn't
> confuse our
> users with old ways of doing things like xsp or pipelines that
> generate content
> by directly accessing datasources without an explicit controller.
>
> this has to be cleared - our first step.
Yes, and it should IMO be based on a list of basic use cases, that in
turn could be used as a base for a user guide as described above. From
such a list we will, IMO, see that the components that you listed above
needs some polishing, and some small aditions to really be enough for
the basic use cases. And this is what I believe we should focus on:
making our basic tools coherent and good enough for making them easy to
learn force full enough for solving all basic use cases with. I'm
working on such a use case list, and I think it is a good exercie for
all of us to do.
> next step:
> imo we should strip down Cocoon to a minimum:
>
> - cocoon servlet env
> - basic pipeline components: fileGen, traxTrans, wildcMatcher,
> htmlSer, xmlSer, cachingPipe, noncachingPipe
> - flowscript
> - jxtemplate
> - cforms
>
> everything else should be factored out to other places. based on this
> micro Cocoon we can start to write docs & beginner tutorials only for
> this *from the scratch* - every single existing doc should be
> evaluated, missing docs newly written.
Exactly!
> third step: reorganizing the rest.
Involving a lot of pruning, (don't worry we don't need to throw away all
of it and create incompabillity, but things that in practice is
unsupported by the community, and that is quite a few components, should
be marked as such).
>
> (following this path also makes blocks dev easier).
>
/Daniel
Re: Cocoon, a Huge, Scary Beast?
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Steven Noels wrote:
> <snip/>
>
>> I had a Cocoon BOF two days ago at JavaPolis. I spoke to quite a few
>> folks during the conference as well, which know how we (as a company)
>> have been pushing people to use Cocoon over the past three years.
>
>
>> With all due respect, I think there's only a few things we should care
>> to work on to give Cocoon more chances for success. I know there were
>> many success stories lately, but we should be realistic as well: the
>> world is looking into a shift from Struts to JSF, and that's about all
>> they care.
>
>
> Or at least the _Java_ world ;) I think that one of the reasons that
> Cocoon is complex is that part of the developer community has a Java
> centric view and other parts of the community has a XML centric view.
> And the perception of what is a nice and elegant solution of a certain
> usecase, often differ between the two groups.
>
>> People still perceive Cocoon as a big, complicated, scary beast.
>
>
> And IMHO they are right. I think we spend much more effort in making
> complicated things possible than in making simple things simple. That
> might be a natural result of gathering higly competent developers, but
> neither the less, the threshold for start using Cocoon is rather high.
>
> I found the Orbeon tutorial
> http://www.orbeon.com/ois/doc/pages/Tutorial.pdf, rather interesting.
> Not that I necesarilly agreed with their solutions. But it seemed that
> simple things actually where simple to achieve.
>
> I think that a basic Cocoon tutorial that describe our _prefered_ way of
> doing basic stuff is what we most of all lack in our documentation.
> Maybe we could start from the supersonic tour. There are several
> advantages on having an _official_ basic tutorial:
>
> * We have to decide what the basic use cases for Cocoon are.
> * We have to decide what _the_ prefered way of doing a certain thing is.
> * We would (hopefully) feel motivated to make the things in the tutorial
> as simple to achieve as possible.
>
>> Some recurring complaints were:
>>
>> * documentation (oh well)
>> * cohesive direction (as in: _only_ explain folks about things like
>> the power trio, and make sure these things work flawlessly, and stop
>> being hesitant about deprecation and removal of alternatives)
>> * prune, prune, prune: make blocks separately downloadable, and drop
>> blocks which aren't supported nor used
>
>
> Yes, I think its time to stop waiting for the "real blocks". They are no
> doubt important and I very much apriciate Reihard's effort in making
> them happen. But IMO blocks are not only about technology its much more
> about how we organize our work. And we can start to work on the
> organizational issues right away.
>
> IMO we should create a block directory directly under cocoon in svn,
> with the sub directories:
> * supported/stable,
> * supported/unstable and
> * unsupported,
> (for the detailed structure I'm certain that Reinhard had a much better
> idea, my main message is the supported, unsupported dimension). Next we
> put all of our blocks in the unsupported directory. Then if someone feel
> that a block actually should be supported by us as a community he/she
> has to start a vote about it. And during such a vote I think that we
> should be carfull about if we are +0 or +1 about a block, i.e. if we are
> mearly positive about it or if we actually are going to support it.
>
> Also we should make an evaluation of the "core" components in
> generation, transformer etc, some of might really be core but many of
> them are there because they where written before the block system or
> because they are percieved to small for being part of a block or because
> no one have cared enough.
>
> Moving all the blocks outside the trunk might complicate things in the
> short term, but I think that it is necessary that we decide what we are
> going to support as a community. Then some of the blocks might become
> sub projects in their own right. It will also make us more motivated in
> working on the tools for block handling.
>
>> * make sure people don't need a bit of everything to build a decent
>> Cocoon app (as in: some Actions, some Input modules, some Javascript,
>> some Java, a bit of CForms, a choice over various O/R efforts, some
>> Springkles here and there, and so on and so forth)
>
>
> Exactly, we could create a minimal Cocoon distro with just core and the
> supported stuff (or even a base subset of the suported stuff).
>
>> The last one doesn't mean people shouldn't use all this, it's just
>> that all this is now perceived as totally separated, isolated,
>> unrelated and incohesively documented stuff.
>>
>> The JBoss folks were right when they told me over drinks that Cocoon
>> is too much of a research project.
>
>
> "It is all about community" I would be supprised if I'm the only one who
> joined the community, not only because I needed an XML based web
> framework, but also as I enjoyed Stefano's and others RTs. Being partly
> a research project is not only one of Cocoon's main problems it is also
> one of its main strenghs. In short tht: if it wasn't partly a research
> project, both the community and the project would be something else, or
> not at all. So the question is how we protect our users and our selfs
> from the negative aspects. IMHO we do a rather good work in keeping
> Cocoon stable, but we might be less succesfull in communicating that we
> care much about it.
>
>> Just to give an example: JXTG isn't even used massively (too many
>> folks still stuck with XSPs), and already we start chatting about
>> JXTG-NG. How should users believe we actually care about them? (=
>> literal remark I got yesterday!)
>
>
> Yes, this is an example of how the perception about what we do and what
> we actually do differ. The JXTG work is mainly about making JXTG easier
> to support and build upp on for our community, and to achieve a position
> where we as a community can say that JXTG is the recomended template
> solution in Cocoon. I think that I and other people involved in the work
> have said that it is going to be back compatible in about every mail
> about it, but it created a lot of FUD anyway :/
>
> /Daniel
first sorry for the short answer, ...
before my accident I held a 3-days training on Cocoon. the feedback was very
positive but there was one thing that made me think: after the third day they
told me that really like cForms, flow and pipelines but they didn't find this
information in the docs in the way I told them. as bertrand said, we have much
more docs than we think but they do not *reflect* Cocoon in 2004. you might also
say that I have a different view on Cocoon than others.
we should make our understanding of Cocoon explicit before we
move on with writing new docs or start to clean up blocks:
The real question is:
+-------------------------------------+
| WHAT IS APACHE COCOON CORE? |
+-------------------------------------+
I try to give an answer in technical terms:
- sitemap & side-effect-free pipelines
- continuation based controller
- xml templating
- forms framewrok
based on the concepts of soc and ioc.
i know this may sound controversial for some of you but we shouldn't confuse our
users with old ways of doing things like xsp or pipelines that generate content
by directly accessing datasources without an explicit controller.
this has to be cleared - our first step.
next step:
imo we should strip down Cocoon to a minimum:
- cocoon servlet env
- basic pipeline components: fileGen, traxTrans, wildcMatcher,
htmlSer, xmlSer, cachingPipe, noncachingPipe
- flowscript
- jxtemplate
- cforms
everything else should be factored out to other places. based on this micro
Cocoon we can start to write docs & beginner tutorials only for this *from the
scratch* - every single existing doc should be evaluated, missing docs newly
written.
third step: reorganizing the rest.
(following this path also makes blocks dev easier).
--
Reinhard
Cocoon, a Huge, Scary Beast? (was: Re: Orbeon vs Cocoon? - Live version
available?)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Steven Noels wrote:
<snip/>
> I had a Cocoon BOF two days ago at JavaPolis. I spoke to quite a few
> folks during the conference as well, which know how we (as a company)
> have been pushing people to use Cocoon over the past three years.
> With all due respect, I think there's only a few things we should care
> to work on to give Cocoon more chances for success. I know there were
> many success stories lately, but we should be realistic as well: the
> world is looking into a shift from Struts to JSF, and that's about all
> they care.
Or at least the _Java_ world ;) I think that one of the reasons that
Cocoon is complex is that part of the developer community has a Java
centric view and other parts of the community has a XML centric view.
And the perception of what is a nice and elegant solution of a certain
usecase, often differ between the two groups.
> People still perceive Cocoon as a big, complicated, scary beast.
And IMHO they are right. I think we spend much more effort in making
complicated things possible than in making simple things simple. That
might be a natural result of gathering higly competent developers, but
neither the less, the threshold for start using Cocoon is rather high.
I found the Orbeon tutorial
http://www.orbeon.com/ois/doc/pages/Tutorial.pdf, rather interesting.
Not that I necesarilly agreed with their solutions. But it seemed that
simple things actually where simple to achieve.
I think that a basic Cocoon tutorial that describe our _prefered_ way of
doing basic stuff is what we most of all lack in our documentation.
Maybe we could start from the supersonic tour. There are several
advantages on having an _official_ basic tutorial:
* We have to decide what the basic use cases for Cocoon are.
* We have to decide what _the_ prefered way of doing a certain thing is.
* We would (hopefully) feel motivated to make the things in the tutorial
as simple to achieve as possible.
> Some recurring complaints were:
>
> * documentation (oh well)
> * cohesive direction (as in: _only_ explain folks about things like
> the power trio, and make sure these things work flawlessly, and stop
> being hesitant about deprecation and removal of alternatives)
> * prune, prune, prune: make blocks separately downloadable, and drop
> blocks which aren't supported nor used
Yes, I think its time to stop waiting for the "real blocks". They are no
doubt important and I very much apriciate Reihard's effort in making
them happen. But IMO blocks are not only about technology its much more
about how we organize our work. And we can start to work on the
organizational issues right away.
IMO we should create a block directory directly under cocoon in svn,
with the sub directories:
* supported/stable,
* supported/unstable and
* unsupported,
(for the detailed structure I'm certain that Reinhard had a much better
idea, my main message is the supported, unsupported dimension). Next we
put all of our blocks in the unsupported directory. Then if someone feel
that a block actually should be supported by us as a community he/she
has to start a vote about it. And during such a vote I think that we
should be carfull about if we are +0 or +1 about a block, i.e. if we are
mearly positive about it or if we actually are going to support it.
Also we should make an evaluation of the "core" components in
generation, transformer etc, some of might really be core but many of
them are there because they where written before the block system or
because they are percieved to small for being part of a block or because
no one have cared enough.
Moving all the blocks outside the trunk might complicate things in the
short term, but I think that it is necessary that we decide what we are
going to support as a community. Then some of the blocks might become
sub projects in their own right. It will also make us more motivated in
working on the tools for block handling.
> * make sure people don't need a bit of everything to build a decent
> Cocoon app (as in: some Actions, some Input modules, some Javascript,
> some Java, a bit of CForms, a choice over various O/R efforts, some
> Springkles here and there, and so on and so forth)
Exactly, we could create a minimal Cocoon distro with just core and the
supported stuff (or even a base subset of the suported stuff).
> The last one doesn't mean people shouldn't use all this, it's just
> that all this is now perceived as totally separated, isolated,
> unrelated and incohesively documented stuff.
>
> The JBoss folks were right when they told me over drinks that Cocoon
> is too much of a research project.
"It is all about community" I would be supprised if I'm the only one who
joined the community, not only because I needed an XML based web
framework, but also as I enjoyed Stefano's and others RTs. Being partly
a research project is not only one of Cocoon's main problems it is also
one of its main strenghs. In short: if it wasn't partly a research
project, both the community and the project would be something else, or
not at all. So the question is how we protect our users and our selfs
from the negative aspects. IMHO we do a rather good work in keeping
Cocoon stable, but we might be less succesfull in communicating that we
care much about it.
> Just to give an example: JXTG isn't even used massively (too many
> folks still stuck with XSPs), and already we start chatting about
> JXTG-NG. How should users believe we actually care about them? (=
> literal remark I got yesterday!)
Yes, this is an example of how the perception about what we do and what
we actually do differ. The JXTG work is mainly about making JXTG easier
to support and build upp on for our community, and to achieve a position
where we as a community can say that JXTG is the recomended template
solution in Cocoon. I think that I and other people involved in the work
have said that it is going to be back compatible in about every mail
about it, but it created a lot of FUD anyway :/
/Daniel
Re: Orbeon vs Cocoon? - Live version available?
Posted by Steven Noels <st...@outerthought.org>.
On 17 Dec 2004, at 10:13, H.vanderLinden@MI.unimaas.nl wrote:
> It would be nice if there was a place where the latest release would be
> running, so everyone could check it out. I know this requires cleaning
> up
> the crap that some people think they should enter, but that might be
> done
> through some simple scripts.
>
> It would also give future users the change to have a look at Cocoon
> before
> doing the actual download. And newbies can verify if they have done
> things
> correctly because they can compare their own version with "THE" live
> version.
>
> I know server hosting will be a problem, but maybe it's running
> somewhere
> already which could be made available to "the world"?
FWIW, this has been running on cocoon.cocoondev.org for more than two
years, but I pulled it down due to lack of hits. Similarly, I will be
dropping the webmail.cocoondev.org demo soonish.
I had a Cocoon BOF two days ago at JavaPolis. I spoke to quite a few
folks during the conference as well, which know how we (as a company)
have been pushing people to use Cocoon over the past three years.
With all due respect, I think there's only a few things we should care
to work on to give Cocoon more chances for success. I know there were
many success stories lately, but we should be realistic as well: the
world is looking into a shift from Struts to JSF, and that's about all
they care. People still perceive Cocoon as a big, complicated, scary
beast.
Some recurring complaints were:
* documentation (oh well)
* cohesive direction (as in: _only_ explain folks about things like the
power trio, and make sure these things work flawlessly, and stop being
hesitant about deprecation and removal of alternatives)
* prune, prune, prune: make blocks separately downloadable, and drop
blocks which aren't supported nor used
* make sure people don't need a bit of everything to build a decent
Cocoon app (as in: some Actions, some Input modules, some Javascript,
some Java, a bit of CForms, a choice over various O/R efforts, some
Springkles here and there, and so on and so forth)
The last one doesn't mean people shouldn't use all this, it's just that
all this is now perceived as totally separated, isolated, unrelated and
incohesively documented stuff.
The JBoss folks were right when they told me over drinks that Cocoon is
too much of a research project.
Just to give an example: JXTG isn't even used massively (too many folks
still stuck with XSPs), and already we start chatting about JXTG-NG.
How should users believe we actually care about them? (= literal remark
I got yesterday!)
end-of-rant
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Orbeon vs Cocoon? - Live version available?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 17 déc. 04, à 10:13, H.vanderLinden@MI.unimaas.nl a écrit :
I won't talk about the docs - we know ;-)
> ...What I do like as well, and this might be
> easier (as in quicker) to accomplish is the fact that they have live
> samples
> on their website...
They were discussions a while ago that we might get a virtual machine
on ASF infrastructure, but I haven't heard more.
If we had this it would be fairly easy to setup a live instance of
Cocoon for the samples (including automatic daily cleanup, we can
simply wipe out the thing every day and rebuild it from a cron job).
You're right that having live samples would be very helpful, if only
because we could refer users to live URLs to see things working (and
the corresponding source code),
It could be a good motivation to make the samples more self-describing,
which IMO is the best way of explaining the details.
I've been playing with the openlaszlo samples yesterday night, being
able to copy code into a web page and seeing the results immediately is
an incredibly good way of learning (wouldn't be so easy with Cocoon
apps but you get the idea I think).
> ...I know server hosting will be a problem, but maybe it's running
> somewhere
> already which could be made available to "the world"?..
Problem is, the load (CPU and bandwidth) on such a server is hard to
estimate, so people might be wary of giving space on a machine that's
used for something else.
But if someone has a spare Linux machine somewhere (preferably Debian),
or if this ASF virtual server things comes to life, I'd be happy to
help setup and maintain this, assuming it would be considered a "best
effort" and not a critical thing.
-Bertrand