[Seaside] Anchor suggestion

[Boris Popov]

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

boris at deepcovelabs.com

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: seaside-bounces at lists.squeakfoundation.org
[mailto:seaside-bounces at lists.squeakfoundation.org] 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: seaside-bounces at lists.squeakfoundation.org
[mailto:seaside-bounces at lists.squeakfoundation.org] 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 

	 

	 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20070831/7554fb0e/attachment-0001.htm