Ruth,
This explains better your feeling about minilang. You thought you had only the choice between minilang or Java (like trapped with
minilang ;o)
Actually it's open, we could even consider to use a Groovy DSL like suggested
Chris
http://docs.codehaus.org/display/GROOVY/Writing+Domain-Specific+Languages
But as I said, minilang is working well for me. I know it (a bit) and when I really need something hard to do with minilang (or
<actions... in widget, this is also an important point: code consistency, if you know minilang it's easier with widget) I call a
grovvy snippet (was BSH before).
Of course Groovy is very concise and smart, and maybe a DSL written in Groovy would please everybody, that's another story...
Notably because I dont think it would be accepted in trunk now without all the needed tests pre-written, ie at least able to do all
what minilang is doing...
Jacques
From: "Ruth Hoffman" <rhoff...@aesolves.com>
Neat!
I never knew.
Thanks much.
Ruth
David E Jones wrote:
I'd recommend using groovy instead of bsh, it's a much better language and much more stable and flexible. To see the list of
supported "engines" for the service engine look at the serviceengine.xml file.
To use groovy on your service definition just use engine="groovy" instead of engine="java", and then the location attribute
should be the location of your groovy script file (usually using the component:// syntax is easiest), and the invoke attribute
can be empty or left off entirely.
For example:
<service name="doSomething" engine="groovy"
location="component://mycomponent/script/com/mycompany/doSomething.groovy">
...
</service>
-David
On Feb 23, 2010, at 9:49 AM, Ruth Hoffman wrote:
Hi David:
How can I use BSH to write a service? I don't mean embed a BSH call inside XML, I mean can I, today write a service using BSH?
If so, thats great! How do I set this up?
Regards,
Ruth
David E Jones wrote:
How would this be different from the java, groovy, bsh, jython, and other scripting languages supported right now by the
service engine?
I'll tell you what's really cool about supporting all of these languages, and for work groups allowing people to use whatever
they want: the end result requires an enormous skill set to maintain. Also, with less structured languages like java and groovy
where you can do whatever you want (and people most certainly do, whether it is helpful or not for the functionality they are
building), so the result is a lot of inconsistency and higher maintenance costs.
-David
On Feb 23, 2010, at 8:54 AM, Ruth Hoffman wrote:
Hi Adrian:
I think I already said what I'd like changed. Perhaps you overlooked this: Please add a procedural language to the mix. PHP,
Groovy, Bean Shell etc. I don't care which.
Regards,
Ruth
Adrian Crum wrote:
Maybe the next time you try to use it, you could create a list of things you would like to see changed and submit it to the
community.
-Adrian
Ruth Hoffman wrote:
Hi Adrian:
To tell the truth, I don't use it to build my services anymore. Too much trouble to try and figure out each time how it
works. Much easier for me to write Java code.
BTW, don't you find it curious that no other non-committers (aside from the original inquiry) has anything to say about
this?
Regards,
Ruth
Adrian Crum wrote:
Ruth Hoffman wrote:
I tried using the Mini Language to create some Simple Services and I found that in each situation, CRUD operations were
only the tip of the ice-berg as far as developing applications was concerned. My applications do much more than update
database records. To go beyond CRUD (and simple HTML forms to update the database) is very cumbersome using the Mini
Language.
If you give us examples of things that could be made easier in mini-language,
then we might be able to change the language.
-Adrian
