+1. Voted.
On Jan 12, 2012, at 3:28 AM, Paul Stanton <p...@mapshed.com.au> wrote:
> Igor,
>
> The zone wildcard idea is a bit flawed in that this 'should' work without any
> zones on the page whatsoever. A zone update is not required for
> AjaxResponseRenderer to be valid, therefore relying on a zone being present
> is illogical.
>
> While a rare case, what would be wrong with executing an eventlink (or the
> like) who's event handler just adds a script command to the
> AjaxResponseRenderer?
>
> tml:
>
> <a t:type="eventlink" event="click" xhr="true">click</a>
>
> java:
>
> private void onClick()
> {
> ajaxResponseRenderer.addCallback(new JavaScriptCallback() {
> @Override
> public void run(JavaScriptSupport javascriptSupport) {
> javascriptSupport.addScript("alert('hello');");
> }
> });
> }
>
> As I mention in the Jira issue (which you should all vote for) you could
> easily ensure backwards compatibility with some simple logic, ie:
> isXhr = xhrParam || zoneParam != null
>
> The problem is that the whole reliance on ZoneManager (tapestry.js) for ajax
> response processing is out dated. Its left over from the initial architecture
> that an event was tied to a single zone for request/response handling.
>
> In my opinion Tapestry.ajaxRequest (or alternative) should be able to handle
> anything AjaxResponseRenderer can throw back at it.
>
> If this were fixed, it would also resolve my other pet hate - the inability
> to initialise an xhr request (who's handler makes use of
> AjaxResponseRenderer) from script without linking to a zone/ZoneManager.
>
> I love tapestry but I hate this feature of it.
>
> Regards, Paul.
>
> On 6/01/2012 9:22 AM, Paul Stanton wrote:
>> +1 vote for this, I previously raised this last January.
>>
>> https://issues.apache.org/jira/browse/TAP5-1404
>>
>> On 6/01/2012 7:37 AM, Igor Drobiazko wrote:
>>> This not a good idea, as we consequently would need to provide
>>> AjaxActionLink, AjaxPageLink, AjaxForm, etc.
>>>
>>> On Thu, Jan 5, 2012 at 9:02 PM, Muhammad Gelbana<m.gelb...@gmail.com>wrote:
>>>
>>>> Or maybe a whole new component with a whole different name ? Instead of
>>>> EventLink we can have AjaxEventLink or something..just an idea.
>>>> I bet you will find this page very interesting Lance
>>>> http://tawus.wordpress.com/2011/10/01/tapestry-5-3-new-features-part-2/ It
>>>> demonstrates many different flavors of ajax calls in tapestry.
>>>>
>>>> On Thu, Jan 5, 2012 at 8:09 PM, Dragan Sahpaski
>>>> <dragan.sahpa...@gmail.com>wrote:
>>>>
>>>>> On Thu, Jan 5, 2012 at 5:35 PM, Igor Drobiazko<igor.drobia...@gmail.com
>>>>>> wrote:
>>>>>> Maybe we should reuse zone paramater by passing a special zone id like
>>>>>> zone="*". There is already a special id ^, which means the first
>>>>> container
>>>>>> zone.
>>>>>>
>>>>> I like this idea.
>>>>> I''m using "^" a lot so at least for me it's a good concept.
>>>>>
>>>>> Cheers
>>>>>
>>>>>
>>>>>> On Thu, Jan 5, 2012 at 2:40 PM, Lance Java<lance.j...@googlemail.com
>>>>>>> wrote:
>>>>>>> Correct me if I'm wrong but currently, if you want an eventlink to
>>>> use
>>>>>>> ajax, you must provide a "zone" parameter. This may have been fine in
>>>>>> early
>>>>>>> versions of tapestry 5 but there are now circumstances where we want
>>>> an
>>>>>>> eventlink to be done via XHR but shouldn't need to specify a zone in
>>>>> the
>>>>>>> tml. These include:
>>>>>>>
>>>>>>> 1. MultiZoneUpdate where the zone(s) are determined in the event
>>>>> handler
>>>>>>> 2. AjaxResponseRenderer where zone updates and javascript execs can
>>>> be
>>>>>>> invoked in the event handler
>>>>>>>
>>>>>>> As a suggestion, eventlink could have a new boolean parameter for
>>>> ajax
>>>>>>> eg<t:eventlink event="foo" ajax="true" />
>>>>>>>
>>>>>>> Should I raise a JIRA for this?
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best regards,
>>>>>>
>>>>>> Igor Drobiazko
>>>>>> http://tapestry5.de
>>>>>> http://twitter.com/drobiazko
>>>>>>
>>>>
>>>>
>>>> --
>>>> *Regards,*
>>>> *Muhammad Gelbana
>>>> Java Developer*
>>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
