You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Patrick Casey <pa...@adelphia.net> on 2005/05/06 17:28:00 UTC
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: As a User, which two items would you personally most like to see in the next Tapestry Release?
Posted by Gregg D Bolinger <gt...@gmail.com>.
Sounds very exciting Howard. Keep up the good work.
Gregg Bolinger
On 5/6/05, Howard Lewis Ship <hl...@gmail.com> 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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: As a User, which two items would you personally most like to see in the next Tapestry Release?
Posted by kranga <kr...@k2d2.org>.
> ".Net severly constrains the objects that can be present "on the page" in
> terms of their own, specific APIs for database access, etc."
And where did you get that from?? .NET components will bind to any "data
source" using a well defined interface - and that will be made more flexible
in 2.0
Things I'd like to see addressed:
- Button listeners firing after the form is posted - this one is a cause of
a lot of grief. If Tapestry's philosophy is simple, then this should be
addressed. I find myself playing tricks just so I can deal with this.
- A .NET like client side state persistence will enable more events - such
as valueChanged for a text field. This is again something you've got to put
hidden fields in Tapestry to achieve
----- Original Message -----
From: "Howard Lewis Ship" <hl...@gmail.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Friday, May 06, 2005 2:53 PM
Subject: Re: As a User, which two items would you personally most like to
see in the next Tapestry Release?
>
>
> 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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: As a User, which two items would you personally most like to see in the next Tapestry Release?
Posted by Howard Lewis Ship <hl...@gmail.com>.
>
>
> 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
Re: As a User, which two items would you personally most like to
see in the next Tapestry Release?
Posted by Michael Echerer <me...@tngtech.com>.
Kent Tong wrote:
> Howard Lewis Ship <hlship <at> gmail.com> writes:
>>(*), then MIME encoded. Only a very dedicated hacker would be able to
>>spoof that information in the URLs ... but because of HiveMind you
>>could create your own implementation that added some form of encoding.
>
>
> I think this will be a necessity for this feature to be used
> in a public production app. It isn't that difficult to encode
> persistence feature is made available, please at least document
> the security risk involved so that the app developer can make his
> own informed decision.
Certainly nobody wants to run into the same security issues we had with
the AssetService lately (before adding the hash). It was no fun to read
my web.xml etc. using a browser...
For sure, crafting an object stream takes a while and if it's documented
and that easy using Hivemind, fine. But probably it's worth to have this
as default (especially if it's that simple to implement as you
mentioned, Howard) in the framework right from the start, instead of
having the follow-up problems (if only dozends of emails on this list
;-) ) later.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: As a User, which two items would you personally most like to see in the next Tapestry Release?
Posted by Kent Tong <ke...@cpttm.org.mo>.
Howard Lewis Ship <hlship <at> gmail.com> writes:
> All client state for a single page is organized into a single object
> that tracks triads of componentIdPath, propertyName and value. These
> triads are serialized to an ObjectOutputStream and gzip compressed
> (*), then MIME encoded. Only a very dedicated hacker would be able to
> spoof that information in the URLs ... but because of HiveMind you
> could create your own implementation that added some form of encoding.
I think this will be a necessity for this feature to be used
in a public production app. It isn't that difficult to encode
such a object, in particular when the Tapestry source is
available to anyone.
I'm grateful for the wonderful work that you've been doing with
Tapestry and understand that your time is limited, but if this
(authencity check) can't be implemented yet when this client side
persistence feature is made available, please at least document
the security risk involved so that the app developer can make his
own informed decision.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: As a User, which two items would you personally most like to see in the next Tapestry Release?
Posted by Howard Lewis Ship <hl...@gmail.com>.
> 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.
>
All client state for a single page is organized into a single object
that tracks triads of componentIdPath, propertyName and value. These
triads are serialized to an ObjectOutputStream and gzip compressed
(*), then MIME encoded. Only a very dedicated hacker would be able to
spoof that information in the URLs ... but because of HiveMind you
could create your own implementation that added some form of encoding.
(*) compression is optional; it creates parallel binary streams, one
using compression, the other not, and uses the shorter of the two. You
actually have to encode a large amount of data before compression
becomes a win, because of the overhead.
--
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: As a User, which two items would you personally most like to
see in the next Tapestry Release?
Posted by Michael Echerer <me...@tngtech.com>.
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Components should maintain their own state unchanged (Was: As a User, which two items would you personally most like to see in the next Tapestry Release?)
Posted by Mind Bridge <mi...@yahoo.com>.
Hi,
> This will help tremendously for component writers. When this becomes
> available, why not make the built-in components such as Conditional
> and Foreach act like FormConditional (or MindBridge's IF) and
> ListEdit (or MindBridge's For)? It should be the component's job
> to ensure that its state doesn't change between render and rewind.
Please see the relevant threads in tapestry-dev -- you will find them
interesting.
This (in the context that requires a rewind) is what is slated for 4.0 and
we are also trying to address the "serializable" (or "primary-key")
questions in an easy manner.
This message may be of a particular interest at the moment, but please see
the entire thread (there are comments from Howards, for example):
http://article.gmane.org/gmane.comp.jakarta.tapestry.devel/5101
----- Original Message -----
From: "Kent Tong" <ke...@cpttm.org.mo>
To: <ta...@jakarta.apache.org>
Sent: Sunday, May 08, 2005 5:29 AM
Subject: Components should maintain their own state unchanged (Was: As a
User, which two items would you personally most like to see in the next
Tapestry Release?)
> Howard Lewis Ship <hlship <at> gmail.com> writes:
>
> >
> > Yes, and persistent properties on the client help ensure that the
> > appllication state stays associated with the request not the session.
>
> This will help tremendously for component writers. When this becomes
> available, why not make the built-in components such as Conditional
> and Foreach act like FormConditional (or MindBridge's IF) and
> ListEdit (or MindBridge's For)? It should be the component's job
> to ensure that its state doesn't change between render and rewind.
>
> The only issue I can see with this approach is that the source will
> have to be serializable if Foreach is going to kee the state
> unchanged. To solve this problem, this feature can be make optional
> at runtime by setting a parameter (just like in .NET people can
> enable or disable the "view state" for the data grid).
>
>
>
> ---------------------------------------------------------------------
> 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: Components should maintain their own state unchanged (Was: As a User, which two items would you personally most like to see in the next Tapestry Release?)
Posted by kranga <kr...@k2d2.org>.
If a component is not part of the form, or if a page has no form, am I
reading correctly that all state will be stuffed into URLs? That would make
terribly long URLs that are not bookmark-capable. Also, you may run over the
URL data size limit fairly easily...
----- Original Message -----
From: "Kent Tong" <ke...@cpttm.org.mo>
To: <ta...@jakarta.apache.org>
Sent: Saturday, May 07, 2005 10:29 PM
Subject: Components should maintain their own state unchanged (Was: As a
User, which two items would you personally most like to see in the next
Tapestry Release?)
> Howard Lewis Ship <hlship <at> gmail.com> writes:
>
> >
> > Yes, and persistent properties on the client help ensure that the
> > appllication state stays associated with the request not the session.
>
> This will help tremendously for component writers. When this becomes
> available, why not make the built-in components such as Conditional
> and Foreach act like FormConditional (or MindBridge's IF) and
> ListEdit (or MindBridge's For)? It should be the component's job
> to ensure that its state doesn't change between render and rewind.
>
> The only issue I can see with this approach is that the source will
> have to be serializable if Foreach is going to kee the state
> unchanged. To solve this problem, this feature can be make optional
> at runtime by setting a parameter (just like in .NET people can
> enable or disable the "view state" for the data grid).
>
>
>
> ---------------------------------------------------------------------
> 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
Components should maintain their own state unchanged (Was: As a User, which two items would you personally most like to see in the next Tapestry Release?)
Posted by Kent Tong <ke...@cpttm.org.mo>.
Howard Lewis Ship <hlship <at> gmail.com> writes:
>
> Yes, and persistent properties on the client help ensure that the
> appllication state stays associated with the request not the session.
This will help tremendously for component writers. When this becomes
available, why not make the built-in components such as Conditional
and Foreach act like FormConditional (or MindBridge's IF) and
ListEdit (or MindBridge's For)? It should be the component's job
to ensure that its state doesn't change between render and rewind.
The only issue I can see with this approach is that the source will
have to be serializable if Foreach is going to kee the state
unchanged. To solve this problem, this feature can be make optional
at runtime by setting a parameter (just like in .NET people can
enable or disable the "view state" for the data grid).
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: As a User, which two items would you personally most like to see in the next Tapestry Release?
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <mu...@gmail.com> 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: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-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: As a User, which two items would you personally most like to see in the next Tapestry Release?
Posted by Michael Musson <mu...@gmail.com>.
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: As a User, which two items would you personally most like to see in the next Tapestry Release?
Posted by Patrick Casey <pa...@adelphia.net>.
> -----Original Message-----
> From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
> 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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: As a User, which two items would you personally most like to see in the next Tapestry Release?
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
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: 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: As a User, which two items would you personally most like to see in the next Tapestry Release?
Posted by Patrick Casey <pa...@adelphia.net>.
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: As a User, which two items would you personally most like to see in the next Tapestry Release?
Posted by Mind Bridge <mi...@yahoo.com>.
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:mindbridgeweb@yahoo.com]
> 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: 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: As a User, which two items would you personally most like to see in the next Tapestry Release?
Posted by Patrick Casey <pa...@adelphia.net>.
-----Original Message-----
From: Mind Bridge [mailto:mindbridgeweb@yahoo.com]
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: As a User, which two items would you personally most like to see in the next Tapestry Release?
Posted by Mind Bridge <mi...@yahoo.com>.
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" <pa...@adelphia.net>
To: "'Tapestry users'" <ta...@jakarta.apache.org>
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: 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: As a User, which two items would you personally most like to see in the next Tapestry Release?
Posted by Marko Kocic <ma...@gmail.com>.
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: As a User, which two items would you personally most like to see in the next Tapestry Release?
Posted by Warner Onstine <wa...@warneronstine.com>.
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: 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: As a User, which two items would you personally most like to see in the next Tapestry Release?
Posted by Gene Volovich <gv...@cite.com>.
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: 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: As a User, which two items would you personally most like to
see in the next Tapestry Release?
Posted by "t.n.a." <tn...@sharanet.org>.
Denis Souza wrote:
>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).
>
>
I'm fighting that one as I write and although it's a solvable problem, I
can't help feeling like it's an unnecesairly complication.
Basically, every time I need to interface a tapestry app with another
application I hit some kind of a wall: the last time the problem was not
beeing able to force <input> field names or values so that when the form
submits, the non tappestry web app receives the data it expects. Also a
solvable problem, but it gives me a feeling of waltzing through a mine
field whenever I need to interface with something else. :(
--
Tomislav Nakic-Alfirevic
Netgen Ltd. www.netgen.hr
Rudeska 172/3
10000 Zagreb, Croatia
tel.: +385 1 387 97 22
fax.: +385 1 387 97 24
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: As a User, which two items would you personally most like to see in the next Tapestry Release?
Posted by Denis Souza <ds...@sti.com.br>.
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:patcasey@adelphia.net]
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: 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