RE: CVS Update: Barracuda

At 08:49 AM 6/20/2003 -0600, you wrote:
> > If it is as simple as this, maybe we can leave the object
> > repository assembler alone and create a separate jython
> > assembler.  Maybe someone can fill in what the actual assembler
> > would look like?
> >
> > Christian, what do you think about this?
>
>Well, I think we should still expand ObjectRepositoryAssembler (as per my
>previous email),

Yep, based on what you've said could be done with the 
ObjectRepositoryAssembler, I think it should be modified as I think it 
would make it a very flexible solution.  My only reservation is using 
"$this" as a keyword, but since you dont' have a problem with it and making 
this compromise keeps everything else simple, I think it is worth reserving 
the key word.  Given that I have never actually looked at the object 
repository assembler and you are intimately familiar with it, should I 
defer the addition of the new functionality to you?  That might be the best 
way to go.

>but...
>
>I'm not at all opposed to creating a separate assembler for this approach
>either. org.enhydra.barracuda.plankton.data.JPythonAssembler maybe? I'd love
>to see a working example,a dn I'll bet Diez and Iman could whip something up
>in no time.
>
>Like I said in a previous email, I think there's plenty of room for multiple
>solutions here - it just offers more choices to those in the community, and
>I think that's a good thing.
>
>So Diez, Iman...what do you guys think? Want to volunteer? :-)

I'd definitely encourage this.  We could even support multiple scripting 
languages if need be...even in the same file, possibly.  Maybe using an XML 
format and declaring the scripting type on different elements enclosing a 
particular scripting technique.  It could be 
called  org.enhydra.barracuda.plankton.data.SriptingAssembler.  Could be 
pretty cool and give users their choice of scripting languages rather than 
forcing a single scripting language upon users.  The interpreters could 
even be loaded using reflection so that there would be no compile-time 
dependencies on these libraries so that the scripting would be entirely 
optional.  We could always log the fact that a scripting library isn't 
available and needs to be added to the classpath in order to work if it 
doesn't exist.

Jake

>Christian
>----------------------------------------------
>Christian Cryder
>Internet Architect, ATMReports.com
>Project Chair, BarracudaMVC - http://barracudamvc.org
>----------------------------------------------
>"Coffee? I could quit anytime, just not today"
>
>
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]]On Behalf Of Jacob Kjome
> > Sent: Friday, June 20, 2003 8:21 AM
> > To: [email protected]
> > Subject: Re: [Barracuda] CVS Update: Barracuda
> >
> >
> > At 12:28 PM 6/20/2003 +0200, you wrote:
> >
> > ----------
> > from org.enhydra.barracuda.core.util.dom import DefaultDOMLoader
> > from org.enhydra.barracuda.core.util.dom import
> > XMLCDeferredParsingDOMFactory
> >
> > # wherever this comes from... But its no problem to declare it :)
> > sc = this.servletContext
> > dl = DefaultDOMLoader.globalInstance
> > df = XMLCDeferredParsingDOMFactory()
> > df.servletContext = sc
> > dl.defaultDOMFactory = df
> > -----------
> >
> > What would the assembler that this gets fed to look like?  I'm
> > not clear on that?  Would it be something like...
> >
> > public void assemble() {
> >    boolean success = JythonInterpreter.interpret(theInputStream);
> >    logger.debug("successful interpretation of jython script? " + success);
> > }
> >
> >
> > If it is as simple as this, maybe we can leave the object
> > repository assembler alone and create a separate jython
> > assembler.  Maybe someone can fill in what the actual assembler
> > would look like?
> >
> > Christian, what do you think about this?
> >
> >
> > Jake
>
>_______________________________________________
>Barracuda mailing list
>[email protected]
>http://barracudamvc.org/lists/listinfo/barracuda