The JavaScript is a bit in flux right now; I'm gradually creating new stable APIs under the T5 namespace, along with a publish/subscribe system to let components work together without explicit binding. In any case, this effort will continue past 5.3 and into 5.4.
That's not an answer, it's just a promise that in 5.4 it will be very, very easy to do what you want. On Thu, Jul 28, 2011 at 2:14 AM, Denis Stepanov <[email protected]> wrote: > Hi, > > It would be nice if there was a way how to trigger a multi zone update on the > client side, waiting for all zone updates to render in one request could take > too long and sometimes it's better to display refreshing zones to the user. Well, you could have a Zone render a ProgressiveDisplay component around your content, that will defer the expensive rendering to yet another request. > > Our simple implementation returns JS code which then triggers zone updates, > because of that it would be nice to have a default event from the Zone > component to refresh its content, also there could be a "pregressive" > parameter which will load it's content after render and it will eleminate the > need for the PregressiveDisplay. > > Denis > > > On Jul 28, 2011, at 4:52 AM, Howard Lewis Ship wrote: > >> On Wed, Jul 27, 2011 at 7:47 PM, Taha Hafeez <[email protected]> >> wrote: >>> Hi Howard >>> >>> The lesson is, don't submit a patch for Howard's jira he will always >>> come up with a better implementation :) >> >> That's not exactly the best lesson! >> >>> >>> regards >>> Taha >>> >>> On Thu, Jul 28, 2011 at 8:10 AM, Howard Lewis Ship <[email protected]> wrote: >>>> On Wed, Jul 27, 2011 at 4:26 PM, Taha Hafeez <[email protected]> >>>> wrote: >>>>> Nice !! >>>>> >>>>> I learned my lesson :) >>>>> >>>> >>>> What lesson would that be? I just had a slightly different vision of >>>> how this would fit in overall and how it would be implemented. The >>>> only concrete advantage is that on a zone update you can still return >>>> the content for the (implicit) zone to be updated along with updates >>>> to other zones explicitly. >>>> >>>>> regards >>>>> Taha >>>>> >>>>> On Thu, Jul 28, 2011 at 1:16 AM, Howard M. Lewis Ship (JIRA) >>>>> <[email protected]> wrote: >>>>>> >>>>>> [ >>>>>> https://issues.apache.org/jira/browse/TAP5-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071942#comment-13071942 >>>>>> ] >>>>>> >>>>>> Howard M. Lewis Ship commented on TAP5-1476: >>>>>> -------------------------------------------- >>>>>> >>>>>> Sorry I didn't use your patch, but I think you'll like the end result. >>>>>> >>>>>>> Deprecate MultiZoneUpdate, replace with an injectable service to >>>>>>> collect zone updates >>>>>>> ------------------------------------------------------------------------------------- >>>>>>> >>>>>>> Key: TAP5-1476 >>>>>>> URL: https://issues.apache.org/jira/browse/TAP5-1476 >>>>>>> Project: Tapestry 5 >>>>>>> Issue Type: Improvement >>>>>>> Components: tapestry-core >>>>>>> Affects Versions: 5.3 >>>>>>> Reporter: Howard M. Lewis Ship >>>>>>> Assignee: Howard M. Lewis Ship >>>>>>> Fix For: 5.3 >>>>>>> >>>>>>> Attachments: zone-updater.patch, >>>>>>> zone_updater_with_zone-updater_as_return.patch, >>>>>>> zone_updater_with_zone-updater_as_return.patch >>>>>>> >>>>>>> >>>>>>> MultiZoneUpdate presumes that there's a single place where all the zone >>>>>>> to be updated are known. This is not necessarilly the case. >>>>>>> I'd like to see something like: >>>>>>> @Inject >>>>>>> private ZoneUpdater zoneUpdater(); >>>>>>> Object onSuccess() >>>>>>> { >>>>>>> zoneUpdater.update("foo", fooBlock); >>>>>>> zoneUpdater.update("bar", barBlock); >>>>>>> return myZone.getBody(); >>>>>>> } >>>>>>> The main point here is that different event handlers would all be able >>>>>>> to invoke ZoneUpdater.update() . >>>>>>> This would also allow a single response to render main content (for the >>>>>>> requesting Zone on the client) plus zone updates to named zones. >>>>>> >>>>>> -- >>>>>> This message is automatically generated by JIRA. >>>>>> For more information on JIRA, see: http://www.atlassian.com/software/jira >>>>>> >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Howard M. Lewis Ship >>>> >>>> Creator of Apache Tapestry >>>> >>>> The source for Tapestry training, mentoring and support. Contact me to >>>> learn how I can get you up and productive in Tapestry fast! >>>> >>>> (971) 678-5210 >>>> http://howardlewisship.com >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> >> >> -- >> Howard M. Lewis Ship >> >> Creator of Apache Tapestry >> >> The source for Tapestry training, mentoring and support. Contact me to >> learn how I can get you up and productive in Tapestry fast! >> >> (971) 678-5210 >> http://howardlewisship.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
