[Building Sakai] More on Covers - From Twitter

[David Haines]

Comments inline.
- Dave

David Haines
CTools Developer
Digital Media Commons
University of Michigan 
dlhaines at umich.edu



On Mar 23, 2010, at 11:58 PM, csev wrote:

> The conversation about alternatives to covers continue on twitter and I could not respond to it all in 142 characters - so back to the dev list I go.
> 
> Lance asked if I liked Annotations better than XML and Setters.
> 
> Definitely yes - less syntax is better and avoiding XML is a big win in terms of documentation and training IMHO. My biggest connern is that is we need to somehow control the moment of constructor and let Spring do the construction - then I have a problem for things like portlets and jws files, and lots of other little gluey things.  Another concern is making sure that there was a moment where I could check that all was well rather than randomly having NPEs is startup did not work.
> 
> Steve Swinsberg said "you could use the ComponentManager which is Spring without the XML. Adds two extra lines per cover."
> 
> I think you meant to say - "it takes two more lines than cover" - but my answer is yes - I am fine with using Component Manager to get the impl - no need to get Spring involved in constructor time - no worries about startup order - a little extra code is not such a big deal.   I would particularly like to find a way to make this as contracted as possible - for example - I don't want a try / catch around every ComponentManager lookup - And I don't want it returning NULL when it can't find an impl - that looks like a NPE one line later - I want the CM lookup to immediately traceback out with a good descriptive error when there is a missing impl.  Also with a bit of work we might get the wordiness down a bit.   It would be nice if one could do all the lookups at init time or constructor time for simple stuff like say a Portlet or JWS.  
> 

The point of the assureInstance method suggestion was to bypass the client side check for nulls.  The cover would generate an instance and return it only if a null was passed in.  If it doesn't get an instance and can't generate one then that is a fatal error.  This would add one canned method per static cover and one method call to the user of the cover.

> But after all that, aren't the static covers simply a way to call the component manager and use the returned instance?  Or is the key that you want to get the instance over and over so that unit tests can inject something different each time.  I just wonder if CM lookups solve the need to poke Mocks into pieces of code.  It would seem if CM lookups were mock-enabled that static covers would be too - or am I missing something?
> 

I'd be happy with that solution but can't figure out how to manage a static ComponentManager from within a JUnit test.  It needs to be controlled from within the individual test setup since different tests would require different mock behavior.


> /Chuck
> 
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> 
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20100324/89b58e55/attachment.html