That's greate news, Paul. I myself would really like
to see 4.0 have the new validation in it. Improved
validation is one of the things I am really hoping to
have as incentive for Trails to upgrade to 4.0. It
would be a shame if it had to wait for 4.1, IMO.
--Chris
--- Paul Ferraro <[EMAIL PROTECTED]> wrote:
> My how time flies... My progress with validation
> improvements has
> admittedly been very slow over the last few months
> as I have been very
> swamped with work. My schedule will be lightening
> up this week - and I
> expect to be able to devote all of this weekend and
> much of next week to
> Tapestry. I expect to have the bulk of this checked
> in within the week.
>
> Paul
>
> Howard Lewis Ship wrote:
>
> >So, how long until 4.0 is ready? That's the
> question I get every single day.
> >
> >I had origionally hoped that 4.0 would be a faster
> release than 3.0.
> >I was very, very off.
> >
> >However, I'm pretty thrilled with how 4.0 is coming
> out. I think it
> >will be somewhat revolutionary in terms of how
> Tapestry applications
> >are created, and developing applications will be
> simpler than ever.
> >Things just *work*.
> >
> >Mind Bridge has some new, smarter looping
> components waiting in the
> >wings, and there's been murmurs of reworked
> validation from Paul
> >and/or Harish, but nothing's been checked in.
> >
> >I'd like to break out the big "Deferred until 4.1"
> stamp and focus on
> >bug fixes and documentation. I think Tapestry 4.0
> needs to get to a
> >beta release Very Soon Now and I think its
> important for the final
> >release be available before the end of the summer.
> >
> >On thing to bear in mind is that many future
> enhancements to Tapestry
> >can be decoupled from the main release; because of
> HiveMind it will be
> >practical to package not only component libraries,
> but framework
> >enhancements, in add-on JARs, allowing for
> significant off-cycle
> >improvements (that may be how I approach Java
> annotations support).
> >
> >I honestly think that the 4.1 cycle *will* be
> short, and will focus on
> >components, including Ajax-style components.
> >
> >One low impact idea I had was to "integrate"
> existing components with
> >validation. This would mean adding displayName
> parameters to all
> >field-element components, and extending them to, at
> least, allow the
> >validation delegate to decorate them. With the
> expected split between
> >converters and validators (the former converting
> between object-values
> >and client-side string values, and the latter
> enforcing constraints)
> >it would be limiting to allow existing components
> to have validators,
> >but the decoration is reasonable.
> >
> >
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
