> 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