On Fri, 14 Oct 2011 08:47:52 -0300, Wechsung, Wulf <wulf.wechs...@sap.com>
wrote:
I've taken 5 minutes to try out the beta with my integration test
project and besides noticing that chenillekit doesn't declare its
dependency on tapestry as "provided" which leads to an
IncompatibleClassChangeError I found the beta-21 to be much stricter
about the location of non-managed classes. In 5.2.6 you could still have
an interface in the components package (now yields plastics error
java.lang.ClassFormatError: Illegal field modifiers in class 0x12) or an
enum in the mixin package ( gave an error stating that is should be
moved to the base package).
I'm sorry, but putting interfaces and classes that aren't pages in the
pages packages, that aren't components in the components package, that
aren't mixins in the mixins package and that aren't superclasses of pages,
components or mixins have been wrong since the first Tapestry 5.0
snapshot. Committing this kind of error leads to hard to understand
errors, so Tapestry catching it and throwing an exception outright is a
very Good Thing. ;)
I also think it would be great if tapestry came repacked with a web-app
validation suite that
It could be just another package or even something built in tapestry-core.
1) attempts to realize all registered services
Agreed.
2) checks all classes in the "managed" package for the class format and
tapestry-required visibility
This is done by the JVM, so I don't know why Tapestry should do that too.
3) checks templates of all pages and components known to tapestry
Agreed.
Framework errors are a great way to let the developer know that he isn't
making any sense or in the case of event handlers that he probably made
an error in the functional implementation. However, webapps are usually
user-facing and it's a little bit embarrassing to have the webapp barf
all over the user just because an empty event handler isn't attached to
a form or because an interface isn't in the "correct" package.
If a person deploy an application to the live server without checking for
errors first, manually or through automated tests, then I think the
problem is responsibility of this person.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org