You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Eric Jain <Er...@isb-sib.ch> on 2005/03/03 17:43:38 UTC
Stateless applications
Is Tapestry suitable for stateless applications? By stateless I mean no
session objects, no cookies, nothing. This, together with the ability to
define custom web addresses, would be a killer feature, at least for us.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Stateless applications
Posted by Danny Mandel <dm...@tolweb.org>.
Yes. By default Tapestry doesn't create a Session object unless one is
requested. You can accomplish state-passing by hidden form fields and
query parameters etc.
Danny
Eric Jain wrote:
> Is Tapestry suitable for stateless applications? By stateless I mean
> no session objects, no cookies, nothing. This, together with the
> ability to define custom web addresses, would be a killer feature, at
> least for us.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Stateless applications
Posted by Jamie Orchard-Hays <ja...@dang.com>.
Definitely. If I'm not mistaken, TSS is stateless.
One of the interesting things about Tapestry is that it uses pooled page
objects to increase its performance.
Jamie
----- Original Message -----
From: "Eric Jain" <Er...@isb-sib.ch>
To: <ta...@jakarta.apache.org>
Sent: Thursday, March 03, 2005 11:43 AM
Subject: Stateless applications
> Is Tapestry suitable for stateless applications? By stateless I mean no
> session objects, no cookies, nothing. This, together with the ability to
> define custom web addresses, would be a killer feature, at least for us.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Stateless applications
Posted by Henri Dupre <he...@gmail.com>.
On Fri, 04 Mar 2005 14:36:45 -0500, Kevin Menard
<ni...@negativetwenty.net> wrote:
> On 3/3/05 11:58 AM, "Erik Hatcher" <er...@ehatchersolutions.com> wrote:
>
> > What Danny said.... I'll add that as long as you never call getVisit()
> > the application stays stateless.
>
> How do persistent properties work then? I thought they went into a session
> object.
I'm not sure to exactly understand what is a persistent property... I
read the docs and the book over and over and that is not so clear. If
I create a property on a page, will it be persistent if I don't make
it explicitely persistent?
Henri.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Stateless applications
Posted by Shawn Church <sh...@boxity.com>.
Thanks. I've read about NullTableSessionStateManager in the past, but I
wasn't sure of all the details and it hasn't been important enough to
spend time on. I will give it a try.
I'm also familiar with ActionLink and LinkSubmit, but I tend to avoid
both of those. ActionLink in my experience creates more problems than
it solves. LinkSubmit is useful sometimes, but I would rather not rely
on JavaScript to submit a form. DirectLink is nice because I can pass a
parm (often a key from within a list), but since LinkSubmit is nothing
more than a form submit, it is not as convenient for picking an item
from a list (for example). From a purist standpoint, doing a form
submission (triggering a rewind, etc.) when I really only want to
perform a simple action and return to the page feels like a hack. There
is no clean way to simply replace DirectLinks with LinkSubmits, since
the corresponding page specification and java code will also have to be
modified. I realize that these problems are due to the nature of the
HTTP protocol, but it would be nice if there were other options.
My main point was to explain that creating a stateless app involves more
than just not calling getVisit(). It's certainly possible to remain
stateless, but it's easier to let Tapestry do it's thing.
Thanks again,
Shawn
Quoting Marcus Brito <mb...@gmail.com>:
> > When I've tried to go stateless, I've run into problems using
> > contrib:Table, and I honestly haven't taken the time to work around
> it.
> > Does anyone have suggestions (or preferably an example) for
> dealing
> > with contrib:Table in a stateless app?
>
> Yes, contrib:Table needs an instance of ITableSessionStateManager to
> record and restore it's state. The default implementation saves lots
> of info in the session, and thus is innapropriate for stateless
> applications. In that case, you should use a
> NullTableSessionStateManager to avoid storing data in the session.
> Please read the guide for the contrib:TableView[1] for more
> information on this subject.
>
>
> > The other times I've found it tricky is when I have a form with
> hidden
> > fields to replace persistent properties, but I need a DirectLink
> > somewhere on the page. Since DirectLink is not a form submit, I
> of
> > course lose all of my hidden form values. So, it's easier to just
> make
> > them persistent. For complex forms, it is not practical to
> duplicate
> > all the hidden properties as DirectLink parameters. Any ideas?
>
> If your hidden fields aren't updated by the client, and are used
> only
> to forward information from one page to another one, you could use
> an
> ActionLink[2] instead of a DirectLink. ActionLink will perform a
> full
> page rewind, so when the listener is invoked, the value for the
> hidden
> field will be in place.
>
> If your hidden fields *are* updated by the client (most likely), I
> think the best solution is to actually perform a form submission
> instead of working with DirectLinks. There's no "SubmitLink" in the
> bundled library, but it would be easy to write a component that
> renders a link that uses javascript to submit the containing form --
> take a look at the Script[3] component for your javascript needs.
>
> [1]
>
http://jakarta.apache.org/tapestry/doc/ComponentReference/contrib.TableView.html
> [2]
> http://jakarta.apache.org/tapestry/doc/ComponentReference/ActionLink.html
> [3]
> http://jakarta.apache.org/tapestry/doc/ComponentReference/Script.html
>
> -- Marcus Brito <mb...@gmail.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: parameter to a tapestry app
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
You could create your own ExternalBasePage that implements the
IExternalPage interface, though. Neither memory nor security are the
reason for the current design - its because they were considered
conceptually different by Howard, I suspect.
All pages are externally reachable:
/app?service=page/PageName
There just is not an entry point for receiving parameters. It makes
more sense to me for PageLink and ExternalLink to merge into one link,
with parameters optional. I treat them basically the same in my apps.
What would be the drawback to only a single link that goes to a page
with parameters optional?
Erik
On Mar 4, 2005, at 5:05 AM, t.n.a. wrote:
> Danny Mandel wrote:
>
>> public class SomeExternalPage implements IExternalPage {
>> ....
>
> <snip>
>
>> Then to pass the param:
>> http://host/appname/app?service=external/SomeExternalPage&sp=1
>>
>> Voila!
>>
>> Hope that helps,
>
>
> Works great, thanks!
> But while we're on topic, why wouldn't all pages be externally
> reachable (at least by default)? What's the penalty for
> "externalizing" a page? A bigger memory footprint? Security?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: parameter to a tapestry app
Posted by "t.n.a." <tn...@sharanet.org>.
Danny Mandel wrote:
> public class SomeExternalPage implements IExternalPage {
> ....
<snip>
> Then to pass the param:
> http://host/appname/app?service=external/SomeExternalPage&sp=1
>
> Voila!
>
> Hope that helps,
Works great, thanks!
But while we're on topic, why wouldn't all pages be externally reachable
(at least by default)? What's the penalty for "externalizing" a page? A
bigger memory footprint? Security?
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: parameter to a tapestry app
Posted by Danny Mandel <dm...@tolweb.org>.
public class SomeExternalPage implements IExternalPage {
public void activateExternalPage(Object[] parameters, IRequestCycle
cycle) {
Integer someParam = (Integer) parameters[0];
setSomeInteger(someParam);
}
public abstract void setSomeInteger(Integer value);
public abstract Integer getSomeInteger();
}
Then to pass the param:
http://host/appname/app?service=external/SomeExternalPage&sp=1
Voila!
Hope that helps,
Danny
t.n.a. wrote:
> Problem: passing a parameter (via, GET or POST) from a, for instance,
> php web page as input to a tapestry application.
> Now, I've read a bit about defining new services to handle
> bookmarkable pages (from what I understand, the problem boils down to
> making the first page bookmarkable), I've looked at the vlib example
> and I just can't believe it takes more than a couple of lines of code
> (certainly not pages and pages of it like in the example!) to do the job.
> Anyway, my question is this: what is the minimum sequence of steps
> needed to allow a page to receive a single integer parameter?
> A simple, small example is all I need...
>
> Regards,
> Tomislav
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
parameter to a tapestry app
Posted by "t.n.a." <tn...@sharanet.org>.
Problem: passing a parameter (via, GET or POST) from a, for instance,
php web page as input to a tapestry application.
Now, I've read a bit about defining new services to handle bookmarkable
pages (from what I understand, the problem boils down to making the
first page bookmarkable), I've looked at the vlib example and I just
can't believe it takes more than a couple of lines of code (certainly
not pages and pages of it like in the example!) to do the job.
Anyway, my question is this: what is the minimum sequence of steps
needed to allow a page to receive a single integer parameter?
A simple, small example is all I need...
Regards,
Tomislav
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Stateless applications
Posted by Marcus Brito <mb...@gmail.com>.
> There actually is a LinkSubmit! It works great.
>
> http://jakarta.apache.org/tapestry/doc/ComponentReference/LinkSubmit.html
Too... little... coffee... my body... needs... more...
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Stateless applications
Posted by Danny Mandel <dm...@tolweb.org>.
There actually is a LinkSubmit! It works great.
http://jakarta.apache.org/tapestry/doc/ComponentReference/LinkSubmit.html
Danny
Marcus Brito wrote:
>>When I've tried to go stateless, I've run into problems using
>>contrib:Table, and I honestly haven't taken the time to work around it.
>> Does anyone have suggestions (or preferably an example) for dealing
>>with contrib:Table in a stateless app?
>>
>>
>
>Yes, contrib:Table needs an instance of ITableSessionStateManager to
>record and restore it's state. The default implementation saves lots
>of info in the session, and thus is innapropriate for stateless
>applications. In that case, you should use a
>NullTableSessionStateManager to avoid storing data in the session.
>Please read the guide for the contrib:TableView[1] for more
>information on this subject.
>
>
>
>
>>The other times I've found it tricky is when I have a form with hidden
>>fields to replace persistent properties, but I need a DirectLink
>>somewhere on the page. Since DirectLink is not a form submit, I of
>>course lose all of my hidden form values. So, it's easier to just make
>>them persistent. For complex forms, it is not practical to duplicate
>>all the hidden properties as DirectLink parameters. Any ideas?
>>
>>
>
>If your hidden fields aren't updated by the client, and are used only
>to forward information from one page to another one, you could use an
>ActionLink[2] instead of a DirectLink. ActionLink will perform a full
>page rewind, so when the listener is invoked, the value for the hidden
>field will be in place.
>
>If your hidden fields *are* updated by the client (most likely), I
>think the best solution is to actually perform a form submission
>instead of working with DirectLinks. There's no "SubmitLink" in the
>bundled library, but it would be easy to write a component that
>renders a link that uses javascript to submit the containing form --
>take a look at the Script[3] component for your javascript needs.
>
>[1] http://jakarta.apache.org/tapestry/doc/ComponentReference/contrib.TableView.html
>[2] http://jakarta.apache.org/tapestry/doc/ComponentReference/ActionLink.html
>[3] http://jakarta.apache.org/tapestry/doc/ComponentReference/Script.html
>
>-- Marcus Brito <mb...@gmail.com>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Stateless applications
Posted by Marcus Brito <mb...@gmail.com>.
> When I've tried to go stateless, I've run into problems using
> contrib:Table, and I honestly haven't taken the time to work around it.
> Does anyone have suggestions (or preferably an example) for dealing
> with contrib:Table in a stateless app?
Yes, contrib:Table needs an instance of ITableSessionStateManager to
record and restore it's state. The default implementation saves lots
of info in the session, and thus is innapropriate for stateless
applications. In that case, you should use a
NullTableSessionStateManager to avoid storing data in the session.
Please read the guide for the contrib:TableView[1] for more
information on this subject.
> The other times I've found it tricky is when I have a form with hidden
> fields to replace persistent properties, but I need a DirectLink
> somewhere on the page. Since DirectLink is not a form submit, I of
> course lose all of my hidden form values. So, it's easier to just make
> them persistent. For complex forms, it is not practical to duplicate
> all the hidden properties as DirectLink parameters. Any ideas?
If your hidden fields aren't updated by the client, and are used only
to forward information from one page to another one, you could use an
ActionLink[2] instead of a DirectLink. ActionLink will perform a full
page rewind, so when the listener is invoked, the value for the hidden
field will be in place.
If your hidden fields *are* updated by the client (most likely), I
think the best solution is to actually perform a form submission
instead of working with DirectLinks. There's no "SubmitLink" in the
bundled library, but it would be easy to write a component that
renders a link that uses javascript to submit the containing form --
take a look at the Script[3] component for your javascript needs.
[1] http://jakarta.apache.org/tapestry/doc/ComponentReference/contrib.TableView.html
[2] http://jakarta.apache.org/tapestry/doc/ComponentReference/ActionLink.html
[3] http://jakarta.apache.org/tapestry/doc/ComponentReference/Script.html
-- Marcus Brito <mb...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Stateless applications
Posted by Shawn Church <sh...@boxity.com>.
Two difficulties come immediately to mind:
When I've tried to go stateless, I've run into problems using
contrib:Table, and I honestly haven't taken the time to work around it.
Does anyone have suggestions (or preferably an example) for dealing
with contrib:Table in a stateless app?
The other times I've found it tricky is when I have a form with hidden
fields to replace persistent properties, but I need a DirectLink
somewhere on the page. Since DirectLink is not a form submit, I of
course lose all of my hidden form values. So, it's easier to just make
them persistent. For complex forms, it is not practical to duplicate
all the hidden properties as DirectLink parameters. Any ideas?
Shawn
Quoting Erik Hatcher <er...@ehatchersolutions.com>:
> What Danny said.... I'll add that as long as you never call
> getVisit()
> the application stays stateless.
>
> Erik
>
> On Mar 3, 2005, at 11:43 AM, Eric Jain wrote:
>
> > Is Tapestry suitable for stateless applications? By stateless I
> mean
> > no session objects, no cookies, nothing. This, together with the
> > ability to define custom web addresses, would be a killer feature,
> at
> > least for us.
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Stateless applications
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
Oops... yes, that is correct - persistent properties force a session
also.
Erik
On Mar 4, 2005, at 2:36 PM, Kevin Menard wrote:
> On 3/3/05 11:58 AM, "Erik Hatcher" <er...@ehatchersolutions.com> wrote:
>
>> What Danny said.... I'll add that as long as you never call getVisit()
>> the application stays stateless.
>
> How do persistent properties work then? I thought they went into a
> session
> object.
>
> --
> Kevin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Stateless applications
Posted by Danny Mandel <dm...@tolweb.org>.
That is correct. The use of persistent properties will force a session
to be created as they are indeed stored in the session.
Danny
Kevin Menard wrote:
>On 3/3/05 11:58 AM, "Erik Hatcher" <er...@ehatchersolutions.com> wrote:
>
>
>
>>What Danny said.... I'll add that as long as you never call getVisit()
>>the application stays stateless.
>>
>>
>
>How do persistent properties work then? I thought they went into a session
>object.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Stateless applications
Posted by Kevin Menard <ni...@negativetwenty.net>.
On 3/3/05 11:58 AM, "Erik Hatcher" <er...@ehatchersolutions.com> wrote:
> What Danny said.... I'll add that as long as you never call getVisit()
> the application stays stateless.
How do persistent properties work then? I thought they went into a session
object.
--
Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Stateless applications
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
What Danny said.... I'll add that as long as you never call getVisit()
the application stays stateless.
Erik
On Mar 3, 2005, at 11:43 AM, Eric Jain wrote:
> Is Tapestry suitable for stateless applications? By stateless I mean
> no session objects, no cookies, nothing. This, together with the
> ability to define custom web addresses, would be a killer feature, at
> least for us.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org