[Seaside] Anchor suggestion

Sebastian Sastre ssastre at seaswork.com
Fri Aug 31 14:12:44 UTC 2007


Hi there,
 
    updating some code not to use anymore the deprecated api #text: I've
found right now in 2.8 (lr-462) that WAAnchorTag has with: and callback: as
expected but one *should* use them in the right order.
 
    There is no other way to know the right order than to: 1 look and
interpret anchor's code 2 try and see what happends
 
    I have no personal problem with this because I'm used to but with a
simple touch it could be better. For example:
 
WAAnchorTagwith: aBlock
 url isNil
  ifFalse: [ self attributes at: 'href' put: url ]
....
 
not only is not commented in the code but also erroneous suggest that only
aBlock is coming. Also annoying is the fact that the anchor is neutralized
by the void(0) action when is not instantiated in the right order. 
 
So.. a little change to this:
 
with: aBlockOrString
 url isNil
  ifFalse: [ self attributes at: 'href' put: url ]
  ifTrue: [
   ((self attributes includesKey: 'href') or: [ self attributes includesKey:
'name' ])
    ifFalse: [ self attributes at: 'href' put: 'javascript:alert("Are you
sure about how the callback for this anchor is coded?")' ] ].
 super with: aBlock
 
will call developers attention right to the solution saving it's time not to
mention the time of not that experienced developers.
 
    my 2 cents,
 
Sebastian Sastre

PS: I'm worried about the criteria more than the case. I don't think this as
being acceptable for *The Seaside Experience* that one could want 

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20070831/43dde856/attachment.htm


More information about the seaside mailing list