cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: [picky-mode] scratchpad 2.0
Date Thu, 17 Jan 2002 11:08:38 GMT

Stefano Mazzocchi wrote:
> Ok guys,
> I'm turned my picky-mode on and I'm going to be a pain in your ass for a
> while :)

Hmm, I have to find the "turn-off" button somehow.

> I'm sure all of you will be delighted to hear this :)

Yupp, absolutely. Life would be so boring without it! Really!

> Anyway, wondering around our nice and great CVS module (looks *much*
> better now, big thanks to Giacomo and Carsten for their wonderful work!)
> I found the 'scratchpad' area a nice concept, but, resonating with
> Gianugo, it is very likely to become the 'place for forgotten code'.
> well, 'forgotten' is not the right word: let's say
> 'individually-developped', which is better, but not that much.

I agree.

> My personal impression looking into scratchpad is that I see lots of
> potentials, but I hardly see a way to try them out. Even less, a way to
> help.


> I know I can write to the author and ask, but what about somebody that
> just grabs the CVS and wants to try new things out?
> Don't rule them out: they are the very spirit of innovation!
> I think that, as it is, "scratchpad" is an invidually-oriented tool. The
> very name says it!
> My proposal turn an individually-oriented R&D location into a
> community-oriented R&D location.
> How? a few suggestions
>  1) let's rename "scratchpad" into "whiteboard"!
>  2) each cocoon developer has the right to ask for a "whiteboard area"
> without requiring a votation, thus the directory structure will be as
> such
>  /src/whiteboard/[area]/

Hm, I'm not sure if this is a good idea. Perhaps it will work, perhaps
we end up by having even more areas with individual code as everyone
starts his one area then.

>  3) the /whiteboard directory contains an XML file that indicates the
> 'owner/s' of the area, along with a brief description of what is
> supposed to do.


>  4) each area contains an 'INSTALL' file that indicates how to install
> the 'area' on top of Cocoon and try it out.


> What do you think?

I don't believe that renaming the directory, writing an INSTALL doc and
separating the scratchpad into different areas will really decrease the
individualism of this area.

The main problem is that the components contained in the scratchpad are
not so easy to install and test. Now the usual procedure is to build
the normal webapp, "deploy it somehow" and then manually add the
for the scratchpad component you want to look at. Now if you change
you propably have to do this all over again. This is very time consuming.

Even worse, for some components you have to change classes from the
main area. You can't do these changes in the main area for obvious reasons,
but how can you maintain it in the scratchpad area? Duplicate code?
I really don't know. So in order to integrate new functionality and to
share it, it seems much easier to start developing in the main area.

Put putting experimental code in the main area will perhaps break the
application for a period of time, it might be that the interfaces change

And another question is, when can things be moved out of the scratchpad?

So, now after I have turned around 360 degrees, we could try your proposal
and see what we end up with. We can then later on still change the rules.

Anyway, I would suggest that we try to minimize the changes until we have
2.0.1 out.


To unsubscribe, e-mail:
For additional commands, email:

View raw message