David:
There are one or more Mini-language based services that are strung
together before processing ever gets to the Java sendMail method call. I
had to disable those services to get the sendMail service to work
correctly for my situation.
I'm not saying the Mini-language is bad. I'm saying that in certain
situations such as the stringing together of services (SECAs) it is
really hard to figure out what is going on. Cuts into productivity and
it effects long-term product maintainability.
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.
Again, just my 2 cents.
Regards,
Ruth
David E Jones wrote:
The sendMail service itself is written in Java, and is a bit of a doosie. I'm
not sure if that's because it's written in Java per-se, it's maybe just a bit
service that does a bunch of stuff (ie doesn't really mean it's bad just
because it's in Java).
-David
On Feb 22, 2010, at 11:28 AM, Ruth Hoffman wrote:
I think it was just a plain old fashion sendMail service call. It was a few
months ago, so I don't remember exactly.
David E Jones wrote:
When you say "send mail seca" do you mean the sendMailFromTemplateSetting
simple-method in the EmailServices.xml file? That one looks pretty straightforward to
me... so I'm guessing you mean a different simple-method...
-David
On Feb 22, 2010, at 10:42 AM, Ruth Hoffman wrote:
Hi David:
Off the top of my head, the send mail seca would be much easier to follow if it
were coded in Java or groovy. I had a heck of a time figuring out why I was
getting HTML formatting errors (on perfectly valid HTML) and trying to follow
the sequence of events. In fact, I just ended up disabling the service because
it just took too much time to figure out.
You asked.
Ruth
David E Jones wrote:
Are there any examples in OFBiz right now where you think that using Java or
groovy would be easier to write and maintain than the simple-method it is
implemented in?
-David
On Feb 22, 2010, at 10:20 AM, Ruth Hoffman wrote:
David:
IMO, what you say is true. When used as originally intended Simple Methods
can't be beat. It is when Simple Methods are put together into complex
services, that do more than data mapping, that this theory of operation starts
to fall apart.
Of course, that is just my opinion.
Regards,
Ruth
David E Jones wrote:
Simple methods are intended to be good for a few things for data mapping
operations (which is the bulk of what needs to be done in business
applications), including:
1. fewer lines than Java/groovy
2. each line less complex than equivalent Java or groovy
3. scripts from different developers are much more consistent
Yes, you're correct that XML makes things more verbose. However, that doesn't
generally increase the time it takes to work with the code (writing or
maintaining). Because the overall complexity is less and the verbose nature of
it makes more explicit, I'd argue that it is significantly more efficient and
simple for developers to both write and maintain data mapping code using simple
methods than using a free-form script.
-David
On Feb 22, 2010, at 7:58 AM, Christopher Snow wrote:
Hi Jacques, minilang is quick, but being xml it's verbose. Groovy would be
much more concise wouldn't it - especially if a DSL was created?
Jacques Le Roux wrote:
For the same reason Java is not used. Once you get a grasp on it you understand
why it's there: productivity.
http://cwiki.apache.org/confluence/display/OFBIZ/Mini-Language+Guide#Mini-LanguageGuide-introduction
Jacques
From: "Christopher Snow" <[email protected]>
I was wondering why groovy is not used for service code instead on minilang?
Any thoughts?
Many thanks,
Chris
