[Seaside] Anchor suggestion

Lukas Renggli renggli at gmail.com
Fri Aug 31 17:03:52 UTC 2007

>     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

Well, #with: is always the last message. No matter what tag and what
other attributes you set.

In previous versions there was a dependency between #onClick:,
#callback: and #with:. I removed this in the last version.

>     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.

The whole WABrush hierarchy uses aBlock as argument to #with:
even-though any other object can be used that responds to #renderOn:.
Maybe that should be changed to anObject?

> Also annoying is the fact that the anchor is neutralized
> by the void(0) action when is not instantiated in the right order.

I don't see how that can happen? Can you give an example.

> 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

The problem is that an anchor either needs a href or a name attribute,
otherwise its invalid and many browsers are unable to properly style
it. Letting the anchor put there javascript:void(0) makes it much
easier to either use the anchor with callbacks or with javascript
actions, without letting the developer worry about the details.


Lukas Renggli

More information about the seaside mailing list