You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Mind Bridge <mi...@yahoo.com> on 2005/05/15 17:31:05 UTC
[DISCUSS] Page prameters, links to properties, call transitions, units, etc
Hi guys,
Normally I would send separate emails for these things, but they are so
interconnected to each other that I think it is best if they come in one
package. Sorry for the lenght...
Please indicate what you think about them. If there are no overly negative
comments or modification suggestions, I will start adding them soon.
PAGE PARAMETERS
At the moment, pages cannot have parameters. In reality, however, pages do
have parameters even now.
Here is a frequent example. (for clarity, let's call the current page
UserPage and let the code below be an excerpt of UserPage.java)
One very typical occurrence in Tapestry applications is code like this
(usually in the listeners):
ShowAddress page = (ShowAddress) getPage("ShowAddress");
page.setUser(user);
page.setEmail(email);
cycle.activate(page);
Note that User and Email are essentially parameters of ShowAddress. They
could be declared in the ShowAddress.page file as parameters of that page
(this was not allowed until now):
<parameter name="user"/>
<parameter name="email"/>
The above code is essentially a transition from UserPage to ShowAddress upon
a particular activity. That could be declared in UserPage like this:
<transition name="address" page="ShowAddress">
<binding name="user" expression="user.name"/>
<binding name="email" expression="user.email"/>
</transition>
That transition could then be invoked in a way similar to this:
<a jwcid="@DirectLink" listener="transition: address">...</a>
Nevertheless, I find the following approach more flexible and thus
preferable, even though it involves a new parameter to the link components:
<a jwcid="@DirectLink" listener="someListener" transition="address">...</a>
Here both 'listener' and 'transition' are optional. If both are defined,
then the listener is invoked before the specified transition is performed,
otherwise only one of them is called.
It was logical to some extent for pages not to have parameters earlier.
Contrast pages with components: the parameters for components were in the
application code and if, for example, a required parameter is not passed,
that is a clear bug that comes within the application. Its fix can be relied
upon in the future.
The page parameters will come from the outside however, specifically from
the request to the server. That means that such an exception can no longer
be labeled simply as a 'bug', but could be a malicious or accidental
tampering instead. This is particularly true of required parameters - they
may simply be omitted. As a result, it is necessary to think whether a page
can have required parameters.
On the other hand, it seems to me that it is easy to invoke an exception in
the application anyway by simply generating a URL that does not provide a
parameter in the proper squeezing format. Thus, I do not see a reason for
required parameters to be removed here. Perhaps an easy page-specific
exception handler may be helpful, although the general exception handler
could be overridden to do a good job as well.
DIRECT LINK WITH PROPERTIES
Currently, DirectLink passes its parameters via an array and
getServiceParameters() needs to be invoked to the get them in the listener
(some improvements have been made in 4.0, but the principle is the same).
While there is a clear need for this approach, I would suggest DirectLink to
be able to store some parameters in the component's properties as well. No
listener should be required.
Also, I do not think having a fixed list of informal parameters such as
onKeyPress to separate them from the parameters is a good idea for a number
of reasons. Instead, in the interest of world peace and backward
compatibility, I think namespaces should be used here.
For example, if UserPage was to provide the selection of a user out of a
list, the above example could be implemented like this:
<span jwcid="for@For" source="users">
<a jwcid="@DirectLink" property:user="components.for.value" transition="
ShowAddress"> . </a>
</span>
<transition name="address" page="ShowAddress">
<binding name="user" expression="user.name"/>
<binding name="email" expression="user.email"/>
</transition>
To put the example in words, DirectLink will squeeze the currently iterated
user into the link it generates. If the link is invoked, it will set the
'user' property of the page and will then invoke the transition to the
ShowAddress page.
As you can see, this is simple and no Java code is required. The 'transition
' here is just an example, this method for setting parameters could be used
in a number of different ways as well.
A similar property-setting scheme could be applied to ExternalLink, etc.
CALL TRANSITIONS
Very often it is necessary for the user to perform an action, such as to
select an item from a list. This same action may be invoked from a number of
different places in the application, however, and the control has to return
to the place where it originally came from. In the programming world there
is a simple mechanism to achieve this - functions. In the web world,
however, there is no good way to that without custom code.
Let's use the name "call transitions" to denote a special type of
transitions that allow you to invoke a particular page and then return back
from it with results. Here is an example: suppose that you have a web store
application. On a number of different places in the application you would
want the user to select a product so that you can do something with it (view
its details, purchase it, etc).
Here is some simple code in pages like Basket that could achieve that:
<a jwcid="@DirectLink" transition="select">Add a product to basket</a>
<!-SelectProduct will return the selection in the 'product' property and the
handleSelectedProduct listener will be called when that happens -->
<call-transition name="select" page="SelectProduct" listener="
handleSelectedProduct">
<binding name="product" expression="product"/>
</transition>
In SelectProduct.page define:
<parameter name="product"/>
And when a product is selected in SelectProduct and you can get back to the
caller, simply invoke the predefined transition "return" to get back to the
page that called us in the first place, e.g.:
in SelectProduct.html:
<span jwcid="for@For" source="products">
<a jwcid="@DirectLink" property:product="components.for.value" transition="
return"> . </a>
</span>
SelectProduct could then be invoked whenever a particular part of the
application needs the user to select a product and the framework will return
to the invoker with the result.
Note that since Tapestry parameters are read/write, the return values, such
as 'product', are also defined as parameters of the page - there is no need
for a different specification type.
STACK
In order for call transitions to work, it is necessary for the framework to
keep a stack in order to determine where to return from a call. The
explanation of how everything would work so that it is Back-button resistant
turned out to be rather long, so I am cutting that part out - may post
another message about it if there is interest. Here are the important points
however:
- The stack needs to be kept in some form both in the request (URL) and in
the session (if any) to avoid funny effects when Back is used. At the moment
only persistent properties may be placed in URL, but I would like us to have
a mechanism that allows a service to be injected and place relevant
information on the URL. The stack is one such service.
- pages on the stack may be forcibly "pop-ed out" (usually upon Back button
use). They may have a listener to be notified when that happens so that they
can clean up if they want to.
Some other things that are a bit further in the pipeline:
UNITS
Units of pages have been mentioned before, specifically in the work of
Geoff. He has put a very nice PPT of his work here:
http://spindle.sourceforge.net/OrcaWorkUnits.ppt
What I think is necessary is something very similar, at the very least
because it allows pages to be combined in units and the unit to be treated
as a "black box". This is particularly important with transitions and call
transitions.
Here is another reason why: Pages are typically placed in a wrap that has
links to pages like Home or ContactUs or some other such generic parts of
the site. If the user goes to those pages, it is as if he starts his
experience anew and the stack should not be dragged across as well.
Units allow us to determine the group of pages related to a particular
action. If the control leaves that group, then a 'return' will simply not
happen and the stack can be discarded as a result (at least on the client
side).
Pages are units of one by default - no definition is needed there. Units
need only to be defined if multiple pages take part in a particular action.
Note that the concept of units may also be used to determine the lifetime of
properties persisted in the URL as well.
And here are a few other topics related to the ones above that we need to
consider: transitions as parameters and integration with global transition
frameworks such as Web Flow. But let's see whether the above makes sense
first...
Best regards,
-mb
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [DISCUSS] Page prameters, links to properties, call transitions, units, etc
Posted by Henri Dupre <he...@gmail.com>.
On 5/17/05, Mind Bridge <mi...@yahoo.com> wrote:
> Also, please note that SWF does not support call transitions at the
> moment. That cannot be done well without URL generation and client-side
> information storage as the stack needs to go in the URL as well --
> something that Tapestry has now more or less, but earlier versions did
> not, and most other frameworks do not either at the moment. Subflows
> are pretty much like functions without a stack. Earlier programming
> languages used to have them, but that is now passe, and a currently used
> languages cannot afford to lack a stack.
You define call transitions by "special type of
transitions that allow you to invoke a particular page and then return back
from it with results". That can be represented by a web flow. But
there won't be any mechanism inside the web flow to handle the state
and retrieve the parameters of that particular page. It seems to be
that this state shouldn't be too difficult to handle with the new
tapestry "persist" feature and I'm wondering if building that handling
into the framework wouldn't be too heavy weight and complex to use.
All the feature you mention seem to really fall into the webflow
stuff. They would be all very usefull but I'm a little scared of the
complexity behind them. I'd rather like to have at first basic webflow
functionalities to replace the cycle.activate() calls.
> Call transitions are absolutely necessary for local (rather than global)
> configuration, in particular being able package functionality into small
> libraries. Wtih SFW that is not entirely possible. (btw local-vs-global
> is an argument similar to choosing HiveMind over Spring).
I don't see why you wouldn't be allowed to define a web flow inside
another one with SWF.
But I'm not sure to understand you here.
> Another issue: developers prefer to develop pages instead of components
> because the component needs to generate links that go to particular
> locations depending on the page it is in. So concepts like 'transitions
> as parameter', or even 'transition namespaces' are needed to handle
> that. Can SWF do that?
No I don't think so but I bet SWF is going to evolve fast and given
the buzz around SWF, I think developer really need it.
> I do think that a clean Java machanism for performing transitions is
> very necessary and the current 'cycle.activate()' is just a temporary
> measure. I believe Howards also discussed this a little bit as well.
> That would also make things like WebFlow quite possible. I just do not
> think if is sifficient and it does not use all the power that Tapestry
> offers.
That's true but even adding a web flow in the framework creates IMO a
fair amount more of complexity for a beginner. What I like with SWF,
is that it is very basic and simple, has documentation, tutorials and
graphical tools => Easy to understand and use for a newbie. Learning
Tapestry is already quite a learning curve and if people have to deal
with Web Flow concepts inside the framework, I think it might be too
much. Even though modularity, componentization are coming very slowly
on the web site of things, most developers tend to still think about
web pages as simple php, sequential stuff (that's also what they
usually taught at school).
Henri.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [DISCUSS] Page prameters, links to properties, call transitions,
units, etc
Posted by Mind Bridge <mi...@yahoo.com>.
> I completly second that. Spring Web Flow seems to be getting more and
> more popular and also has now a nice set of tools. MindBridge, have
> you looked at SWF?
Yes, I mentioned it a couple of times in my emails. Please see the
'parameters vs. properties' section in my email to Erik to see why I
think this is necessary, but I am not a strong supporter of that concept
without some additional string attached.
Also, please note that SWF does not support call transitions at the
moment. That cannot be done well without URL generation and client-side
information storage as the stack needs to go in the URL as well --
something that Tapestry has now more or less, but earlier versions did
not, and most other frameworks do not either at the moment. Subflows
are pretty much like functions without a stack. Earlier programming
languages used to have them, but that is now passe, and a currently used
languages cannot afford to lack a stack.
Call transitions are absolutely necessary for local (rather than global)
configuration, in particular being able package functionality into small
libraries. Wtih SFW that is not entirely possible. (btw local-vs-global
is an argument similar to choosing HiveMind over Spring).
Another issue: developers prefer to develop pages instead of components
because the component needs to generate links that go to particular
locations depending on the page it is in. So concepts like 'transitions
as parameter', or even 'transition namespaces' are needed to handle
that. Can SWF do that?
Since web development tends to lag the rest of the world by many years
(e.g. components and some sort of encapsulation only became popular
quite recently and now appear to be a great success), but ultimately it
repeats evreything that has been done elsewhere, I expect that proper
call transitions, with local, rather that global configuration files
will be the future.
I do think that a clean Java machanism for performing transitions is
very necessary and the current 'cycle.activate()' is just a temporary
measure. I believe Howards also discussed this a little bit as well.
That would also make things like WebFlow quite possible. I just do not
think if is sifficient and it does not use all the power that Tapestry
offers. What I proposed is just a simple interface using that mechanism
so that people can begin using it immediately and easily.
Developers here do not seem to like that very much, but does someone
have a better alternative? (other than SWF, which suffers from the
problems mentioned before)
-mb
Henri Dupre wrote:
>On 5/16/05, Howard Lewis Ship <hl...@gmail.com> wrote:
>
>
>>My other impression is that this will heavily overlap Spring Web Flow or
>>other similar technologies, and perhaps what we need is to properly wrap
>>such a library, rather than reinvent it inside Tapestry.
>>
>>
>
>I completly second that. Spring Web Flow seems to be getting more and
>more popular and also has now a nice set of tools. MindBridge, have
>you looked at SWF? transitions should be part of a web flow. I agree
>with you that aspect stuff wouldn't be really good, it would make the
>framework too difficult to understand.
>IMO if there is a web flow involved, the link and form components
>should be different because the flow will introduce a new logic. After
>looking at the spring web flow, I think that these special components
>shouldn't have any listener (what you would write as the listener
>method should be inside the webflow framework). Also the flow id
>should be carried by these components... I don't think it would
>require much work to implement SWF but it is not straightforward to
>map the concepts to Tapestry.
>
>Henri.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [DISCUSS] Page prameters, links to properties, call transitions, units, etc
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On May 16, 2005, at 2:08 PM, Henri Dupre wrote:
> On 5/16/05, Howard Lewis Ship <hl...@gmail.com> wrote:
>
>> My other impression is that this will heavily overlap Spring Web
>> Flow or
>> other similar technologies, and perhaps what we need is to
>> properly wrap
>> such a library, rather than reinvent it inside Tapestry.
>>
>
> I completly second that. Spring Web Flow seems to be getting more and
> more popular and also has now a nice set of tools. MindBridge, have
> you looked at SWF? transitions should be part of a web flow. I agree
> with you that aspect stuff wouldn't be really good, it would make the
> framework too difficult to understand.
Folks - don't let the word "aspect" cause alarm. With HiveMind and
Tapestry 4.0, there is tons of it already going on! By "aspect", I
mean technically a way to add behavior before/after/around some
service (like the invocation of a listener). No particular
technology is implied, but Howard has already made the listener
invocation hookable in an aspect-oriented way in 4.0 with some
HiveMind magic.
Erik
> IMO if there is a web flow involved, the link and form components
> should be different because the flow will introduce a new logic. After
> looking at the spring web flow, I think that these special components
> shouldn't have any listener (what you would write as the listener
> method should be inside the webflow framework). Also the flow id
> should be carried by these components... I don't think it would
> require much work to implement SWF but it is not straightforward to
> map the concepts to Tapestry.
>
> Henri.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [DISCUSS] Page prameters, links to properties, call transitions, units, etc
Posted by Henri Dupre <he...@gmail.com>.
On 5/16/05, Howard Lewis Ship <hl...@gmail.com> wrote:
> My other impression is that this will heavily overlap Spring Web Flow or
> other similar technologies, and perhaps what we need is to properly wrap
> such a library, rather than reinvent it inside Tapestry.
I completly second that. Spring Web Flow seems to be getting more and
more popular and also has now a nice set of tools. MindBridge, have
you looked at SWF? transitions should be part of a web flow. I agree
with you that aspect stuff wouldn't be really good, it would make the
framework too difficult to understand.
IMO if there is a web flow involved, the link and form components
should be different because the flow will introduce a new logic. After
looking at the spring web flow, I think that these special components
shouldn't have any listener (what you would write as the listener
method should be inside the webflow framework). Also the flow id
should be carried by these components... I don't think it would
require much work to implement SWF but it is not straightforward to
map the concepts to Tapestry.
Henri.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
RE: [DISCUSS] Page prameters, links to properties, call transitions, units, etc
Posted by Stephen Haberman <st...@chase3000.com>.
> I'm really hoping to eliminate
> page and component specs entirely at some
> future date.
Spiffy.
> My other impression is that this will heavily overlap Spring
> Web Flow or other similar technologies, and perhaps what we
> need is to properly wrap such a library, rather than reinvent
> it inside Tapestry.
Oh, interesting...I missed the "web flow" angle in my first read.
Instead of getting that fancy right away, a simpler, short-term use case
that is a good starting point and could grow into what Mind Bridge is
talking about would be:
<a jwcid="@SomeLink" page="PageName" parameters="#{'fooId': 1,
'otherProperty': 'asdf'}">
And having it generate the URL:
/context/PageName.html?fooId=1&otherProperty=asdf
And the parameters are auto-mapped to page properties, so in your page
listeners/onRender/etc. all you have to do is:
this.getFooId()
The @SomeLink syntax could change, e.g. maybe fooId=1 is a full attribute
instead of in a Ognl map, but seeing exactly "?fooId=1" and not some
squeezed/base64-encoded/etc. in the URL is important (to me in terms of
style/elegance/etc.).
This is really just finishing up the great start already made with Friendly
URLs.
As an asside, I've got a hack that does this via overriding page.attach and
doing, psuedo-code, BeanUtils.populate(page, request.getParameterMap()). But
having this rolled in as an official feature, in the correct
Tapestry/HiveMind fashion, etc., woudl, for me, be 4.0's killer feature
(along with the current Friendly URL support).
- Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [DISCUSS] Page prameters, links to properties, call transitions, units, etc
Posted by Howard Lewis Ship <hl...@gmail.com>.
I'm still reading the the discussion, but my very first impression was: "Oh
No! More XML!".
I kind of like the idea of transitions, but I really don't think they belong
inside XML. I'm really hoping to eliminate page and component specs entirely
at some future date.
I'm trying to envision a Transition object that could be accessed by the
link component to run its behavior both at render and when triggered by a
later request. Perhaps there could be a "transisition:" shorthand binding
prefix, or properties that return proper Transition objects. Possibly, even
a listener method type mapping (that is, reference a transition by name and
it maps to a method, with variable parameters, for the transition).
My other impression is that this will heavily overlap Spring Web Flow or
other similar technologies, and perhaps what we need is to properly wrap
such a library, rather than reinvent it inside Tapestry.
Still going over it ...
On 5/15/05, Mind Bridge <mi...@yahoo.com> wrote:
>
> Hi Erik,
>
> Thank you for the thoughtful comments. Just to mention that I am not
> fanatical about those changes -- they are simply born out of necessity.
> Anything that is better is very welcome :)
>
> A few comments:
>
> - I actually think that minimizing the number of link components is a very
> good thing. My examples were simply taking into account the status quo,
> but
> I do think this is a good direction to move in. In fact, DirectLink,
> ActionLink, PageLink, and ExternalLink could relatively easily be folded
> into a single Link component (e.g. by making 'page' optional as well,
> etc).
> That will greatly simplify the amount of material a new Tapestry user
> would
> have to learn and will open up some new, albeit unconventional
> possibilities
> (e.g. execute a listener in another page)
>
> - As you have indirectly mentioned in your mail, if the framework is too
> complex, or if too many mechanisms are involved in a particular action,
> people will simply not use it.
>
> I have thus been trying to find an approach that is relatively
> straight-forward for the random user.
> As it stands, at the moment one has to learn Tapestry, HTML, XML, and Java
> in order to be achieve something with the framework. Adding aspects to the
> mix (and the proper way to use them as there are lots of improper ways),
> would be unnecessarily painful. I feel that we should come up with an easy
> way to achieve transitions with a minimum of Java code involved and
> without
> the necessity of another framework. Even experienced Java users would
> appreciate an easy solution for something they code over and over again.
> Aspects are a possibility for implementation, but I am not sure they
> should
> be exposed to the general user.
>
> Perhaps I am misunderstanding what you mean... Could you give an example?
> Also, if what I have come up with is too complex, is there a simpler
> alternative? (This is not a critique, I am genuinly curious and ready to
> accept it).
>
> Please note that what I have proposed does not make the listener/aspects
> approach impossible by any means.
>
> - Using the finate set of HTML attrubites in Direct links as informal
> parameter, and make everything else properties:
> I do not like this method for the following reasons:
> a) That set of attributes will possibly expand with the next version of
> HTML/XHTML
> b) Some of the HTML attributes are logical property names
> c) You may want to have attributes outside of this set -- they make no
> sense
> in HTML, but the Javascript of the page may do something with them.
>
> - The 'attribute' namespace was just an example, and any other would be
> quite okay with me. I am actually partial of 'jwc', as jwcid could become
> 'jwc:id'
>
> - ICallback is a nice work around at the moment, but firstly it does make
> things more complex than necessary, and secondly it is somewhat limited.
> For
> example, one could make a page that selects an item out of a list. So
> first
> you call that page to select a product out of a list of products, then in
> there you call the same page to select a county for which the product
> prices
> should be views. The second call must have a different state than the
> first
> (i.e. be associated with the specific stack frame it is in).
>
> - Just a side note: There is a difference between parameters and
> properties.
> As I see it, parameters are a part of the public contract of the
> page/component. Properties, on the other hand, are a part of the private
> contract. When you modify your page, you can rearrange your properties to
> your heart content as there are very few files affected. On the other hand
> you have to take great care of modifying your public interface as lots of
> other pages may rely on it (and often you do not even know what they are).
> This is especially true when there is no static verification as it is in
> Tapestry.
>
> I have noticed that in the web world there is little appreciation of the
> difference between public and private interface, probably because there is
> low instant gratification. This only becomes critical (and not following
> the
> principle quite painful) in big applications. Nevertheless, I think we
> should try to follow this distinction when we can.
>
> Btw, this is also the reason why I do not like much some of the 'global
> transition definition' frameworks -- the main file(s) rely too much on
> specific properties (not parameters) of the pages, and a small
> modification
> in the implementation of a particular page would cause everything to fall
> apart.
>
> Also, this is one possible difference between tying to properties in
> DirectLink and ExternalLink -- in the former case they could be any
> property
> as this is a local call, in the latter they should be parameters, as the
> call is remote... If there is unification, however, it probably makes
> sense
> to limit both to parameters.
>
> Sorry, I am a bit pressed for time at the moment and cannot respond to all
> of your questions, but I will write additionally.
>
> Thank you for the comments again,
> -mb
>
>
> ----- Original Message -----
> From: "Erik Hatcher" <er...@ehatchersolutions.com>
> To: "Tapestry development" <ta...@jakarta.apache.org>
> Sent: Sunday, May 15, 2005 11:20 PM
> Subject: Re: [DISCUSS] Page prameters, links to properties, call
> transitions, units, etc
>
> > A few quick thoughts inline to get the discussion rolling...
> >
> > On May 15, 2005, at 11:31 AM, Mind Bridge wrote:
> > > PAGE PARAMETERS
> > >
> > >
> > > At the moment, pages cannot have parameters. In reality, however,
> > > pages do
> > > have parameters even now.
> > >
> > > Here is a frequent example. (for clarity, let's call the current page
> > > UserPage and let the code below be an excerpt of UserPage.java)
> > >
> > >
> > > One very typical occurrence in Tapestry applications is code like this
> > > (usually in the listeners):
> > >
> > > ShowAddress page = (ShowAddress) getPage("ShowAddress");
> > > page.setUser(user);
> > > page.setEmail(email);
> > > cycle.activate(page);
> > >
> > > Note that User and Email are essentially parameters of ShowAddress.
> > > They
> > > could be declared in the ShowAddress.page file as parameters of
> > > that page
> > > (this was not allowed until now):
> > >
> > >
> > >
> > > <parameter name="user"/>
> > > <parameter name="email"/>
> > >
> > > The above code is essentially a transition from UserPage to
> > > ShowAddress upon
> > > a particular activity. That could be declared in UserPage like this:
> > >
> > >
> > >
> > > <transition name="address" page="ShowAddress">
> > > <binding name="user" expression="user.name <http://user.name>"/>
> > > <binding name="email" expression="user.email"/>
> > > </transition>
> > >
> > > That transition could then be invoked in a way similar to this:
> > >
> > >
> > >
> > > <a jwcid="@DirectLink" listener="transition: address">...</a>
> > >
> > > Nevertheless, I find the following approach more flexible and thus
> > > preferable, even though it involves a new parameter to the link
> > > components:
> > >
> > >
> > >
> > > <a jwcid="@DirectLink" listener="someListener"
> > > transition="address">...</a>
> > >
> > >
> > > Here both 'listener' and 'transition' are optional. If both are
> > > defined,
> > > then the listener is invoked before the specified transition is
> > > performed,
> > > otherwise only one of them is called.
> >
> > Page flow is an area where Tapestry has remained agnostic thus far,
> > so this is breaking new ground for sure.
> >
> > I'm having trouble coming up with an elaborate rationale for why I
> > don't like the transition attribute, it just doesn't feel right to
> > me. I'm trying to push the idea that the link components in Tapestry
> > are already too numerous and confusing, and this adds another layer
> > to the complexity. Would your transitions support client-side
> > redirects? If so, how?
> >
> > If listener methods had before/after hooks built-in, then page flow
> > could be "aspected" in as an _after_ hook and various strategies
> > could be employed, with my favorite being a client-side redirect.
> > Your transition feature could be incorporated in this manner somehow,
> > I'd think.
> >
> > > The page parameters will come from the outside however,
> > > specifically from
> > > the request to the server. That means that such an exception can no
> > > longer
> > > be labeled simply as a 'bug', but could be a malicious or accidental
> > > tampering instead. This is particularly true of required parameters
> > > - they
> > > may simply be omitted. As a result, it is necessary to think
> > > whether a page
> > > can have required parameters.
> >
> > In your example, the page parameters aren't quite coming from the
> > request, but rather from the rewind after the initial page has had a
> > chance to set those properties. Right?
> >
> > It is an interesting point to consider parameters for pages, and
> > something I feel is important. I'd like to be able to very cleanly
> > map pieces of the URL to parameters (or properties, whatever we call
> > them) of the page. Consider a blog-style URLs:
> >
> > /2005/05/12
> >
> > /category/entry_name
> >
> > /2005/05
> >
> > or del.icio.us-style (which is similar to the system I'm building now):
> >
> > /UserName
> >
> > /UserName/tag-expression
> >
> > Consider the competition, Ruby on Rails routing:
> >
> > <http://manuals.rubyonrails.com/read/chapter/65#page164>
> >
> > I see this as related to your idea of pages with parameters. I'd
> > love to be able to declaratively say that /UserName/tag-expression
> > can go to the Display page with the "username" and "tagExpression"
> > properties already set and usable. I could (and have in a limited
> > sense) done this very thing with servlet filters, and this may be the
> > right way to do what I'm after more generally yet this does so
> > without access to Tapestry internals so I'm not really creating a
> > page and setting properties, but rather fabricating a URL that is
> > ExternalLink style with a request wrapper.
> >
> > > DIRECT LINK WITH PROPERTIES
> > >
> > > Currently, DirectLink passes its parameters via an array and
> > > getServiceParameters() needs to be invoked to the get them in the
> > > listener
> > > (some improvements have been made in 4.0, but the principle is the
> > > same).
> > > While there is a clear need for this approach, I would suggest
> > > DirectLink to
> > > be able to store some parameters in the component's properties as
> > > well. No
> > > listener should be required.
> >
> > I'm not following why listener should be optional in the DirectLink
> > case. In that case, it's simply a PageLink that sets parameters. In
> > other words, I'm suggesting that the link components converge rather
> > than getting more diverse.
> >
> > > Also, I do not think having a fixed list of informal parameters
> > > such as
> > > onKeyPress to separate them from the parameters is a good idea for
> > > a number
> > > of reasons.
> >
> > It's a finite set of attributes. Why shouldn't Tapestry be smart
> > about the output format?
> >
> >
> > > Instead, in the interest of world peace and backward
> > > compatibility, I think namespaces should be used here.
> >
> > I agree in general except in details....
> >
> > > For example, if UserPage was to provide the selection of a user out
> > > of a
> > > list, the above example could be implemented like this:
> > >
> > >
> > >
> > > <span jwcid="for@For" source="users">
> > >
> > > <a jwcid="@DirectLink" property:user="components.for.value"
> > > transition="
> > > ShowAddress"> . </a>
> > >
> > > </span>
> >
> > you probably meant transition="address" there, given the below snippet.
> >
> > Re: namespaces - it should be a Tapestry namespace, in the formal XML
> > sense, not just a conventional prefix like "property:user". What
> > about "tap:user"?
> >
> > > To put the example in words, DirectLink will squeeze the currently
> > > iterated
> > > user into the link it generates. If the link is invoked, it will
> > > set the
> > > 'user' property of the page and will then invoke the transition to the
> > > ShowAddress page.
> >
> > Again, I'd prefer the flow of where the page goes after a listener is
> > invoked be decoupled from the link itself. The flow "aspect" can
> > (and in your examples, should) be connected though.
> >
> > > As you can see, this is simple and no Java code is required. The
> > > 'transition
> > > ' here is just an example, this method for setting parameters could
> > > be used
> > > in a number of different ways as well.
> >
> > By a mapping from the hyperlink! :)
> >
> > > A similar property-setting scheme could be applied to ExternalLink,
> > > etc.
> >
> > Let's coalesce the link components, not diverge them. Please!
> >
> > > CALL TRANSITIONS
> > >
> > > Very often it is necessary for the user to perform an action, such
> > > as to
> > > select an item from a list. This same action may be invoked from a
> > > number of
> > > different places in the application, however, and the control has
> > > to return
> > > to the place where it originally came from. In the programming
> > > world there
> > > is a simple mechanism to achieve this - functions. In the web world,
> > > however, there is no good way to that without custom code.
> > >
> > > Let's use the name "call transitions" to denote a special type of
> > > transitions that allow you to invoke a particular page and then
> > > return back
> > > from it with results. Here is an example: suppose that you have a
> > > web store
> > > application. On a number of different places in the application you
> > > would
> > > want the user to select a product so that you can do something with
> > > it (view
> > > its details, purchase it, etc).
> > >
> > >
> > >
> > > Here is some simple code in pages like Basket that could achieve that:
> > >
> > >
> > >
> > > <a jwcid="@DirectLink" transition="select">Add a product to basket</a>
> > >
> > >
> > >
> > > <!-SelectProduct will return the selection in the 'product'
> > > property and the
> > > handleSelectedProduct listener will be called when that happens -->
> > >
> > > <call-transition name="select" page="SelectProduct" listener="
> > > handleSelectedProduct">
> > >
> > > <binding name="product" expression="product"/>
> > >
> > > </transition>
> > >
> > >
> > >
> > > In SelectProduct.page define:
> > >
> > >
> > >
> > > <parameter name="product"/>
> > >
> > >
> > >
> > > And when a product is selected in SelectProduct and you can get
> > > back to the
> > > caller, simply invoke the predefined transition "return" to get
> > > back to the
> > > page that called us in the first place, e.g.:
> > >
> > >
> > >
> > > in SelectProduct.html:
> > >
> > > <span jwcid="for@For" source="products">
> > >
> > > <a jwcid="@DirectLink" property:product="components.for.value"
> > > transition="
> > > return"> . </a>
> > >
> > > </span>
> > >
> > >
> > >
> > > SelectProduct could then be invoked whenever a particular part of the
> > > application needs the user to select a product and the framework
> > > will return
> > > to the invoker with the result.
> >
> > This seems like something that could be done with clever use of
> > ICallback. I like the idea, but again for some reason the transition
> > specifics don't hit home with me.
> >
> > > STACK
> >
> > A stack of ICallback's??
> >
> > > - The stack needs to be kept in some form both in the request (URL)
> > > and in
> > > the session (if any) to avoid funny effects when Back is used. At
> > > the moment
> > > only persistent properties may be placed in URL, but I would like
> > > us to have
> > > a mechanism that allows a service to be injected and place relevant
> > > information on the URL. The stack is one such service.
> > >
> > >
> > >
> > > - pages on the stack may be forcibly "pop-ed out" (usually upon
> > > Back button
> > > use). They may have a listener to be notified when that happens so
> > > that they
> > > can clean up if they want to.
> >
> > The back button doesn't bother me much, as I opt for client-side
> > redirects for actions that POST'ed or for URL's that could be
> > damaging if reloaded. Idempotent GET's!
> >
> > > UNITS
> > >
> > >
> > > Units of pages have been mentioned before, specifically in the work of
> > > Geoff. He has put a very nice PPT of his work here:
> > >
> > > http://spindle.sourceforge.net/OrcaWorkUnits.ppt
> >
> > Interesting! I don't quite get it yet, so will let it get some
> > background thinking before I have anything to say on this topic.
> >
> > > Note that the concept of units may also be used to determine the
> > > lifetime of
> > > properties persisted in the URL as well.
> >
> > This seems to relate to what Howard and Drew "OGNL" Davidson have
> > discussed about the lifetime and scope of persistent properties and
> > how Tapestry differs from WebObjects with WO having a nice feature to
> > allow persistent properties to only be within the scope of a certain
> > page flow path. I'd like to hear how Howard and/or Drew have
> > contemplated the implementation of this.
> >
> > > And here are a few other topics related to the ones above that we
> > > need to
> > > consider: transitions as parameters and integration with global
> > > transition
> > > frameworks such as Web Flow. But let's see whether the above makes
> > > sense
> > > first...
> >
> > Your concepts make sense, but your examples seem to complicate things
> > rather than making it simpler. Links are already a mess to work with
> > for me, and surely for newbies even more so. I want cleaner/simpler
> > ways to link to pages, hand them parameters, and be able to do so
> > from the URL or from a listener code, or in an "aspect".
> >
> > Erik
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
Re: [DISCUSS] Page prameters, links to properties, call transitions, units, etc
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On May 15, 2005, at 7:15 PM, Mind Bridge wrote:
> A few comments:
>
> - I actually think that minimizing the number of link components is
> a very
> good thing. My examples were simply taking into account the status
> quo, but
> I do think this is a good direction to move in. In fact, DirectLink,
> ActionLink, PageLink, and ExternalLink could relatively easily be
> folded
> into a single Link component (e.g. by making 'page' optional as
> well, etc).
> That will greatly simplify the amount of material a new Tapestry
> user would
> have to learn and will open up some new, albeit unconventional
> possibilities
> (e.g. execute a listener in another page)
Yay, consensus on this one!
> As it stands, at the moment one has to learn Tapestry, HTML, XML,
> and Java
> in order to be achieve something with the framework.
That's just barely scratching the surface of what a developer needs
to know to be proficient with Tapestry (or any other Java web
framework for that matter).
> Adding aspects to the
> mix (and the proper way to use them as there are lots of improper
> ways),
> would be unnecessarily painful. I feel that we should come up with
> an easy
> way to achieve transitions with a minimum of Java code involved and
> without
> the necessity of another framework. Even experienced Java users would
> appreciate an easy solution for something they code over and over
> again.
> Aspects are a possibility for implementation, but I am not sure
> they should
> be exposed to the general user.
To clarify - when I say "aspects" I don't mean any particular
technology. And in the case of Howard's recent change to Tapestry
4.0, the aspecting technology for listener method wrapping is a
HiveMind pipeline.
I have tinkered with AspectJ and had prototype success with doing
_around_ aspecting of listener methods as well.
Whether the aspect nature of things is built into the framework or
not is an interesting architectural decision. Should the framework
be more complex and have built-in hooks for everything or should the
framework be simpler and leave aspects up to another technology like
AspectJ? I prefer simpler pieces that can be constructed in complex
ways if I like but the complexity is up to me as a developer using
the frameworks, and having the frameworks themselves be simpler.
> Perhaps I am misunderstanding what you mean... Could you give an
> example?
The use case for listener aspects for me is to wrap them with a DB
transaction boundary - commit or rollback after a listener is invoked
based on whether the listener succeeded or not. A listener
succeeding is a tricky thing to determine though with the use of two
flow control exceptions mucking it up.
> - Using the finate set of HTML attrubites in Direct links as informal
> parameter, and make everything else properties:
> I do not like this method for the following reasons:
> a) That set of attributes will possibly expand with the next
> version of
> HTML/XHTML
> b) Some of the HTML attributes are logical property names
> c) You may want to have attributes outside of this set -- they make
> no sense
> in HTML, but the Javascript of the page may do something with them.
I agree with these points. But with c) the non-standard attributes
really should be namespaced, especially to be compliant to XHTML.
My point is from the most modern XHTML spec point of view, and is
more idealistic than Tapestry ought to be.
> - Just a side note: There is a difference between parameters and
> properties.
> As I see it, parameters are a part of the public contract of the
> page/component. Properties, on the other hand, are a part of the
> private
> contract. When you modify your page, you can rearrange your
> properties to
> your heart content as there are very few files affected. On the
> other hand
> you have to take great care of modifying your public interface as
> lots of
> other pages may rely on it (and often you do not even know what
> they are).
> This is especially true when there is no static verification as it
> is in
> Tapestry.
>
> I have noticed that in the web world there is little appreciation
> of the
> difference between public and private interface, probably because
> there is
> low instant gratification. This only becomes critical (and not
> following the
> principle quite painful) in big applications. Nevertheless, I think we
> should try to follow this distinction when we can.
These are good points about public interfaces to pages.
> Also, this is one possible difference between tying to properties in
> DirectLink and ExternalLink -- in the former case they could be any
> property
> as this is a local call, in the latter they should be parameters,
> as the
> call is remote... If there is unification, however, it probably
> makes sense
> to limit both to parameters.
more good points! The distinction between the local call with
DirectLink and "remote" call with ExternalLink is important and
whether the rewind is part of the equation or not.
> Sorry, I am a bit pressed for time at the moment and cannot respond
> to all
> of your question
Same here.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [DISCUSS] Page prameters, links to properties, call transitions, units, etc
Posted by Mind Bridge <mi...@yahoo.com>.
Hi Erik,
Thank you for the thoughtful comments. Just to mention that I am not
fanatical about those changes -- they are simply born out of necessity.
Anything that is better is very welcome :)
A few comments:
- I actually think that minimizing the number of link components is a very
good thing. My examples were simply taking into account the status quo, but
I do think this is a good direction to move in. In fact, DirectLink,
ActionLink, PageLink, and ExternalLink could relatively easily be folded
into a single Link component (e.g. by making 'page' optional as well, etc).
That will greatly simplify the amount of material a new Tapestry user would
have to learn and will open up some new, albeit unconventional possibilities
(e.g. execute a listener in another page)
- As you have indirectly mentioned in your mail, if the framework is too
complex, or if too many mechanisms are involved in a particular action,
people will simply not use it.
I have thus been trying to find an approach that is relatively
straight-forward for the random user.
As it stands, at the moment one has to learn Tapestry, HTML, XML, and Java
in order to be achieve something with the framework. Adding aspects to the
mix (and the proper way to use them as there are lots of improper ways),
would be unnecessarily painful. I feel that we should come up with an easy
way to achieve transitions with a minimum of Java code involved and without
the necessity of another framework. Even experienced Java users would
appreciate an easy solution for something they code over and over again.
Aspects are a possibility for implementation, but I am not sure they should
be exposed to the general user.
Perhaps I am misunderstanding what you mean... Could you give an example?
Also, if what I have come up with is too complex, is there a simpler
alternative? (This is not a critique, I am genuinly curious and ready to
accept it).
Please note that what I have proposed does not make the listener/aspects
approach impossible by any means.
- Using the finate set of HTML attrubites in Direct links as informal
parameter, and make everything else properties:
I do not like this method for the following reasons:
a) That set of attributes will possibly expand with the next version of
HTML/XHTML
b) Some of the HTML attributes are logical property names
c) You may want to have attributes outside of this set -- they make no sense
in HTML, but the Javascript of the page may do something with them.
- The 'attribute' namespace was just an example, and any other would be
quite okay with me. I am actually partial of 'jwc', as jwcid could become
'jwc:id'
- ICallback is a nice work around at the moment, but firstly it does make
things more complex than necessary, and secondly it is somewhat limited. For
example, one could make a page that selects an item out of a list. So first
you call that page to select a product out of a list of products, then in
there you call the same page to select a county for which the product prices
should be views. The second call must have a different state than the first
(i.e. be associated with the specific stack frame it is in).
- Just a side note: There is a difference between parameters and properties.
As I see it, parameters are a part of the public contract of the
page/component. Properties, on the other hand, are a part of the private
contract. When you modify your page, you can rearrange your properties to
your heart content as there are very few files affected. On the other hand
you have to take great care of modifying your public interface as lots of
other pages may rely on it (and often you do not even know what they are).
This is especially true when there is no static verification as it is in
Tapestry.
I have noticed that in the web world there is little appreciation of the
difference between public and private interface, probably because there is
low instant gratification. This only becomes critical (and not following the
principle quite painful) in big applications. Nevertheless, I think we
should try to follow this distinction when we can.
Btw, this is also the reason why I do not like much some of the 'global
transition definition' frameworks -- the main file(s) rely too much on
specific properties (not parameters) of the pages, and a small modification
in the implementation of a particular page would cause everything to fall
apart.
Also, this is one possible difference between tying to properties in
DirectLink and ExternalLink -- in the former case they could be any property
as this is a local call, in the latter they should be parameters, as the
call is remote... If there is unification, however, it probably makes sense
to limit both to parameters.
Sorry, I am a bit pressed for time at the moment and cannot respond to all
of your questions, but I will write additionally.
Thank you for the comments again,
-mb
----- Original Message -----
From: "Erik Hatcher" <er...@ehatchersolutions.com>
To: "Tapestry development" <ta...@jakarta.apache.org>
Sent: Sunday, May 15, 2005 11:20 PM
Subject: Re: [DISCUSS] Page prameters, links to properties, call
transitions, units, etc
> A few quick thoughts inline to get the discussion rolling...
>
> On May 15, 2005, at 11:31 AM, Mind Bridge wrote:
> > PAGE PARAMETERS
> >
> >
> > At the moment, pages cannot have parameters. In reality, however,
> > pages do
> > have parameters even now.
> >
> > Here is a frequent example. (for clarity, let's call the current page
> > UserPage and let the code below be an excerpt of UserPage.java)
> >
> >
> > One very typical occurrence in Tapestry applications is code like this
> > (usually in the listeners):
> >
> > ShowAddress page = (ShowAddress) getPage("ShowAddress");
> > page.setUser(user);
> > page.setEmail(email);
> > cycle.activate(page);
> >
> > Note that User and Email are essentially parameters of ShowAddress.
> > They
> > could be declared in the ShowAddress.page file as parameters of
> > that page
> > (this was not allowed until now):
> >
> >
> >
> > <parameter name="user"/>
> > <parameter name="email"/>
> >
> > The above code is essentially a transition from UserPage to
> > ShowAddress upon
> > a particular activity. That could be declared in UserPage like this:
> >
> >
> >
> > <transition name="address" page="ShowAddress">
> > <binding name="user" expression="user.name"/>
> > <binding name="email" expression="user.email"/>
> > </transition>
> >
> > That transition could then be invoked in a way similar to this:
> >
> >
> >
> > <a jwcid="@DirectLink" listener="transition: address">...</a>
> >
> > Nevertheless, I find the following approach more flexible and thus
> > preferable, even though it involves a new parameter to the link
> > components:
> >
> >
> >
> > <a jwcid="@DirectLink" listener="someListener"
> > transition="address">...</a>
> >
> >
> > Here both 'listener' and 'transition' are optional. If both are
> > defined,
> > then the listener is invoked before the specified transition is
> > performed,
> > otherwise only one of them is called.
>
> Page flow is an area where Tapestry has remained agnostic thus far,
> so this is breaking new ground for sure.
>
> I'm having trouble coming up with an elaborate rationale for why I
> don't like the transition attribute, it just doesn't feel right to
> me. I'm trying to push the idea that the link components in Tapestry
> are already too numerous and confusing, and this adds another layer
> to the complexity. Would your transitions support client-side
> redirects? If so, how?
>
> If listener methods had before/after hooks built-in, then page flow
> could be "aspected" in as an _after_ hook and various strategies
> could be employed, with my favorite being a client-side redirect.
> Your transition feature could be incorporated in this manner somehow,
> I'd think.
>
> > The page parameters will come from the outside however,
> > specifically from
> > the request to the server. That means that such an exception can no
> > longer
> > be labeled simply as a 'bug', but could be a malicious or accidental
> > tampering instead. This is particularly true of required parameters
> > - they
> > may simply be omitted. As a result, it is necessary to think
> > whether a page
> > can have required parameters.
>
> In your example, the page parameters aren't quite coming from the
> request, but rather from the rewind after the initial page has had a
> chance to set those properties. Right?
>
> It is an interesting point to consider parameters for pages, and
> something I feel is important. I'd like to be able to very cleanly
> map pieces of the URL to parameters (or properties, whatever we call
> them) of the page. Consider a blog-style URLs:
>
> /2005/05/12
>
> /category/entry_name
>
> /2005/05
>
> or del.icio.us-style (which is similar to the system I'm building now):
>
> /UserName
>
> /UserName/tag-expression
>
> Consider the competition, Ruby on Rails routing:
>
> <http://manuals.rubyonrails.com/read/chapter/65#page164>
>
> I see this as related to your idea of pages with parameters. I'd
> love to be able to declaratively say that /UserName/tag-expression
> can go to the Display page with the "username" and "tagExpression"
> properties already set and usable. I could (and have in a limited
> sense) done this very thing with servlet filters, and this may be the
> right way to do what I'm after more generally yet this does so
> without access to Tapestry internals so I'm not really creating a
> page and setting properties, but rather fabricating a URL that is
> ExternalLink style with a request wrapper.
>
> > DIRECT LINK WITH PROPERTIES
> >
> > Currently, DirectLink passes its parameters via an array and
> > getServiceParameters() needs to be invoked to the get them in the
> > listener
> > (some improvements have been made in 4.0, but the principle is the
> > same).
> > While there is a clear need for this approach, I would suggest
> > DirectLink to
> > be able to store some parameters in the component's properties as
> > well. No
> > listener should be required.
>
> I'm not following why listener should be optional in the DirectLink
> case. In that case, it's simply a PageLink that sets parameters. In
> other words, I'm suggesting that the link components converge rather
> than getting more diverse.
>
> > Also, I do not think having a fixed list of informal parameters
> > such as
> > onKeyPress to separate them from the parameters is a good idea for
> > a number
> > of reasons.
>
> It's a finite set of attributes. Why shouldn't Tapestry be smart
> about the output format?
>
>
> > Instead, in the interest of world peace and backward
> > compatibility, I think namespaces should be used here.
>
> I agree in general except in details....
>
> > For example, if UserPage was to provide the selection of a user out
> > of a
> > list, the above example could be implemented like this:
> >
> >
> >
> > <span jwcid="for@For" source="users">
> >
> > <a jwcid="@DirectLink" property:user="components.for.value"
> > transition="
> > ShowAddress"> . </a>
> >
> > </span>
>
> you probably meant transition="address" there, given the below snippet.
>
> Re: namespaces - it should be a Tapestry namespace, in the formal XML
> sense, not just a conventional prefix like "property:user". What
> about "tap:user"?
>
> > To put the example in words, DirectLink will squeeze the currently
> > iterated
> > user into the link it generates. If the link is invoked, it will
> > set the
> > 'user' property of the page and will then invoke the transition to the
> > ShowAddress page.
>
> Again, I'd prefer the flow of where the page goes after a listener is
> invoked be decoupled from the link itself. The flow "aspect" can
> (and in your examples, should) be connected though.
>
> > As you can see, this is simple and no Java code is required. The
> > 'transition
> > ' here is just an example, this method for setting parameters could
> > be used
> > in a number of different ways as well.
>
> By a mapping from the hyperlink! :)
>
> > A similar property-setting scheme could be applied to ExternalLink,
> > etc.
>
> Let's coalesce the link components, not diverge them. Please!
>
> > CALL TRANSITIONS
> >
> > Very often it is necessary for the user to perform an action, such
> > as to
> > select an item from a list. This same action may be invoked from a
> > number of
> > different places in the application, however, and the control has
> > to return
> > to the place where it originally came from. In the programming
> > world there
> > is a simple mechanism to achieve this - functions. In the web world,
> > however, there is no good way to that without custom code.
> >
> > Let's use the name "call transitions" to denote a special type of
> > transitions that allow you to invoke a particular page and then
> > return back
> > from it with results. Here is an example: suppose that you have a
> > web store
> > application. On a number of different places in the application you
> > would
> > want the user to select a product so that you can do something with
> > it (view
> > its details, purchase it, etc).
> >
> >
> >
> > Here is some simple code in pages like Basket that could achieve that:
> >
> >
> >
> > <a jwcid="@DirectLink" transition="select">Add a product to basket</a>
> >
> >
> >
> > <!-SelectProduct will return the selection in the 'product'
> > property and the
> > handleSelectedProduct listener will be called when that happens -->
> >
> > <call-transition name="select" page="SelectProduct" listener="
> > handleSelectedProduct">
> >
> > <binding name="product" expression="product"/>
> >
> > </transition>
> >
> >
> >
> > In SelectProduct.page define:
> >
> >
> >
> > <parameter name="product"/>
> >
> >
> >
> > And when a product is selected in SelectProduct and you can get
> > back to the
> > caller, simply invoke the predefined transition "return" to get
> > back to the
> > page that called us in the first place, e.g.:
> >
> >
> >
> > in SelectProduct.html:
> >
> > <span jwcid="for@For" source="products">
> >
> > <a jwcid="@DirectLink" property:product="components.for.value"
> > transition="
> > return"> . </a>
> >
> > </span>
> >
> >
> >
> > SelectProduct could then be invoked whenever a particular part of the
> > application needs the user to select a product and the framework
> > will return
> > to the invoker with the result.
>
> This seems like something that could be done with clever use of
> ICallback. I like the idea, but again for some reason the transition
> specifics don't hit home with me.
>
> > STACK
>
> A stack of ICallback's??
>
> > - The stack needs to be kept in some form both in the request (URL)
> > and in
> > the session (if any) to avoid funny effects when Back is used. At
> > the moment
> > only persistent properties may be placed in URL, but I would like
> > us to have
> > a mechanism that allows a service to be injected and place relevant
> > information on the URL. The stack is one such service.
> >
> >
> >
> > - pages on the stack may be forcibly "pop-ed out" (usually upon
> > Back button
> > use). They may have a listener to be notified when that happens so
> > that they
> > can clean up if they want to.
>
> The back button doesn't bother me much, as I opt for client-side
> redirects for actions that POST'ed or for URL's that could be
> damaging if reloaded. Idempotent GET's!
>
> > UNITS
> >
> >
> > Units of pages have been mentioned before, specifically in the work of
> > Geoff. He has put a very nice PPT of his work here:
> >
> > http://spindle.sourceforge.net/OrcaWorkUnits.ppt
>
> Interesting! I don't quite get it yet, so will let it get some
> background thinking before I have anything to say on this topic.
>
> > Note that the concept of units may also be used to determine the
> > lifetime of
> > properties persisted in the URL as well.
>
> This seems to relate to what Howard and Drew "OGNL" Davidson have
> discussed about the lifetime and scope of persistent properties and
> how Tapestry differs from WebObjects with WO having a nice feature to
> allow persistent properties to only be within the scope of a certain
> page flow path. I'd like to hear how Howard and/or Drew have
> contemplated the implementation of this.
>
> > And here are a few other topics related to the ones above that we
> > need to
> > consider: transitions as parameters and integration with global
> > transition
> > frameworks such as Web Flow. But let's see whether the above makes
> > sense
> > first...
>
> Your concepts make sense, but your examples seem to complicate things
> rather than making it simpler. Links are already a mess to work with
> for me, and surely for newbies even more so. I want cleaner/simpler
> ways to link to pages, hand them parameters, and be able to do so
> from the URL or from a listener code, or in an "aspect".
>
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [DISCUSS] Page prameters, links to properties, call transitions, units, etc
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
A few quick thoughts inline to get the discussion rolling...
On May 15, 2005, at 11:31 AM, Mind Bridge wrote:
> PAGE PARAMETERS
>
>
> At the moment, pages cannot have parameters. In reality, however,
> pages do
> have parameters even now.
>
> Here is a frequent example. (for clarity, let's call the current page
> UserPage and let the code below be an excerpt of UserPage.java)
>
>
> One very typical occurrence in Tapestry applications is code like this
> (usually in the listeners):
>
> ShowAddress page = (ShowAddress) getPage("ShowAddress");
> page.setUser(user);
> page.setEmail(email);
> cycle.activate(page);
>
> Note that User and Email are essentially parameters of ShowAddress.
> They
> could be declared in the ShowAddress.page file as parameters of
> that page
> (this was not allowed until now):
>
>
>
> <parameter name="user"/>
> <parameter name="email"/>
>
> The above code is essentially a transition from UserPage to
> ShowAddress upon
> a particular activity. That could be declared in UserPage like this:
>
>
>
> <transition name="address" page="ShowAddress">
> <binding name="user" expression="user.name"/>
> <binding name="email" expression="user.email"/>
> </transition>
>
> That transition could then be invoked in a way similar to this:
>
>
>
> <a jwcid="@DirectLink" listener="transition: address">...</a>
>
> Nevertheless, I find the following approach more flexible and thus
> preferable, even though it involves a new parameter to the link
> components:
>
>
>
> <a jwcid="@DirectLink" listener="someListener"
> transition="address">...</a>
>
>
> Here both 'listener' and 'transition' are optional. If both are
> defined,
> then the listener is invoked before the specified transition is
> performed,
> otherwise only one of them is called.
Page flow is an area where Tapestry has remained agnostic thus far,
so this is breaking new ground for sure.
I'm having trouble coming up with an elaborate rationale for why I
don't like the transition attribute, it just doesn't feel right to
me. I'm trying to push the idea that the link components in Tapestry
are already too numerous and confusing, and this adds another layer
to the complexity. Would your transitions support client-side
redirects? If so, how?
If listener methods had before/after hooks built-in, then page flow
could be "aspected" in as an _after_ hook and various strategies
could be employed, with my favorite being a client-side redirect.
Your transition feature could be incorporated in this manner somehow,
I'd think.
> The page parameters will come from the outside however,
> specifically from
> the request to the server. That means that such an exception can no
> longer
> be labeled simply as a 'bug', but could be a malicious or accidental
> tampering instead. This is particularly true of required parameters
> - they
> may simply be omitted. As a result, it is necessary to think
> whether a page
> can have required parameters.
In your example, the page parameters aren't quite coming from the
request, but rather from the rewind after the initial page has had a
chance to set those properties. Right?
It is an interesting point to consider parameters for pages, and
something I feel is important. I'd like to be able to very cleanly
map pieces of the URL to parameters (or properties, whatever we call
them) of the page. Consider a blog-style URLs:
/2005/05/12
/category/entry_name
/2005/05
or del.icio.us-style (which is similar to the system I'm building now):
/UserName
/UserName/tag-expression
Consider the competition, Ruby on Rails routing:
<http://manuals.rubyonrails.com/read/chapter/65#page164>
I see this as related to your idea of pages with parameters. I'd
love to be able to declaratively say that /UserName/tag-expression
can go to the Display page with the "username" and "tagExpression"
properties already set and usable. I could (and have in a limited
sense) done this very thing with servlet filters, and this may be the
right way to do what I'm after more generally yet this does so
without access to Tapestry internals so I'm not really creating a
page and setting properties, but rather fabricating a URL that is
ExternalLink style with a request wrapper.
> DIRECT LINK WITH PROPERTIES
>
> Currently, DirectLink passes its parameters via an array and
> getServiceParameters() needs to be invoked to the get them in the
> listener
> (some improvements have been made in 4.0, but the principle is the
> same).
> While there is a clear need for this approach, I would suggest
> DirectLink to
> be able to store some parameters in the component's properties as
> well. No
> listener should be required.
I'm not following why listener should be optional in the DirectLink
case. In that case, it's simply a PageLink that sets parameters. In
other words, I'm suggesting that the link components converge rather
than getting more diverse.
> Also, I do not think having a fixed list of informal parameters
> such as
> onKeyPress to separate them from the parameters is a good idea for
> a number
> of reasons.
It's a finite set of attributes. Why shouldn't Tapestry be smart
about the output format?
> Instead, in the interest of world peace and backward
> compatibility, I think namespaces should be used here.
I agree in general except in details....
> For example, if UserPage was to provide the selection of a user out
> of a
> list, the above example could be implemented like this:
>
>
>
> <span jwcid="for@For" source="users">
>
> <a jwcid="@DirectLink" property:user="components.for.value"
> transition="
> ShowAddress"> . </a>
>
> </span>
you probably meant transition="address" there, given the below snippet.
Re: namespaces - it should be a Tapestry namespace, in the formal XML
sense, not just a conventional prefix like "property:user". What
about "tap:user"?
> To put the example in words, DirectLink will squeeze the currently
> iterated
> user into the link it generates. If the link is invoked, it will
> set the
> 'user' property of the page and will then invoke the transition to the
> ShowAddress page.
Again, I'd prefer the flow of where the page goes after a listener is
invoked be decoupled from the link itself. The flow "aspect" can
(and in your examples, should) be connected though.
> As you can see, this is simple and no Java code is required. The
> 'transition
> ' here is just an example, this method for setting parameters could
> be used
> in a number of different ways as well.
By a mapping from the hyperlink! :)
> A similar property-setting scheme could be applied to ExternalLink,
> etc.
Let's coalesce the link components, not diverge them. Please!
> CALL TRANSITIONS
>
> Very often it is necessary for the user to perform an action, such
> as to
> select an item from a list. This same action may be invoked from a
> number of
> different places in the application, however, and the control has
> to return
> to the place where it originally came from. In the programming
> world there
> is a simple mechanism to achieve this - functions. In the web world,
> however, there is no good way to that without custom code.
>
> Let's use the name "call transitions" to denote a special type of
> transitions that allow you to invoke a particular page and then
> return back
> from it with results. Here is an example: suppose that you have a
> web store
> application. On a number of different places in the application you
> would
> want the user to select a product so that you can do something with
> it (view
> its details, purchase it, etc).
>
>
>
> Here is some simple code in pages like Basket that could achieve that:
>
>
>
> <a jwcid="@DirectLink" transition="select">Add a product to basket</a>
>
>
>
> <!-SelectProduct will return the selection in the 'product'
> property and the
> handleSelectedProduct listener will be called when that happens -->
>
> <call-transition name="select" page="SelectProduct" listener="
> handleSelectedProduct">
>
> <binding name="product" expression="product"/>
>
> </transition>
>
>
>
> In SelectProduct.page define:
>
>
>
> <parameter name="product"/>
>
>
>
> And when a product is selected in SelectProduct and you can get
> back to the
> caller, simply invoke the predefined transition "return" to get
> back to the
> page that called us in the first place, e.g.:
>
>
>
> in SelectProduct.html:
>
> <span jwcid="for@For" source="products">
>
> <a jwcid="@DirectLink" property:product="components.for.value"
> transition="
> return"> . </a>
>
> </span>
>
>
>
> SelectProduct could then be invoked whenever a particular part of the
> application needs the user to select a product and the framework
> will return
> to the invoker with the result.
This seems like something that could be done with clever use of
ICallback. I like the idea, but again for some reason the transition
specifics don't hit home with me.
> STACK
A stack of ICallback's??
> - The stack needs to be kept in some form both in the request (URL)
> and in
> the session (if any) to avoid funny effects when Back is used. At
> the moment
> only persistent properties may be placed in URL, but I would like
> us to have
> a mechanism that allows a service to be injected and place relevant
> information on the URL. The stack is one such service.
>
>
>
> - pages on the stack may be forcibly "pop-ed out" (usually upon
> Back button
> use). They may have a listener to be notified when that happens so
> that they
> can clean up if they want to.
The back button doesn't bother me much, as I opt for client-side
redirects for actions that POST'ed or for URL's that could be
damaging if reloaded. Idempotent GET's!
> UNITS
>
>
> Units of pages have been mentioned before, specifically in the work of
> Geoff. He has put a very nice PPT of his work here:
>
> http://spindle.sourceforge.net/OrcaWorkUnits.ppt
Interesting! I don't quite get it yet, so will let it get some
background thinking before I have anything to say on this topic.
> Note that the concept of units may also be used to determine the
> lifetime of
> properties persisted in the URL as well.
This seems to relate to what Howard and Drew "OGNL" Davidson have
discussed about the lifetime and scope of persistent properties and
how Tapestry differs from WebObjects with WO having a nice feature to
allow persistent properties to only be within the scope of a certain
page flow path. I'd like to hear how Howard and/or Drew have
contemplated the implementation of this.
> And here are a few other topics related to the ones above that we
> need to
> consider: transitions as parameters and integration with global
> transition
> frameworks such as Web Flow. But let's see whether the above makes
> sense
> first...
Your concepts make sense, but your examples seem to complicate things
rather than making it simpler. Links are already a mess to work with
for me, and surely for newbies even more so. I want cleaner/simpler
ways to link to pages, hand them parameters, and be able to do so
from the URL or from a listener code, or in an "aspect".
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org