Re: [Vote] notation of blocks selection properties
Upayavira upaya.co.uk> writes: > Joerg, > > How hard would it be to switch to having: > > build stable > or > build unstable > > instead of build webapp? > > That would enable someone to choose right up front, without having to do > any file editing. I will add my thoughts to the "excluding unstable blocks by default" thread: http://marc.theaimsgroup.com/?t=10808494146&r=1&w=4. Joerg
Re: [Vote] notation of blocks selection properties
Joerg, How hard would it be to switch to having: build stable or build unstable instead of build webapp? That would enable someone to choose right up front, without having to do any file editing. Regards, Upayavira Joerg Heinicke wrote: Tim Larson keow.org> writes: include=true == exclude=false No. include=false == exclude=true Yes. I admit that I did not completely follow your explanation, but is the problem that the statement equalities listed above are not correct, Why should they be not correct? No, it's indeed only implementation/Ant. or that even if they are correct that they still would not provide compatibility, or lastly only that it cannot be implemented via Ant? If it is only this last problem, then surely there is some other way to make Ant fit the need. We have at the moment: exclude.block.blockname=true #exclude.block.blockname=true and exclude.block.blockname=false would also work. But the latter only because of the mapping of exclude.block.blockname to unless.exclude.block.blockname through this construct: So unless.exclude.block.blockname is *only* set if exclude.block.blockname is true/yes/on. Otherwise it is *not* set (to false or similar). Ant can execute targets in dependency on set properties: means: execute this target if the property unless.exclude.block.blockname is *not* set. Setting the property to false would let the target be executed. What I wanted to do: include.block.blockname=true|false mapped via and use unless="exclude.block.blockname". This solution would be backwards compatible except for the case exclude.block.blockname=false (or any value != true/yes/on) as this would not lead to expected behaviour. The block would be excluded independent on the value of this property. Now when writing the answer to your first statement equalities mail I had the idea that we could use double mapping: As the default settings (blocks.properties) use include.block.blockname, in local.blocks.properties exclude.block.blockname can be used with arbitrary value because it's mapped again. This would lead to complete backwards compatibility and fulfill your both statement equalities. The more I think about it the more I like the latter solution though there is a bit more code. It was a long mail, but I hope it's more clear now. Joerg
Re: [Vote] notation of blocks selection properties
Tim Larson keow.org> writes: > > > include=true == exclude=false > > > > No. > > > > > include=false == exclude=true > > > > Yes. > > > I admit that I did not completely follow your explanation, but > is the problem that the statement equalities listed above are > not correct, Why should they be not correct? No, it's indeed only implementation/Ant. > or that even if they are correct that they still > would not provide compatibility, or lastly only that it cannot > be implemented via Ant? If it is only this last problem, then > surely there is some other way to make Ant fit the need. We have at the moment: exclude.block.blockname=true #exclude.block.blockname=true and exclude.block.blockname=false would also work. But the latter only because of the mapping of exclude.block.blockname to unless.exclude.block.blockname through this construct: So unless.exclude.block.blockname is *only* set if exclude.block.blockname is true/yes/on. Otherwise it is *not* set (to false or similar). Ant can execute targets in dependency on set properties: means: execute this target if the property unless.exclude.block.blockname is *not* set. Setting the property to false would let the target be executed. What I wanted to do: include.block.blockname=true|false mapped via and use unless="exclude.block.blockname". This solution would be backwards compatible except for the case exclude.block.blockname=false (or any value != true/yes/on) as this would not lead to expected behaviour. The block would be excluded independent on the value of this property. Now when writing the answer to your first statement equalities mail I had the idea that we could use double mapping: As the default settings (blocks.properties) use include.block.blockname, in local.blocks.properties exclude.block.blockname can be used with arbitrary value because it's mapped again. This would lead to complete backwards compatibility and fulfill your both statement equalities. The more I think about it the more I like the latter solution though there is a bit more code. It was a long mail, but I hope it's more clear now. Joerg
Re: [Vote] notation of blocks selection properties
On Fri, Apr 02, 2004 at 12:28:22AM +0200, Joerg Heinicke wrote: > On 01.04.2004 22:00, Tim Larson wrote: > > >Likewise. BTW, am I missing something or can these two options be > >made completely compatible, as in: > > include=true == exclude=false > > No. > > > include=false == exclude=true > > Yes. I admit that I did not completely follow your explanation, but is the problem that the statement equalities listed above are not correct, or that even if they are correct that they still would not provide compatibility, or lastly only that it cannot be implemented via Ant? If it is only this last problem, then surely there is some other way to make Ant fit the need. --Tim Larson
Re: [Vote] notation of blocks selection properties
On Apr 1, 2004, at 11:45 AM, Tony Collen wrote: Better to use a single positive instead of a double negative ;) Or in other words, better not to use a double negative :-) If my +1 counted, I'd give it to [X] include.block.blockname=true|false I don't know if it's because I'm a native English speaker, but the sense always seemed bass-ackwards to me too :-) ~ml
Re: [Vote] notation of blocks selection properties
On 01.04.2004 22:00, Tim Larson wrote: Likewise. BTW, am I missing something or can these two options be made completely compatible, as in: include=true == exclude=false No. include=false == exclude=true Yes. Using If local config contains exclude, the above is not evaluated (properties can not be reset). exclude.block.blockname is therefore the old unless.exclude.block.blockname. exclude=false would not work then because in @unless and @if Ant looks only if the property is set, not to which value. So exclude=false would be interpreted the same way as exclude=true. Now I could imagine the following: But I don't think that I really like this. Joerg
Re: [Vote] notation of blocks selection properties
Marc Portier dijo: > well, imagine trying to figure it out if you're not a native English > speaker :-) > > > in any case: this will be rather bath news for people that have adopted > to this scheme: > http://wiki.cocoondev.org/Wiki.jsp?page=YourCocoonBasedProjectAnt16 This is what I call an "incompatible change" and this is why I voted for the other option. Glad to hear somebody else see the compatibility problem too :-D Best Regards, Antonio Gallardo
Re: [Vote] notation of blocks selection properties
On Thu, Apr 01, 2004 at 02:41:32PM -0500, Vadim Gritsenko wrote: > Upayavira wrote: > > >Joerg Heinicke wrote: > > > >>[ ] exclude.block.blockname=true|false > >>[+1] include.block.blockname=true|false > >> > >Exclude always seemed really odd to a native English speaker. It was > >always the wrong way around. Likewise. BTW, am I missing something or can these two options be made completely compatible, as in: include=true == exclude=false include=false == exclude=true of course with the local config overriding the default config as we already have it doing. The old local configs would keep working, and new installations could use the more understandable "include=" syntax. --Tim Larson
Re: [Vote] notation of blocks selection properties [OT]
Le 1 avr. 04, à 21:41, Vadim Gritsenko a écrit : ...I trust opinion of native English speaker - very scarce resource nowadays! ;-) me I can find to Vadim that you serioulsly think when Vadim you something write, almost. So fortunateless I tendency to very much agreement, thanks Vadim for the non-scarceness of us English speaking. -Bertrand (cheek around tongue)
Re: [Vote] notation of blocks selection properties
Joerg Heinicke wrote: [ ] exclude.block.blockname=true|false [X] include.block.blockname=true|false Better to use a single positive instead of a double negative ;) Better later than never, Tony
Re: [Vote] notation of blocks selection properties
Upayavira wrote: Joerg Heinicke wrote: So now the vote: [ ] exclude.block.blockname=true|false [+1] include.block.blockname=true|false is my vote too... Joerg Exclude always seemed really odd to a native English speaker. It was always the wrong way around. Upayavira well, imagine trying to figure it out if you're not a native English speaker :-) in any case: this will be rather bath news for people that have adopted to this scheme: http://wiki.cocoondev.org/Wiki.jsp?page=YourCocoonBasedProjectAnt16 just because they want an easy swap from 2.1.x to current cvs-head and back if needed... have to think about a flexible way out for those, hints and tips welcome... only thing I can figure now is for those people to have both exclude.** and include.** props in their local.build.properties so they get the same kind of build result regards, -marc= -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [Vote] notation of blocks selection properties
Upayavira wrote: Joerg Heinicke wrote: [ ] exclude.block.blockname=true|false [+1] include.block.blockname=true|false Exclude always seemed really odd to a native English speaker. It was always the wrong way around. I trust opinion of native English speaker - very scarce resource nowadays! ;-) Vadim
Re: [Vote] notation of blocks selection properties
[ ] exclude.block.blockname=true|false [X] include.block.blockname=true|false Ugo
Re: [Vote] notation of blocks selection properties
Joerg Heinicke wrote: So now the vote: [ ] exclude.block.blockname=true|false [x] include.block.blockname=true|false -- Reinhard
Re: [Vote] notation of blocks selection properties
Joerg Heinicke wrote: Le 31 mars 04, Ã 23:46, Joerg Heinicke a Ãcrit : ...WDYT? Change only the documentation (to "use true|false") or additionally the property names from exclude to include I'm for changing from exclude to include, but you might want to ask for a [VOTE], or at least a quick vote as this is a kind of "interface change". -Bertrand Ok, then let's start a vote for it: For recall the thread can be found at http://thread.gmane.org/gmane.text.xml.cocoon.devel/33630, the important part starts at http://article.gmane.org/gmane.text.xml.cocoon.devel/33944. It's about changing the notation for blocks selection properties from exclude.block.blockname to include.block.blockname, which IMO is a bit more intuitive. As I wrote in my mail, the solution I have is partly backward compatible, this means a local.blocks.properties in the old style will still work and the blocks selection will be as expected expected for the case exclude.block.blockname=false is already in use. This works because I changed the unless.exclude.block.blockname property (to which exclude.block.blockname is mapped to) to only exclude.block.blockname. So now the vote: [ ] exclude.block.blockname=true|false [+1] include.block.blockname=true|false Joerg Exclude always seemed really odd to a native English speaker. It was always the wrong way around. Upayavira
Re: [Vote] notation of blocks selection properties
...So now the vote: [ ] exclude.block.blockname=true|false [+1 ] include.block.blockname=true|false -Bertrand
Re: [Vote] notation of blocks selection properties
IMHO backward compatibility is important. not here IMHO ...so >>[ ] exclude.block.blockname=true|false >>[x] include.block.blockname=true|false cheers -- Torsten
Re: [Vote] notation of blocks selection properties
Am Do, den 01.04.2004 schrieb Joerg Heinicke um 14:39: > So now the vote: > > [ ] exclude.block.blockname=true|false > [+1] include.block.blockname=true|false Stephan.
Re: [Vote] notation of blocks selection properties
Joerg Heinicke gmx.de> writes: > As I wrote in my mail, the solution I have is partly backward compatible, this > means a local.blocks.properties in the old style will still work and the blocks > selection will be as expected expected for the case > exclude.block.blockname=false is already in use. Just for clarification: The second "expected" should read "except", which might give the sentence another meaning ;-) Joerg
Re: [Vote] notation of blocks selection properties
Joerg Heinicke gmx.de> writes: > So now the vote: > > [ ] exclude.block.blockname=true|false > [X] include.block.blockname=true|false Joerg
Re: [Vote] notation of blocks selection properties
Joerg Heinicke dijo: > So now the vote: > > [+1 ] exclude.block.blockname=true|false > [ ] include.block.blockname=true|false IMHO backward compatibility is important. Antonio Gallardo
