Thanx Jesse,
There are two things I did implement, which currently I can not see
being done with 4.1 (but mayby I am wrong there).
1. Performing callbacks on widgets
We need to perform callbacks on widgets. Specifically: On the widget
that generated the request (the event's source).
The callbacks contain parameters which are either strings or html
node-sets (rendered by tapestry components).
2. Inserting new HTML in a specific place in the html
This we call a "window": Some HTML which is coming from some tapestry
page and is inserted in a specific place in the html.
Its not a dojo dialog, nor a dojo window, it can not be implemented by
refreshing a component, since it comes from another tapestry page.
---
So thats the problem - I would have also a solution ( an idee for a
patch ) - but maybe the current system already covers this use-cases,
and I didn't know.
Another thing which I miss is making event listeners disabled and
enabled, and only active when a certain condition is met. ( This is a
usecase I actually have ).
Cheers,
Ron
Jesse Kuhnert wrote:
Hi Ron,
I definitely welcome any feedback people may have.
It's obvious that I haven't spent nearly as much time on components/widgets
as I have been on general infrastructure.
If you have a specific problem or two in mind I can try to come up with
solutions, but with only solutions I'm going to have a hard time
visualizing
everything properly.
Please feel free to chirp up with more specifics, I do value your input
very
much. (as you have been doing this for as long as I have I think ..)
On 8/22/06, Ron Piterman <[EMAIL PROTECTED]> wrote:
Hi all -
The 4.1 version seems very exciting: the @EventListener annotation is
really cool and easy to use.
Currently I am working on a Project with a very extensive use of XHR
using Dojo and currently Tapestry 4.0
In evaluating 4.1 it seems to me, a great work has been done to enable
render and process XHRs - it seems to me however that some *abstraction*
and *extensibility* is missing.
Talking concrete:
The ResponseBuilder (Dojo, Default, JSON) are built around an Interface
that enables these three.
The Tapestry Javascript Response renderer (tapestry.load) handles a few
actions : JavaScript processing and "replace by id".
I would suggest making both response builder implementations and
tapestry.load more extendable, adding pluggable actions to both.
Cheers,
Ron
---------------------------------------------------------------------
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]
