On Wed, 05 Jan 2011 21:58:15 -0200, Paul Stanton <p...@mapshed.com.au>
wrote:
1. Using the zone parameter to flag an event as XHR
To specify that you want to perform an XHR request (EventLink,
ActionLink, Form etc), you need to supply the zone parameter. The
existence of this parameter is a flag that tells the component to use
XHR. In some cases this may be useful (although I'm yet to find one).
This strikes me as bad design since there is not necessarily a known
One-to-One relationship between the event and the zone(s) updated.
Since all of my XHR event handlers return a MultiZoneUpdate, I ended up
creating a dummy zone on every page and component and supplying that to
every zone parameter. The dummy zone was always hidden and never
actually updated. This hack made it easier to code and maintain my pages.
As far as I know, when you return a MultiZoneUpdate, the value passed to
the zone parameter is completely ignored, so there's no need to create a
dummy zone.
Obviously an improvement would be to add a 'xhr' parameter to the
components (EventLink, Form etc) and for zone to be an optional
parameter if xhr is true. You could even hard set xhr=true if zone !=
null for backwards compatibility.
That's a good point.
I would suggest the refactoring of MultiZoneUpdate so that it
1. can be constructed without a zone update request
2. keys updates by zoneId (no point performing multiple updates on a
single zone)
3. behaves as if 'null' was returned (from the event handler) if it
is returned with no zone updates
I don't see any reason why this couldn't be backwards compatible.
That's another good point.
3. XHR requests should be easily callable from javascript
I quite often needed to initialise an XHR request-response from
javascript. I ended up writing a function to facilitate this. It handles:
1. the zone wiring (note the need for a dummy zone shows up here too)
2. context parameters (unfortunately does not properly conform to
encoding rules as per server side generated params)
3. query strings (sometimes useful)
4. url based session ids (for when cookies are disabled)
This is a very good point. It was raised before in this list. Inge Solvol
posted some examples here: http://tinybits.blogspot.com. Of course, it
would be very nice to have them in Tapestry itself.
Do you give us permission to use it in Tapestry itself if the team
approves your code?
For the most part, tapestry has been a breeze to work with, however It
would be easier to continue developing complicated ajax applications
with these few changes. I hope I can either be pointed in a better
direction, or that these ideas are considered in future releases.
Contributions, including feedback, are always welcome. They help a lot to
know what people want and need, as nobody can foresee everything that
could improve the framework. ;)
Feel free to file a JIRA for your suggestions.
--
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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
