-1 non binding
without class reloading my vote would be +1,
speedy reload and excellent error reporting may be enough to overcome typing
errors
and enjoy more descriptive templates.
Davor Hrg
On 2/19/07, Massimo Lusetti <[EMAIL PROTECTED]> wrote:
On 2/17/07, Jesse Kuhnert <[EMAIL PROTECTED]>
On 2/17/07, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
-1
-1 (non-binding)
--
Massimo
http://meridio.blogspot.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
1) I shouldn't have to rely on the features of an IDE to make it non-
annoying/non-tedious to work with a framework
2) I just don't see what you gain with type-safe bindings. This
really doesn't seem that much different than having synthetic wrapper
properties in your component class.
-1 (
-0 (non-binding)
Kudos to Kent for his work on an interesting (if controversial) idea.
Surely the dialog can only have helped Howard refine his vision for T5.
Cheers,
Nick.
Jesse Kuhnert wrote:
This is a vote on whether or not we want anything in the type safe
refactoring branch to move forwa
On 2/18/07, D&J Gredler <[EMAIL PROTECTED]> wrote:
So if non-binding votes from users matter...
-1
They matter!
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind
Professional Tapestry t
I'm a Tapestry 4 user who has played with version 5. I've been very
concerned with the proliferation of configuration and logic outside of Java
code and the ensuing number of runtime errors (rather than compile time
errors). A couple of years ago at the JavaOne web frameworks smackdown,
during the
Howard Lewis Ship: -1
I really appreciate the work Kent has done with the type safe option,
as well as the unit testing work. I strongly feel that the type safe
approach loses more than it gains, as we've discussed in the relevant
threads. I think making sure Tapestry works with Groovy and JRuby
This is a vote on whether or not we want anything in the type safe
refactoring branch to move forward within the confines of the Tapestry
project. It's not a discussion for or against the various aspects of
the arguments - there are obviously plenty of threads dealing with
that.
The only reason I
