[
https://issues.apache.org/jira/browse/TAP5-375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12662851#action_12662851
]
Howard M. Lewis Ship commented on TAP5-375:
-------------------------------------------
Tapestry IoC is very rigid here: all module classes are converted to ModuleDefs
early on; each ModuleDef lists all service builders, decorators and
contributors. This makes sense in the Tapestry world, where (due to
contributions and decorators) virtually any service may have an effect on
virtually any other service.
That means that there's no injection into bind() methods. If you want to
instantiate a ClassNameLocatorImpl and use it with AutoServiceBinder ... sure,
no problem. It might be easier to create a ModuleDef implementation and use
then when constructing the Registry.
What I don't want to get into is some kind of multi-level container, where a
simple container must be instantiated to bootstrap the real container. I think
that will drive everyone crazy!
I don't mind binding my services explicitly, I don't know that this initiative
solves any real problems.
> Provide some way to bind services without explicit binder.bind() calls or
> builder methods
> -----------------------------------------------------------------------------------------
>
> Key: TAP5-375
> URL: https://issues.apache.org/jira/browse/TAP5-375
> Project: Tapestry 5
> Issue Type: New Feature
> Affects Versions: 5.0.16
> Reporter: Thiago H. de Paula Figueiredo
> Priority: Minor
>
> Full discussion at
> http://www.nabble.com/Tapestry-IoC%3A-binding-service-without-code%2C-just-convention-over-configuration-td20585891.html.
> I have been wondering about some ways to write even less configuration with
> Tapestry-IoC and yet more convention over configuration.
>
> At first we had:
>
> public static void bind(ServiceBinder binder) {
> binder.bind(Service.class, ServiceImplementation.class);
> }
>
> Then, if ServiceImplementation is in the same package, we can write:
>
> public static void bind(ServiceBinder binder) {
> binder.bind(Service.class);
> }
>
> I'm thinking of not even have that binder.bind() call, automatically binding
> services located in packages defined by some convention. How could I
> implement that? Can we add services to a Registry or use ServiceBinder just
> like we can use add objects to a service distributed configuration? I spent
> some time looking at the Tapestry sources, but I couldn't find an answer.
>
> Another related funcionality I was thinking was to automatically provide some
> well-know service implementations when no one was explicitly providaded.
> Example: suppose we have the convention that every entity class must a
> corresponding controller class. Then I want to provide a default controller
> implementation for it if none is provided, because some components and pages
> expect one controller instance for each entity class. How could I do that?
>
> My goal is to to have non-trivial zero configuration (or almost zero
> configuration) applications in Tapestry, provided that they follow the
> conventions.
> Em Wed, 19 Nov 2008 15:31:16 -0300, Howard Lewis Ship <hls...@...>
> escreveu:
> > Interesting idea. You could probably put something together around
> > ClassNameLocator, i.e., a wrapper that given package names, find
> > interfaces inside those packages that have matching Impl classes. i.e.
> >
> > public static void bind(ServiceBinder binder)
> > {
> > new AutoServiceBinder("my.package.root").bind(binder);
> > }
> How can I get a ClassNameLocator instance in bind(ServiceBinder binder)?
> Trying to inject through public static void bind(ServiceBinder binder,
> ClassNameLocator classNameLocator) does not work (method is never
> invoked). It must be static, so I cannot use a constructor in my module
> class.
> And what about the creation of default implementation for unbound services?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
