You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Paul Stanton <pa...@mapshed.com.au> on 2010/07/13 04:31:01 UTC

using a js confirm to cancel an async eventlink

Hi all,

I was hoping to be able to use a simple js confirm in order to 
(conditionally) cancel the callback from an async event link:

<a t:type="eventLink" event="DeleteRecord" context="record.id" 
zone="myZone" onclick="return confirm('sure?');">delete</a>

Unfortunately, even when 'Cancel' is clicked, the callback is executed.

What is the simplest way to add one stage of logic to this process?

Thanks, Paul.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: using a js confirm to cancel an async eventlink

Posted by Paul Stanton <pa...@mapshed.com.au>.
thanks josh, and geoff.

Josh Canfield wrote:
>> i have tried both of these approaches but neither cancel the event on the
>> <a>... if yours works what is the fundamental difference?
>>     
>
> when you click on the text only one click event is created and it
> bubbles up through the dom.  So it first is triggered on the span and
> then bubbles up to the a and so on. You need to actually cancel the
> event if you want it to stop bubbling. In prototype you can use the
> Event.stop() function.
>
> <a href="#" id="link"><span id="linkSpan">Observed</span></a>
> <script>
> $('link').observe("click", function(e) {alert("You clicked a link!");});
> $('linkSpan').observe("click", function(e) { if ( confirm('stop span
> click event?') ) { Event.stop(e); return false; }});
> </script>
>
> Hope that helps!
>
> Josh
>
> On Tue, Jul 13, 2010 at 5:04 AM, Paul Stanton <pa...@mapshed.com.au> wrote:
>   
>> thanks geoff,
>>
>> your last post where you put the confirm mixin on a <span> within the <a> is
>> interesting .. wouldn't that be rendered as the equivalent of:
>>
>> <a ....><span onclick="return confirm('?');">text</span></a>
>>
>> or at least the prototypesque version of this:
>>
>> <a ....><span id="spanId">text</span></a>
>> Event.observe($("spanId"), 'click', function(e){if (!confirm('?'))
>> e.stop();});
>>
>> i have tried both of these approaches but neither cancel the event on the
>> <a>... if yours works what is the fundamental difference?
>>
>> regards, p.
>>
>> Geoff Callender wrote:
>>     
>>> http://tapestry-users.832.n2.nabble.com/Confirm-mixin-won-t-cancel-when-in-zone-td5048950.html#a5048950
>>>
>>> On 13/07/2010, at 12:31 PM, Paul Stanton wrote:
>>>
>>>
>>>       
>>>> Hi all,
>>>>
>>>> I was hoping to be able to use a simple js confirm in order to
>>>> (conditionally) cancel the callback from an async event link:
>>>>
>>>> <a t:type="eventLink" event="DeleteRecord" context="record.id"
>>>> zone="myZone" onclick="return confirm('sure?');">delete</a>
>>>>
>>>> Unfortunately, even when 'Cancel' is clicked, the callback is executed.
>>>>
>>>> What is the simplest way to add one stage of logic to this process?
>>>>
>>>> Thanks, Paul.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>>         
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>>>       
>
>
>
>   

Re: using a js confirm to cancel an async eventlink

Posted by Josh Canfield <jo...@gmail.com>.
> i have tried both of these approaches but neither cancel the event on the
> <a>... if yours works what is the fundamental difference?

when you click on the text only one click event is created and it
bubbles up through the dom.  So it first is triggered on the span and
then bubbles up to the a and so on. You need to actually cancel the
event if you want it to stop bubbling. In prototype you can use the
Event.stop() function.

<a href="#" id="link"><span id="linkSpan">Observed</span></a>
<script>
$('link').observe("click", function(e) {alert("You clicked a link!");});
$('linkSpan').observe("click", function(e) { if ( confirm('stop span
click event?') ) { Event.stop(e); return false; }});
</script>

Hope that helps!

Josh

On Tue, Jul 13, 2010 at 5:04 AM, Paul Stanton <pa...@mapshed.com.au> wrote:
> thanks geoff,
>
> your last post where you put the confirm mixin on a <span> within the <a> is
> interesting .. wouldn't that be rendered as the equivalent of:
>
> <a ....><span onclick="return confirm('?');">text</span></a>
>
> or at least the prototypesque version of this:
>
> <a ....><span id="spanId">text</span></a>
> Event.observe($("spanId"), 'click', function(e){if (!confirm('?'))
> e.stop();});
>
> i have tried both of these approaches but neither cancel the event on the
> <a>... if yours works what is the fundamental difference?
>
> regards, p.
>
> Geoff Callender wrote:
>>
>>
>> http://tapestry-users.832.n2.nabble.com/Confirm-mixin-won-t-cancel-when-in-zone-td5048950.html#a5048950
>>
>> On 13/07/2010, at 12:31 PM, Paul Stanton wrote:
>>
>>
>>>
>>> Hi all,
>>>
>>> I was hoping to be able to use a simple js confirm in order to
>>> (conditionally) cancel the callback from an async event link:
>>>
>>> <a t:type="eventLink" event="DeleteRecord" context="record.id"
>>> zone="myZone" onclick="return confirm('sure?');">delete</a>
>>>
>>> Unfortunately, even when 'Cancel' is clicked, the callback is executed.
>>>
>>> What is the simplest way to add one stage of logic to this process?
>>>
>>> Thanks, Paul.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>



-- 
--
http://www.bodylabgym.com - a private, by appointment only, one-on-one
health and fitness facility.
--
http://www.ectransition.com - Quality Electronic Cigarettes at a
reasonable price!
--
TheDailyTube.com. Sign up and get the best new videos on the internet
delivered fresh to your inbox.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: using a js confirm to cancel an async eventlink

Posted by Geoff Callender <ge...@gmail.com>.
The link http://jumpstart.doublenegative.com.au/jumpstart/examples/ajaxcomponentscrud
has been replaced by:

	http://jumpstart.doublenegative.com.au/jumpstart/examples/ajax/componentscrud/persons


On 14/07/2010, at 7:01 AM, Geoff Callender wrote:

> Can't stop to consider the difference right now (maybe later today) but you can see it working in this example:
> 
> 	http://jumpstart.doublenegative.com.au/jumpstart/examples/ajaxcomponentscrud
> 
> HTH,
> 
> Geoff
> 
> On 13/07/2010, at 10:04 PM, Paul Stanton wrote:
> 
>> thanks geoff,
>> 
>> your last post where you put the confirm mixin on a <span> within the <a> is interesting .. wouldn't that be rendered as the equivalent of:
>> 
>> <a ....><span onclick="return confirm('?');">text</span></a>
>> 
>> or at least the prototypesque version of this:
>> 
>> <a ....><span id="spanId">text</span></a>
>> Event.observe($("spanId"), 'click', function(e){if (!confirm('?')) e.stop();});
>> 
>> i have tried both of these approaches but neither cancel the event on the <a>... if yours works what is the fundamental difference?
>> 
>> regards, p.
>> 
>> Geoff Callender wrote:
>>> http://tapestry-users.832.n2.nabble.com/Confirm-mixin-won-t-cancel-when-in-zone-td5048950.html#a5048950
>>> 
>>> On 13/07/2010, at 12:31 PM, Paul Stanton wrote:
>>> 
>>> 
>>>> Hi all,
>>>> 
>>>> I was hoping to be able to use a simple js confirm in order to (conditionally) cancel the callback from an async event link:
>>>> 
>>>> <a t:type="eventLink" event="DeleteRecord" context="record.id" zone="myZone" onclick="return confirm('sure?');">delete</a>
>>>> 
>>>> Unfortunately, even when 'Cancel' is clicked, the callback is executed.
>>>> 
>>>> What is the simplest way to add one stage of logic to this process?
>>>> 
>>>> Thanks, Paul.
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>> 
>>>> 
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>> 
>>> 
>>> 
> 


Re: using a js confirm to cancel an async eventlink

Posted by Geoff Callender <ge...@gmail.com>.
Ah, I should have realised that's what you meant. Yep, worth considering.

Thanks,

Geoff

On 15/07/2010, at 12:13 AM, Chris Mylonas wrote:

> Thanks for the reply Geoff,
> 
> Safe to ignore my request/suggestion :)
> 
> I meant moreso when the example "exercise/tutorial"  was added to jumpstart.
> E.g. you've added more AJAX examples in the past couple of months, but the onActivate/onPassivate example would be a couple of years old.
> 
> and I think I found what I wanted here: http://jumpstart.doublenegative.com.au/bugs_enhancements.html
> 
> 
> I was thinking of an on-the-page easy-to-find property like this:
> 
> .java
> @Property
> private Date addedToJumpstart = new Date("2010-07-14");
> 
> .tml
> This example was added to jumpstart at version ${addedJumpstartVersion} on ${addedJumpstartDate}
> 
> ;)
> 
> Cheers
> Chris
> 
> 
> On 14/07/2010, at 11:47 PM, Geoff Callender wrote:
> 
>> Chris,
>> 
>> Hmmm, I'm always tossing up between keeping the examples simple and making them complete. Your request is pretty compelling so I'll consider it for the next release. In the meantime, here's what I use in simple entities...
>> 
>> 	private java.sql.Timestamp createdAt;
>> 	private java.sql.Timestamp modifiedAt;
>> 
>> 	@PrePersist
>> 	public void prePersist() throws ValidationException {
>> 		validate();
>> 		createdAt = new java.sql.Timestamp(System.currentTimeMillis());
>> 		modifiedAt = createdAt;
>> 	}
>> 
>> 	@PreUpdate
>> 	public void preUpdate() throws ValidationException {
>> 		validate();
>> 		modifiedAt = new java.sql.Timestamp(System.currentTimeMillis());
>> 	}
>> 
>> instead of...
>> 
>> 	@PrePersist
>> 	@PreUpdate
>> 	public void validate() throws ValidationException {
>> 		// etc...
>> 	}
>> 
>> For entities that have more complex state changes than just create, change, and delete this isn't enough, but that's another story.
>> 
>> HTH,
>> 
>> Geoff
>> 
>> On 14/07/2010, at 10:47 PM, Chris Mylonas wrote:
>> 
>>> Geoff that's a great example of some more advanced layout/theme possibilities.
>>> 
>>> Sorry to hijack the thread somewhat,
>>> Any chance of adding to jumpstart a "Date added" and/or "Last modified" section to each example?
>>> 
>>> 
>>> Cheers
>>> Chris
>>> 
>>> On 14/07/2010, at 7:01 AM, Geoff Callender wrote:
>>> 
>>>> Can't stop to consider the difference right now (maybe later today) but you can see it working in this example:
>>>> 
>>>> 	http://jumpstart.doublenegative.com.au/jumpstart/examples/ajaxcomponentscrud
>>>> 
>>>> HTH,
>>>> 
>>>> Geoff
>>>> 
>>>> On 13/07/2010, at 10:04 PM, Paul Stanton wrote:
>>>> 
>>>>> thanks geoff,
>>>>> 
>>>>> your last post where you put the confirm mixin on a <span> within the <a> is interesting .. wouldn't that be rendered as the equivalent of:
>>>>> 
>>>>> <a ....><span onclick="return confirm('?');">text</span></a>
>>>>> 
>>>>> or at least the prototypesque version of this:
>>>>> 
>>>>> <a ....><span id="spanId">text</span></a>
>>>>> Event.observe($("spanId"), 'click', function(e){if (!confirm('?')) e.stop();});
>>>>> 
>>>>> i have tried both of these approaches but neither cancel the event on the <a>... if yours works what is the fundamental difference?
>>>>> 
>>>>> regards, p.
>>>>> 
>>>>> Geoff Callender wrote:
>>>>>> http://tapestry-users.832.n2.nabble.com/Confirm-mixin-won-t-cancel-when-in-zone-td5048950.html#a5048950
>>>>>> 
>>>>>> On 13/07/2010, at 12:31 PM, Paul Stanton wrote:
>>>>>> 
>>>>>> 
>>>>>>> Hi all,
>>>>>>> 
>>>>>>> I was hoping to be able to use a simple js confirm in order to (conditionally) cancel the callback from an async event link:
>>>>>>> 
>>>>>>> <a t:type="eventLink" event="DeleteRecord" context="record.id" zone="myZone" onclick="return confirm('sure?');">delete</a>
>>>>>>> 
>>>>>>> Unfortunately, even when 'Cancel' is clicked, the callback is executed.
>>>>>>> 
>>>>>>> What is the simplest way to add one stage of logic to this process?
>>>>>>> 
>>>>>>> Thanks, Paul.
>>>>>>> 
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>> 
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>> 
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: using a js confirm to cancel an async eventlink

Posted by Chris Mylonas <ch...@mrvoip.com.au>.
Thanks Thiago - I've read the follow ups to this from you and Josh,  
and the "nevers" are good to know early on.
"...because of the page pooling" is a good enough reason to make it  
register.

There seems to be a shortage of "never do this" cheat sheet library in  
the 21st century :)



>> .java
>> @Property
>> private Date addedToJumpstart = new Date("2010-07-14");
>
> Never initialize fields like you've done in the above snippet  
> because of the page pooling. Use the activate or begin render event  
> to initialize fields.

Re: using a js confirm to cancel an async eventlink

Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Wed, 14 Jul 2010 15:39:11 -0300, Josh Canfield <jo...@gmail.com>  
wrote:

> HA! I guess I've been using joda-time for too long... I've always
> treated Date as immutable, too bad Java 6 has to be backward
> compatible with Java 1.1 or the setter methods could have been removed
> a LONG time ago!

Agreed.

>> but I prefer to give a
>> short advice instead of a longer one informing the exceptions to the  
>> rule.
>
> That's a valid point of view, but to say "never" without an
> explanation leaves me feeling empty inside ;)

I was too lazy and busy at that time to give the full explanation. :P

-- 
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: using a js confirm to cancel an async eventlink

Posted by Josh Canfield <jo...@gmail.com>.
HA! I guess I've been using joda-time for too long... I've always
treated Date as immutable, too bad Java 6 has to be backward
compatible with Java 1.1 or the setter methods could have been removed
a LONG time ago!

> but I prefer to give a
> short advice instead of a longer one informing the exceptions to the rule.

That's a valid point of view, but to say "never" without an
explanation leaves me feeling empty inside ;)

Josh

On Wed, Jul 14, 2010 at 11:22 AM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> On Wed, 14 Jul 2010 15:13:06 -0300, Josh Canfield <jo...@gmail.com>
> wrote:
>
>>>> @Property
>>>> private Date addedToJumpstart = new Date("2010-07-14");
>>>
>>> Never initialize fields like you've done in the above snippet because of
>>> the
>>> page pooling. Use the activate or begin render event to initialize
>>> fields.
>>>
>>
>> In general that's sound advice, but if you look at the use case here
>> he's building a constant (maybe it should actually be a constant?)
>
>> safe.onstants should be declared as constants (final static). You're right
>> about initializing fields with immutable values, but I prefer to give a
>> short advice instead of a longer one informing the exceptions to the rule.
>
>> Also, Date is an immutable object so using it as an initializer is
>
> It isn't. You need to invoke deprecated methods, but it has many setXXX
> methods.
>
>> The danger with field initializers is that they'll be saved as
>> the default value for the field and modifications can be
>> unpredictable.
>
> Absolutely right. :) But this is also a huge security hole: the data store
> by one user in this object will be viewed by another user that happens to
> have a request handled by the same page object.
>
>> So, don't use mutable objects to initialize fields
>> unless you are really sure about what you are doing.
>
> Or never. :)
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and
> instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>



-- 
--
http://www.bodylabgym.com - a private, by appointment only, one-on-one
health and fitness facility.
--
http://www.ectransition.com - Quality Electronic Cigarettes at a
reasonable price!
--
TheDailyTube.com. Sign up and get the best new videos on the internet
delivered fresh to your inbox.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: using a js confirm to cancel an async eventlink

Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Wed, 14 Jul 2010 15:13:06 -0300, Josh Canfield <jo...@gmail.com>  
wrote:

>>> @Property
>>> private Date addedToJumpstart = new Date("2010-07-14");
>>
>> Never initialize fields like you've done in the above snippet because  
>> of the
>> page pooling. Use the activate or begin render event to initialize  
>> fields.
>>
>
> In general that's sound advice, but if you look at the use case here
> he's building a constant (maybe it should actually be a constant?)

> safe.onstants should be declared as constants (final static). You're  
> right about initializing fields with immutable values, but I prefer to  
> give a short advice instead of a longer one informing the exceptions to  
> the rule.

> Also, Date is an immutable object so using it as an initializer is

It isn't. You need to invoke deprecated methods, but it has many setXXX  
methods.

> The danger with field initializers is that they'll be saved as
> the default value for the field and modifications can be
> unpredictable.

Absolutely right. :) But this is also a huge security hole: the data store  
by one user in this object will be viewed by another user that happens to  
have a request handled by the same page object.

> So, don't use mutable objects to initialize fields
> unless you are really sure about what you are doing.

Or never. :)

-- 
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: using a js confirm to cancel an async eventlink

Posted by Josh Canfield <jo...@gmail.com>.
>> @Property
>> private Date addedToJumpstart = new Date("2010-07-14");
>
> Never initialize fields like you've done in the above snippet because of the
> page pooling. Use the activate or begin render event to initialize fields.
>

In general that's sound advice, but if you look at the use case here
he's building a constant (maybe it should actually be a constant?)
Also, Date is an immutable object so using it as an initializer is
safe. The danger with field initializers is that they'll be saved as
the default value for the field and modifications can be
unpredictable. So, don't use mutable objects to initialize fields
unless you are really sure about what you are doing.


Josh

On Wed, Jul 14, 2010 at 8:43 AM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> On Wed, 14 Jul 2010 11:13:07 -0300, Chris Mylonas <ch...@mrvoip.com.au>
> wrote:
>
>> .java
>> @Property
>> private Date addedToJumpstart = new Date("2010-07-14");
>
> Never initialize fields like you've done in the above snippet because of the
> page pooling. Use the activate or begin render event to initialize fields.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and
> instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>



-- 
--
http://www.bodylabgym.com - a private, by appointment only, one-on-one
health and fitness facility.
--
http://www.ectransition.com - Quality Electronic Cigarettes at a
reasonable price!
--
TheDailyTube.com. Sign up and get the best new videos on the internet
delivered fresh to your inbox.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: using a js confirm to cancel an async eventlink

Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Wed, 14 Jul 2010 11:13:07 -0300, Chris Mylonas <ch...@mrvoip.com.au>  
wrote:

> .java
> @Property
> private Date addedToJumpstart = new Date("2010-07-14");

Never initialize fields like you've done in the above snippet because of  
the page pooling. Use the activate or begin render event to initialize  
fields.

-- 
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: using a js confirm to cancel an async eventlink

Posted by Chris Mylonas <ch...@mrvoip.com.au>.
Thanks for the reply Geoff,

Safe to ignore my request/suggestion :)

I meant moreso when the example "exercise/tutorial"  was added to  
jumpstart.
E.g. you've added more AJAX examples in the past couple of months, but  
the onActivate/onPassivate example would be a couple of years old.

and I think I found what I wanted here: http://jumpstart.doublenegative.com.au/bugs_enhancements.html


I was thinking of an on-the-page easy-to-find property like this:

.java
@Property
private Date addedToJumpstart = new Date("2010-07-14");

.tml
This example was added to jumpstart at version $ 
{addedJumpstartVersion} on ${addedJumpstartDate}

;)

Cheers
Chris


On 14/07/2010, at 11:47 PM, Geoff Callender wrote:

> Chris,
>
> Hmmm, I'm always tossing up between keeping the examples simple and  
> making them complete. Your request is pretty compelling so I'll  
> consider it for the next release. In the meantime, here's what I use  
> in simple entities...
>
> 	private java.sql.Timestamp createdAt;
> 	private java.sql.Timestamp modifiedAt;
>
> 	@PrePersist
> 	public void prePersist() throws ValidationException {
> 		validate();
> 		createdAt = new java.sql.Timestamp(System.currentTimeMillis());
> 		modifiedAt = createdAt;
> 	}
>
> 	@PreUpdate
> 	public void preUpdate() throws ValidationException {
> 		validate();
> 		modifiedAt = new java.sql.Timestamp(System.currentTimeMillis());
> 	}
>
> instead of...
>
> 	@PrePersist
> 	@PreUpdate
> 	public void validate() throws ValidationException {
> 		// etc...
> 	}
>
> For entities that have more complex state changes than just create,  
> change, and delete this isn't enough, but that's another story.
>
> HTH,
>
> Geoff
>
> On 14/07/2010, at 10:47 PM, Chris Mylonas wrote:
>
>> Geoff that's a great example of some more advanced layout/theme  
>> possibilities.
>>
>> Sorry to hijack the thread somewhat,
>> Any chance of adding to jumpstart a "Date added" and/or "Last  
>> modified" section to each example?
>>
>>
>> Cheers
>> Chris
>>
>> On 14/07/2010, at 7:01 AM, Geoff Callender wrote:
>>
>>> Can't stop to consider the difference right now (maybe later  
>>> today) but you can see it working in this example:
>>>
>>> 	http://jumpstart.doublenegative.com.au/jumpstart/examples/ajaxcomponentscrud
>>>
>>> HTH,
>>>
>>> Geoff
>>>
>>> On 13/07/2010, at 10:04 PM, Paul Stanton wrote:
>>>
>>>> thanks geoff,
>>>>
>>>> your last post where you put the confirm mixin on a <span> within  
>>>> the <a> is interesting .. wouldn't that be rendered as the  
>>>> equivalent of:
>>>>
>>>> <a ....><span onclick="return confirm('?');">text</span></a>
>>>>
>>>> or at least the prototypesque version of this:
>>>>
>>>> <a ....><span id="spanId">text</span></a>
>>>> Event.observe($("spanId"), 'click', function(e){if (! 
>>>> confirm('?')) e.stop();});
>>>>
>>>> i have tried both of these approaches but neither cancel the  
>>>> event on the <a>... if yours works what is the fundamental  
>>>> difference?
>>>>
>>>> regards, p.
>>>>
>>>> Geoff Callender wrote:
>>>>> http://tapestry-users.832.n2.nabble.com/Confirm-mixin-won-t-cancel-when-in-zone-td5048950.html#a5048950
>>>>>
>>>>> On 13/07/2010, at 12:31 PM, Paul Stanton wrote:
>>>>>
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I was hoping to be able to use a simple js confirm in order to  
>>>>>> (conditionally) cancel the callback from an async event link:
>>>>>>
>>>>>> <a t:type="eventLink" event="DeleteRecord" context="record.id"  
>>>>>> zone="myZone" onclick="return confirm('sure?');">delete</a>
>>>>>>
>>>>>> Unfortunately, even when 'Cancel' is clicked, the callback is  
>>>>>> executed.
>>>>>>
>>>>>> What is the simplest way to add one stage of logic to this  
>>>>>> process?
>>>>>>
>>>>>> Thanks, Paul.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>>
>>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: using a js confirm to cancel an async eventlink

Posted by Chris Mylonas <ch...@mrvoip.com.au>.
jeez, some people are never pleased are they...

ideally, if all the tapestry devs that came before me would have just  
built a drag and drop tapestry gui builder in html5, geoff wouldn't  
have had to build and maintain jumpstart

/ducks

***Thanks for all that came before me on this list***

Cheers
Chris



On 15/07/2010, at 12:23 AM, Erick Erickson wrote:

> Making the enough-but-not-overwhelming decision is always a tough  
> one. What
> *I* want is an example that shows only and exactly what I want to  
> see at the
> moment I'm looking. Oh, and I want it to come up first on whatever  
> vaguely
> related terms I put in a Google search.
>
> I almost forgot; I also want the Jumpstart examples to be cut-n- 
> pasteable
> into whatever code I'm working on... And don't forget to include the  
> test
> cases. Also cut-n-pasteable.
>
> Do you think you'll have time to get around to that soon <G>...
>
> Hmmmm, sounds like what I *really* want is a Tapestry lackey who  
> works for
> free that I can subcontract my work to while I go sailing.
>
> Seriously though, thanks much for your efforts, they've helped me
> enormously.
>
> Best
> Erick
>
> On Wed, Jul 14, 2010 at 9:47 AM, Geoff Callender <
> geoff.callender.jumpstart@gmail.com> wrote:
>
>> Chris,
>>
>> Hmmm, I'm always tossing up between keeping the examples simple and  
>> making
>> them complete. Your request is pretty compelling so I'll consider  
>> it for the
>> next release. In the meantime, here's what I use in simple  
>> entities...
>>
>>       private java.sql.Timestamp createdAt;
>>       private java.sql.Timestamp modifiedAt;
>>
>>       @PrePersist
>>       public void prePersist() throws ValidationException {
>>               validate();
>>               createdAt = new
>> java.sql.Timestamp(System.currentTimeMillis());
>>               modifiedAt = createdAt;
>>       }
>>
>>       @PreUpdate
>>       public void preUpdate() throws ValidationException {
>>               validate();
>>               modifiedAt = new
>> java.sql.Timestamp(System.currentTimeMillis());
>>       }
>>
>> instead of...
>>
>>       @PrePersist
>>       @PreUpdate
>>       public void validate() throws ValidationException {
>>               // etc...
>>       }
>>
>> For entities that have more complex state changes than just create,  
>> change,
>> and delete this isn't enough, but that's another story.
>>
>> HTH,
>>
>> Geoff
>>
>> On 14/07/2010, at 10:47 PM, Chris Mylonas wrote:
>>
>>> Geoff that's a great example of some more advanced layout/theme
>> possibilities.
>>>
>>> Sorry to hijack the thread somewhat,
>>> Any chance of adding to jumpstart a "Date added" and/or "Last  
>>> modified"
>> section to each example?
>>>
>>>
>>> Cheers
>>> Chris
>>>
>>> On 14/07/2010, at 7:01 AM, Geoff Callender wrote:
>>>
>>>> Can't stop to consider the difference right now (maybe later  
>>>> today) but
>> you can see it working in this example:
>>>>
>>>>
>> http://jumpstart.doublenegative.com.au/jumpstart/examples/ajaxcomponentscrud
>>>>
>>>> HTH,
>>>>
>>>> Geoff
>>>>
>>>> On 13/07/2010, at 10:04 PM, Paul Stanton wrote:
>>>>
>>>>> thanks geoff,
>>>>>
>>>>> your last post where you put the confirm mixin on a <span>  
>>>>> within the
>> <a> is interesting .. wouldn't that be rendered as the equivalent of:
>>>>>
>>>>> <a ....><span onclick="return confirm('?');">text</span></a>
>>>>>
>>>>> or at least the prototypesque version of this:
>>>>>
>>>>> <a ....><span id="spanId">text</span></a>
>>>>> Event.observe($("spanId"), 'click', function(e){if (!confirm('?'))
>> e.stop();});
>>>>>
>>>>> i have tried both of these approaches but neither cancel the  
>>>>> event on
>> the <a>... if yours works what is the fundamental difference?
>>>>>
>>>>> regards, p.
>>>>>
>>>>> Geoff Callender wrote:
>>>>>>
>> http://tapestry-users.832.n2.nabble.com/Confirm-mixin-won-t-cancel-when-in-zone-td5048950.html#a5048950
>>>>>>
>>>>>> On 13/07/2010, at 12:31 PM, Paul Stanton wrote:
>>>>>>
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I was hoping to be able to use a simple js confirm in order to
>> (conditionally) cancel the callback from an async event link:
>>>>>>>
>>>>>>> <a t:type="eventLink" event="DeleteRecord" context="record.id"
>> zone="myZone" onclick="return confirm('sure?');">delete</a>
>>>>>>>
>>>>>>> Unfortunately, even when 'Cancel' is clicked, the callback is
>> executed.
>>>>>>>
>>>>>>> What is the simplest way to add one stage of logic to this  
>>>>>>> process?
>>>>>>>
>>>>>>> Thanks, Paul.
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: using a js confirm to cancel an async eventlink

Posted by Erick Erickson <er...@gmail.com>.
Making the enough-but-not-overwhelming decision is always a tough one. What
*I* want is an example that shows only and exactly what I want to see at the
moment I'm looking. Oh, and I want it to come up first on whatever vaguely
related terms I put in a Google search.

I almost forgot; I also want the Jumpstart examples to be cut-n-pasteable
into whatever code I'm working on... And don't forget to include the test
cases. Also cut-n-pasteable.

Do you think you'll have time to get around to that soon <G>...

Hmmmm, sounds like what I *really* want is a Tapestry lackey who works for
free that I can subcontract my work to while I go sailing.

Seriously though, thanks much for your efforts, they've helped me
enormously.

Best
Erick

On Wed, Jul 14, 2010 at 9:47 AM, Geoff Callender <
geoff.callender.jumpstart@gmail.com> wrote:

> Chris,
>
> Hmmm, I'm always tossing up between keeping the examples simple and making
> them complete. Your request is pretty compelling so I'll consider it for the
> next release. In the meantime, here's what I use in simple entities...
>
>        private java.sql.Timestamp createdAt;
>        private java.sql.Timestamp modifiedAt;
>
>        @PrePersist
>        public void prePersist() throws ValidationException {
>                validate();
>                createdAt = new
> java.sql.Timestamp(System.currentTimeMillis());
>                modifiedAt = createdAt;
>        }
>
>        @PreUpdate
>        public void preUpdate() throws ValidationException {
>                validate();
>                modifiedAt = new
> java.sql.Timestamp(System.currentTimeMillis());
>        }
>
> instead of...
>
>        @PrePersist
>        @PreUpdate
>        public void validate() throws ValidationException {
>                // etc...
>        }
>
> For entities that have more complex state changes than just create, change,
> and delete this isn't enough, but that's another story.
>
> HTH,
>
> Geoff
>
> On 14/07/2010, at 10:47 PM, Chris Mylonas wrote:
>
> > Geoff that's a great example of some more advanced layout/theme
> possibilities.
> >
> > Sorry to hijack the thread somewhat,
> > Any chance of adding to jumpstart a "Date added" and/or "Last modified"
> section to each example?
> >
> >
> > Cheers
> > Chris
> >
> > On 14/07/2010, at 7:01 AM, Geoff Callender wrote:
> >
> >> Can't stop to consider the difference right now (maybe later today) but
> you can see it working in this example:
> >>
> >>
> http://jumpstart.doublenegative.com.au/jumpstart/examples/ajaxcomponentscrud
> >>
> >> HTH,
> >>
> >> Geoff
> >>
> >> On 13/07/2010, at 10:04 PM, Paul Stanton wrote:
> >>
> >>> thanks geoff,
> >>>
> >>> your last post where you put the confirm mixin on a <span> within the
> <a> is interesting .. wouldn't that be rendered as the equivalent of:
> >>>
> >>> <a ....><span onclick="return confirm('?');">text</span></a>
> >>>
> >>> or at least the prototypesque version of this:
> >>>
> >>> <a ....><span id="spanId">text</span></a>
> >>> Event.observe($("spanId"), 'click', function(e){if (!confirm('?'))
> e.stop();});
> >>>
> >>> i have tried both of these approaches but neither cancel the event on
> the <a>... if yours works what is the fundamental difference?
> >>>
> >>> regards, p.
> >>>
> >>> Geoff Callender wrote:
> >>>>
> http://tapestry-users.832.n2.nabble.com/Confirm-mixin-won-t-cancel-when-in-zone-td5048950.html#a5048950
> >>>>
> >>>> On 13/07/2010, at 12:31 PM, Paul Stanton wrote:
> >>>>
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> I was hoping to be able to use a simple js confirm in order to
> (conditionally) cancel the callback from an async event link:
> >>>>>
> >>>>> <a t:type="eventLink" event="DeleteRecord" context="record.id"
> zone="myZone" onclick="return confirm('sure?');">delete</a>
> >>>>>
> >>>>> Unfortunately, even when 'Cancel' is clicked, the callback is
> executed.
> >>>>>
> >>>>> What is the simplest way to add one stage of logic to this process?
> >>>>>
> >>>>> Thanks, Paul.
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>
> >>>>
> >>>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
>
>

Re: using a js confirm to cancel an async eventlink

Posted by Geoff Callender <ge...@gmail.com>.
Chris,

Hmmm, I'm always tossing up between keeping the examples simple and making them complete. Your request is pretty compelling so I'll consider it for the next release. In the meantime, here's what I use in simple entities...

	private java.sql.Timestamp createdAt;
	private java.sql.Timestamp modifiedAt;

	@PrePersist
	public void prePersist() throws ValidationException {
		validate();
		createdAt = new java.sql.Timestamp(System.currentTimeMillis());
		modifiedAt = createdAt;
	}

	@PreUpdate
	public void preUpdate() throws ValidationException {
		validate();
		modifiedAt = new java.sql.Timestamp(System.currentTimeMillis());
	}

instead of...

	@PrePersist
	@PreUpdate
	public void validate() throws ValidationException {
		// etc...
	}

For entities that have more complex state changes than just create, change, and delete this isn't enough, but that's another story.

HTH,

Geoff

On 14/07/2010, at 10:47 PM, Chris Mylonas wrote:

> Geoff that's a great example of some more advanced layout/theme possibilities.
> 
> Sorry to hijack the thread somewhat,
> Any chance of adding to jumpstart a "Date added" and/or "Last modified" section to each example?
> 
> 
> Cheers
> Chris
> 
> On 14/07/2010, at 7:01 AM, Geoff Callender wrote:
> 
>> Can't stop to consider the difference right now (maybe later today) but you can see it working in this example:
>> 
>> 	http://jumpstart.doublenegative.com.au/jumpstart/examples/ajaxcomponentscrud
>> 
>> HTH,
>> 
>> Geoff
>> 
>> On 13/07/2010, at 10:04 PM, Paul Stanton wrote:
>> 
>>> thanks geoff,
>>> 
>>> your last post where you put the confirm mixin on a <span> within the <a> is interesting .. wouldn't that be rendered as the equivalent of:
>>> 
>>> <a ....><span onclick="return confirm('?');">text</span></a>
>>> 
>>> or at least the prototypesque version of this:
>>> 
>>> <a ....><span id="spanId">text</span></a>
>>> Event.observe($("spanId"), 'click', function(e){if (!confirm('?')) e.stop();});
>>> 
>>> i have tried both of these approaches but neither cancel the event on the <a>... if yours works what is the fundamental difference?
>>> 
>>> regards, p.
>>> 
>>> Geoff Callender wrote:
>>>> http://tapestry-users.832.n2.nabble.com/Confirm-mixin-won-t-cancel-when-in-zone-td5048950.html#a5048950
>>>> 
>>>> On 13/07/2010, at 12:31 PM, Paul Stanton wrote:
>>>> 
>>>> 
>>>>> Hi all,
>>>>> 
>>>>> I was hoping to be able to use a simple js confirm in order to (conditionally) cancel the callback from an async event link:
>>>>> 
>>>>> <a t:type="eventLink" event="DeleteRecord" context="record.id" zone="myZone" onclick="return confirm('sure?');">delete</a>
>>>>> 
>>>>> Unfortunately, even when 'Cancel' is clicked, the callback is executed.
>>>>> 
>>>>> What is the simplest way to add one stage of logic to this process?
>>>>> 
>>>>> Thanks, Paul.
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>> 
>>>> 
>>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
> 


Re: using a js confirm to cancel an async eventlink

Posted by Chris Mylonas <ch...@mrvoip.com.au>.
Geoff that's a great example of some more advanced layout/theme  
possibilities.

Sorry to hijack the thread somewhat,
Any chance of adding to jumpstart a "Date added" and/or "Last  
modified" section to each example?


Cheers
Chris

On 14/07/2010, at 7:01 AM, Geoff Callender wrote:

> Can't stop to consider the difference right now (maybe later today)  
> but you can see it working in this example:
>
> 	http://jumpstart.doublenegative.com.au/jumpstart/examples/ajaxcomponentscrud
>
> HTH,
>
> Geoff
>
> On 13/07/2010, at 10:04 PM, Paul Stanton wrote:
>
>> thanks geoff,
>>
>> your last post where you put the confirm mixin on a <span> within  
>> the <a> is interesting .. wouldn't that be rendered as the  
>> equivalent of:
>>
>> <a ....><span onclick="return confirm('?');">text</span></a>
>>
>> or at least the prototypesque version of this:
>>
>> <a ....><span id="spanId">text</span></a>
>> Event.observe($("spanId"), 'click', function(e){if (!confirm('?'))  
>> e.stop();});
>>
>> i have tried both of these approaches but neither cancel the event  
>> on the <a>... if yours works what is the fundamental difference?
>>
>> regards, p.
>>
>> Geoff Callender wrote:
>>> http://tapestry-users.832.n2.nabble.com/Confirm-mixin-won-t-cancel-when-in-zone-td5048950.html#a5048950
>>>
>>> On 13/07/2010, at 12:31 PM, Paul Stanton wrote:
>>>
>>>
>>>> Hi all,
>>>>
>>>> I was hoping to be able to use a simple js confirm in order to  
>>>> (conditionally) cancel the callback from an async event link:
>>>>
>>>> <a t:type="eventLink" event="DeleteRecord" context="record.id"  
>>>> zone="myZone" onclick="return confirm('sure?');">delete</a>
>>>>
>>>> Unfortunately, even when 'Cancel' is clicked, the callback is  
>>>> executed.
>>>>
>>>> What is the simplest way to add one stage of logic to this process?
>>>>
>>>> Thanks, Paul.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: using a js confirm to cancel an async eventlink

Posted by Geoff Callender <ge...@gmail.com>.
Can't stop to consider the difference right now (maybe later today) but you can see it working in this example:

	http://jumpstart.doublenegative.com.au/jumpstart/examples/ajaxcomponentscrud

HTH,

Geoff

On 13/07/2010, at 10:04 PM, Paul Stanton wrote:

> thanks geoff,
> 
> your last post where you put the confirm mixin on a <span> within the <a> is interesting .. wouldn't that be rendered as the equivalent of:
> 
> <a ....><span onclick="return confirm('?');">text</span></a>
> 
> or at least the prototypesque version of this:
> 
> <a ....><span id="spanId">text</span></a>
> Event.observe($("spanId"), 'click', function(e){if (!confirm('?')) e.stop();});
> 
> i have tried both of these approaches but neither cancel the event on the <a>... if yours works what is the fundamental difference?
> 
> regards, p.
> 
> Geoff Callender wrote:
>> http://tapestry-users.832.n2.nabble.com/Confirm-mixin-won-t-cancel-when-in-zone-td5048950.html#a5048950
>> 
>> On 13/07/2010, at 12:31 PM, Paul Stanton wrote:
>> 
>>  
>>> Hi all,
>>> 
>>> I was hoping to be able to use a simple js confirm in order to (conditionally) cancel the callback from an async event link:
>>> 
>>> <a t:type="eventLink" event="DeleteRecord" context="record.id" zone="myZone" onclick="return confirm('sure?');">delete</a>
>>> 
>>> Unfortunately, even when 'Cancel' is clicked, the callback is executed.
>>> 
>>> What is the simplest way to add one stage of logic to this process?
>>> 
>>> Thanks, Paul.
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>> 
>>>    
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>> 
>> 
>>  


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: using a js confirm to cancel an async eventlink

Posted by Paul Stanton <pa...@mapshed.com.au>.
thanks geoff,

your last post where you put the confirm mixin on a <span> within the 
<a> is interesting .. wouldn't that be rendered as the equivalent of:

<a ....><span onclick="return confirm('?');">text</span></a>

or at least the prototypesque version of this:

<a ....><span id="spanId">text</span></a>
Event.observe($("spanId"), 'click', function(e){if (!confirm('?')) 
e.stop();});

i have tried both of these approaches but neither cancel the event on 
the <a>... if yours works what is the fundamental difference?

regards, p.

Geoff Callender wrote:
> http://tapestry-users.832.n2.nabble.com/Confirm-mixin-won-t-cancel-when-in-zone-td5048950.html#a5048950
>
> On 13/07/2010, at 12:31 PM, Paul Stanton wrote:
>
>   
>> Hi all,
>>
>> I was hoping to be able to use a simple js confirm in order to (conditionally) cancel the callback from an async event link:
>>
>> <a t:type="eventLink" event="DeleteRecord" context="record.id" zone="myZone" onclick="return confirm('sure?');">delete</a>
>>
>> Unfortunately, even when 'Cancel' is clicked, the callback is executed.
>>
>> What is the simplest way to add one stage of logic to this process?
>>
>> Thanks, Paul.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>     
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>   

Re: using a js confirm to cancel an async eventlink

Posted by Geoff Callender <ge...@gmail.com>.
http://tapestry-users.832.n2.nabble.com/Confirm-mixin-won-t-cancel-when-in-zone-td5048950.html#a5048950

On 13/07/2010, at 12:31 PM, Paul Stanton wrote:

> Hi all,
> 
> I was hoping to be able to use a simple js confirm in order to (conditionally) cancel the callback from an async event link:
> 
> <a t:type="eventLink" event="DeleteRecord" context="record.id" zone="myZone" onclick="return confirm('sure?');">delete</a>
> 
> Unfortunately, even when 'Cancel' is clicked, the callback is executed.
> 
> What is the simplest way to add one stage of logic to this process?
> 
> Thanks, Paul.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org