My almost exclusive use of simple methods stems from my lack of
technical skills and not from a perceived superiority of it. When
getting familiar with OFBiz I found it much easier to find examples of
use because the tags could be searched for. Without the tags that are
present in an xml structured language, it is much more difficult for
someone to produce anything of value unless they have a strong
understanding of java and are willing to spend the time to get
intimately involved with the major classes in OFBiz.
As far as typing, if you're talking keystrokes, that's an editor issue.
The xml editor available in the the eclipse web tools platform does a
perfect job of reading the xsd. If it's actual characters on the
screen, I can't really offer anything there. If you find it difficult
to read, changing the coloring of the editor is a rather obvious point
of help, but I imagine you already know that.
In regards to a possible GUI aspect or using OFBiz as a sort of IDE, I
think you would need to be able to load/unload components and services
before you would want to seriously consider the potential benefit.
Is minilang the devil? Possibly. It's allowed just enough crutch for
me not to really invest the time in learning Java. I can certainly
read what's going on, but I still lack the creative tonicity needed to
write quickly in Java starting with a blank screen. If minilang is the
devil, maybe the devil has gotten a bad wrap ;-)
--- Jonathon -- Improov <[EMAIL PROTECTED]> wrote:
> Ean,
>
> A major part of the reason why Simple Methods can be difficult to
> read is this: you can't write
> reentrant functions in Minilang. Maybe repeated chunks of Minilang
> codes cannot be abstracted into
> neat reentrant functions.
>
> Once you introduce reentrant functions, you'll find Minilang just as
> simple as any other
> script/language, like PHP, C, Javascript.
>
> Plus Minilang is specifically made for backend data operations.
>
> As for any syntactic sugars that may be absent from Minilang, it
> really won't be difficult to
> enhance it. All we need (or all I need) is feedback! :) Chris Howe is
> a good source for opinions
> and experience on Minilang, I think. Maybe we can ask him.
>
> I added the ability to do reentrant Simple Methods inside of an hour.
>
> Jonathon
>
> Ean Schuessler wrote:
> > On Wednesday 06 June 2007 10:51:28 pm David E Jones wrote:
> >> Alternatively Ean, and maybe even better: in an ideal world what
> would you
> >> use in place of the MiniLang/simple-method code (regardless of
> whether or
> >> not it exists already)?
> >>
> >> As we've done in the past, if there is anything that represents a
> >> sufficient efficiency gain for development and maintenance it may
> very well
> >> be worth the transition to it.
> >
> > Wellll....
> >
> > I don't like the XML approach because the code is difficult to read
> and it
> > makes me type a lot of characters that have no syntactic meaning
> when I
> > presume Minilang is intended to reduce typing. I also assume (or
> have heard)
> > that using XML simplifies parsing and generation so that a GUI
> based tool
> > could be built on top of it. I accept that idea but note that
> pretty much any
> > major language built on the Java VM generates some sort of the AST
> and
> > outputting that tree to an XML format would be pretty trivial. I
> also note
> > that we do not have such a case tool and wonder if we really want
> to duel
> > with something like BPEL (I vote no).
> >
> > I think that most of the scripting conveniences afforded by
> MiniLang can be
> > achieved more thoroughly by one of the many scripting languages
> available for
> > the JVM. My personal choice would be Groovy because it offers the
> same
> > conveniences touted by other dynamic languages and its Map
> syntactic sugar
> > directly supports native Java Maps. This feature should not be
> underestimated
> > because it is suprsingly absent from both Jython and JRuby and is
> very, very
> > useful:
> >
> > delegator.findByPrimaryKey("UserLogin", ["userLoginId": "admin"])
> > person.firstName = "Ean"
> > address.putAll([address1: "1000 Smith St.", stateProvinceGeoId:
> "TX",
> > postalCode: "75226"]);
> > ...etc...
> >
> > More than once I've thought about XSLT that produces Groovy from
> Minilang.
> > Regex sugar, closures, dynamic typing and tree builders all are
> tremendous
> > conveniences. Operator overloading also implies certain guilty
> pleasures that
> > are best not discussed on this public list. Plus Groovy compiles to
> native
> > bytecode and is already supported by a JSR.
> >
> > Plus we'd get lots of marketing cheese out of a move like that.
> >
> > I also wonder if we shouldn't wrap the dispatcher in a proxy and do
> things
> > like:
> >
> > me = [:]
> > me.firstName = "Ean"
> > me.lastName = "Schuessler"
> > dispatcher.createPerson(me)
> >
> > That's my .02 anyway.
> >
>
>
