Re: [picocontainer-dev] Providers

>
> At first when I read your design of Chocolatier in the test case, I  
> thought...
> "Why do this when we have Behaviors in the first place???"....  Then  
> when I hit
> Chocolatier2, I finally realized where you were going with it and  
> thought ...
> "Way cool" :)
>
> Thoughts:
> --How do you consider using a marker interface vs an annotation.  ie:
>
> @Provider
> public class MyProvider {
>
> }
>
> vs
>
> public class MyProvider implements Provider {
>
> }
>

Its a good thought.  The way it is now (with no methods) it fits an  
annotation better.

> ?
>
> --I think the thing I like most about it is that it allows people to  
> create
> Factory objects without deep knowledge of the inner workings of  
> PicoContainer
> like Custom ComponentAdapters require.
>
> --I don't think its fringe... I think it is far more accessible to  
> developers
> for providing custom ways of getting at your components.  For example:
>
> public class JNDILookupProvider<T> implements Provider {
>
> 	public JNDILookupProvider(String contextPath) {
> 		/* ex contextPath = ' java:comp/env/jdbc/default' */
> 	};
>
> 	public <T> provide(IntialContext ctx) {
> 		/*Perform lookup on initialContext using contextPath*/
> 		return T;
> 	}
> }
>
> Nice and simple (if you can ever call JNDI lookups 'simple'! :) )...  
> and the
> build of the container is logical:
>

maybe nice, but I'm not sure if the ProviderAdapter.getProvideMethod()  
(and key determination) will work with that.  I think return's can be  
generic specified, but subclasses may compile that out of course.

> import javax.mail.Session;
>
> container.as(NO_CACHE).addComponent(InitialContext.class)
> 	.addAdapter(Session.class, new ProviderAdapter(new
> JNDILookupProvider<Session>("java:comp/env/mail/default"));
>
>
> Although from a usability standpoint, it would be nicer to have
>
> container.as(NO_CACHE).addComponent(InitialContext.class)
> 	.addComponent(Session.class, new
> JNDILookupProvider<Session>("java:comp/env/mail/default"));

or

container.as(NO_CACHE).addComponent(InitialContext.class)
	.addAdapter(new JNDILookupProvider<Session>("java:comp/env/mail/ 
default"));

where Session is pulled from the generic type to become the key also ?

>
>
> and like instance registrations, have provider registrations wrapped  
> in the
> appropriate adapter.
>
> Or possibly even delayed instantiation of the provider:
>
> container.as(NO_CACHE).addComponent(InitialContext.class)
> 	.addComponent(Session.class, new JNDILookupProvider.class, new
> ConstantParameter("java:comp/env/mail/default"));
>

maybe.

>
>
> Opposing thoughts: (Or as Tevya would say:  "On the other hand...")
>
> --But just as ComponentAdapters have gotten more complicated over  
> the years to
> handle specific use cases, is Provider too simple? For example, does  
> it need
> lifecycle events?  I'd personally hate to destroy the simplicity to  
> handle those
> additional use cases.
>

I consider it niche to be honest.  And for webapps is that niche.   
Imagine a queryString param like so '?make=nike'.  What if an action  
wanted to depend on that (we're imagining a non-webwork, non-struts,  
non-waffle web app).

public class Make {
    private String name;
    public Make(String name) {
        this.name = name;
    }
    public String getName() {
        return name;
    }
}

public class Cart {
   public boolean addTo(Make make, Model model, int quantity) {
     // etc
   }
}

public class CartFromRequest extends ProviderAdapter {
      public Cart provide(HttpServletRequest req) {
          return new Cart(req.getParameter("brandName"));
      }
}


or better still.  A parent class that could handle request params and :

pico.as(NO_CACHE).addAdapter(new FromRequest(Make.class, "make"));

more later.


> --Is there too much overlap between Providers and ComponentAdapters  
> in the first
> place?  After all, in the past, if I needed a custom provider, I  
> just made a new
> ComponentAdapter.  (Or even a custom ComponentParameter!).  In fact,  
> code base
> has JNDIComponentParameter, and I have in my own code a JNDIParameter:
>
> container.addComponent(EmailService.class,
> 				EmailService.class,
> 				new
> JNDIParameter("java:comp/env/mail/default"));
>
> So do we need yet another way to instantiate a component?
>
> Just thoughts :)
>
> 	
> -Mike
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email