On Wed, 19 May 2010 23:19:35 -0300, Howard Lewis Ship <[email protected]>
wrote:
The first transition is to move away from Javassist to a simpler, more
stable (more JDK 1.6 compatible) approach to dynamic class generation
and runtime bytecode transformation. This has been reflected in the
new ClassTransformation APIs. However, there is more yet to do,
including a similar update of the ClassFactory/ClassFab APIs. Will
that last part make it into 5.2?
Regarding this interfaces and their implementations, what I really miss in
Tapestry-IoC is the annotations in service implementations methods being
added to ther proxy counterparts. This obliges us to add annotations to
service definitions (interfaces) so they can be recognized through
reflection, and not always we have the possibility of doing this change.
This also prevents services built in Tapestry-IoC to be used in other
frameworks that process anotations. CDI (JSR 330) is one of them.
Where I'm at now is a more functional (if still
stateful) approach based almost entirely on event publishers and
observers combined with JavaScript closure functions.
Cool!
I've been hoping to introduce two additional layers on top of
Tapestry: support for Spring Web Flow and for Portlet development.
Both of these keep getting deferred out due to lack of time on my
part.
I don't consider them priorities.
In addition, I feel that the current Tapestry URL rewriting layer
needs to be revisited, even in a non-backwards compatible way. The
current approach has a number of gaps in functionality, and a somewhat
awkward approach.
As the original creator of that layer, I agree that the outbound rewriting
is awkward and some better way must be provided. I guess having a
decorator pipeline around LinkSource would solve most of this problem.
What exactly are the gaps?
I think we could create something simpler and more
effective (and capable of handling asset URLs as well as component
event and page render request URLs).
The current approach is awkward, but handles any kind of URL.
I know there's a backlog of bugs to be dealt with; some are hard, many
are not. Some are drudgery. It would be nice to see at least the
low-hanging fruit addressed. Simply cleaning up duplicate issues in
the backlog would be a great benefit!
I agree 100%.
I think, once we draw a line in the sand, we can have a final 5.2
release out very quickly (the code is stable and well tested). In
fact, finalizing before JavaOne in September would be ideal.
I haven't had free time to play with the 5.2 snapshots yet, but this new
version looks very promising and stable already. As long as it's stable
enough, I think we shouldn't take long to release it. As was discussed
here in this list, we could use some smaller, more frequent releases.
--
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: [email protected]
For additional commands, e-mail: [email protected]
