app skeleton based on YourCocoonBasedProjectAnt16? (was: Splitting cocoon.xconf)

[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: app skeleton based on YourCocoonBasedProjectAnt16?

[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?

[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?

["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?

[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 }