As a User, which two items would you personally most like to see in the next Tapestry Release?

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

As a User, which two items would you personally most like to see in the next Tapestry Release?

Patrick Casey

        Hi Folks,

I'm vaguely inspired by a thread that's been floating around wherein a
couple of us have been talking about the forthcoming Tapestry release. I
thought I'd see if I could get some feedback from the community at large and
this might be a decent first step.

So I'm asking what would *you* most like to see in a future Tapestry
release? I'll start the ball rolling with something I'd like to see, but in
the grand scheme of things what I want isn't anywhere near as important as
what the community as a whole wants so please feel free to add to or comment
upon the list.

Also as I'm not a dev, I'm not remotely able to comment on the feasibility
of any of these suggestions (that's a whole second discussion), so I'm
mostly hoping to just get together a list of stuff we'd like to see and let
the devs sort out what can and can't be done as they can answer that
question a lot better than we can. I would ask though that we try to keep
things at least remotely feasible e.g. "The next version of Tapestry should
print $20.00 bills" probably shouldn't make its way onto the list :).

Suggestion 1: Fix Rewind

There are other web gui frameworks I've worked with (.NET for one) that
don't have all the rewind problems that Tapestry does. For .NET at least,
they solve the solution by "packing" all the data on a form into a
compressed serialized form and sending it off on a hidden field. They then
reconstruct the form off of that serialized hidden field rather than off of
session memory so they avoid stale links, the need to keep crap around in
session memory, and the ever-present danger in a multi-user system that
somebody else might have changed the data in question between the time a
form as rendered and the time it was rewound.

I understand that you can do something vaguely like this via datasqueezers,
but it's far from a transparent implementation. I'd dearly love for Tapestry
rewinds to "just work" every time by default.

Suggestion 2: Better Defaulting

Right now in Tapestry, I have to fill in a lot of fairly repetitive data to
set up a form/page combination. It's certainly not an J2EE configuration,
but it's still a bit of a pain in the posterior if you ask me. I'd love the
ability for the system to have an intelligent defaulting convention that I
as a developer, could optionally use if I didn't want to specify anything.
To take advantage of this defaulting behavior I'd probably have to follow
some (fairly strict) naming and file structure rules, but then I'm not
*forced* to do so, I can always use my own conventions and name everything
myself in the .page files.

Some possible examples:

1) If no page class is specified, try to classLoad one named
forms/<PageName>. If that doesn't work, use BasePage.
2) If a text field is bound to a numeric property, add a default number
validator automagically.
3) This one's a reach I know but ... I'd love a default "scaffold" form
that'll throw up an ugly but functional edit form for the public properties
on an arbitrary object.

So what does everyone else want? Don't be shy :).

--- Pat



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: As a User, which two items would you personally most like to see in the next Tapestry Release?

Marko Kocić-2
I would like to be able to get rid completely of .jwc and .page files.
Since java 1.5 has annotations, it would be good if user had an option
to configure component/page through annotations.
.jwc and .page files could still be used to override annotations.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: As a User, which two items would you personally most like to see in the next Tapestry Release?

Gene Volovich
In reply to this post by Patrick Casey
I would very much like to see the rewind fix you are talking about.  A
while ago I wrote my own web framework for my application, similar to
Struts, but using a home-grown templating mechanism instead of JSP,  
and I implemented this feature in a similar way you mentioned .NET did,
except I had hidden fields for each data element I wanted to pass
through instead of packing all of them in.  I found this feature very
useful for me.

Gene

On May 6, 2005, at 11:28 AM, Patrick Casey wrote:

>
> Hi Folks,
>
> I'm vaguely inspired by a thread that's been floating around wherein a
> couple of us have been talking about the forthcoming Tapestry release.
> I
> thought I'd see if I could get some feedback from the community at
> large and
> this might be a decent first step.
>
> So I'm asking what would *you* most like to see in a future Tapestry
> release? I'll start the ball rolling with something I'd like to see,
> but in
> the grand scheme of things what I want isn't anywhere near as
> important as
> what the community as a whole wants so please feel free to add to or
> comment
> upon the list.
>
> Also as I'm not a dev, I'm not remotely able to comment on the
> feasibility
> of any of these suggestions (that's a whole second discussion), so I'm
> mostly hoping to just get together a list of stuff we'd like to see
> and let
> the devs sort out what can and can't be done as they can answer that
> question a lot better than we can. I would ask though that we try to
> keep
> things at least remotely feasible e.g. "The next version of Tapestry
> should
> print $20.00 bills" probably shouldn't make its way onto the list :).
>
> Suggestion 1: Fix Rewind
>
> There are other web gui frameworks I've worked with (.NET for one) that
> don't have all the rewind problems that Tapestry does. For .NET at
> least,
> they solve the solution by "packing" all the data on a form into a
> compressed serialized form and sending it off on a hidden field. They
> then
> reconstruct the form off of that serialized hidden field rather than
> off of
> session memory so they avoid stale links, the need to keep crap around
> in
> session memory, and the ever-present danger in a multi-user system that
> somebody else might have changed the data in question between the time
> a
> form as rendered and the time it was rewound.
>
> I understand that you can do something vaguely like this via
> datasqueezers,
> but it's far from a transparent implementation. I'd dearly love for
> Tapestry
> rewinds to "just work" every time by default.
>
> Suggestion 2: Better Defaulting
>
> Right now in Tapestry, I have to fill in a lot of fairly repetitive
> data to
> set up a form/page combination. It's certainly not an J2EE
> configuration,
> but it's still a bit of a pain in the posterior if you ask me. I'd
> love the
> ability for the system to have an intelligent defaulting convention
> that I
> as a developer, could optionally use if I didn't want to specify
> anything.
> To take advantage of this defaulting behavior I'd probably have to
> follow
> some (fairly strict) naming and file structure rules, but then I'm not
> *forced* to do so, I can always use my own conventions and name
> everything
> myself in the .page files.
>
> Some possible examples:
>
> 1) If no page class is specified, try to classLoad one named
> forms/<PageName>. If that doesn't work, use BasePage.
> 2) If a text field is bound to a numeric property, add a default number
> validator automagically.
> 3) This one's a reach I know but ... I'd love a default "scaffold" form
> that'll throw up an ugly but functional edit form for the public
> properties
> on an arbitrary object.
>
> So what does everyone else want? Don't be shy :).
>
> --- Pat
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: As a User, which two items would you personally most like to see in the next Tapestry Release?

Warner Onstine-2
In reply to this post by Patrick Casey
Here are the two that I would love to see get fixed:
1) Better validation and field labeling - I know Paul is working on
this so I will be digging into it for the book most definitely
Specifically I would like to see the following:
The ability to conditionally validate a field (ie - one field has a
particular value which means a second field now needs to be validated)
2) Get rid of the flat-file nature of templates and page files - I
believe that this is being fixed in the next release

I know nothing of the form rewind problems. I've seen posts, but
haven't seen this issue myself. Now that I'm digging into a much larger
app this will become an issue.

-warner

On May 6, 2005, at 8:28 AM, Patrick Casey wrote:

>
> Hi Folks,
>
> I'm vaguely inspired by a thread that's been floating around wherein a
> couple of us have been talking about the forthcoming Tapestry release.
> I
> thought I'd see if I could get some feedback from the community at
> large and
> this might be a decent first step.
>
> So I'm asking what would *you* most like to see in a future Tapestry
> release? I'll start the ball rolling with something I'd like to see,
> but in
> the grand scheme of things what I want isn't anywhere near as
> important as
> what the community as a whole wants so please feel free to add to or
> comment
> upon the list.
>
> Also as I'm not a dev, I'm not remotely able to comment on the
> feasibility
> of any of these suggestions (that's a whole second discussion), so I'm
> mostly hoping to just get together a list of stuff we'd like to see
> and let
> the devs sort out what can and can't be done as they can answer that
> question a lot better than we can. I would ask though that we try to
> keep
> things at least remotely feasible e.g. "The next version of Tapestry
> should
> print $20.00 bills" probably shouldn't make its way onto the list :).
>
> Suggestion 1: Fix Rewind
>
> There are other web gui frameworks I've worked with (.NET for one) that
> don't have all the rewind problems that Tapestry does. For .NET at
> least,
> they solve the solution by "packing" all the data on a form into a
> compressed serialized form and sending it off on a hidden field. They
> then
> reconstruct the form off of that serialized hidden field rather than
> off of
> session memory so they avoid stale links, the need to keep crap around
> in
> session memory, and the ever-present danger in a multi-user system that
> somebody else might have changed the data in question between the time
> a
> form as rendered and the time it was rewound.
>
> I understand that you can do something vaguely like this via
> datasqueezers,
> but it's far from a transparent implementation. I'd dearly love for
> Tapestry
> rewinds to "just work" every time by default.
>
> Suggestion 2: Better Defaulting
>
> Right now in Tapestry, I have to fill in a lot of fairly repetitive
> data to
> set up a form/page combination. It's certainly not an J2EE
> configuration,
> but it's still a bit of a pain in the posterior if you ask me. I'd
> love the
> ability for the system to have an intelligent defaulting convention
> that I
> as a developer, could optionally use if I didn't want to specify
> anything.
> To take advantage of this defaulting behavior I'd probably have to
> follow
> some (fairly strict) naming and file structure rules, but then I'm not
> *forced* to do so, I can always use my own conventions and name
> everything
> myself in the .page files.
>
> Some possible examples:
>
> 1) If no page class is specified, try to classLoad one named
> forms/<PageName>. If that doesn't work, use BasePage.
> 2) If a text field is bound to a numeric property, add a default number
> validator automagically.
> 3) This one's a reach I know but ... I'd love a default "scaffold" form
> that'll throw up an ugly but functional edit form for the public
> properties
> on an arbitrary object.
>
> So what does everyone else want? Don't be shy :).
>
> --- Pat
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: As a User, which two items would you personally most like to see in the next Tapestry Release?

Mind Bridge
In reply to this post by Patrick Casey
Hi Patrick,

> Suggestion 1: Fix Rewind

Do you mean something like ListEdit or FormConditional in the current
version? Using those within a Form should resolve most stale link problems,
I believe.

You may also want to have a look at the If, Else, and For components on
www.t-deli.com -- they combine Conditional and FormConditional, as well as
Foreach and ListEdit, for example, and determine automatically (and
transparently) whether to create hidden fields.
There is a discussion on tapestry-dev on how to best add those to 4.0.


----- Original Message -----
From: "Patrick Casey" <[hidden email]>
To: "'Tapestry users'" <[hidden email]>
Sent: Friday, May 06, 2005 6:28 PM
Subject: As a User, which two items would you personally most like to see in
the next Tapestry Release?


>
> Hi Folks,
>
> I'm vaguely inspired by a thread that's been floating around wherein a
> couple of us have been talking about the forthcoming Tapestry release. I
> thought I'd see if I could get some feedback from the community at large
and
> this might be a decent first step.
>
> So I'm asking what would *you* most like to see in a future Tapestry
> release? I'll start the ball rolling with something I'd like to see, but
in
> the grand scheme of things what I want isn't anywhere near as important as
> what the community as a whole wants so please feel free to add to or
comment
> upon the list.
>
> Also as I'm not a dev, I'm not remotely able to comment on the feasibility
> of any of these suggestions (that's a whole second discussion), so I'm
> mostly hoping to just get together a list of stuff we'd like to see and
let
> the devs sort out what can and can't be done as they can answer that
> question a lot better than we can. I would ask though that we try to keep
> things at least remotely feasible e.g. "The next version of Tapestry
should
> print $20.00 bills" probably shouldn't make its way onto the list :).
>
> Suggestion 1: Fix Rewind
>
> There are other web gui frameworks I've worked with (.NET for one) that
> don't have all the rewind problems that Tapestry does. For .NET at least,
> they solve the solution by "packing" all the data on a form into a
> compressed serialized form and sending it off on a hidden field. They then
> reconstruct the form off of that serialized hidden field rather than off
of
> session memory so they avoid stale links, the need to keep crap around in
> session memory, and the ever-present danger in a multi-user system that
> somebody else might have changed the data in question between the time a
> form as rendered and the time it was rewound.
>
> I understand that you can do something vaguely like this via
datasqueezers,
> but it's far from a transparent implementation. I'd dearly love for
Tapestry
> rewinds to "just work" every time by default.
>
> Suggestion 2: Better Defaulting
>
> Right now in Tapestry, I have to fill in a lot of fairly repetitive data
to
> set up a form/page combination. It's certainly not an J2EE configuration,
> but it's still a bit of a pain in the posterior if you ask me. I'd love
the

> ability for the system to have an intelligent defaulting convention that I
> as a developer, could optionally use if I didn't want to specify anything.
> To take advantage of this defaulting behavior I'd probably have to follow
> some (fairly strict) naming and file structure rules, but then I'm not
> *forced* to do so, I can always use my own conventions and name everything
> myself in the .page files.
>
> Some possible examples:
>
> 1) If no page class is specified, try to classLoad one named
> forms/<PageName>. If that doesn't work, use BasePage.
> 2) If a text field is bound to a numeric property, add a default number
> validator automagically.
> 3) This one's a reach I know but ... I'd love a default "scaffold" form
> that'll throw up an ugly but functional edit form for the public
properties

> on an arbitrary object.
>
> So what does everyone else want? Don't be shy :).
>
> --- Pat
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: As a User, which two items would you personally most like to see in the next Tapestry Release?

Patrick Casey


-----Original Message-----
From: Mind Bridge [mailto:[hidden email]]
Sent: Friday, May 06, 2005 9:49 AM
To: Tapestry users
Subject: Re: As a User, which two items would you personally most like to
see in the next Tapestry Release?

Hi Patrick,

> Suggestion 1: Fix Rewind

Do you mean something like ListEdit or FormConditional in the current
version? Using those within a Form should resolve most stale link problems,
I believe.
<snip>

For any given special case, I can usually get a rewind to work through a
combination of measures like you described. The thing is though I have to
*do* something to make it work almost every time. To me that makes it an
untrustworthy feature and one I can't rely on (which is why my apps only
directlinks almost exclusively).

In contrast lots of other parts of tapestry just work. DirectLinks *just
work*. User pushes link, listener fires, I do stuff. It works 100% of the
time, every time and I don't have to much around with it for hours to get it
to work.

I'd love for rewinds to *just work*. Basically I'd like to see a general
case developer level solution to the problem so that no tapestry user ever
has to worry about the rewind cycle again.





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: As a User, which two items would you personally most like to see in the next Tapestry Release?

Mind Bridge
Just curious: can you come up with a case when you will get a stale link
problem if you use If and For instead of Foreach, etc?

>
>
> -----Original Message-----
> From: Mind Bridge [mailto:[hidden email]]
> Sent: Friday, May 06, 2005 9:49 AM
> To: Tapestry users
> Subject: Re: As a User, which two items would you personally most like to
> see in the next Tapestry Release?
>
> Hi Patrick,
>
> > Suggestion 1: Fix Rewind
>
> Do you mean something like ListEdit or FormConditional in the current
> version? Using those within a Form should resolve most stale link
problems,

> I believe.
> <snip>
>
> For any given special case, I can usually get a rewind to work through a
> combination of measures like you described. The thing is though I have to
> *do* something to make it work almost every time. To me that makes it an
> untrustworthy feature and one I can't rely on (which is why my apps only
> directlinks almost exclusively).
>
> In contrast lots of other parts of tapestry just work. DirectLinks *just
> work*. User pushes link, listener fires, I do stuff. It works 100% of the
> time, every time and I don't have to much around with it for hours to get
it

> to work.
>
> I'd love for rewinds to *just work*. Basically I'd like to see a general
> case developer level solution to the problem so that no tapestry user ever
> has to worry about the rewind cycle again.
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: As a User, which two items would you personally most like to see in the next Tapestry Release?

Denis Souza
In reply to this post by Patrick Casey
Hi,

        I'm relatively new to Tapestry but I do have quite a few years of
experience with web development. Most of my experience comes from using
WebObjects, which made it easier for me to learn Tapestry. In general, I
really like the way Tapestry works (otherwise I wouldn't be using it :) )
but a few things were a bit of a disappointment for me when I learned about
them, so here they are as suggestions for a future release:

1) Fix and hide rewind
        I strongly agree with your opinion about rewind. Dynamic web pages
have gone a long way since cgi scripts and having to worry about the use of
the back button should already be a thing of the past. As I see it, Tapestry
users shouldn't even have to be aware of the rewind cycle. I think this goes
a bit beyond just restoring the page to a previous state. I find it
extremely annoying to have my submit button listeners be called during the
rewind cycle when you can't actually do anything important. You end up with
all of the page's logic crammed into the single form listener method full of
IFs to decide what to do next.

2) More flexibility when passing parameters to pages
        I don't know if I just haven't learned enough about Tapestry to find
a better way to do this, but I really don't enjoy the way parameters are
passed from a page to another either using DirectLink or ExternalLink. The
concept of service parameters gives me a sensation that I'm leaving some
things hard-coded since the parameters need to be in a certain order. When I
read the parameters on the receiving page I have to make absolutely sure I'm
reading them in the exact same order as I passed them. So if I change the
order of parameters in a page I have to go around correcting every single
page that has a reference to it and there is no way to check that at
compile-time so I can't be sure I didn't break anything unless I write tests
for it. My suggestion here is that service parameters each have a
(user-defined) name so you can pass the parameters in whichever order you
want and still be sure you're not breaking anything at the receiving end. It
would also help when integrating to external services that insist on passing
URL parameters with names you have no control over. Eg. An integration with
another web site (such as an online payment system) might call your URL with
a "transaction-id" parameter (and maybe other additional parameters whose
names you can't control).


There are other smaller things I'd like to see changed, but these two are
the most important in my opinion.

Denis


-----Original Message-----
From: Patrick Casey [mailto:[hidden email]]
Sent: sexta-feira, 6 de maio de 2005 12:28
To: 'Tapestry users'
Subject: As a User, which two items would you personally most like to see in
the next Tapestry Release?


        Hi Folks,

I'm vaguely inspired by a thread that's been floating around wherein a
couple of us have been talking about the forthcoming Tapestry release. I
thought I'd see if I could get some feedback from the community at large and
this might be a decent first step.

So I'm asking what would *you* most like to see in a future Tapestry
release? I'll start the ball rolling with something I'd like to see, but in
the grand scheme of things what I want isn't anywhere near as important as
what the community as a whole wants so please feel free to add to or comment
upon the list.

Also as I'm not a dev, I'm not remotely able to comment on the feasibility
of any of these suggestions (that's a whole second discussion), so I'm
mostly hoping to just get together a list of stuff we'd like to see and let
the devs sort out what can and can't be done as they can answer that
question a lot better than we can. I would ask though that we try to keep
things at least remotely feasible e.g. "The next version of Tapestry should
print $20.00 bills" probably shouldn't make its way onto the list :).

Suggestion 1: Fix Rewind

There are other web gui frameworks I've worked with (.NET for one) that
don't have all the rewind problems that Tapestry does. For .NET at least,
they solve the solution by "packing" all the data on a form into a
compressed serialized form and sending it off on a hidden field. They then
reconstruct the form off of that serialized hidden field rather than off of
session memory so they avoid stale links, the need to keep crap around in
session memory, and the ever-present danger in a multi-user system that
somebody else might have changed the data in question between the time a
form as rendered and the time it was rewound.

I understand that you can do something vaguely like this via datasqueezers,
but it's far from a transparent implementation. I'd dearly love for Tapestry
rewinds to "just work" every time by default.

Suggestion 2: Better Defaulting

Right now in Tapestry, I have to fill in a lot of fairly repetitive data to
set up a form/page combination. It's certainly not an J2EE configuration,
but it's still a bit of a pain in the posterior if you ask me. I'd love the
ability for the system to have an intelligent defaulting convention that I
as a developer, could optionally use if I didn't want to specify anything.
To take advantage of this defaulting behavior I'd probably have to follow
some (fairly strict) naming and file structure rules, but then I'm not
*forced* to do so, I can always use my own conventions and name everything
myself in the .page files.

Some possible examples:

1) If no page class is specified, try to classLoad one named
forms/<PageName>. If that doesn't work, use BasePage.
2) If a text field is bound to a numeric property, add a default number
validator automagically.
3) This one's a reach I know but ... I'd love a default "scaffold" form
that'll throw up an ugly but functional edit form for the public properties
on an arbitrary object.

So what does everyone else want? Don't be shy :).

--- Pat



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: As a User, which two items would you personally most like to see in the next Tapestry Release?

Patrick Casey
In reply to this post by Mind Bridge

Just curious: can you come up with a case when you will get a stale link
problem if you use If and For instead of Foreach, etc?

I haven't yet, but I don't feel like I should have to go out and get a third
party library to make iteration work. I just want to download Tapestry,
follow the sample code in the doc, and end up with an application that just
works.

I want the OOB component set to rewind perfectly every time with no
intervention on my part, no third party libraries, and no massaging of my
forms to worry about things like order of operations and/or changing
something during the rewind cycle.

As I said before I know that if I try hard enough I can solve the special
case of any specific rewind issue e.g. there's always a way to make it work.
I don't feel like I should have to solve that problem at all though; I feel
like the OOB platform should hide all that nastiness from me and let me
worry about application behavior rather than esoteric form rewind issues.



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: As a User, which two items would you personally most like to see in the next Tapestry Release?

Chris Nelson
In reply to this post by Patrick Casey
Apologies if someone alreay said this, but that
"scaffold" component you are talking about is in
Trails.  

http://trails.dev.java.net/

--- Patrick Casey <[hidden email]> wrote:

>
> Hi Folks,
>
> I'm vaguely inspired by a thread that's been
> floating around wherein a
> couple of us have been talking about the forthcoming
> Tapestry release. I
> thought I'd see if I could get some feedback from
> the community at large and
> this might be a decent first step.
>
> So I'm asking what would *you* most like to see in a
> future Tapestry
> release? I'll start the ball rolling with something
> I'd like to see, but in
> the grand scheme of things what I want isn't
> anywhere near as important as
> what the community as a whole wants so please feel
> free to add to or comment
> upon the list.
>
> Also as I'm not a dev, I'm not remotely able to
> comment on the feasibility
> of any of these suggestions (that's a whole second
> discussion), so I'm
> mostly hoping to just get together a list of stuff
> we'd like to see and let
> the devs sort out what can and can't be done as they
> can answer that
> question a lot better than we can. I would ask
> though that we try to keep
> things at least remotely feasible e.g. "The next
> version of Tapestry should
> print $20.00 bills" probably shouldn't make its way
> onto the list :).
>
> Suggestion 1: Fix Rewind
>
> There are other web gui frameworks I've worked with
> (.NET for one) that
> don't have all the rewind problems that Tapestry
> does. For .NET at least,
> they solve the solution by "packing" all the data on
> a form into a
> compressed serialized form and sending it off on a
> hidden field. They then
> reconstruct the form off of that serialized hidden
> field rather than off of
> session memory so they avoid stale links, the need
> to keep crap around in
> session memory, and the ever-present danger in a
> multi-user system that
> somebody else might have changed the data in
> question between the time a
> form as rendered and the time it was rewound.
>
> I understand that you can do something vaguely like
> this via datasqueezers,
> but it's far from a transparent implementation. I'd
> dearly love for Tapestry
> rewinds to "just work" every time by default.
>
> Suggestion 2: Better Defaulting
>
> Right now in Tapestry, I have to fill in a lot of
> fairly repetitive data to
> set up a form/page combination. It's certainly not
> an J2EE configuration,
> but it's still a bit of a pain in the posterior if
> you ask me. I'd love the
> ability for the system to have an intelligent
> defaulting convention that I
> as a developer, could optionally use if I didn't
> want to specify anything.
> To take advantage of this defaulting behavior I'd
> probably have to follow
> some (fairly strict) naming and file structure
> rules, but then I'm not
> *forced* to do so, I can always use my own
> conventions and name everything
> myself in the .page files.
>
> Some possible examples:
>
> 1) If no page class is specified, try to classLoad
> one named
> forms/<PageName>. If that doesn't work, use
> BasePage.
> 2) If a text field is bound to a numeric property,
> add a default number
> validator automagically.
> 3) This one's a reach I know but ... I'd love a
> default "scaffold" form
> that'll throw up an ugly but functional edit form
> for the public properties
> on an arbitrary object.
>
> So what does everyone else want? Don't be shy :).
>
> --- Pat
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [hidden email]
> For additional commands, e-mail:
> [hidden email]
>
>


               
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: As a User, which two items would you personally most like to see in the next Tapestry Release?

Erik Hatcher
In reply to this post by Patrick Casey

On May 6, 2005, at 1:30 PM, Patrick Casey wrote:

>
> Just curious: can you come up with a case when you will get a stale  
> link
> problem if you use If and For instead of Foreach, etc?
>
> I haven't yet, but I don't feel like I should have to go out and  
> get a third
> party library to make iteration work. I just want to download  
> Tapestry,
> follow the sample code in the doc, and end up with an application  
> that just
> works.

Patrick - first, your e-mail replies are not clearly separated from  
what you quote, so it is hard to follow what someone else said versus  
what you add.

Next - Mindbridge is asking you so that he can help alleviate the  
issue you've brought up - so if you could bear with him and ensure  
that his components fix the issue then he'll integrate them into  
Tapestry 4.0!

     Erik


>
> I want the OOB component set to rewind perfectly every time with no
> intervention on my part, no third party libraries, and no massaging  
> of my
> forms to worry about things like order of operations and/or changing
> something during the rewind cycle.
>
> As I said before I know that if I try hard enough I can solve the  
> special
> case of any specific rewind issue e.g. there's always a way to make  
> it work.
> I don't feel like I should have to solve that problem at all  
> though; I feel
> like the OOB platform should hide all that nastiness from me and  
> let me
> worry about application behavior rather than esoteric form rewind  
> issues.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: As a User, which two items would you personally most like to see in the next Tapestry Release?

Michael Musson
One example like what I think Patrick is saying is the evil browser
back button. One benefit of pushing persistence to the form like .NET
is that the "context" stays in sync with the browser (ie. I go back to
a previous version of the page (now stale) but the embeded context is
also stale (consistent with the page).

On May 6, 2005, at 1:30 PM, Patrick Casey wrote:
> Just curious: can you come up with a case when you will get a stale
> link
> problem if you use If and For instead of Foreach, etc?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: As a User, which two items would you personally most like to see in the next Tapestry Release?

Patrick Casey
In reply to this post by Erik Hatcher


> -----Original Message-----
> From: Erik Hatcher [mailto:[hidden email]]
> Sent: Friday, May 06, 2005 11:21 AM
> To: Tapestry users
> Subject: Re: As a User, which two items would you personally most like to
> see in the next Tapestry Release?
<snip>
> Patrick - first, your e-mail replies are not clearly separated from
> what you quote, so it is hard to follow what someone else said versus
> what you add.

Sorry, I'm using outlook for email and I hadn't bothered to set carot
quoting yet on my laptop. Hopefully this will be easier for everyone to read
:).

>
> Next - Mindbridge is asking you so that he can help alleviate the
> issue you've brought up - so if you could bear with him and ensure
> that his components fix the issue then he'll integrate them into
> Tapestry 4.0!
>

        I'm happy to help test and/or answer questions. As you've no doubt
guessed the rewind cycle is my personal bugaboo so anything I can do to help
improve its handling is a good thing :).

        On the specifics of the rewind cycle, I think it's really two
distinct things that I find "unnatural".

        A) The rewind cycle is frail and can get confused unless you use
techniques like Mindbridge suggested. I'd love to see those sorts of
"guaranteed-safe-rewind" components become the default for 4.0 (maybe
deprecate foreach?)
        B) On a parallel but slightly unrelated note I still have trouble
with the order of operations of listeners where they get called during
rewind. As Dennis mentioned it requires sort of weird programming juditsu to
have listeners fire *during* rewind. I'd love to see my listeners always
fire after rewind when it was safe to do things.

        In any even I'm glad to hear it's being looked at for 4.0. It may be
a relatively minor issue for some people and some sorts of apps, but for the
kind of stuff I do (which works with lots of users and highly volatile data
sets), it's definitely the top of my personal wish list.

        --- Pat



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: As a User, which two items would you personally most like to see in the next Tapestry Release?

Howard Lewis Ship
In reply to this post by Patrick Casey
>
>
> I want the OOB component set to rewind perfectly every time with no
> intervention on my part, no third party libraries, and no massaging of my
> forms to worry about things like order of operations and/or changing
> something during the rewind cycle.



.Net severly constrains the objects that can be present "on the page" in
terms of their own, specific APIs for database access, etc.
That won't fly in the Java world ... Tapestry needs to stay compatibly with
JDO/EJB/Hibernate/Castor/Ad-hoc/raw JDBC. Flexibilty can be a curse.
MindBridge's For component rolls together Foreach and ListEdit nicely, but
still needs some configuration to figure out which object property is stored
into the form, and how to convert it back to an object during the form
submission.

If you look at the pace of changes recently, you might just pick up on how
important HiveMind is to Tapestry 4.0. Here's a few cool things I've been
able to add, largely because of HiveMInd:
- A plethora of binding prefixs (supplmenting "ognl:" and "message:") that
simplify templates and offer much better performance (no reflection)
- Much smarter component parameters that just work without having to figure
out the right "direction"
- Persisent properties stored on the client as query parameters and hidden
fields
- Improved line-precise exception reporting that displays the actual source
- Native JSR-168 Portlet support, as an add-on library
- Native, configrable friendly URLs without a seperate patch
- Elimination of trivial .page files
- Modular applications (spread across multiple folders)

... and much more that slips my mind. Most of these were driven by my own
needs (as a Tapestry user, not as a Tapestry developer) and those of the
community. I'm the guy at the front of the class room who sees what's
tripping people up the worst.

The input is valuable, and 4.0 will be a significantly better platform to
develop applications and reusable components on. It's all a matter of
prioritization. The HiveMind work, and the improved test suite, lets me move
faster and faster and make more and more aggressive changes.



--
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
Reply | Threaded
Open this post in threaded view
|

Re: As a User, which two items would you personally most like to see in the next Tapestry Release?

Howard Lewis Ship
In reply to this post by Michael Musson
Yes, and persistent properties on the client help ensure that the
appllication state stays associated with the request not the session.

On 5/6/05, Michael Musson <[hidden email]> wrote:

>
> One example like what I think Patrick is saying is the evil browser
> back button. One benefit of pushing persistence to the form like .NET
> is that the "context" stays in sync with the browser (ie. I go back to
> a previous version of the page (now stale) but the embeded context is
> also stale (consistent with the page).
>
> On May 6, 2005, at 1:30 PM, Patrick Casey wrote:
> > Just curious: can you come up with a case when you will get a stale
> > link
> > problem if you use If and For instead of Foreach, etc?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
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
Reply | Threaded
Open this post in threaded view
|

Re: As a User, which two items would you personally most like to see in the next Tapestry Release?

Gregg D Bolinger
In reply to this post by Howard Lewis Ship
Sounds very exciting Howard.  Keep up the good work.

Gregg Bolinger

On 5/6/05, Howard Lewis Ship <[hidden email]> wrote:

> >
> >
> > I want the OOB component set to rewind perfectly every time with no
> > intervention on my part, no third party libraries, and no massaging of my
> > forms to worry about things like order of operations and/or changing
> > something during the rewind cycle.
>
> .Net severly constrains the objects that can be present "on the page" in
> terms of their own, specific APIs for database access, etc.
> That won't fly in the Java world ... Tapestry needs to stay compatibly with
> JDO/EJB/Hibernate/Castor/Ad-hoc/raw JDBC. Flexibilty can be a curse.
> MindBridge's For component rolls together Foreach and ListEdit nicely, but
> still needs some configuration to figure out which object property is stored
> into the form, and how to convert it back to an object during the form
> submission.
>
> If you look at the pace of changes recently, you might just pick up on how
> important HiveMind is to Tapestry 4.0. Here's a few cool things I've been
> able to add, largely because of HiveMInd:
> - A plethora of binding prefixs (supplmenting "ognl:" and "message:") that
> simplify templates and offer much better performance (no reflection)
> - Much smarter component parameters that just work without having to figure
> out the right "direction"
> - Persisent properties stored on the client as query parameters and hidden
> fields
> - Improved line-precise exception reporting that displays the actual source
> - Native JSR-168 Portlet support, as an add-on library
> - Native, configrable friendly URLs without a seperate patch
> - Elimination of trivial .page files
> - Modular applications (spread across multiple folders)
>
> ... and much more that slips my mind. Most of these were driven by my own
> needs (as a Tapestry user, not as a Tapestry developer) and those of the
> community. I'm the guy at the front of the class room who sees what's
> tripping people up the worst.
>
> The input is valuable, and 4.0 will be a significantly better platform to
> develop applications and reusable components on. It's all a matter of
> prioritization. The HiveMind work, and the improved test suite, lets me move
> faster and faster and make more and more aggressive changes.
>
> --
> 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
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: As a User, which two items would you personally most like to see in the next Tapestry Release?

Mark Stang
In reply to this post by Patrick Casey
Which is wrong in so many ways...

We are doing this backwards!  The session is what must be considered current not the request.  If I store state in request and then delete something in another request, when the first request returns data is missing, bad things happen!

Ignore the request if it doesn't match the current state of the session.  Rewind does a very nice job.  The very first time it finds something out of sync, it tosses you out and quits trying to do the rewind.  I need to make it more robust so that I can detect the rewind at the beginning before bad things happen.  I suspect there is a way to fool it by using the same screen and changing it so it "matches" the rewind, but screws up the data.  Right now my screens are so different that the rewind bails on finding mis-matched fields, which is a good thing.

Detect that the user has done something wrong, warn them and move on!

I think Howard should put in a "token" that changes with every screen randomly and if it doesn't match what is happening, then throw them out!!!

This is a common technique with databases.  When you save data, put in a timestamp.  When it comes time to update the same data, if the timestamp doesn't match, then they don't have the current data, throw them out!  Now databases have a nicer interface, they can override the timestamp and force it to save it anyway.  Of course, other rows and your entire data model might get out of sync if they did that!  What we have here is last one in wins, all others are rejected!  Tapestry has a good start on that process.

regards,

Mark


-----Original Message-----
From: Howard Lewis Ship [mailto:[hidden email]]
Sent: Fri 5/6/2005 12:55 PM
To: Tapestry users; Michael Musson
Subject: Re: As a User, which two items would you personally most like to see in the next Tapestry Release?
 
Yes, and persistent properties on the client help ensure that the
appllication state stays associated with the request not the session.

On 5/6/05, Michael Musson <[hidden email]> wrote:

>
> One example like what I think Patrick is saying is the evil browser
> back button. One benefit of pushing persistence to the form like .NET
> is that the "context" stays in sync with the browser (ie. I go back to
> a previous version of the page (now stale) but the embeded context is
> also stale (consistent with the page).
>
> On May 6, 2005, at 1:30 PM, Patrick Casey wrote:
> > Just curious: can you come up with a case when you will get a stale
> > link
> > problem if you use If and For instead of Foreach, etc?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
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

Reply | Threaded
Open this post in threaded view
|

RE: As a User, which two items would you personally most like to see in the next Tapestry Release?

Patrick Casey

        Mark,

I've shipped apps that used an approach like you're describing e.g. keep
state in the session and "break" if the user had the audacity to use the
back button. To say they performed poorly in the market is overly kind; I
damn near got lynched at user conferences.

For better or for worse, the web is an inherently stateless system. We can
try to add our own statefulness system onto of HTTP, but we have to do so in
a way that is transparent to the users. Users *expect* to be able to hit
back twice and select a different camera off the list of cameras and have
the system just work. Telling a user that behavior won't work is like
telling a user of a word processor that your new version is way better than
the old one because you removed UNDO.

Statelessness definitely does create locking issues as you identify below as
it basically forces you into a permissive locking scheme and can absolutely
result in the user returning stale transactions e.g. operating on a stale
record. A stateless system means that I as a developer have to defense
against this in my code which is more work for me. Whereas in a stateful
system I could use more aggressive locking and not have to worry about the
error case.

It basically comes down to user expectation. Users *expect* to be able to
use the back button. Their entire life history with web applications has
trained them to work that way. To try to break them of that habit is like
trying to stop the tide rising (not to mention a sure-fire way to guarantee
you sell no copies of your app).

        -- Pat

> -----Original Message-----
> From: Mark Stang [mailto:[hidden email]]
> Sent: Friday, May 06, 2005 2:41 PM
> To: Tapestry users Howard Lewis Ship; Tapestry users; Michael Musson
> Subject: RE: As a User, which two items would you personally most like to
> see in the next Tapestry Release?
>
> Which is wrong in so many ways...
>
> We are doing this backwards!  The session is what must be considered
> current not the request.  If I store state in request and then delete
> something in another request, when the first request returns data is
> missing, bad things happen!
>
> Ignore the request if it doesn't match the current state of the session.
> Rewind does a very nice job.  The very first time it finds something out
> of sync, it tosses you out and quits trying to do the rewind.  I need to
> make it more robust so that I can detect the rewind at the beginning
> before bad things happen.  I suspect there is a way to fool it by using
> the same screen and changing it so it "matches" the rewind, but screws up
> the data.  Right now my screens are so different that the rewind bails on
> finding mis-matched fields, which is a good thing.
>
> Detect that the user has done something wrong, warn them and move on!
>
> I think Howard should put in a "token" that changes with every screen
> randomly and if it doesn't match what is happening, then throw them out!!!
>
> This is a common technique with databases.  When you save data, put in a
> timestamp.  When it comes time to update the same data, if the timestamp
> doesn't match, then they don't have the current data, throw them out!  Now
> databases have a nicer interface, they can override the timestamp and
> force it to save it anyway.  Of course, other rows and your entire data
> model might get out of sync if they did that!  What we have here is last
> one in wins, all others are rejected!  Tapestry has a good start on that
> process.
>
> regards,
>
> Mark
>
>
> -----Original Message-----
> From: Howard Lewis Ship [mailto:[hidden email]]
> Sent: Fri 5/6/2005 12:55 PM
> To: Tapestry users; Michael Musson
> Subject: Re: As a User, which two items would you personally most like to
> see in the next Tapestry Release?
>
> Yes, and persistent properties on the client help ensure that the
> appllication state stays associated with the request not the session.
>
> On 5/6/05, Michael Musson <[hidden email]> wrote:
> >
> > One example like what I think Patrick is saying is the evil browser
> > back button. One benefit of pushing persistence to the form like .NET
> > is that the "context" stays in sync with the browser (ie. I go back to
> > a previous version of the page (now stale) but the embeded context is
> > also stale (consistent with the page).
> >
> > On May 6, 2005, at 1:30 PM, Patrick Casey wrote:
> > > Just curious: can you come up with a case when you will get a stale
> > > link
> > > problem if you use If and For instead of Foreach, etc?
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> 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




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: As a User, which two items would you personally most like to see in the next Tapestry Release?

Michael Hamilton
Well said.  

Because it's easy to use the session, Java programmers often seem to fall
into this kind of mindset - then they resort to awful hacks such as hiding
the back buttons, switching off the new window shortcuts, or throwing errors back
to the user.    

It would be wonderful to have a framework where it would be natural to work
with the browser.  I built several websites, in most circumstances it's
reasonably easy to deal with such things by adding code to embed state or
state-keys in URL's and forms - it would be nice if the framework could
help with this or make it invisible/natural.

On Saturday 07 May 2005 09:56, Patrick Casey wrote:

>
> Mark,
>
> I've shipped apps that used an approach like you're describing e.g. keep
> state in the session and "break" if the user had the audacity to use the
> back button. To say they performed poorly in the market is overly kind; I
> damn near got lynched at user conferences.
>
> For better or for worse, the web is an inherently stateless system. We can
> try to add our own statefulness system onto of HTTP, but we have to do so in
> a way that is transparent to the users. Users *expect* to be able to hit
> back twice and select a different camera off the list of cameras and have
> the system just work. Telling a user that behavior won't work is like
> telling a user of a word processor that your new version is way better than
> the old one because you removed UNDO.
>
> Statelessness definitely does create locking issues as you identify below as
> it basically forces you into a permissive locking scheme and can absolutely
> result in the user returning stale transactions e.g. operating on a stale
> record. A stateless system means that I as a developer have to defense
> against this in my code which is more work for me. Whereas in a stateful
> system I could use more aggressive locking and not have to worry about the
> error case.
>
> It basically comes down to user expectation. Users *expect* to be able to
> use the back button. Their entire life history with web applications has
> trained them to work that way. To try to break them of that habit is like
> trying to stop the tide rising (not to mention a sure-fire way to guarantee
> you sell no copies of your app).
>
> -- Pat
>
> > -----Original Message-----
> > From: Mark Stang [mailto:[hidden email]]
> > Sent: Friday, May 06, 2005 2:41 PM
> > To: Tapestry users Howard Lewis Ship; Tapestry users; Michael Musson
> > Subject: RE: As a User, which two items would you personally most like to
> > see in the next Tapestry Release?
> >
> > Which is wrong in so many ways...
> >
> > We are doing this backwards!  The session is what must be considered
> > current not the request.  If I store state in request and then delete
> > something in another request, when the first request returns data is
> > missing, bad things happen!
> >
> > Ignore the request if it doesn't match the current state of the session.
> > Rewind does a very nice job.  The very first time it finds something out
> > of sync, it tosses you out and quits trying to do the rewind.  I need to
> > make it more robust so that I can detect the rewind at the beginning
> > before bad things happen.  I suspect there is a way to fool it by using
> > the same screen and changing it so it "matches" the rewind, but screws up
> > the data.  Right now my screens are so different that the rewind bails on
> > finding mis-matched fields, which is a good thing.
> >
> > Detect that the user has done something wrong, warn them and move on!
> >
> > I think Howard should put in a "token" that changes with every screen
> > randomly and if it doesn't match what is happening, then throw them out!!!
> >
> > This is a common technique with databases.  When you save data, put in a
> > timestamp.  When it comes time to update the same data, if the timestamp
> > doesn't match, then they don't have the current data, throw them out!  Now
> > databases have a nicer interface, they can override the timestamp and
> > force it to save it anyway.  Of course, other rows and your entire data
> > model might get out of sync if they did that!  What we have here is last
> > one in wins, all others are rejected!  Tapestry has a good start on that
> > process.
> >
> > regards,
> >
> > Mark
> >
> >
> > -----Original Message-----
> > From: Howard Lewis Ship [mailto:[hidden email]]
> > Sent: Fri 5/6/2005 12:55 PM
> > To: Tapestry users; Michael Musson
> > Subject: Re: As a User, which two items would you personally most like to
> > see in the next Tapestry Release?
> >
> > Yes, and persistent properties on the client help ensure that the
> > appllication state stays associated with the request not the session.
> >
> > On 5/6/05, Michael Musson <[hidden email]> wrote:
> > >
> > > One example like what I think Patrick is saying is the evil browser
> > > back button. One benefit of pushing persistence to the form like .NET
> > > is that the "context" stays in sync with the browser (ie. I go back to
> > > a previous version of the page (now stale) but the embeded context is
> > > also stale (consistent with the page).
> > >
> > > On May 6, 2005, at 1:30 PM, Patrick Casey wrote:
> > > > Just curious: can you come up with a case when you will get a stale
> > > > link
> > > > problem if you use If and For instead of Foreach, etc?
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> >
> > --
> > 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
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: As a User, which two items would you personally most like to see in the next Tapestry Release?

Michael Echerer
In reply to this post by Howard Lewis Ship
Howard Lewis Ship wrote:
> Yes, and persistent properties on the client help ensure that the
> appllication state stays associated with the request not the session.
>
That's definitely a cool thing that I'd like to have backported in
Tapestry 3.0 (or at least a major reason to upgrade ;-) ).

We've build apps that only have "one" page containing tabs inside with
dozends of components to let it virtually look like a GUI app. We just
adjust the components & rerender the page instead of switching between
pages. That means we rely heavily on form submission and having the
correct state.
The browser back button is really a bad thing in such a scenario.
Components like ListEdit or FormConditionals are IHMO just a partial
workaround. But client-side state could solve this once and forever.
BTW: Is the client side state encoded or encrypted somehow in Tapestry 4.0?
I wouldn't like users to be able to mess around too easily in that
state. As long as you could only do this with normal form fields or
hidden fields one could mess around using plain form parameters or the
html page itself, but if "all" state is client-side one should try to
crypt things or people could basically stick anything in our apps.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12