Jesse Kuhnert wrote:
Those sound like requirements :)
This is good, I hadn't fully attacked/handled widget support yet (hence the
lack of seeing very many), but I'd love to be able to pick your brain about
more specifics of what/how/why you are doing some of the things with your
widgets. (If it's not a public sort of thing you can email me off list).
thanx jesse,
The most simple example here is a selection of a table row. We use
tables extensivly, and one of the most common actions is selecting a
table row by clicking on it.
What the user sees is that the row is selected (a class name is added,
and removed somewhere else, the background color changes) - but actually
the row widget sends a request to the server - using a plain tapestry
listener url. the listener method changes the application state and then
renders a
<perform><action do="selectRow"><param>true</param></action></perform>
the row widget recieves this xml, lets dojo parse it and invokes all
<action> elements in it, in this case the selectRow method.
So I don't need to generate javascript from tapestry. ever. Everything
is a widget and an rpc. I find it very comfortable and clean, and since
the widget is corresponding with its tapestry component, the tapestry
component just has to "know" the widget (which actions it supports).
Its really like two systems (tapestry and dojo) work together through an
API. I find the tap4.1 way of using dojo is very much event oriented,
while the way I use dojo is very much encapsulating everything inside
widgets.
One of the common actions, which is implemented in a base widget from
which all inherit is a "replaceById" - and there are some other like
"redirect" and so on.
Going back to the example above:
It seems very very easy to create from tapestry the event TR.onclick but
how to I render the response?
At the moment I would guess that I have to generate some javascript from
tapestry which does the work, don't I ?
Cheers,
Ron
The format is currently "similar" to tacos, though handled a little
differently.
The client side file that handles the xml-rpc sort of calls is
http://svn.apache.org/viewvc/tapestry/tapestry4/trunk/tapestry-framework/src/js/tapestry/core.js?view=markup.
The element types/id's mostly come from the ResponseBuilder interface,
http://tapestry.apache.org/tapestry4.1/tapestry-framework/apidocs/org/apache/tapestry/services/ResponseBuilder.html
.
I don't know if I can promise anything this extensive being done in one
weekend but the more input I can get the better. (for day to day
pondering's
sake )
On 8/2/06, Ron Piterman <[EMAIL PROTECTED]> wrote:
Hi,
In an application I am currently working on (tapestry 4.0) we use
extensivley dojo widgets and a custom ajax render cycle.
Usually the Ajax responses are rendered by a special renderer which
wrapps components renders inside a kind of xml-rpc. This is parsed by
java scripts and performs different actions:
It looks something like:
<action do="replaceRow"><tr hash="..." dojoType="..."><td>...
and so on.
The nice thing is, the widget that sends the request handles the
response, so one can call from inside tapestry methods on the widgets,
passing component render-results as parameters.
Now as far as I understand from the docu, tapestry 4.1 contains one very
important method for ajax response: ResponseBuilder.updateComponent(...)
this will end in a replace-by-id, which is quite trivial - but what is
the tap4.1 way of doing other things like openning a dojo dialog,
changing status of existing widgets (and thus the under- or overlying
html) and so on? Do I have to write javascript templates for all of
those actions?
As far as can remember from tacos, the ajax response was also a sort of
xml-rpc, handled by the tacos JS library. I would guess it was
"imported" into tap4.1 - is there an overview of this somewhere? (how
the response should look like ...) - more under the hood as in the
existing docu?
Thanx for reading that long ;)
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]
