Oh, I think I'm starting to understand what the you've been talking
about, maybe.. or maybe I'm just seeing what I want to see. :)
> - Ability to use not only Blocks, but also other independent components
> that are not placed into a holding pages. In other words it requires to
> load components in a similar way pages are loaded (this is usually
> requested for the wrong reasons, but it is quite necessary in some cases)
This sounds kinda like what I would want as well... The thing is that I
am playing with Client-Side-Include of html fragments. What I had to do
was to create pages to output the html fragment, then the CSI would load
and insert that page ( it's actually really cool, you can have a look at
http://www.protrade.com lower left to see it in action ). But I thought
it would have been better if I could have called a component both as a
page or a component, without me having to create a component, then a
thin wrapper page. So that the CSI Component could decide whether to
insert the content directly while rendering the page ( treat it as
component ), or load it from the client-side like a page...
anyhow.. is this anything close to what you're talking about???
ps - if anyone is interested in protrade.com 's client-side-include
stuff, I can talk more about it, 3 easy components, and I can start to
do some interesting things :) Like cache parts of the page differently.
And even cache the whole page, and only load the user specific
sidebar.. etc etc. I even worked out a simple ajax operations by having
the system reload the CSI part once I click on a button..
Mind Bridge wrote:
Hi Andreas,
I am aware of AjaxDirectLink and have been following it for quite a
while. I do think it is a great first step and is the logical base to
implement a part of the functionality.
Nevertheless, a number other ideas are described here:
- Ability to use not only Blocks, but also other independent components
that are not placed into a holding pages. In other words it requires to
load components in a similar way pages are loaded (this is usually
requested for the wrong reasons, but it is quite necessary in some cases)
- Ability to define parameters of the above components using
link:<parameter>.
- The 'go' parameter, as you mentioned
- The support for call and return transitions
The most important issue is that this functionality can be used in a
straight-forward and natural way.
Andreas Andreou wrote:
Interesting ideas here...
And CellLink is really a tacos:AjaxDirectLink (with a go parameter),
which
works correctly even with javascript disabled...
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]
---------------------------------------------------------------------
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]
