[jira] [Commented] (OFBIZ-9350) Deprecate Mini Lang

["Rishi Solanki (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OFBIZ-9350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16079026#comment-16079026 ] 

Rishi Solanki commented on OFBIZ-9350:
--------------------------------------

Review comments from [~lektran] on dev list to follow in upcoming conversion:

1. It would be good if the services were converted one per commit, with the
empty minilang file removed at the end with a separate commit.  That would
allow reviewers to compare the removed XML code with the new groovy code.
2. Defaults should (where possible) be moved to the service definition
3. I could be wrong about this but I don't think it is a good practice to
assign/change values in the parameters map, I think callers would not
expect their inputs to be changed by the service.  But I'm not sure if that
is actually happening or if groovy has copied the map beforehand, I'm also
unsure of how minilang used to handle the same.
4. Because groovy has "Groovy Truth", UtilValidate.isEmpty/isNotEmpty isn't
required, you can simply do "if (parameters.ratesList)".  An empty list or
null would return false.
5. I think it would be better to add the service documentation to the
service definition instead of a comment inline with the code.
6. I'm curious about the getRateAmount() "level" variable, I see it is only
defined within the local scope of the if/else blocks whereas "serviceName"
was defined at the method scope.  Does groovy allow "level" to take on the
method scope or is it an error?

> Deprecate Mini Lang
> -------------------
>
>                 Key: OFBIZ-9350
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-9350
>             Project: OFBiz
>          Issue Type: Improvement
>          Components: ALL APPLICATIONS, ALL COMPONENTS
>    Affects Versions: Trunk
>            Reporter: Michael Brohl
>            Assignee: Michael Brohl
>            Priority: Minor
>              Labels: documentation
>
> According to the proposal thread in [1] we decided to deprecate mini lang.
> This issue tracks the next steps proposed in the aformentioned thread, namely:
> 1. create a Wiki page for the documentation and description of the migration process and how mini lang will be replaced.
> 2. prominently state in the Wiki that minilang will be deprecated, e.g. in [2]
> 3. put deprecation tags in the corresponding code
> 4. kindly ask contributors with open patches written in mini lang to replace them by Java code [3]
> 5. start an initiative to replace existing mini lang code with Java code where applicable. This needs some more planning and discussion which parts we'll like to replace with Java code and which parts will better be replaced by some kind of DSL. A good starting point can be [4][5][6].
> [1] https://lists.apache.org/thread.html/253b41060a295b8ab68bc78763cc129fc74b712cf776f8716022097f@%3Cdev.ofbiz.apache.org%3E
> [2]  https://cwiki.apache.org/confluence/display/OFBADMIN/Mini+Language+-+minilang+-+simple-method+-+Reference
> [3] does anyone know a way to batch comment Jira issues like it is possible in Redmine?
> [4] https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+DSL+for+OFBiz+business+logic
> [5] https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Tutorial+-+A+Beginners+Development+Guide
> [6] https://cwiki.apache.org/confluence/display/OFBADMIN/Coding+Conventions



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)