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 <
[hidden email]> wrote:
> On Mon, Dec 30, 2013 at 8:33 PM, Torsten Bergmann <
[hidden email]> 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
>
[hidden email]
>
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Locked
