groovy service code instead of minilang
Locked
12
12
groovy service code instead of minilang
 
|
I was wondering why groovy is not used for service code instead on minilang?
Any thoughts? Many thanks, Chris |
Re: groovy service code instead of minilang
Administrator
|
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" <[hidden email]> >I was wondering why groovy is not used for service code instead on minilang? > > Any thoughts? > > Many thanks, > > Chris > |
Re: groovy service code instead of minilang
|
|
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" <[hidden email]> >> I was wondering why groovy is not used for service code instead on >> minilang? >> >> Any thoughts? >> >> Many thanks, >> >> Chris >> > |
Re: groovy service code instead of minilang
|
|
In reply to this post by Jacques Le Roux
Hi Jacques:
IMHO, there is nothing productive about trying to write procedures using XML. I'd really like to see the Mini-Language facility augmented with support for something like Groovy, Bean Shell or PHP. Do you think that is possible? Those who like using XML can continue to do so. Those who prefer to use a tool more suited to writing procedures would have another option. Regards, Ruth 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" <[hidden email]> >> I was wondering why groovy is not used for service code instead on >> minilang? >> >> Any thoughts? >> >> Many thanks, >> >> Chris >> > > |
Re: groovy service code instead of minilang
|
|
On Feb 22, 2010, at 4:12 PM, Ruth Hoffman wrote:
> Hi Jacques: > IMHO, there is nothing productive about trying to write procedures using XML. IMO Minilang is very productive. > I'd really like to see the Mini-Language facility augmented with support for something like Groovy, Bean Shell or PHP. Do you think that is possible? You can already develop services in different languages; and of course it is possible (and quite easy) to extend the framework to add new service engines for additional languages. > Those who like using XML can continue to do so. Those who prefer to use a tool more suited to writing procedures would have another option. Yes, this is the philosophy of OFBiz. Kind regards, Jacopo > Regards, > Ruth > > 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" <[hidden email]> >>> I was wondering why groovy is not used for service code instead on minilang? >>> >>> Any thoughts? >>> >>> Many thanks, >>> >>> Chris >>> >> >> |
Re: groovy service code instead of minilang
|
Administrator
|
In reply to this post by Chris Snow-3
You just have to choose the right tool for the task at hand.
For the moment, I prefer minilang when it comes to deal with simple CRUD services and a bit more elaborated. I agree that a groovy DSL could be a good thing though, I have just not enough time to even think about it... Jacques From: "Christopher Snow" <[hidden email]> > 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" <[hidden email]> >>> I was wondering why groovy is not used for service code instead on >>> minilang? >>> >>> Any thoughts? >>> >>> Many thanks, >>> >>> Chris >>> >> > |
Re: groovy service code instead of minilang
|
|
In reply to this post by Jacques Le Roux
ofbiz is able to support anything if someone once to put the time into
doing it. That said, minilang, is geared to the entities so is really a shortcut language to manipulate data. I see no difference in XML and C##, for Basic, or php. if someone had no proficiency in one of them, the one they are use to is easier Christopher Snow sent the following on 2/22/2010 6:58 AM: > 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" <[hidden email]> >>> I was wondering why groovy is not used for service code instead on >>> minilang? >>> >>> Any thoughts? >>> >>> Many thanks, >>> >>> Chris >>> >> > > |
Re: groovy service code instead of minilang
|
|
In reply to this post by Chris Snow-3
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" <[hidden email]> >>> I was wondering why groovy is not used for service code instead on minilang? >>> >>> Any thoughts? >>> >>> Many thanks, >>> >>> Chris >>> >> > |
Re: groovy service code instead of minilang
|
|
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" <[hidden email]> >>> >>>> I was wondering why groovy is not used for service code instead on minilang? >>>> >>>> Any thoughts? >>>> >>>> Many thanks, >>>> >>>> Chris >>>> >>>> > > > |
Re: groovy service code instead of minilang
|
|
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" <[hidden email]> >>>> >>>>> I was wondering why groovy is not used for service code instead on minilang? >>>>> >>>>> Any thoughts? >>>>> >>>>> Many thanks, >>>>> >>>>> Chris >>>>> >>>>> >> >> >> |
Re: groovy service code instead of minilang
|
|
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" <[hidden email]> >>>>> >>>>> >>>>>> I was wondering why groovy is not used for service code instead on minilang? >>>>>> >>>>>> Any thoughts? >>>>>> >>>>>> Many thanks, >>>>>> >>>>>> Chris >>>>>> >>>>>> >>>>>> >>> >>> > > > |
Re: groovy service code instead of minilang
|
|
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" <[hidden email]> >>>>>> >>>>>>> I was wondering why groovy is not used for service code instead on minilang? >>>>>>> >>>>>>> Any thoughts? >>>>>>> >>>>>>> Many thanks, >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> >>>> >> >> >> |
Re: groovy service code instead of minilang
|
|
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" <[hidden email]> >>>>>>> >>>>>>> >>>>>>>> I was wondering why groovy is not used for service code instead on minilang? >>>>>>>> >>>>>>>> Any thoughts? >>>>>>>> >>>>>>>> Many thanks, >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>>>> >>> >>> > > > |
Re: groovy service code instead of minilang
|
|
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" <[hidden email]> >>>>>>>> >>>>>>>>> I was wondering why groovy is not used for service code instead on minilang? >>>>>>>>> >>>>>>>>> Any thoughts? >>>>>>>>> >>>>>>>>> Many thanks, >>>>>>>>> >>>>>>>>> Chris >>>>>>>>> >>>>>>>>> >>>>>> >>>> >> >> >> |
Re: groovy service code instead of minilang
|
|
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" <[hidden email]> >>>>>>>>> >>>>>>>>> >>>>>>>>>> I was wondering why groovy is not used for service code instead on minilang? >>>>>>>>>> >>>>>>>>>> Any thoughts? >>>>>>>>>> >>>>>>>>>> Many thanks, >>>>>>>>>> >>>>>>>>>> Chris >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > > |
Re: groovy service code instead of minilang
|
|
On Feb 22, 2010, at 12:23 PM, Ruth Hoffman wrote: > 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. So, in other words, that has nothing to do with simple-methods versus Java? > 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. Are we back to square one, looking for an example of a simple-method that you think would be better in Java or groovy? -David > > 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" <[hidden email]> >>>>>>>>>> >>>>>>>>>>> I was wondering why groovy is not used for service code instead on minilang? >>>>>>>>>>> >>>>>>>>>>> Any thoughts? >>>>>>>>>>> >>>>>>>>>>> Many thanks, >>>>>>>>>>> >>>>>>>>>>> Chris >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>> >>>> >> >> >> |
Re: groovy service code instead of minilang
|
|
David E Jones wrote: > On Feb 22, 2010, at 12:23 PM, Ruth Hoffman wrote: > > >> 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. >> > > So, in other words, that has nothing to do with simple-methods versus Java? > Method based services (and one Java method) that I think would be easier to follow and support if they were all written in something other than XML. > >> 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. >> > > Are we back to square one, looking for an example of a simple-method that you think would be better in Java or groovy? > David, I don't know why I even try. Sorry, but I am not as patient as you when it comes to explaining things to people who I believe should already know better. > -David > > > >> 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" <[hidden email]> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I was wondering why groovy is not used for service code instead on minilang? >>>>>>>>>>>> >>>>>>>>>>>> Any thoughts? >>>>>>>>>>>> >>>>>>>>>>>> Many thanks, >>>>>>>>>>>> >>>>>>>>>>>> Chris >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > > |
Re: groovy service code instead of minilang
|
|
Compelling argument. It's a beautiful style: restate the assertion as a lead in to argumentum ad hominem. Don't worry, I feel it too... it's hard to watch anything about news or politics these days without having this pattern drilled into one's head. Anyway, as for the sendMail and related services my point was that the issue seems to be related to how the services are organized and how they work together as opposed to what they are written in. Looking at the actual simple-method code, it all seems pretty straightforward... but I'll admit that is subjective and others might find it easier to read and work with if it was written in Java or groovy, and details about that is what I think would be more helpful to this discussion. -David On Feb 22, 2010, at 12:54 PM, Ruth Hoffman wrote: > David E Jones wrote: >> On Feb 22, 2010, at 12:23 PM, Ruth Hoffman wrote: >>> 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. >>> >> >> So, in other words, that has nothing to do with simple-methods versus Java? >> > Only in so far as the service itself is composed of several other Simple Method based services (and one Java method) that I think would be easier to follow and support if they were all written in something other than XML. >> >>> 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. >>> >> >> Are we back to square one, looking for an example of a simple-method that you think would be better in Java or groovy? >> > David, I don't know why I even try. > Sorry, but I am not as patient as you when it comes to explaining things to people who I believe should already know better. >> -David >> >> >> >>> 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" <[hidden email]> >>>>>>>>>>>> >>>>>>>>>>>>> I was wondering why groovy is not used for service code instead on minilang? >>>>>>>>>>>>> >>>>>>>>>>>>> Any thoughts? >>>>>>>>>>>>> >>>>>>>>>>>>> Many thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Chris >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >> >> >> |
Re: groovy service code instead of minilang
|
|
In reply to this post by Ruth Hoffman-2
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 |
Re: groovy service code instead of minilang
|
|
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 > |
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |