RE: CVS Update: Barracuda

Hi Jake! (and Diez...thanks for your comments too!)

> So, I really don't think I came as far out of left field as you
> are thinking I did with the implementation I chose here.  I had
> precedence which, I believe, you created yourself.  I just
> followed your lead.  As such, I'm surprised my implementation
> confused you.

Heh heh...point well taken ;-) ObjectRepositoryAssembler was basically a
reimplementation of the (very primitive) scripting support that I originally
added in the application assembler. The long and the short of it I was so
dissatisfied with the way I had originally done it that I reimplemented from
scratch and haven't really looked at the old approach since (so maybe that
explains why it looked so strange to me ;-)

At any rate, I'd really be in favor of removing all the scripting support
from the gateway assembler (or at least deprecating it).

Of course this assumes that we can make the object repository assembler work
the way it needs to... :-)

> First, keep in mind that I am not proposing doing everything
> exactly the same as the config in the application assember.

Ah, ok, that helps...I was misunderstanding you then. In that case, let me
restate that I'd be more than happy to add support to object repository
assembler to make it possible to achieve what you're trying to accomplish;
I'd just like to work with the existing semantics (more or less).

> First, I would think that the value of the "name" attribute on
> the <object> element could be arbitrary.  The definition of
> "this" would be that the "class" attribute wasn't provided and
> the only class that can be assumed is the repository assember
> itself.  Maybe this is what you meant, but I just wanted to
> clarify.  So, it could be <object name="$blah"> and mean "this".
> It wouldn't depend on naming it "$this".

Actually, I was thinking of $this as being the only non-arbitrary name
(meaning refer to the servlet object). Perhaps simply "this" would be better
(I like the $ signs to indicate that I'm setting "variables").

So here's how the <object> logic would work...

  <object name="" class="" arg1="" arg2="">

-When you reference an object, everything beneath it (ie. method calls)
refer to the parent object

-When the name attribute is present, it says "look in your assembler
object-pool for an object with this name (ie. $dl, etc)...if you find it,
use it; if not, see if we can instantiate it based on the class attribute.
So I don't think we actually need a separate objectcreate tag. If an object
has no name, it is scoped only until the </object> tag

-An object name of "this" (or "$this") would be special - it refers to the
assembler servlet

-In order to instantiate an object, it must provide a public constructor
(with or without args). So the question would be...how to handle objects
which don't get instantiated but just have a factory method (getINstance(),
etc). I think we could do this...but it would require some
tweaking...basically, if we couldn't instantiate the object we could just
save a reference to the Class, and then all the methods invoked would have
to be static.

-The arg1, arg2, argX attributes provide a way to pass objects (or values)
into either a constructor or a method. So attributes could look like this:
"foo" (String), "foo.com.Blah" (Class), "1" (Integer/int), "true"
(Boolean/boolean), etc. The way the assembler works here is pretty
smart...it examines all possible constructor or method names and tries to
find those that match the number of parameters and then it tries to convert
the parameters into the types the methods take. So to answer one of your
questions about a Class object...yes, I think it could already handle that.

-The only functionality that would really need to be added is a way to name
an object returned from a method, and I think that could be accomplished as
previously suggested:

  <method name="getGlobalInstance" return="$dl" />

> DOMFactory classes with specific DOM classes.  The DOMFactory
> classes, on the other hand, are the workhorses which actually
> know how to load up a DOM.  As such, they would require more
> configuration and are the obvious recipient of the
> ServletContext, not the DOMLoader.  So, here's how I'd change it...
>
> <object name="$this">
>    <method name="getServletContext" return="$sc"/>
> </object>
> <object class="org.enhydra.barracuda.core.util.dom.DefaultDOMLoader">
>    <method name="getGlobalInstance" return="$dl" />
> </object>
> <object name="$df"
> class="org.enhydra.barracuda.core.util.dom.XMLCDeferredParsingDOMFactory">
>    <method name="setServletContext" arg1="$sc" />
> </object>
> <object name="$dl">
>    <method name="setDefaultDOMFactory" arg1="$df" />
> </object>

Ok, I'm with you now, and I think the way you written it would work just
fine once we implement the few pieces of missing functionality to the
assembler...specifically, this includes:

a) support for name="$this"
b) support for calling a static method on a class with no public constructor
c) support for return attribute

I think all of these are pretty straightforward.

> 1.  My "First" point above doesn't really hold up since <object>
> elements seem to have some ambiguous behavior.  The "name"
> attribute can refer to both an object "to be" instantiated or an
> object that is "already" instantiated.  It seems to be that
> things would be more clear if you differentiated this using two
> separate elements such as <object> and <objectcreate>.  The
> latter would create an object from a given class and  store the
> resulting object in the value of the "name" attribute.  The
> former would not work upon classes, but only upon objects that
> are already instantiated by <objectcreate>.

I think I addressed this sufficiently above, but let me know if I didn't. I
think we can handle both scenarios (creation, referencing an existing obj)
with one tag, as long as we document how things work. And that should keep
things simpler, which is good in my mind.

> 2.  It seems to me that <object> attempts to instantiate a class.
>  In the case of the DefaultDOMLoader, you can't instantiate it
> because it has a private default constructor.  So, is <object>
> smart about this and, secondly, does <method> know the difference
> between static and non-static methods or is there need to differentiate?

<method> is already smart enough to support calls to static and non-static
methods, but I think <object> needs some work for the static case (as
described above).

> 3.  How does one specify a class to be given to the
> registerDOMLoader() method such as....
>
> globalDomLoader.registerDOMFactory(instantiatedDomFactory,
> domClassButNotInstantiated)
>
> do you just provide the fully qulaified name of the class as the
> arg2?  I don't see how the <method> would know that we mean to
> load string as a class, and give it to the method?  Is this possible?

Yes. I explained this briefly above (where talking about how it runs through
all possible methods and tries to map args into the target types). Holler if
that needs further explanation.

> I don't think any of my suggestions above change semantics to a
> degree that we'd want to create a separate assembler.  Plus, I
> think being able to do things like this actually would make this
> an "end-all-be-all" scripting solution, because it would let you
> do everything you'd ever need to do.  It would be ideal.

Cool...sounds like theirs a path of commonality here. Let me know what you
think about my comments above and we can figure out how best to move
forward. I think we can make this happen pretty easily.

Things have been so hectic this past year that I end up having very little
time to spend on email, which makes it real easy to misunderstand what other
people are saying...Thanks for your persistence in explaining where you were
coming from :-)

Christian
----------------------------------------------
Christian Cryder
Internet Architect, ATMReports.com
Project Chair, BarracudaMVC - http://barracudamvc.org
----------------------------------------------
"Coffee? I could quit anytime, just not today"