[Seaside] Anchor suggestion

Sebastian Sastre ssastre at seaswork.com
Fri Aug 31 17:36:39 UTC 2007

> -----Mensaje original-----
> De: seaside-bounces at lists.squeakfoundation.org 
> [mailto:seaside-bounces at lists.squeakfoundation.org] En nombre 
> de Lukas Renggli
> Enviado el: Viernes, 31 de Agosto de 2007 14:04
> Para: Seaside - general discussion
> Asunto: Re: [Seaside] Anchor suggestion
> >     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.
Yes, I wasn't aware of the need of respecting this sequence rigurously until
today  with your intervention :) I can't remember to read about this
anywhere so wonder if perhaps some indication could prevent to repeat this
story for newcomers.

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

> >     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?
If so I'll think about the most obvious: aRendereable or aRendereableObject

> > 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.
2 minutes after complaining I saw that onClick:, for instance, needs badly
that void(0), so I understand that *the hole is more deep* and in fact that
void(0) seems to be a reasonable solution.

My point is to try to facilitate the path from the problem to the solution.
I saw a sign of progress about this on 2.8 in the web walkback when it tries
to suggest what could possibly be wrong. This could be the same criteria
applied to a bad instantiated brush (the brush can complain somehow when
instantiated in an improper sequence for instance). Some kind of
instantiation validation. But is not a problem at all right now for me is
clarified. It's just a suggestion to smooth the experience.



> Lukas
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

More information about the seaside mailing list