[Seaside] Anchor suggestion
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:
> > 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
> 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 Renggli
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
More information about the seaside