cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject Re: [Woody] woody.js (show) woody2.js (showForm) et al
Date Sat, 18 Oct 2003 00:57:04 GMT
Sylvain Wallez dijo:
> Antonio Gallardo wrote:
>>Sylvain Wallez dijo:
>>>Yep. And posts like Barzilai's one make me wonder if we should stop
>>> development in the 2.1 repo and move it over to 2.2 into a new
>>> "cforms" (Cocoon forms) block. Note that this doesn't prevent to
>>> backport this block to 2.1 before an official 2.2 release if we
>>> consider that it has reached some level of stability (including docs).
>>-1. I think woody need to get improved even faster than the current
>> trend in the current release too. 2.2 is far away and since it will be
>> at a stable level this would slowdown the development of woody. :-(
>>If someone wants to work with a "non-moving target" then there is 2.1.x
> I guess you misunderstood what I was saying, as you're stating more or
> less my thoughts (if I understand correctly): what I'm suggesting is to
> move the development to the 2.2 repository, but make updates to the 2.1
> repository when we consider to have reached a stable milestone on the
> *cforms block*, and not the entire Cocoon repository.

Hi Sylvain,

I cleary understand what you had in mind. Please note woody is still
marked as an alpha block. So we are free to make any changes without
worrying about back compatibility or similars. This is a fact.

If we right now move to 2.2, I bet the woody development will slowdown for
2 reasons:

1) Woody testers (as me) will not currently move to 2.2 until it will
reach some stable milestone. This is not because I don't want to support
2.2 development, but because I need to end a project.

> This would avoid people working with the 2.1 branch to be too much
> disturbed by this moving target. The 2.1 branch will only have steps
> corresponding to the milestones of the continuous development occuring
> in the 2.2 repo.

OK. Check the pro and cons. Suppose you made another incompatibility
change to cforms. So later you will move it to woody. I don't think this
is a good idea. I think the pain must be fast and as soon as posible.

In my lazy mind, if I see there is a future change that will break all my
work, then I think: Why to continue, if at the end I will need to rework
all this stuff? So this is not too smart to just delays changes from repo
2.2 to 2.1. This is why I prefer to get the changes right now and work
with this.

As I posted before, for people that does not want a "moving target" then
they can use any of the release or any fixed CVS version. But soon or
later they will move to 2.2. For example: if they choose to use some nice
features of Cocoon 2.2. What will be there: Woody forms does not exist at
all, se then?

By my own experience working with the moving target means:

Monitor the cocoon-cvs:
To see if a posted change is important to you. For example: If there are
just a website update (typo fixing), then this will not affect you current
development. You don't need to run all updating procedure for this type of
cvs posts.

When an interesting cvs update happens:

1- Backup your project and update Cocoon CVS.
2- See if the changes on the CVS have a direct impact in your application.
For example: if you are working with woody, so check the changes related
to woody tags, etc.
3-Build the new cocoon and import your project.
4-Test if your project works with the new version.
5-If the project does not work, try to fix it.
6-If after fixing there are other problems (example: a Cocoon internal):
   6.a) Inform in the mail list about the problem
   6.b) go back to the backup copy of the project
   6.c) stay tunned to see if in the CVS is a fix of the error.

I learned to work in this way. I do this every 1 to 7 days. It depends of
the level and importance of changes to my current work. I do this for 2
types of applications that use diferents blocks config. Maybe this is
additional work and I am crazy. I know. But I love to see and use every
new features and bug fix in Cocoon.

I hope this explain my view point.

Best Regards,

Antonio Gallardo

>>I was working in druid - for get the boring O/R
>> mapping done by a Druid generator.
> This thing is very interesting as, although DB and O/R mappings are not
> Cocoon's concern, having a full working template in Cocoon greatly helps
>  people to build complex apps.

You are right, but I do this to show people that there is a faster and
easier road to build database-oriented web applications with Cocoon.

Cocoon is also a moving target it self:

1-Web publishing framework
2-Webapp framework.

And I am pointing to:

3- RAD webapp framework.

When I started with Cocoon it was just an publishing framework. My project
was a database oriented project and I choosed Cocoon as my flagship to do
the job done. Somepeople told me:

"Looks this guy! Choosed an web publishing framework to build a database
application! It must be crazy enough!"

So I am now trying to see an RAD webapp framework in Cocoon. This is the
next level for me. Here is where Druid and OJB go into the play. And this
is why I am writing about Druid and OJB. Woody is just a piece of all the

Best Regards,

Antonio Gallardo

View raw message