You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Adrian Crum <ad...@sandglass-software.com> on 2012/07/02 16:44:23 UTC

Update: Mini-language Overhaul

The Mini-language Reference has reached the final draft status - with 
the exception of the Map Processor section. I am running out of time to 
work on the overhaul, so I am skipping that section for now.

https://cwiki.apache.org/OFBADMIN/mini-language-reference.html

Please take some time to review the document. If there are no objections 
to the new grammar, I will remove all of the yellow "draft status" notes 
next weekend.

The overhauled source code is fairly complete. I will spend the next few 
days working on the JavaDocs and then I will be done with the trunk updates.

If everything looks okay, I will back-port the overhaul to the Release 
12 branch. The overhaul includes some enhancements, but most of it is 
bug fixes and code cleanups - so I hope there will be no objections to 
porting the overhaul in its entirety.

Keep in mind none of this is set in stone - everyone is welcome to make 
changes.

-Adrian


Re: Update: Mini-language Overhaul

Posted by Adrian Crum <ad...@sandglass-software.com>.
No worries. I appreciate your review.

Btw, I'm currently working on getting Mini-language unit tests started. 
I will be making an initial commit that will contain only a few tests, 
but at least it's a start and we can build them out over time.

-Adrian

On 7/3/2012 12:51 PM, Scott Gray wrote:
> Please ignore, I was completely wrong :-)
>
> Regards
> Scott
>
> On 3/07/2012, at 11:37 PM, Scott Gray wrote:
>
>> Hi Adrian,
>>
>> Not sure if this is the best place for it but I noticed today that call-service handles service errors a bit differently from the service engine itself.
>>
>> In ServiceDispatcher.runSync(), the service returned an error if:
>> ModelService.RESPOND_ERROR.equals(results.get(ModelService.RESPONSE_MESSAGE))
>>
>> but in CallService the result is treated as an error if:
>> (result.containsKey(ModelService.ERROR_MESSAGE)) || (result.containsKey(ModelService.ERROR_MESSAGE_LIST))
>>
>> The problem here is that it seems common for services returning failure to use the error message map keys for the failure message.  This means that execution halts in minilang when a failure is returned even though the purpose of the failure response is to allow processing to continue.
>>
>> Regards
>> Scott
>>
>> On 3/07/2012, at 2:44 AM, Adrian Crum wrote:
>>
>>> The Mini-language Reference has reached the final draft status - with the exception of the Map Processor section. I am running out of time to work on the overhaul, so I am skipping that section for now.
>>>
>>> https://cwiki.apache.org/OFBADMIN/mini-language-reference.html
>>>
>>> Please take some time to review the document. If there are no objections to the new grammar, I will remove all of the yellow "draft status" notes next weekend.
>>>
>>> The overhauled source code is fairly complete. I will spend the next few days working on the JavaDocs and then I will be done with the trunk updates.
>>>
>>> If everything looks okay, I will back-port the overhaul to the Release 12 branch. The overhaul includes some enhancements, but most of it is bug fixes and code cleanups - so I hope there will be no objections to porting the overhaul in its entirety.
>>>
>>> Keep in mind none of this is set in stone - everyone is welcome to make changes.
>>>
>>> -Adrian
>>>



Re: Update: Mini-language Overhaul

Posted by Scott Gray <sc...@hotwaxmedia.com>.
Please ignore, I was completely wrong :-)

Regards
Scott

On 3/07/2012, at 11:37 PM, Scott Gray wrote:

> Hi Adrian,
> 
> Not sure if this is the best place for it but I noticed today that call-service handles service errors a bit differently from the service engine itself.
> 
> In ServiceDispatcher.runSync(), the service returned an error if:
> ModelService.RESPOND_ERROR.equals(results.get(ModelService.RESPONSE_MESSAGE))
> 
> but in CallService the result is treated as an error if:
> (result.containsKey(ModelService.ERROR_MESSAGE)) || (result.containsKey(ModelService.ERROR_MESSAGE_LIST))
> 
> The problem here is that it seems common for services returning failure to use the error message map keys for the failure message.  This means that execution halts in minilang when a failure is returned even though the purpose of the failure response is to allow processing to continue.
> 
> Regards
> Scott
> 
> On 3/07/2012, at 2:44 AM, Adrian Crum wrote:
> 
>> The Mini-language Reference has reached the final draft status - with the exception of the Map Processor section. I am running out of time to work on the overhaul, so I am skipping that section for now.
>> 
>> https://cwiki.apache.org/OFBADMIN/mini-language-reference.html
>> 
>> Please take some time to review the document. If there are no objections to the new grammar, I will remove all of the yellow "draft status" notes next weekend.
>> 
>> The overhauled source code is fairly complete. I will spend the next few days working on the JavaDocs and then I will be done with the trunk updates.
>> 
>> If everything looks okay, I will back-port the overhaul to the Release 12 branch. The overhaul includes some enhancements, but most of it is bug fixes and code cleanups - so I hope there will be no objections to porting the overhaul in its entirety.
>> 
>> Keep in mind none of this is set in stone - everyone is welcome to make changes.
>> 
>> -Adrian
>> 
> 


Re: Update: Mini-language Overhaul

Posted by Scott Gray <sc...@hotwaxmedia.com>.
Hi Adrian,

Not sure if this is the best place for it but I noticed today that call-service handles service errors a bit differently from the service engine itself.

In ServiceDispatcher.runSync(), the service returned an error if:
ModelService.RESPOND_ERROR.equals(results.get(ModelService.RESPONSE_MESSAGE))

but in CallService the result is treated as an error if:
(result.containsKey(ModelService.ERROR_MESSAGE)) || (result.containsKey(ModelService.ERROR_MESSAGE_LIST))

The problem here is that it seems common for services returning failure to use the error message map keys for the failure message.  This means that execution halts in minilang when a failure is returned even though the purpose of the failure response is to allow processing to continue.

Regards
Scott

On 3/07/2012, at 2:44 AM, Adrian Crum wrote:

> The Mini-language Reference has reached the final draft status - with the exception of the Map Processor section. I am running out of time to work on the overhaul, so I am skipping that section for now.
> 
> https://cwiki.apache.org/OFBADMIN/mini-language-reference.html
> 
> Please take some time to review the document. If there are no objections to the new grammar, I will remove all of the yellow "draft status" notes next weekend.
> 
> The overhauled source code is fairly complete. I will spend the next few days working on the JavaDocs and then I will be done with the trunk updates.
> 
> If everything looks okay, I will back-port the overhaul to the Release 12 branch. The overhaul includes some enhancements, but most of it is bug fixes and code cleanups - so I hope there will be no objections to porting the overhaul in its entirety.
> 
> Keep in mind none of this is set in stone - everyone is welcome to make changes.
> 
> -Adrian
> 


Re: Update: Mini-language Overhaul

Posted by Jacques Le Roux <ja...@les7arts.com>.
I did not review details, but really quite a steady work Adrian, appreciated at its real value!

I hope it will not be used to drop minilang in favour of only a Groovy DSL though.

I think the minilang can stay, and people used to it continue to use and appreciate its quality. Then maybe time will tell, but
dropping it from start shall not be.

Thanks

Jacques


From: "Adrian Crum" <ad...@sandglass-software.com>
> The Mini-language Reference has reached the final draft status - with the exception of the Map Processor section. I am running out
> of time to work on the overhaul, so I am skipping that section for now.
>
> https://cwiki.apache.org/OFBADMIN/mini-language-reference.html
>
> Please take some time to review the document. If there are no objections to the new grammar, I will remove all of the yellow
> "draft status" notes next weekend.
>
> The overhauled source code is fairly complete. I will spend the next few days working on the JavaDocs and then I will be done with
> the trunk updates.
>
> If everything looks okay, I will back-port the overhaul to the Release 12 branch. The overhaul includes some enhancements, but
> most of it is bug fixes and code cleanups - so I hope there will be no objections to porting the overhaul in its entirety.
>
> Keep in mind none of this is set in stone - everyone is welcome to make changes.
>
> -Adrian
>

Re: Update: Mini-language Overhaul

Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
Adrian,

I will try to find some time to review again the document but in the meantime I would like to thank you for all the work you did on this overhaul.

Regards,

Jacopo

On Jul 2, 2012, at 4:44 PM, Adrian Crum wrote:

> The Mini-language Reference has reached the final draft status - with the exception of the Map Processor section. I am running out of time to work on the overhaul, so I am skipping that section for now.
> 
> https://cwiki.apache.org/OFBADMIN/mini-language-reference.html
> 
> Please take some time to review the document. If there are no objections to the new grammar, I will remove all of the yellow "draft status" notes next weekend.
> 
> The overhauled source code is fairly complete. I will spend the next few days working on the JavaDocs and then I will be done with the trunk updates.
> 
> If everything looks okay, I will back-port the overhaul to the Release 12 branch. The overhaul includes some enhancements, but most of it is bug fixes and code cleanups - so I hope there will be no objections to porting the overhaul in its entirety.
> 
> Keep in mind none of this is set in stone - everyone is welcome to make changes.
> 
> -Adrian
>