[Seaside] Anchor suggestion

[Lukas Renggli]

>     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

-- 
Lukas Renggli
http://www.lukas-renggli.ch