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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
