cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject Re: new way more painful to use
Date Mon, 05 Apr 2004 03:16:57 GMT
Joerg Heinicke dijo:
> On 05.04.2004 04:53, Antonio Gallardo wrote:
>>>But the real need for changing it came out of the discussion about
>>>default excludes of blocks (e.g. javaflow or all unstable blocks). You
>>>have *no* possibility to re-include a block then in
>> Yes you have a posibility. I posted, while I developed the OJB block I
>> found the way to do that:
>> Suppose in you set: exclude.block.ojb=true
>> Then to rewrite the value, you can use in your
>> exclude.block.ojb=false
>> and this works.
>> It is the "nature" of Ant properties. Once you set it, you cannot change
>> it. If I already set it in the, even in the case
>> you try to rewrite it in the you will not success and
>> the
>> property remain as it was defined in the block.
> Ah, sorry, you are right. I found this out myself, but had it not in
> mind when writing the above:
> But exactly the "nature" of Ant properties or at least the behaviour
> when using them in @unless and @if (which is independent on their value
> true or false, only set or not set is tested) let me think that the
> above would not work. Only the mapping through
> <condition><istrue/></condition> made this work.
> And at the end the vote was even about just changing docu ("use
> true/false for default excluded blocks") or additionally rename the
> properties.

Yep. If we are changing too often the way the things work in Cocoon from
the user POV and not leaving the "old" way work is that people will think
Cocoon is like a "big scratch pad" for geek experiments and nothing more.
They will not use it.

I know this change is very simple, but a set of simple changes can be saw
also as a one complex change. I hope this explain my POV in this case.

While doing the multiple <fb:unique> in Forms, Tim asked me to support the
"old style" for people already using it. If not they will face the need to
change all without an option. This is why we "deprecate" and later remove
old things. You know this is not easy thinking how to also support the old
way why creating a new way, but necesary to avoid confusions.

In short, the best we can do is to "deprecate" and tell people it will be
removed in the current+x release. This is what we expect to see in a
releseNotes.txt. We need to think in users that are not follow the dev
list and install the next version and saw the things does not work as

Best Regards,

Antonio Gallardo

View raw message