You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2004/04/05 00:18:07 UTC
new blocks.properties way more painful to use
in the past I was used to:
1) cp blocks.properties local.blocks.properties
2) vi local.blocks.properties
3) uncomment the blocks that I wanted to exclude
Today, I have to go thru a bunch of include and change them from true to
false. Much more hassle than just uncommenting/commenting one line.
Please, revert back to how it was before or make it equivalently
painless to reduce the blocks tuning time.
Thanks.
--
Stefano.
Re: new blocks.properties way more painful to use
Posted by Joerg Heinicke <jo...@gmx.de>.
On 05.04.2004 04:31, Antonio Gallardo wrote:
>>>in the past I was used to:
>>>
>>> 1) cp blocks.properties local.blocks.properties
>>> 2) vi local.blocks.properties
>>> 3) uncomment the blocks that I wanted to exclude
>>>
>>>Today, I have to go thru a bunch of include and change them from true to
>>>false. Much more hassle than just uncommenting/commenting one line.
>>Stefano,
>>
>>There was a vote:
>>
>>http://marc.theaimsgroup.com/?t=108082330700004&r=1&w=2
> I think this is the same again a less than 24 hours vote. AFAIK, there
> must be at least a 48 hours.
That's not true! I started the vote on Thursday before work:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108082318706889&w=4
and committed the stuff Friday after work:
http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=108093289629087&w=4
Of course you can still object that it have been only 30 hours, but til
Stefano's objection there had been 80 hours:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108111709731490&w=4
which is even more than the longest voting period of 72 hours I know of.
Joerg
Re: new blocks.properties way more painful to use
Posted by Antonio Gallardo <ag...@agssa.net>.
Tony Collen dijo:
> Stefano Mazzocchi wrote:
>> in the past I was used to:
>>
>> 1) cp blocks.properties local.blocks.properties
>> 2) vi local.blocks.properties
>> 3) uncomment the blocks that I wanted to exclude
>>
>> Today, I have to go thru a bunch of include and change them from true to
>> false. Much more hassle than just uncommenting/commenting one line.
>>
>> Please, revert back to how it was before or make it equivalently
>> painless to reduce the blocks tuning time.
>>
>> Thanks.
>>
>
> Stefano,
>
> There was a vote:
>
> http://marc.theaimsgroup.com/?t=108082330700004&r=1&w=2
>
> Please don't take this the wrong way, but where were you during the vote?
> :)
I think this is the same again a less than 24 hours vote. AFAIK, there
must be at least a 48 hours.
Best Regards,
Antonio Gallardo
Re: new blocks.properties way more painful to use
Posted by Stefano Mazzocchi <st...@apache.org>.
Tony Collen wrote:
> Stefano Mazzocchi wrote:
>
>> in the past I was used to:
>>
>> 1) cp blocks.properties local.blocks.properties
>> 2) vi local.blocks.properties
>> 3) uncomment the blocks that I wanted to exclude
>>
>> Today, I have to go thru a bunch of include and change them from true
>> to false. Much more hassle than just uncommenting/commenting one line.
>>
>> Please, revert back to how it was before or make it equivalently
>> painless to reduce the blocks tuning time.
>>
>> Thanks.
>>
>
> Stefano,
>
> There was a vote:
>
> http://marc.theaimsgroup.com/?t=108082330700004&r=1&w=2
>
> Please don't take this the wrong way, but where were you during the
> vote? :)
Earning the money that feeds me, which doesn't come from following this
list.
You guys debate on avoiding the double negative, but failed completely
to see the value of the previous schema that you could remove a block
with a single keystroke.
Now, I don't care what wording you use for the properties, but I *DO*
care about how much effort one is supposed to undergo to tune cocoon.
So, no matter what wording you use, please, make it as easy as it was
before or I'll call a new vote to revert it.
--
Stefano.
Re: new blocks.properties way more painful to use
Posted by Tony Collen <co...@umn.edu>.
Stefano Mazzocchi wrote:
> in the past I was used to:
>
> 1) cp blocks.properties local.blocks.properties
> 2) vi local.blocks.properties
> 3) uncomment the blocks that I wanted to exclude
>
> Today, I have to go thru a bunch of include and change them from true to
> false. Much more hassle than just uncommenting/commenting one line.
>
> Please, revert back to how it was before or make it equivalently
> painless to reduce the blocks tuning time.
>
> Thanks.
>
Stefano,
There was a vote:
http://marc.theaimsgroup.com/?t=108082330700004&r=1&w=2
Please don't take this the wrong way, but where were you during the vote? :)
Tony
Re: new blocks.properties way more painful to use
Posted by Stefano Mazzocchi <st...@apache.org>.
Geoff Howard wrote:
> Ugo Cei wrote:
>
>> Il giorno 05/apr/04, alle 16:54, Geoff Howard ha scritto:
>>
>>> Ugo Cei wrote:
>>>
>>>> Il giorno 05/apr/04, alle 15:38, Geoff Howard ha scritto:
>>>>
>>>>> Is "/" "." that much more harder than "arrow down" "x" ?
>>>>>
>>>> The coommand for findiing the next match is "n" not "/".
>>>
>>>
>>>
>>> Actually, it's /-enter (a blank search - it's an old habit) -
>>> they both work.
>>>
>>> Geoff
>>>
>>
>> /-enter is two keystrokes instead of one ;-)
>
> :) true.
First, not everyone is a VI user.
Second, we have introduced an inconsistency between blocks.properties
and build.properties semantics.
Third, if it isn't broke don't fix it.
--
Stefano.
Re: new blocks.properties way more painful to use
Posted by Geoff Howard <co...@leverageweb.com>.
Ugo Cei wrote:
> Il giorno 05/apr/04, alle 16:54, Geoff Howard ha scritto:
>
>> Ugo Cei wrote:
>>
>>> Il giorno 05/apr/04, alle 15:38, Geoff Howard ha scritto:
>>>
>>>> Is "/" "." that much more harder than "arrow down" "x" ?
>>>>
>>> The coommand for findiing the next match is "n" not "/".
>>
>>
>> Actually, it's /-enter (a blank search - it's an old habit) -
>> they both work.
>>
>> Geoff
>>
>
> /-enter is two keystrokes instead of one ;-)
:) true.
Geoff
Re: new blocks.properties way more painful to use
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 05/apr/04, alle 16:54, Geoff Howard ha scritto:
> Ugo Cei wrote:
>
>> Il giorno 05/apr/04, alle 15:38, Geoff Howard ha scritto:
>>> Is "/" "." that much more harder than "arrow down" "x" ?
>>>
>> The coommand for findiing the next match is "n" not "/".
>
> Actually, it's /-enter (a blank search - it's an old habit) -
> they both work.
>
> Geoff
>
/-enter is two keystrokes instead of one ;-)
Ugo
Re: new blocks.properties way more painful to use
Posted by Geoff Howard <co...@leverageweb.com>.
Ugo Cei wrote:
> Il giorno 05/apr/04, alle 15:38, Geoff Howard ha scritto:
>
>> Is "/" "." that much more harder than "arrow down" "x" ?
>>
> The coommand for findiing the next match is "n" not "/".
Actually, it's /-enter (a blank search - it's an old habit) -
they both work.
Geoff
Re: new blocks.properties way more painful to use
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 05/apr/04, alle 15:38, Geoff Howard ha scritto:
> Is "/" "." that much more harder than "arrow down" "x" ?
>
The coommand for findiing the next match is "n" not "/".
Ugo
Re: new blocks.properties way more painful to use
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le 8 avr. 04, à 04:02, Joerg Heinicke a écrit :
> ...In blocks.properties there are #include=false lines (except for the
> deprecated ones), blocks are included by default. This solution would
> bring back Stefano's uncommenting/commenting, but has one down side:
> the deprecated blocks excluded via include=false in blocks.properties
> can not be included by exclude=false (as it is possible now, backwards
> compatibility), but must be included by include=true.
>
> WDYT? Commit?
Thanks Joerg, I think this solves both the "commenting" and the "use a
meaningful syntax" problems. I'm +1 for your commit.
IMHO adding a comment in blocks.properties about the "exclude" syntax
being deprecated solves the downside that you mention above.
-Bertrand
Re: new blocks.properties way more painful to use
Posted by David Crossley <cr...@apache.org>.
Joerg Heinicke wrote:
<snip/>
>
> Thanks for the constructive idea. I have it working now the following
> way: internal.exclude set through include set through exclude property.
> In blocks.properties there are #include=false lines (except for the
> deprecated ones), blocks are included by default. This solution would
> bring back Stefano's uncommenting/commenting, but has one down side: the
> deprecated blocks excluded via include=false in blocks.properties can
> not be included by exclude=false (as it is possible now, backwards
> compatibility), but must be included by include=true.
>
> WDYT? Commit?
Good on you, Joerg. Thanks for this important work. You would
have needed your logic hat firmly fixed to your head to write
both the code and the above paragraph.
The "down side" is not so bad. People should need to do
specific and deliberate actions to include deprecated stuff.
+1 to commit.
--David
Re: new blocks.properties way more painful to use
Posted by Joerg Heinicke <jo...@gmx.de>.
On 05.04.2004 17:19, Vadim Gritsenko wrote:
>>> in the past I was used to:
>>>
>>> 1) cp blocks.properties local.blocks.properties
>>> 2) vi local.blocks.properties
>>> 3) uncomment the blocks that I wanted to exclude
>>>
>>> Today, I have to go thru a bunch of include and change them from true
>>> to false. Much more hassle than just uncommenting/commenting one line.
>
> Ok, but it should be fairly easy to make "include" properties default to
> "true" if nothing else is defined - then it (almost) solves an issue:
> block.properties can contain comments only, and explain format. And
> local.block.properties can define properties in any syntax - include or
> exclude.
Thanks for the constructive idea. I have it working now the following
way: internal.exclude set through include set through exclude property.
In blocks.properties there are #include=false lines (except for the
deprecated ones), blocks are included by default. This solution would
bring back Stefano's uncommenting/commenting, but has one down side: the
deprecated blocks excluded via include=false in blocks.properties can
not be included by exclude=false (as it is possible now, backwards
compatibility), but must be included by include=true.
WDYT? Commit?
Joerg
Re: new blocks.properties way more painful to use
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Geoff Howard wrote:
> Stefano Mazzocchi wrote:
>
>> in the past I was used to:
>>
>> 1) cp blocks.properties local.blocks.properties
>> 2) vi local.blocks.properties
>> 3) uncomment the blocks that I wanted to exclude
>>
>> Today, I have to go thru a bunch of include and change them from true
>> to false. Much more hassle than just uncommenting/commenting one line.
>
>
> ? With the previous uncomment scheme, you probably did arrow down,
> and then the "x" command to delete the # character. With the new
> scheme for the first line you would do "/true" (find the word true)
> and then "cw" "false" "esc". From them on you'd do "/" (repeat the
> last find) until you found a line you want to change then "." (repeat
> the last edit).
>
> Is "/" "." that much more harder than "arrow down" "x" ?
I guess it depends on your "vi" skills ;-)
Ok, but it should be fairly easy to make "include" properties default to
"true" if nothing else is defined - then it (almost) solves an issue:
block.properties can contain comments only, and explain format. And
local.block.properties can define properties in any syntax - include or
exclude.
Vadim
Re: new blocks.properties way more painful to use
Posted by Geoff Howard <co...@leverageweb.com>.
Stefano Mazzocchi wrote:
> in the past I was used to:
>
> 1) cp blocks.properties local.blocks.properties
> 2) vi local.blocks.properties
> 3) uncomment the blocks that I wanted to exclude
>
> Today, I have to go thru a bunch of include and change them from true to
> false. Much more hassle than just uncommenting/commenting one line.
? With the previous uncomment scheme, you probably did arrow down, and then the
"x" command to delete the # character. With the new scheme for the first line
you would do "/true" (find the word true) and then "cw" "false" "esc". From
them on you'd do "/" (repeat the last find) until you found a line you want to
change then "." (repeat the last edit).
Is "/" "." that much more harder than "arrow down" "x" ?
Geoff
Re: new blocks.properties way more painful to use
Posted by Antonio Gallardo <ag...@agssa.net>.
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
>>>local.blocks.properties.
>>
>>
>> Yes you have a posibility. I posted, while I developed the OJB block I
>> found the way to do that:
>>
>> Suppose in block.properties you set: exclude.block.ojb=true
>>
>> Then to rewrite the value, you can use in your local.block.properties:
>>
>> 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 local.block.properties, even in the case
>> you try to rewrite it in the block.properties you will not success and
>> the
>> property remain as it was defined in the local.block.properties block.
>
> Ah, sorry, you are right. I found this out myself, but had it not in
> mind when writing the above:
> http://article.gmane.org/gmane.text.xml.cocoon.devel/33944
>
> 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
might.
Best Regards,
Antonio Gallardo
Re: new blocks.properties way more painful to use
Posted by Joerg Heinicke <jo...@gmx.de>.
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
>>local.blocks.properties.
>
>
> Yes you have a posibility. I posted, while I developed the OJB block I
> found the way to do that:
>
> Suppose in block.properties you set: exclude.block.ojb=true
>
> Then to rewrite the value, you can use in your local.block.properties:
>
> 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 local.block.properties, even in the case
> you try to rewrite it in the block.properties you will not success and the
> property remain as it was defined in the local.block.properties block.
Ah, sorry, you are right. I found this out myself, but had it not in
mind when writing the above:
http://article.gmane.org/gmane.text.xml.cocoon.devel/33944
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.
Joerg
Re: new blocks.properties way more painful to use
Posted by Antonio Gallardo <ag...@agssa.net>.
Joerg Heinicke dijo:
> 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
> local.blocks.properties.
Yes you have a posibility. I posted, while I developed the OJB block I
found the way to do that:
Suppose in block.properties you set: exclude.block.ojb=true
Then to rewrite the value, you can use in your local.block.properties:
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 local.block.properties, even in the case
you try to rewrite it in the block.properties you will not success and the
property remain as it was defined in the local.block.properties block.
That worked in this way. We can easily make a test using Cocoon 2.1.4.
Best Regards,
Antonio Gallardo
Re: new blocks.properties way more painful to use
Posted by Joerg Heinicke <jo...@gmx.de>.
On 05.04.2004 00:18, Stefano Mazzocchi wrote:
> in the past I was used to:
>
> 1) cp blocks.properties local.blocks.properties
> 2) vi local.blocks.properties
> 3) uncomment the blocks that I wanted to exclude
>
> Today, I have to go thru a bunch of include and change them from true to
> false. Much more hassle than just uncommenting/commenting one line.
That's true obviously. But you can still use the exclude syntax in your
local.blocks.properties if you want.
> Please, revert back to how it was before or make it equivalently
> painless to reduce the blocks tuning time.
Tony already pointed it out, it was based on a vote started by me. The
reason for the change is naming itself on the one hand. Not only native
English speaking people found the exclude syntax a mass.
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 local.blocks.properties.
Furthermore the ideas already go beyond the current version:
http://marc.theaimsgroup.com/?t=108084941400006&r=1&w=4
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108091508726085&w=4
Joerg
Re: new blocks.properties way more painful to use
Posted by Tim Larson <ti...@keow.org>.
On Sun, Apr 04, 2004 at 06:18:07PM -0400, Stefano Mazzocchi wrote:
> in the past I was used to:
>
> 1) cp blocks.properties local.blocks.properties
> 2) vi local.blocks.properties
> 3) uncomment the blocks that I wanted to exclude
>
> Today, I have to go thru a bunch of include and change them from true to
> false. Much more hassle than just uncommenting/commenting one line.
We could auto-generate two sample config files, one "excluding"
everything and the other "including" everything. Then you could
pick one of these to copy and comment out the lines you want to
have fall back to the default.
Personally, I like the clarity of the new "include=" syntax.
--Tim Larson