Howard Lewis Ship wrote:
LinkFactoryListener has been made public, as LinkCreationListener.
Good, the next version will use that.
PersistentFieldManager ... I'd want to see a use case for why it needs
to be public. The more hidden behind the "internal" curtain, the
easier it is to morph th
LinkFactoryListener has been made public, as LinkCreationListener.
PersistentFieldManager ... I'd want to see a use case for why it needs
to be public. The more hidden behind the "internal" curtain, the
easier it is to morph the framework.
For example, over the last few days I've been doing some
Indeed, the LinkFactoryListener and PersistentFieldManager classes are
internal.
These seem pretty important for the extensability. Should these not be
made public?
Kind regards,
Joachim
Howard Lewis Ship wrote:
Third party modules that use some of T5's internal classes and
interfaces may not
Third party modules that use some of T5's internal classes and
interfaces may not be compatible with 5.1. Many things have shifted
around internally ... that's the nature of the internal APIs.
On Sun, Feb 15, 2009 at 8:33 AM, Joachim Van der Auwera
wrote:
> I have a module which works fine in ta
I have a module which works fine in tapestry 5.0.18.
However when I try using this in tapestry 5.1.0 (using jetty:run) I get
the exception below.
The line reported in my code reads
public static void bind( ServiceBinder binder )
{
binder.bind( NavigationDispatcher.class ); // line which cau
