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

Reply via email to