* CellCall and CellReturn
The Manage example could be implemented in a different way as well:
<span jwcid="@Cell">
<span jwcid="[EMAIL PROTECTED]:Table" source="ognl:source" columns="...,
!edit">
...
<span jwcid="[EMAIL PROTECTED]">
<span jwcid="@CellCall" go="EditValue"
call:valueParam="ognl:
components.table.tableValue">Edit</span>
</span>
</span>
</span>
Here, CellLink is replaced with CellCall and everything else is (almost)
the same. The implementation of the EditValue component is different
however. In the original example, EditValue must have a CellLink that
returns to the core Manage component and therefore it will be tied to
Manage. With CellCall invocation it will have a CellReturn instead of a
CellLink in its template which will return it to the place that invoked
it. As such, it will not be tied to Manage at all -- other places in the
application can use that component as well.
Perhaps other parameters to CellCall will be useful as well, such as
'returnListener' and 'returnGo', for example -- a listener that will be
invoked when the call is returned and a target that will transitioned to
under the same circumstances.
-mb
Mind Bridge wrote:
Hi,
Since values can be stored on the client (in URLs or hidden fields) T4
allows some rather nifty things to be implemented. I had been planning
to create a library of components that provide some of the features
for many months now, but unfortunately I simple lack the time to
concentrate on the development.
Some of the topics discussed in this forum are related to what I would
like to do, so I will describe my suggestions here in the hope that
they may be useful.
* Local links
Currently it is not natural to create complex components that consist
of several screens. For example, one should be able to easily create a
component that provides CRUD functionality for editing the contents of
the list:
<span jwcid="@Manage" source="ognl: objects"
createType="org.mb.manage.Example"/>
The idea is that the Manage component should have several screens:
- list elements
- create new element
- edit element
- confirm delete
Trails provides a similar ability (plus storing the data into a
database), but its implementation (not its use) has to jump through
hoops to achieve it -- it is certainly possible, but not
straight-forward.
One simple reason that links in Tapestry operate on the level of the
page, but there are no standard link components that operate on the
level of a section of the page. If it is possible to use this ability
(which I termed in my work "Cell"), one could implement Manage like this:
<span jwcid="@Cell">
<span jwcid="[EMAIL PROTECTED]:Table" source="ognl:source"
columns="name:toString(), !edit">
...
<span jwcid="[EMAIL PROTECTED]">
<span jwcid="@CellLink" go="editValue"
link:valueParam="ognl:
components.table.tableValue">Edit</span>
</span>
</span>
</span>
There are several things to note in this example:
- CellLink is similar to a DirectLink, but it only operates on the
Cell in which it is placed (or on another Cell which can be passed as
a parameter). Everything else outside the Cell remains the same --
there are no page changes.
- If CellLink has a listener (like a DirectLink), then the listener
will be invoked and it can change the component displayed in the
selected Cell. In this case, however, the 'go' parameter is used
instead which is analogous to the listener returning a given value.
Basically the 'go' parameter in here says to go to the 'editValue'
component (or Block).
- The "link:valueParam" essentially says that the current table value
must be passed to the valueParam parameter of the component. In this
case this allows the editValue component to be rendered correctly with
the provided table value. The combination of "go" and "link:<param>"
allow the user to perform functions that would otherwise require code
to complete. (Note that "link:<param>" requires the value to be stored
using client-side property)
There are a number of other items that I want to mention in relation
to Cell, such as the CellCall and the CellReturn components, page flow
(and no, the current solutions are fundamentally limited I believe),
page parameters, etc, but I will write about them later.
A part of this functionality is strongly related to Ajax and is
already implemented in Tacos. This approach must be able to operate
correctly w/o JavaScript as well, however. So Ajax is not the core,
but simply a way to help the operation.
Since I do not have the ability to work on the ideas at the moment,
please feel free to implement the above if the ideas seem reasonable
and useful to you...
Best regards,
- mb
---------------------------------------------------------------------
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]
