[Seaside-dev] Re: WATagBrush>>class:if: with boolean and additional blocks

[Johan Brichau]

I agree it’s a nice-to-have but, as Philippe mentions, it seems to raise incompatibility issues.
It is also not ugly to work around in your own app if you need it. In essence:

class: ‘hidden’ if: aBlock value

The #scriptBlock:if: message is different because it’s the script generation that goes into the block (it just made me think about it when you raised this). Without it, we need to do other stuff:

div := html div.
canWrite ifTrue:[ div script: (self generateScript)].
div
  with: [ … ]

The above is ugly and much nicer as follows:

html div
	scriptBlock: [self generateScript[ if: canWrite;
	with: [ …. ]

But I don’t like the name of the method ;-)

Cheers,
Johan

On 30 Dec 2013, at 21:42, Philippe Marschall <philippe.marschall at gmail.com> wrote:

> On Mon, Dec 30, 2013 at 8:33 PM, Torsten Bergmann <astares at gmx.de> wrote:
>>> What's the use case for this?
>> 
>> One can pass a block instead of a boolean which is more flexible since a block
>> can be passed around
> 
> So can booleans.
> 
>> and (although defined/dynamically constructed elsewhere)
>> evaluated at rendering time.
> 
> I understand. Do you have a concrete example?
> 
>>> Do not assume #value is part of the Object protocol
>> 
>> No I do not assume that any object can be given - only booleans and
>> blocks. Thats where the name "aBooleanOrBlock" for the parameter came from.
> 
> I'm also not sure we can make this assumptions for booleans. If #value
> isn't on Object why should it be on Boolean?
> 
> Cheers
> Philippe
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev