Apologies if someone alreay said this, but that "scaffold" component you are talking about is in Trails.
http://trails.dev.java.net/ --- Patrick Casey <[EMAIL PROTECTED]> 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: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
