Re: [morph-developer] Reflector delegation strategy

[Matt B. <gud...@ya...>]

Sorry it took me so long to respond.  Been pretty busy
here lately.  Anyway, I guess I feel like option #1 is
most compatible with Morph's existing architecture. 
But I would definitely implement this generically as
some kind of CompositeReflector that queries each of
its components in turn for handling of a given
property.  e.g. one child might know how to read
property foo, while the other might know how to write
it.  Who knows?  The available properties would be the
union of all properties reported by all components.

WDYT?

-Matt B



--- Matt Sgarlata <mat...@sp...>
wrote:

> There is a use case that Morph does not cover that
> has been an "itch" of 
> mine since pretty much the beginning. 
> Morph.get(request, "something") 
> will only return request attributes, never request
> parameters.  There 
> are a lot of ways this could be worked around, but
> there are a couple 
> reasons that conspired to cause this.
> 
> One reason the code works the way it does now is
> because of how I wrote 
> reflectors.  My intent for reflectors was that they
> would be very 
> low-level objects with relatively simple behavior. 
> So, I have a 
> separate ServletRequestAttributeReflector and 
> ServletRequestParameterReflector, just like I have
> separate 
> CollectionReflector and IteratorReflectors (rather
> than trying to 
> squeeze them into a single ContainerReflector). 
> This keeps their 
> implementation very clean and makes them easily
> testable.
> 
> The other reason for this behavior is the
> SimpleDelegatingReflector's 
> strategy for choosing a reflector for an object. 
> Currently, the first 
> reflector that can reflect an object is chosen and
> that's it, which 
> makes the implementation of most Reflector methods
> trivial, for example,
> 
>     protected Object getImpl(Object bean, String
> propertyName) throws 
> Exception {
>         return getBeanReflector(bean).get(bean,
> propertyName);
>     }
> 
> So there are a number of ways to work around this
> and I could never 
> decide the best one:
> 1) Write a ServletRequestReflector that delegates to
> the 
> ServletRequestParameterReflector and
> ServletRequestAttributeReflector.  
> An upside is this approach is fairly simple to
> understand conceptually.  
> A downside of this approach is the delegation code
> here could become a 
> bit repetitive if this situation is encountered
> multiple times.  One 
> need not look far to find another example where this
> would have to be 
> implemented again or called again (if some sort of
> delegate or 
> superclass was written): again for the Servlet API
> we have separate a 
> ServletContextInitParameterReflector and
> ServletContextAttributeReflector.
> 2) Change the default implementation of
> SimpleDelegatingReflector so 
> that it tries multiple reflectors if the first one
> fails.  The big 
> downside here is this could be fairly confusing
> since all objects are 
> reflectable by the ObjectReflector which could be
> unexpected and/or 
> confusing.  For example, this would cause all
> objects to automatically 
> receive a "class" property.  In addition to being
> confusing, this could 
> cause problems when using objects over which the
> user has little or no 
> control, such a ServletRequest objects.  If the
> implementation class for 
> the request object has public mutators, those would
> be exposed which 
> could be a particular annoyance for adherents to
> interface-based design 
> that just declare lots of stuff public to make
> utilizing dependency 
> injections frameworks (like me).
> 3) Introduce a configuration parameter or some type
> of Strategy delegate 
> object that decides how a delegate is chosen in the 
> SimpleDelegatingReflector.
> 4) Introduce a new type of DelegatingReflector (the
> current delegate 
> implementation is called 'simple' after all!)
> 
> I don't think #3 or #4 is really workable, because
> the behavior I'm 
> really trying to affect here is for the Morph static
> method, so option 3 
> and 4 are really just dodging the original issues
> presented by option 
> 2.  I suppose options 3 and 4 would really be the
> implementation 
> approach for option #1.  I guess after writing this
> massive amount of 
> text I'm leaning towards option #1, but I would love
> to hear some more 
> ideas.
> 
> Thanks,
> 
> Matt S
> 
> -- 
> This message is intended only for the named
> recipient. If you are not the intended recipient,
> you are notified that disclosing, copying,
> distributing, or taking any action in reliance on
> the contents of this information is strictly
> prohibited.
> 
> 
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2
> express and take
> control of your XML. No limits. Just data. Click to
> get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> morph-developer mailing list
> mor...@li...
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> 



       
____________________________________________________________________________________Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. 
http://mobile.yahoo.com/go?refer=1GNXIC