Smalltalk › Frameworks & Tools › Seaside › Seaside General

Anchor suggestion

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Sebastian Sastre-2

Anchor suggestion

Hi there,

updating some code not to use anymore the deprecated api #text: I've found right now in 2.8 (lr-462) that WAAnchorTag has with: and callback: as expected but one *should* use them in the right order.

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

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. Also annoying is the fact that the anchor is neutralized by the void(0) action when is not instantiated in the right order.

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

will call developers attention right to the solution saving it's time not to mention the time of not that experienced developers.

my 2 cents,

Sebastian Sastre

PS: I'm worried about the criteria more than the case. I don't think this as being acceptable for *The Seaside Experience* that one could want

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Sebastian Sastre-2

RE: Anchor suggestion

I see there is not that easy because anchors *should* just do nothing when they have updates onClick and let the update request do the trick. Mmmmmm... at least this could be commented somehow

cheers,

Sebastian Sastre

De: [hidden email] [mailto:[hidden email]] En nombre de Sebastian Sastre
Enviado el: Viernes, 31 de Agosto de 2007 11:13
Para: 'Seaside - general discussion'
Asunto: [Seaside] Anchor suggestion

Hi there,

    updating some code not to use anymore the deprecated api #text: I've found right now in 2.8 (lr-462) that WAAnchorTag has with: and callback: as expected but one *should* use them in the right order.

    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

    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. Also annoying is the fact that the anchor is neutralized by the void(0) action when is not instantiated in the right order.

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

will call developers attention right to the solution saving it's time not to mention the time of not that experienced developers.

    my 2 cents,

Sebastian Sastre

PS: I'm worried about the criteria more than the case. I don't think this as being acceptable for *The Seaside Experience* that one could want

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Lukas Renggli

Re: Anchor suggestion

In reply to this post by Sebastian Sastre-2

> 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
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Boris Popov, DeepCove Labs (SNN)

RE: Anchor suggestion

In reply to this post by Sebastian Sastre-2

Not sure I understand exactly what the problem is because #with: should always come last, regardless which tag you are writing, so there’s no ordering ambiguity AFACT.

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

From: [hidden email] [mailto:[hidden email]] On Behalf Of Sebastian Sastre
Sent: Friday, August 31, 2007 7:37 AM
To: 'Seaside - general discussion'
Subject: RE: [Seaside] Anchor suggestion

I see there is not that easy because anchors *should* just do nothing when they have updates onClick and let the update request do the trick. Mmmmmm... at least this could be commented somehow

cheers,

Sebastian Sastre

De: [hidden email] [mailto:[hidden email]] En nombre de Sebastian Sastre
Enviado el: Viernes, 31 de Agosto de 2007 11:13
Para: 'Seaside - general discussion'
Asunto: [Seaside] Anchor suggestion

Hi there,

    updating some code not to use anymore the deprecated api #text: I've found right now in 2.8 (lr-462) that WAAnchorTag has with: and callback: as expected but one *should* use them in the right order.

    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

    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. Also annoying is the fact that the anchor is neutralized by the void(0) action when is not instantiated in the right order.

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

will call developers attention right to the solution saving it's time not to mention the time of not that experienced developers.

    my 2 cents,

Sebastian Sastre

PS: I'm worried about the criteria more than the case. I don't think this as being acceptable for *The Seaside Experience* that one could want

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Sebastian Sastre-2

RE: Anchor suggestion

In reply to this post by Lukas Renggli

> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]] 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.

cheers,

Sebastian

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

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside