Re: Discussion: Mini-language Overhaul
Adrian, what is your plan ? you want to use mini-lang for development and compile to java at the same time ?! Issues with recompile can resolved with an ant task that monitors src directory for changes, and trigger a recompile when changes occur. Reloading the compile java can be by external utilities. Honestly, I don't think this is should be done by the framework, as it makes it harder to maintain. Tools that can reload java classes like jrebel (commercial), hotswap, jreloader ... etc. On Wed, Mar 7, 2012 at 11:22 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: That's one of the advantages to mini-language - you don't need to compile it. It would be nice to have a tool that converts schemas to Java model classes however. -Adrian On 3/7/2012 11:35 PM, Mansour Al Akeel wrote: Not sure if this discussion open for users as well. I don't use mini-lang, and prefer to do things in java. But I am wondering why not move all the repetitive code to java (copying fields). Those who prefer to use mini-lang can have an XSLT that will produce the java code as they want. This way, every contributor can customize their XSLT and have their grammar that will produce the java code. Maintenance will not be possible with mini-lang, since the code generated is committed to SVN is in java. On Wed, Mar 7, 2012 at 1:18 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: I created a Wiki page to help get things started: https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference I put just enough information in it to work on the layout. I will continue working on it when I have time. Everyone with write access is welcome to work on it also. The information is based on the mini-language Java code - which is the ultimate authority. The schemas are inaccurate - they should be used only for looking up schema-supplied default values. The goal is to document the current mini-language grammar, and add proposed changes. If a proposal is approved, then it can get a green check mark. If a proposal is vetoed, then it can get a red X. When everyone agrees on the grammar, the document will be updated, and it will move out of the draft stage. Then the job will be to work on the Java and XML code to make it match the grammar. I put a couple of proposals in the page to help get things started. Let me know what you think. -Adrian On 3/6/2012 9:42 AM, Adrian Crum wrote: set field=field4 from=parameters.inputField1 + 10/ !-- use Minilang built-in and efficient support: not currently supported but maybe something to consider in the future -- The from attribute contains a UEL expression, so it is currently supported. -Adrian On 3/6/2012 9:33 AM, Jacopo Cappellato wrote: On Mar 6, 2012, at 10:03 AM, Adrian Crum wrote: Replacing FSE with Groovy is a bad idea. Adam and I optimized FSE so that it is very lightweight and fast. I also optimized the UEL integration so there is very little overhead in the evaluation process. Switching everything to Groovy will slow things down and increase memory usage. Also keep in mind that Groovy creates a class for every script, so we will run out of permgen space again. Ok, makes perfect sense, thank you. I think a wiser strategy would be to make mini-lang as feature complete as possible, and include a from-script attribute for any feature gaps. In other words, use from-script as a last resort - because it is costly. +1: by the way we could still use the from attribute for both: set field=field4 from=parameters.inputField1/ !-- use Minilang built-in and efficient support -- set field=field4 from=parameters.inputField1 + 10/ !-- use Minilang built-in and efficient support: not currently supported but maybe something to consider in the future -- set field=field4 from=groovy: parameters.inputField1 + 10/ !-- use Groovy (inefficient) -- Jacopo -Adrian On 3/6/2012 8:53 AM, Jacopo Cappellato wrote: On Mar 6, 2012, at 9:32 AM, Adrian Crum wrote: I don't understand what you mean by supporting a limited number of types. Currently, mini-lang supports any type - thanks to the conversion framework. The conversion framework is fine; I was thinking that we could implicitly (by default) treat in Minilang all the numbers as BigDecimals, all the strings as GStrings/Expandable Strings; where special conversions are required than the type can be specified. I like the idea of changing the from-field attribute to from. I would like to see a from-script attribute added: set field=field4 from-script=groovy: parameters.inputField1 + 10/!-- Use Groovy -- and why not: set field=field4 from=parameters.inputField1/!-- Use Groovy internally: refactor OFBiz custom code to delegate on Groovy the evaluation of simple assignments; this could potentially replace FlexibleStringExpander related code -- set field=field4 from=groovy: parameters.inputField1 + 10/!-- Use Groovy
Re: Discussion: Mini-language Overhaul
Thanks adrian for this works,
I will add my propositions.
After all proposition will include on wiki, how to you proceed to
approve each ? A vote on mailing list for each ?
Nicolas
Le 07/03/2012 19:18, Adrian Crum a écrit :
I created a Wiki page to help get things started:
https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference
I put just enough information in it to work on the layout. I will
continue working on it when I have time. Everyone with write access is
welcome to work on it also. The information is based on the
mini-language Java code - which is the ultimate authority. The schemas
are inaccurate - they should be used only for looking up
schema-supplied default values.
The goal is to document the current mini-language grammar, and add
proposed changes. If a proposal is approved, then it can get a green
check mark. If a proposal is vetoed, then it can get a red X. When
everyone agrees on the grammar, the document will be updated, and it
will move out of the draft stage. Then the job will be to work on the
Java and XML code to make it match the grammar.
I put a couple of proposals in the page to help get things started.
Let me know what you think.
-Adrian
On 3/6/2012 9:42 AM, Adrian Crum wrote:
set field=field4 from=parameters.inputField1 + 10/ !-- use
Minilang built-in and efficient support: not currently supported but
maybe something to consider in the future --
The from attribute contains a UEL expression, so it is currently
supported.
-Adrian
On 3/6/2012 9:33 AM, Jacopo Cappellato wrote:
On Mar 6, 2012, at 10:03 AM, Adrian Crum wrote:
Replacing FSE with Groovy is a bad idea. Adam and I optimized FSE
so that it is very lightweight and fast. I also optimized the UEL
integration so there is very little overhead in the evaluation
process. Switching everything to Groovy will slow things down and
increase memory usage. Also keep in mind that Groovy creates a
class for every script, so we will run out of permgen space again.
Ok, makes perfect sense, thank you.
I think a wiser strategy would be to make mini-lang as feature
complete as possible, and include a from-script attribute for any
feature gaps. In other words, use from-script as a last resort -
because it is costly.
+1: by the way we could still use the from attribute for both:
set field=field4 from=parameters.inputField1/ !-- use
Minilang built-in and efficient support --
set field=field4 from=parameters.inputField1 + 10/ !-- use
Minilang built-in and efficient support: not currently supported but
maybe something to consider in the future --
set field=field4 from=groovy: parameters.inputField1 + 10/
!-- use Groovy (inefficient) --
Jacopo
-Adrian
On 3/6/2012 8:53 AM, Jacopo Cappellato wrote:
On Mar 6, 2012, at 9:32 AM, Adrian Crum wrote:
I don't understand what you mean by supporting a limited number
of types. Currently, mini-lang supports any type - thanks to the
conversion framework.
The conversion framework is fine; I was thinking that we could
implicitly (by default) treat in Minilang all the numbers as
BigDecimals, all the strings as GStrings/Expandable Strings; where
special conversions are required than the type can be specified.
I like the idea of changing the from-field attribute to from. I
would like to see a from-script attribute added:
set field=field4 from-script=groovy: parameters.inputField1 +
10/!-- Use Groovy --
and why not:
set field=field4 from=parameters.inputField1/!-- Use Groovy
internally: refactor OFBiz custom code to delegate on Groovy the
evaluation of simple assignments; this could potentially replace
FlexibleStringExpander related code --
set field=field4 from=groovy: parameters.inputField1 +
10/!-- Use Groovy explicitly to evaluate the expression (use
the same from attribute instead of a separate from-script)--
set field=field4 from=parameters.inputField1 + 10/!-- Use
Groovy (by default, configurable) to evaluate the expression--
set field=field4 from=beanshell: parameters.inputField1 +
10/!-- Use Beanshell to evaluate the expression--
?
Then we can remove script support from expressions, which will
eliminate ugly hacks like:
set field=field4 value=${groovy: parameters.inputField1 + 10}/
+1
Jacopo
-Adrian
On 3/6/2012 7:31 AM, Jacopo Cappellato wrote:
I am a big fan of Minilang too.
The evolution strategy that I would like to see implemented
for Minilang is actually the same one I would liketo see applied
to OFBiz framework in general: review the current usage of the
tool, fix existing usage for consistency (upgrade old code to
use newer mechanisms offered by the tool), get rid of unused or
old mechanisms in the attempt to slim down the size of the
framework code, unify/simplify mechanisms based on lesson
learned; all of this could be useful even to prepare the future
migration to a different tool (e.g. Groovy).
I know that it is very vague and doesn't add much to this thread
but I like
Re: Discussion: Mini-language Overhaul
Voting on each item will not work because there are too many. We can
discuss things here and when there seems to be general agreement, I
will ask for a vote on the entire grammar. When that vote passes, I
will include the proposals in the grammar (move them out of the blue
boxes and into the normal text), and change the status from draft to
final.
-Adrian
Quoting Nicolas Malin malin.nico...@librenberry.net:
Thanks adrian for this works,
I will add my propositions.
After all proposition will include on wiki, how to you proceed to
approve each ? A vote on mailing list for each ?
Nicolas
Le 07/03/2012 19:18, Adrian Crum a écrit :
I created a Wiki page to help get things started:
https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference I put just enough information in it to work on the layout. I will continue working on it when I have time. Everyone with write access is welcome to work on it also. The information is based on the mini-language Java code - which is the ultimate authority. The schemas are inaccurate - they should be used only for looking up schema-supplied default
values.
The goal is to document the current mini-language grammar, and add
proposed changes. If a proposal is approved, then it can get a
green check mark. If a proposal is vetoed, then it can get a red X.
When everyone agrees on the grammar, the document will be updated,
and it will move out of the draft stage. Then the job will be to
work on the Java and XML code to make it match the grammar.
I put a couple of proposals in the page to help get things started.
Let me know what you think.
-Adrian
On 3/6/2012 9:42 AM, Adrian Crum wrote:
set field=field4 from=parameters.inputField1 + 10/ !-- use
Minilang built-in and efficient support: not currently supported
but maybe something to consider in the future --
The from attribute contains a UEL expression, so it is currently supported.
-Adrian
On 3/6/2012 9:33 AM, Jacopo Cappellato wrote:
On Mar 6, 2012, at 10:03 AM, Adrian Crum wrote:
Replacing FSE with Groovy is a bad idea. Adam and I optimized
FSE so that it is very lightweight and fast. I also optimized
the UEL integration so there is very little overhead in the
evaluation process. Switching everything to Groovy will slow
things down and increase memory usage. Also keep in mind that
Groovy creates a class for every script, so we will run out of
permgen space again.
Ok, makes perfect sense, thank you.
I think a wiser strategy would be to make mini-lang as feature
complete as possible, and include a from-script attribute for
any feature gaps. In other words, use from-script as a last
resort - because it is costly.
+1: by the way we could still use the from attribute for both:
set field=field4 from=parameters.inputField1/ !-- use
Minilang built-in and efficient support --
set field=field4 from=parameters.inputField1 + 10/ !-- use
Minilang built-in and efficient support: not currently supported
but maybe something to consider in the future --
set field=field4 from=groovy: parameters.inputField1 + 10/
!-- use Groovy (inefficient) --
Jacopo
-Adrian
On 3/6/2012 8:53 AM, Jacopo Cappellato wrote:
On Mar 6, 2012, at 9:32 AM, Adrian Crum wrote:
I don't understand what you mean by supporting a limited
number of types. Currently, mini-lang supports any type -
thanks to the conversion framework.
The conversion framework is fine; I was thinking that we could
implicitly (by default) treat in Minilang all the numbers as
BigDecimals, all the strings as GStrings/Expandable Strings;
where special conversions are required than the type can be
specified.
I like the idea of changing the from-field attribute to from.
I would like to see a from-script attribute added:
set field=field4 from-script=groovy:
parameters.inputField1 + 10/!-- Use Groovy --
and why not:
set field=field4 from=parameters.inputField1/!-- Use
Groovy internally: refactor OFBiz custom code to delegate on
Groovy the evaluation of simple assignments; this could
potentially replace FlexibleStringExpander related code --
set field=field4 from=groovy: parameters.inputField1 +
10/!-- Use Groovy explicitly to evaluate the expression (use
the same from attribute instead of a separate from-script)--
set field=field4 from=parameters.inputField1 + 10/!--
Use Groovy (by default, configurable) to evaluate the
expression--
set field=field4 from=beanshell: parameters.inputField1 +
10/!-- Use Beanshell to evaluate the expression--
?
Then we can remove script support from expressions, which will
eliminate ugly hacks like:
set field=field4 value=${groovy: parameters.inputField1 + 10}/
+1
Jacopo
-Adrian
On 3/6/2012 7:31 AM, Jacopo Cappellato wrote:
I am a big fan of Minilang too.
The evolution strategy that I would like to see implemented
for Minilang is actually the same one I would liketo see
applied to OFBiz framework in general: review the
Re: Discussion: Mini-language Overhaul
Ok thanks adrian
Nicolas
Le 08/03/2012 14:46, adrian.c...@sandglass-software.com a écrit :
Voting on each item will not work because there are too many. We can
discuss things here and when there seems to be general agreement, I
will ask for a vote on the entire grammar. When that vote passes, I
will include the proposals in the grammar (move them out of the blue
boxes and into the normal text), and change the status from draft to
final.
-Adrian
Quoting Nicolas Malin malin.nico...@librenberry.net:
Thanks adrian for this works,
I will add my propositions.
After all proposition will include on wiki, how to you proceed to
approve each ? A vote on mailing list for each ?
Nicolas
Le 07/03/2012 19:18, Adrian Crum a écrit :
I created a Wiki page to help get things started:
https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference
I put just enough information in it to work on the layout. I will
continue working on it when I have time. Everyone with write access
is welcome to work on it also. The information is based on the
mini-language Java code - which is the ultimate authority. The
schemas are inaccurate - they should be used only for looking up
schema-supplied default values.
The goal is to document the current mini-language grammar, and add
proposed changes. If a proposal is approved, then it can get a green
check mark. If a proposal is vetoed, then it can get a red X. When
everyone agrees on the grammar, the document will be updated, and it
will move out of the draft stage. Then the job will be to work on
the Java and XML code to make it match the grammar.
I put a couple of proposals in the page to help get things started.
Let me know what you think.
-Adrian
On 3/6/2012 9:42 AM, Adrian Crum wrote:
set field=field4 from=parameters.inputField1 + 10/ !-- use
Minilang built-in and efficient support: not currently supported
but maybe something to consider in the future --
The from attribute contains a UEL expression, so it is currently
supported.
-Adrian
On 3/6/2012 9:33 AM, Jacopo Cappellato wrote:
On Mar 6, 2012, at 10:03 AM, Adrian Crum wrote:
Replacing FSE with Groovy is a bad idea. Adam and I optimized FSE
so that it is very lightweight and fast. I also optimized the UEL
integration so there is very little overhead in the evaluation
process. Switching everything to Groovy will slow things down and
increase memory usage. Also keep in mind that Groovy creates a
class for every script, so we will run out of permgen space again.
Ok, makes perfect sense, thank you.
I think a wiser strategy would be to make mini-lang as feature
complete as possible, and include a from-script attribute for any
feature gaps. In other words, use from-script as a last resort -
because it is costly.
+1: by the way we could still use the from attribute for both:
set field=field4 from=parameters.inputField1/ !-- use
Minilang built-in and efficient support --
set field=field4 from=parameters.inputField1 + 10/ !-- use
Minilang built-in and efficient support: not currently supported
but maybe something to consider in the future --
set field=field4 from=groovy: parameters.inputField1 + 10/
!-- use Groovy (inefficient) --
Jacopo
-Adrian
On 3/6/2012 8:53 AM, Jacopo Cappellato wrote:
On Mar 6, 2012, at 9:32 AM, Adrian Crum wrote:
I don't understand what you mean by supporting a limited number
of types. Currently, mini-lang supports any type - thanks to
the conversion framework.
The conversion framework is fine; I was thinking that we could
implicitly (by default) treat in Minilang all the numbers as
BigDecimals, all the strings as GStrings/Expandable Strings;
where special conversions are required than the type can be
specified.
I like the idea of changing the from-field attribute to from. I
would like to see a from-script attribute added:
set field=field4 from-script=groovy: parameters.inputField1
+ 10/!-- Use Groovy --
and why not:
set field=field4 from=parameters.inputField1/!-- Use
Groovy internally: refactor OFBiz custom code to delegate on
Groovy the evaluation of simple assignments; this could
potentially replace FlexibleStringExpander related code --
set field=field4 from=groovy: parameters.inputField1 +
10/!-- Use Groovy explicitly to evaluate the expression (use
the same from attribute instead of a separate from-script)--
set field=field4 from=parameters.inputField1 + 10/!-- Use
Groovy (by default, configurable) to evaluate the expression--
set field=field4 from=beanshell: parameters.inputField1 +
10/!-- Use Beanshell to evaluate the expression--
?
Then we can remove script support from expressions, which will
eliminate ugly hacks like:
set field=field4 value=${groovy: parameters.inputField1 +
10}/
+1
Jacopo
-Adrian
On 3/6/2012 7:31 AM, Jacopo Cappellato wrote:
I am a big fan of Minilang too.
The evolution strategy that I would like to see implemented
for Minilang is actually the same one I would liketo
Re: Discussion: Mini-language Overhaul
A) I would like to see removed all the attributes map-name and just leave the field attribute; for example: clear-field field=foo map-name=parameters/ can be: clear-field field=parameters.foo/ B) instead of: fail-property resource=ErrorMessages property=FooError / we could have fail-property property=ErrorMessages.FooError / C) instead of: request-to-field session-to-field we could have: set field=foo from=parameters.request.inputFoo/ set field=foo from=parameters.session.inputFoo/ D) similarly deprecate (replaced by set): field-to-env field-to-field field-to-list field-to-request field-to-session property-to-field now-timestamp-to-env now-date-to-env map-to-map list-to-list string-to-field string-to-list to-string webapp-property-to-field set-current-user-login I don't have more time today but there may be others :-) Jacopo On Mar 8, 2012, at 3:16 PM, Nicolas Malin wrote: Ok thanks adrian Nicolas Le 08/03/2012 14:46, adrian.c...@sandglass-software.com a écrit : Voting on each item will not work because there are too many. We can discuss things here and when there seems to be general agreement, I will ask for a vote on the entire grammar. When that vote passes, I will include the proposals in the grammar (move them out of the blue boxes and into the normal text), and change the status from draft to final. -Adrian Quoting Nicolas Malin malin.nico...@librenberry.net: Thanks adrian for this works, I will add my propositions. After all proposition will include on wiki, how to you proceed to approve each ? A vote on mailing list for each ? Nicolas Le 07/03/2012 19:18, Adrian Crum a écrit : I created a Wiki page to help get things started: https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference I put just enough information in it to work on the layout. I will continue working on it when I have time. Everyone with write access is welcome to work on it also. The information is based on the mini-language Java code - which is the ultimate authority. The schemas are inaccurate - they should be used only for looking up schema-supplied default values. The goal is to document the current mini-language grammar, and add proposed changes. If a proposal is approved, then it can get a green check mark. If a proposal is vetoed, then it can get a red X. When everyone agrees on the grammar, the document will be updated, and it will move out of the draft stage. Then the job will be to work on the Java and XML code to make it match the grammar. I put a couple of proposals in the page to help get things started. Let me know what you think. -Adrian On 3/6/2012 9:42 AM, Adrian Crum wrote: set field=field4 from=parameters.inputField1 + 10/ !-- use Minilang built-in and efficient support: not currently supported but maybe something to consider in the future -- The from attribute contains a UEL expression, so it is currently supported. -Adrian On 3/6/2012 9:33 AM, Jacopo Cappellato wrote: On Mar 6, 2012, at 10:03 AM, Adrian Crum wrote: Replacing FSE with Groovy is a bad idea. Adam and I optimized FSE so that it is very lightweight and fast. I also optimized the UEL integration so there is very little overhead in the evaluation process. Switching everything to Groovy will slow things down and increase memory usage. Also keep in mind that Groovy creates a class for every script, so we will run out of permgen space again. Ok, makes perfect sense, thank you. I think a wiser strategy would be to make mini-lang as feature complete as possible, and include a from-script attribute for any feature gaps. In other words, use from-script as a last resort - because it is costly. +1: by the way we could still use the from attribute for both: set field=field4 from=parameters.inputField1/ !-- use Minilang built-in and efficient support -- set field=field4 from=parameters.inputField1 + 10/ !-- use Minilang built-in and efficient support: not currently supported but maybe something to consider in the future -- set field=field4 from=groovy: parameters.inputField1 + 10/ !-- use Groovy (inefficient) -- Jacopo -Adrian On 3/6/2012 8:53 AM, Jacopo Cappellato wrote: On Mar 6, 2012, at 9:32 AM, Adrian Crum wrote: I don't understand what you mean by supporting a limited number of types. Currently, mini-lang supports any type - thanks to the conversion framework. The conversion framework is fine; I was thinking that we could implicitly (by default) treat in Minilang all the numbers as BigDecimals, all the strings as GStrings/Expandable Strings; where special conversions are required than the type can be specified. I like the idea of changing the from-field attribute to from. I would like to see a from-script attribute added: set field=field4 from-script=groovy: parameters.inputField1 + 10/!-- Use Groovy -- and why not: set field=field4
Re: Discussion: Mini-language Overhaul
Ah, and just to be clear: I also agree with the comments in Confluence about deprecating other elements as well (I actually didn't include them in my list but I agree they should be removed). Jacopo On Mar 8, 2012, at 4:18 PM, Jacopo Cappellato wrote: A) I would like to see removed all the attributes map-name and just leave the field attribute; for example: clear-field field=foo map-name=parameters/ can be: clear-field field=parameters.foo/ B) instead of: fail-property resource=ErrorMessages property=FooError / we could have fail-property property=ErrorMessages.FooError / C) instead of: request-to-field session-to-field we could have: set field=foo from=parameters.request.inputFoo/ set field=foo from=parameters.session.inputFoo/ D) similarly deprecate (replaced by set): field-to-env field-to-field field-to-list field-to-request field-to-session property-to-field now-timestamp-to-env now-date-to-env map-to-map list-to-list string-to-field string-to-list to-string webapp-property-to-field set-current-user-login I don't have more time today but there may be others :-) Jacopo On Mar 8, 2012, at 3:16 PM, Nicolas Malin wrote: Ok thanks adrian Nicolas Le 08/03/2012 14:46, adrian.c...@sandglass-software.com a écrit : Voting on each item will not work because there are too many. We can discuss things here and when there seems to be general agreement, I will ask for a vote on the entire grammar. When that vote passes, I will include the proposals in the grammar (move them out of the blue boxes and into the normal text), and change the status from draft to final. -Adrian Quoting Nicolas Malin malin.nico...@librenberry.net: Thanks adrian for this works, I will add my propositions. After all proposition will include on wiki, how to you proceed to approve each ? A vote on mailing list for each ? Nicolas Le 07/03/2012 19:18, Adrian Crum a écrit : I created a Wiki page to help get things started: https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference I put just enough information in it to work on the layout. I will continue working on it when I have time. Everyone with write access is welcome to work on it also. The information is based on the mini-language Java code - which is the ultimate authority. The schemas are inaccurate - they should be used only for looking up schema-supplied default values. The goal is to document the current mini-language grammar, and add proposed changes. If a proposal is approved, then it can get a green check mark. If a proposal is vetoed, then it can get a red X. When everyone agrees on the grammar, the document will be updated, and it will move out of the draft stage. Then the job will be to work on the Java and XML code to make it match the grammar. I put a couple of proposals in the page to help get things started. Let me know what you think. -Adrian On 3/6/2012 9:42 AM, Adrian Crum wrote: set field=field4 from=parameters.inputField1 + 10/ !-- use Minilang built-in and efficient support: not currently supported but maybe something to consider in the future -- The from attribute contains a UEL expression, so it is currently supported. -Adrian On 3/6/2012 9:33 AM, Jacopo Cappellato wrote: On Mar 6, 2012, at 10:03 AM, Adrian Crum wrote: Replacing FSE with Groovy is a bad idea. Adam and I optimized FSE so that it is very lightweight and fast. I also optimized the UEL integration so there is very little overhead in the evaluation process. Switching everything to Groovy will slow things down and increase memory usage. Also keep in mind that Groovy creates a class for every script, so we will run out of permgen space again. Ok, makes perfect sense, thank you. I think a wiser strategy would be to make mini-lang as feature complete as possible, and include a from-script attribute for any feature gaps. In other words, use from-script as a last resort - because it is costly. +1: by the way we could still use the from attribute for both: set field=field4 from=parameters.inputField1/ !-- use Minilang built-in and efficient support -- set field=field4 from=parameters.inputField1 + 10/ !-- use Minilang built-in and efficient support: not currently supported but maybe something to consider in the future -- set field=field4 from=groovy: parameters.inputField1 + 10/ !-- use Groovy (inefficient) -- Jacopo -Adrian On 3/6/2012 8:53 AM, Jacopo Cappellato wrote: On Mar 6, 2012, at 9:32 AM, Adrian Crum wrote: I don't understand what you mean by supporting a limited number of types. Currently, mini-lang supports any type - thanks to the conversion framework. The conversion framework is fine; I was thinking that we could implicitly (by default) treat in Minilang all the numbers as BigDecimals, all the strings as GStrings/Expandable Strings; where special
[jira] [Closed] (OFBIZ-2628) No Url encoding for get parameters
[ https://issues.apache.org/jira/browse/OFBIZ-2628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sascha Rodekamp closed OFBIZ-2628. -- Resolution: Fixed fixed the redirect bug. The encoding in the RequestHandler was obsolete and causes this error. The new patch is committed in Trunk @Rev1298454 11.04 @Rev1298455 10.04 @Rev1298456 No Url encoding for get parameters -- Key: OFBIZ-2628 URL: https://issues.apache.org/jira/browse/OFBIZ-2628 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 4.0, Release Branch 09.04, SVN trunk Environment: All Reporter: Patrick Antivackis Assignee: Sascha Rodekamp Priority: Critical Fix For: Release Branch 10.04, Release Branch 11.04, SVN trunk Attachments: OFBIZ-2628-Add-URL-encoding-to-RequestHandler.patch, OFBIZ-2628-Add-URL-encoding-to-RequestHandler.patch Original Estimate: 4h Remaining Estimate: 4h Let's say I want to create a new category which ID is DVD+R Creation is ok through the admin interface, but whenever i want to access this category, the get parameter productCategoryId= of the url is wrong as it's not url encoded, so we have : https://localhost:8443/catalog/control/EditCategory?productCategoryId=DVD#43;R instead of https://localhost:8443/catalog/control/EditCategory?productCategoryId=DVD%2BR Both @ofbizUrl tag and menu widgets are not encoding get parameters. Way to correct : framework/webapp/src/org/ofbiz/webapp/control/RequestHandler.java modify the makeLink function framework/widget/src/org/ofbiz/widget/WidgetWorker.java : function buildhyperlinkUrl need to use defaultWebEncoder.encodeForURL instead of simpleEncoder Beofre i do the fix, can a core developper let me know about possible side effects -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4726) 9.04.02 and 10.04 releases are broken and don't install at all
9.04.02 and 10.04 releases are broken and don't install at all -- Key: OFBIZ-4726 URL: https://issues.apache.org/jira/browse/OFBIZ-4726 Project: OFBiz Issue Type: Bug Affects Versions: Release 10.04, Release 09.04.01 Environment: linux Ubuntu 12.04, amd64, openjdk6, openjdk7 Reporter: Mark ./ant run-install gives the following build/compilation error: classes: [javac15] Compiling 4 source files to /home/stier/tmp/apache-ofbiz-09.04.02/framework/security/build/classes [javac15] warning: [options] bootstrap class path not set in conjunction with -source 1.5 [javac15] /home/stier/tmp/apache-ofbiz-09.04.02/framework/security/src/org/ofbiz/security/OFBizSecurity.java:50: error: invalid inferred types for V; inferred type does not conform to declared bound(s) [javac15] public static final MapString, MapString, String simpleRoleEntity = UtilMisc.toMap( [javac15] ^ [javac15] inferred: MapString,Object [javac15] bound(s): MapString,String [javac15] where V,V1,V2,V3 are type-variables: [javac15] V extends Object declared in method V,V1,V2,V3toMap(String,V1,String,V2,String,V3) [javac15] V1 extends V declared in method V,V1,V2,V3toMap(String,V1,String,V2,String,V3) [javac15] V2 extends V declared in method V,V1,V2,V3toMap(String,V1,String,V2,String,V3) [javac15] V3 extends V declared in method V,V1,V2,V3toMap(String,V1,String,V2,String,V3) [javac15] 1 error [javac15] 1 warning -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Groovy services and a DSL for OFBiz - a POC
Hi all, I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang. Please review my notes here: https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-) Regards, Jacopo PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
Re: Discussion: Mini-language Overhaul
This is a good list. Thanks Jacopo! There are some issues with your suggestions - comments inline... -Adrian On 3/8/2012 3:18 PM, Jacopo Cappellato wrote: A) I would like to see removed all the attributes map-name and just leave the field attribute; for example: clear-field field=foo map-name=parameters/ can be: clear-field field=parameters.foo/ B) instead of: fail-property resource=ErrorMessages property=FooError / we could have fail-property property=ErrorMessages.FooError / Keep in mind that UEL would interpret FooError as an element of a Map called ErrorMessages. What you suggested can be done, but it will require more modifications to the UEL integration - something I try to avoid because it causes more problems than it solves. I recommend we keep the resource attribute. C) instead of: request-to-field session-to-field we could have: set field=foo from=parameters.request.inputFoo/ set field=foo from=parameters.session.inputFoo/ That can be done, but with a slight difference: set field=foo from=request.parameters.inputFoo/ set field=foo from=session.parameters.inputFoo/ D) similarly deprecate (replaced by set): field-to-env field-to-field field-to-list field-to-request field-to-session property-to-field now-timestamp-to-env We can eliminate now-timestamp-to-env if we just put a nowTimestamp field in the method context - like we do now with screen widgets. now-date-to-env map-to-map list-to-list string-to-field string-to-list to-string webapp-property-to-field set-current-user-login I agree all of those can be deprecated. I don't have more time today but there may be others :-) Jacopo On Mar 8, 2012, at 3:16 PM, Nicolas Malin wrote: Ok thanks adrian Nicolas Le 08/03/2012 14:46, adrian.c...@sandglass-software.com a écrit : Voting on each item will not work because there are too many. We can discuss things here and when there seems to be general agreement, I will ask for a vote on the entire grammar. When that vote passes, I will include the proposals in the grammar (move them out of the blue boxes and into the normal text), and change the status from draft to final. -Adrian Quoting Nicolas Malinmalin.nico...@librenberry.net: Thanks adrian for this works, I will add my propositions. After all proposition will include on wiki, how to you proceed to approve each ? A vote on mailing list for each ? Nicolas Le 07/03/2012 19:18, Adrian Crum a écrit : I created a Wiki page to help get things started: https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference I put just enough information in it to work on the layout. I will continue working on it when I have time. Everyone with write access is welcome to work on it also. The information is based on the mini-language Java code - which is the ultimate authority. The schemas are inaccurate - they should be used only for looking up schema-supplied default values. The goal is to document the current mini-language grammar, and add proposed changes. If a proposal is approved, then it can get a green check mark. If a proposal is vetoed, then it can get a red X. When everyone agrees on the grammar, the document will be updated, and it will move out of the draft stage. Then the job will be to work on the Java and XML code to make it match the grammar. I put a couple of proposals in the page to help get things started. Let me know what you think. -Adrian On 3/6/2012 9:42 AM, Adrian Crum wrote: set field=field4 from=parameters.inputField1 + 10/ !-- use Minilang built-in and efficient support: not currently supported but maybe something to consider in the future -- The from attribute contains a UEL expression, so it is currently supported. -Adrian On 3/6/2012 9:33 AM, Jacopo Cappellato wrote: On Mar 6, 2012, at 10:03 AM, Adrian Crum wrote: Replacing FSE with Groovy is a bad idea. Adam and I optimized FSE so that it is very lightweight and fast. I also optimized the UEL integration so there is very little overhead in the evaluation process. Switching everything to Groovy will slow things down and increase memory usage. Also keep in mind that Groovy creates a class for every script, so we will run out of permgen space again. Ok, makes perfect sense, thank you. I think a wiser strategy would be to make mini-lang as feature complete as possible, and include a from-script attribute for any feature gaps. In other words, use from-script as a last resort - because it is costly. +1: by the way we could still use the from attribute for both: set field=field4 from=parameters.inputField1/ !-- use Minilang built-in and efficient support -- set field=field4 from=parameters.inputField1 + 10/ !-- use Minilang built-in and efficient support: not currently supported but maybe something to consider in the future -- set field=field4 from=groovy: parameters.inputField1 + 10/ !-- use Groovy (inefficient) -- Jacopo -Adrian On 3/6/2012 8:53 AM, Jacopo Cappellato wrote:
Re: Discussion: Mini-language Overhaul
On Mar 8, 2012, at 7:03 PM, Adrian Crum wrote: B) instead of: fail-property resource=ErrorMessages property=FooError / we could have fail-property property=ErrorMessages.FooError / Keep in mind that UEL would interpret FooError as an element of a Map called ErrorMessages. What you suggested can be done, but it will require more modifications to the UEL integration - something I try to avoid because it causes more problems than it solves. I recommend we keep the resource attribute. Np then, I was not even sure it was a good idea and if requires customizations to uel then I agree it is not worth the effort. Thank you, Jacopo
Re: Discussion: Mini-language Overhaul
Some more food for thought... Looking through the Java code, I can see that there is no runtime validation being performed. Granted, a decent XML editor will warn you about required attributes and elements and such, but not everyone uses that type of XML editor. Worse yet, there is no way to know you've done something wrong - because mini-lang hides the errors in verbose log statements. So, I would like to add runtime validation. If the script is coded improperly, then it should throw an exception. Another change I would like to make is to remove default attribute values in the schema. From my perspective, defaults should be in the mini-language code. The wiki page has demonstrated to me how difficult it is to understand what's going on when you have to look through Java code, and then also look through the schema to see what values it is supplying. Plus, it makes me wonder how mini-language will behave when the server doesn't have access to the schema. Which brings up another point: Once the grammar has been cleaned up, we will need a new schema. I think we need to start giving our schemas version numbers so that XML editors and runtime XML validation will work properly. -Adrian On 3/8/2012 6:19 PM, Jacopo Cappellato wrote: On Mar 8, 2012, at 7:03 PM, Adrian Crum wrote: B) instead of: fail-property resource=ErrorMessages property=FooError / we could have fail-property property=ErrorMessages.FooError / Keep in mind that UEL would interpret FooError as an element of a Map called ErrorMessages. What you suggested can be done, but it will require more modifications to the UEL integration - something I try to avoid because it causes more problems than it solves. I recommend we keep the resource attribute. Np then, I was not even sure it was a good idea and if requires customizations to uel then I agree it is not worth the effort. Thank you, Jacopo
Re: Groovy services and a DSL for OFBiz - a POC
Hi Jacopo, a nice step in the right direction, IMHO. I like it. Do you think it's possible to hack up a transpiler from Minilang to JacopoLang(tm), (i.e. like Coffescript has for Javascript), so that we can get rid of minilang entirely? Greetings, - Karl On 08.03.2012, at 19:02, Jacopo Cappellato wrote: Hi all, I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang. Please review my notes here: https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-) Regards, Jacopo PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
Re: Discussion: Mini-language Overhaul
From: Adrian Crum adrian.c...@sandglass-software.com Some more food for thought... Looking through the Java code, I can see that there is no runtime validation being performed. Granted, a decent XML editor will warn you about required attributes and elements and such, but not everyone uses that type of XML editor. Worse yet, there is no way to know you've done something wrong - because mini-lang hides the errors in verbose log statements. So, I would like to add runtime validation. If the script is coded improperly, then it should throw an exception. +1 No time for the rest for now, Jacopo's proposition sounds good to me Jacques Another change I would like to make is to remove default attribute values in the schema. From my perspective, defaults should be in the mini-language code. The wiki page has demonstrated to me how difficult it is to understand what's going on when you have to look through Java code, and then also look through the schema to see what values it is supplying. Plus, it makes me wonder how mini-language will behave when the server doesn't have access to the schema. Which brings up another point: Once the grammar has been cleaned up, we will need a new schema. I think we need to start giving our schemas version numbers so that XML editors and runtime XML validation will work properly. -Adrian On 3/8/2012 6:19 PM, Jacopo Cappellato wrote: On Mar 8, 2012, at 7:03 PM, Adrian Crum wrote: B) instead of: fail-property resource=ErrorMessages property=FooError / we could have fail-property property=ErrorMessages.FooError / Keep in mind that UEL would interpret FooError as an element of a Map called ErrorMessages. What you suggested can be done, but it will require more modifications to the UEL integration - something I try to avoid because it causes more problems than it solves. I recommend we keep the resource attribute. Np then, I was not even sure it was a good idea and if requires customizations to uel then I agree it is not worth the effort. Thank you, Jacopo
Re: Groovy services and a DSL for OFBiz - a POC
Le 08/03/2012 20:04, Karl Pitrich a écrit : Hi Jacopo, a nice step in the right direction, IMHO. I like it. Do you think it's possible to hack up a transpiler from Minilang to JacopoLang(tm), (i.e. like Coffescript has for Javascript), so that we can get rid of minilang entirely? Hi Karl, minilang won't be removed from OFBiz. It is widely used, and very useful. Look at the other thread Adrian started, there is a will to improve it ! Cheers, Greetings, - Karl On 08.03.2012, at 19:02, Jacopo Cappellato wrote: Hi all, I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang. Please review my notes here: https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-) Regards, Jacopo PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence -- Erwan de FERRIERES www.nereide.biz
Re: Groovy services and a DSL for OFBiz - a POC
Hi Jacopo, Interesting, but then (question to all, and espaically Adrian who began on minilang overhaul ) should we continue the minilang overhaul or rather gather all efforts to completly, step by step, move all minilang scripts to this new possiblity? Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com Hi all, I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang. Please review my notes here: https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-) Regards, Jacopo PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
Re: Groovy services and a DSL for OFBiz - a POC
I like the general concept, but I think it can be made generic so it is reusable in other languages. That is what I was trying to describe earlier. I looked at GroovyBaseScript and I don't see any reason why it needs to be made Groovy-specific. Have the class access bindings from JSR-223 and Tah-dah! It works for all scripting languages. -Adrian On 3/8/2012 6:02 PM, Jacopo Cappellato wrote: Hi all, I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang. Please review my notes here: https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-) Regards, Jacopo PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
Re: Groovy services and a DSL for OFBiz - a POC
Thanks Jacques. I actually don't know the answer but I will be surprised if everyone will agree to switch from Minilang to Groovy (at least not in the short term); by the way I still see a value in the effort of cleaning and making Minilang more consistent (maybe I would not spend much of my time on the effort, because at the moment I see a greater potential in Groovy, but I understand that it makes sense to invest time in that great language); even if at some point in the future we will decide to migrate out of Minilang, having a cleaner set of scripts will greatly help the migration. Jacopo On Mar 8, 2012, at 8:29 PM, Jacques Le Roux wrote: Hi Jacopo, Interesting, but then (question to all, and espaically Adrian who began on minilang overhaul ) should we continue the minilang overhaul or rather gather all efforts to completly, step by step, move all minilang scripts to this new possiblity? Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com Hi all, I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang. Please review my notes here: https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-) Regards, Jacopo PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
Re: Groovy services and a DSL for OFBiz - a POC
On Mar 8, 2012, at 8:30 PM, Adrian Crum wrote: I like the general concept, but I think it can be made generic so it is reusable in other languages. That is what I was trying to describe earlier. I looked at GroovyBaseScript and I don't see any reason why it needs to be made Groovy-specific. Have the class access bindings from JSR-223 and Tah-dah! It works for all scripting languages. Thank you Adrian. In this first step I was actually focused on the definition (and their design as DSL) of all the implicit rules that make Minilang such a productive tool, and I have used Groovy because it helps to implement this kind of patterns. But if we can enhance and reuse the same class for all the JSR-223 compliant scripting languages that would be nice. Jacopo -Adrian On 3/8/2012 6:02 PM, Jacopo Cappellato wrote: Hi all, I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang. Please review my notes here: https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-) Regards, Jacopo PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence
[jira] [Commented] (OFBIZ-4725) Currently the system ecommerce is B2C add functions to enable B2B
[ https://issues.apache.org/jira/browse/OFBIZ-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225708#comment-13225708 ] Anne Jessel commented on OFBIZ-4725: I don't think points 4 through 8 are right. One person in a company shouldn't be able to see everything ever ordered by anyone else in the company. An employee working in the Australian branch shouldn't be able to see what the French branch have been ordering. I think the order/quote/request related functions should only display the items relevant to the employee. The company details should be used for shipping and invoicing contacts, but not for display of historical items. Does that make sense? Currently the system ecommerce is B2C add functions to enable B2B - Key: OFBIZ-4725 URL: https://issues.apache.org/jira/browse/OFBIZ-4725 Project: OFBiz Issue Type: Improvement Components: order, specialpurpose/ecommerce Affects Versions: SVN trunk Reporter: Hans Bakker Currently the ecommerce and order component is facilitating B2C (business to consumer) We suggest to add functions to allow also B2B Business to Business where a contact person uses the ecommerce on behalf of the company he works for, i.e. not entering quotes/orders for himself but entering orders for the company he works for. This relationship is already establsihed on the party component in the profile contact/related-account box. These are functions which need change: 1. Registration : add the related company field and create a relationship between person and company. 2. Profile page: display an information of the related company: already shown 3. Checkout: if person who login has the related company, an order what person created will be an order of the related company. 4. Order History: adjust to be an order list for the related company. 5. Request entry : adjust to be the request list for the related company. 6. Quote entry: adjust to be the quote list for the related company. 7. Message : adjust to be the message list for the related company. 8. Shopping Lists : adjust to be the shopping list for the related company and adjust create a shopping list for the related company. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Groovy services and a DSL for OFBiz - a POC
Hi Jacopo That is an excellent start! I used to prefer minilang to java because it was so easy to do common tasks, but 2 things about it were so annoying that I now only use it for the simplest tasks. But with java I have to put up with all that extra code to get simple things done. Your groovy approach takes the best of minilang and the best of java, and combines them. My only concern with it is speed, but I suppose we could use ant to compile the groovy if there is a problem? A couple of thoughts (probably you have already thought of these): Change runService to runServiceSync, so there can also be a runServiceAsync. The design effort on this could combine with the current design effort on improving minilang. Adrian's new wiki page ( https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference) could be used to guide what functionality the new groovy DSL needs. So there could (almost) be a one-to-one mapping between a minilang tag and a DSL function. Do you intend for the DSL to work with events, as well as services? Cheers, Anne. On 9 March 2012 05:02, Jacopo Cappellato jacopo.cappell...@hotwaxmedia.comwrote: Hi all, I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang. Please review my notes here: https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-) Regards, Jacopo PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
[jira] [Commented] (OFBIZ-4725) Currently the system ecommerce is B2C add functions to enable B2B
[ https://issues.apache.org/jira/browse/OFBIZ-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225835#comment-13225835 ] Jacopo Cappellato commented on OFBIZ-4725: -- In most common B2B scenarios the point #1 will have to consider at least few different use cases: * the company running OFBiz doesn't allow customer companies (and their employees) to self register; the party for the customer company is manually created by backend users and then parties and userlogins for employees accounts are also created and sent to the users * the company running OFBiz allows customer companies to self register; the user that registers the company will also get a user account (as primary contact); if additional employees are needed the primary contact will have some kind of dashboard from where she could invite other users * allow users to self register as employees of an existing company; an admin will have to validate/activate their registration (after making sure that she is actually an employee of the company) In general the system should never allow the user to self register and pretend to be an employee of company ABC to avoid security risks: I could register and see/place orders of that company. I also agree with Anne that very few companies will be happy to show all the order information to all their employees; especially if the employee is a sales rep, she should only see the orders placed by her (in the most simplistic scenario) and/or the orders placed by sales rep under her (if a sales hierarchy is in place); and administrator will have to see the orders for the whole company (or division if he is only associated to a sub-division). Currently the system ecommerce is B2C add functions to enable B2B - Key: OFBIZ-4725 URL: https://issues.apache.org/jira/browse/OFBIZ-4725 Project: OFBiz Issue Type: Improvement Components: order, specialpurpose/ecommerce Affects Versions: SVN trunk Reporter: Hans Bakker Currently the ecommerce and order component is facilitating B2C (business to consumer) We suggest to add functions to allow also B2B Business to Business where a contact person uses the ecommerce on behalf of the company he works for, i.e. not entering quotes/orders for himself but entering orders for the company he works for. This relationship is already establsihed on the party component in the profile contact/related-account box. These are functions which need change: 1. Registration : add the related company field and create a relationship between person and company. 2. Profile page: display an information of the related company: already shown 3. Checkout: if person who login has the related company, an order what person created will be an order of the related company. 4. Order History: adjust to be an order list for the related company. 5. Request entry : adjust to be the request list for the related company. 6. Quote entry: adjust to be the quote list for the related company. 7. Message : adjust to be the message list for the related company. 8. Shopping Lists : adjust to be the shopping list for the related company and adjust create a shopping list for the related company. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Groovy services and a DSL for OFBiz - a POC
Thank you Anne,
please see my comments inline:
On Mar 9, 2012, at 1:55 AM, Anne wrote:
Hi Jacopo
That is an excellent start! I used to prefer minilang to java because it
was so easy to do common tasks, but 2 things about it were so annoying that
I now only use it for the simplest tasks. But with java I have to put up
with all that extra code to get simple things done.
Your groovy approach takes the best of minilang and the best of java, and
combines them. My only concern with it is speed, but I suppose we could use
ant to compile the groovy if there is a problem?
It would be really nice to run some serious test on performance and compare the
two tools.
Currently the bytecode generated parsing Groovy is cached by OFBiz; but speed
is one aspect and we should also consider the usage of memory.
A couple of thoughts (probably you have already thought of these):
Change runService to runServiceSync, so there can also be a runServiceAsync.
Yes, this is a nice to have; I would prefer a slightly different naming like:
runService: sync calls
scheduleService or submitService or runServiceAsync: async calls
In this way we still have a very easy name, runService, for the most common
usage (calling services synchronously)
The design effort on this could combine with the current design effort on
improving minilang. Adrian's new wiki page (
https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference)
could be used to guide what functionality the new groovy DSL needs. So
there could (almost) be a one-to-one mapping between a minilang tag and a
DSL function.
That page (and effort) will be really useful to help this DSL grow in the right
direction; but in general Minilang, and most of all the huge amount of Minilang
code we have in OFBiz (some good, some bad) is really useful to decide what we
need in a Groovy DSL: in fact all the ideas I have tried to implement in this
poc are based on a careful review of Minilang (and my experience of Minilang
development).
I like the idea of preparing a page that shows the best practices for
implementing Minilang-equivalent code in Groovy: however, rather that
implementing a one-to-one method mapping between Minilang and this DSL I would
prefer to stay focused on the most common tasks only: all the other operations
can still be used using the standard support provided by delegator, dispatcher
etc... objects, or the various utils classes we have in OFBiz.
A natural and good way to decide what we should provide as a DSL and what
(probably) not is how frequent the feature is currently used in our Minilang
code (but of course feedback from developers using it would help greatly).
For example:
the call-service operation in Minilang can take an optional attribute
require-new-transaction: if it is set to true the service will be executed in
a separate transaction.
the equivalent Groovy (DSL for OFBiz) is runService and doesn't support this
option (it runs the service in the same transaction); even if it would be
trivial to enhance the DSL to support also a runService method that takes an
additional argument (or use a different name), after reviewing the existing
code I realized that we won't probably need this feature: in all the OFBiz
applications the require-new-transaction attribute is set to true for only
2 service calls; and for this rare occasions you can achieve the same in Groovy
using the dispatcher:
result1 = runService('someService', inputMap); // run the service in the
current transaction
result2 = dispatcher.runSync('someService', inputMap, 36000, true); // run in a
new transaction
if (ServiceUtil.isError(result)) return
error(ServiceUtil.getErrorMessage(result));
Of course we will have the flexibility to expand at will our DSL.
Another nice feature is that it is possible to extend the DSL base class and
add additional custom methods: everyone could customize the DSL and possibly
implement an industry specific (or company specific or project specific) DSL
very easily (something currently rather difficult in Minilang).
Do you intend for the DSL to work with events, as well as services?
Thanks for asking: yes my next task in my todo list is to enable it for events
and data preparation scripts.
Cheers,
Jacopo
Cheers,
Anne.
On 9 March 2012 05:02, Jacopo Cappellato
jacopo.cappell...@hotwaxmedia.comwrote:
Hi all,
I have just completed my first pass in the implementation of a DSL (Domain
Specific Language) for OFBiz that can be used by Groovy services to act
like a modern version of Minilang.
Please review my notes here:
https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz
I look forward to your comments and feedback but please consider that 1)
it is a work in progress, 2) I spent a lot of time and mental energy in the
effort (reaching simplicity is really complex task!)... so please don't be
too picky :-)
Regards,
Jacopo
PS:
[jira] [Closed] (OFBIZ-4726) 9.04.02 and 10.04 releases are broken and don't install at all
[ https://issues.apache.org/jira/browse/OFBIZ-4726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-4726. -- Resolution: Duplicate Fix Version/s: Release Branch 10.04 Release Branch 09.04 Assignee: Jacques Le Roux Sorry, but AFAIK all OFBiz versions requires -Sun- Oracle JDK. I close as duplicate of OFBIZ-3993 and OFBIZ-4638 9.04.02 and 10.04 releases are broken and don't install at all -- Key: OFBIZ-4726 URL: https://issues.apache.org/jira/browse/OFBIZ-4726 Project: OFBiz Issue Type: Bug Affects Versions: Release 09.04.01, Release 10.04 Environment: linux Ubuntu 12.04, amd64, openjdk6, openjdk7 Reporter: Mark Assignee: Jacques Le Roux Fix For: Release Branch 09.04, Release Branch 10.04 ./ant run-install gives the following build/compilation error: classes: [javac15] Compiling 4 source files to /home/stier/tmp/apache-ofbiz-09.04.02/framework/security/build/classes [javac15] warning: [options] bootstrap class path not set in conjunction with -source 1.5 [javac15] /home/stier/tmp/apache-ofbiz-09.04.02/framework/security/src/org/ofbiz/security/OFBizSecurity.java:50: error: invalid inferred types for V; inferred type does not conform to declared bound(s) [javac15] public static final MapString, MapString, String simpleRoleEntity = UtilMisc.toMap( [javac15] ^ [javac15] inferred: MapString,Object [javac15] bound(s): MapString,String [javac15] where V,V1,V2,V3 are type-variables: [javac15] V extends Object declared in method V,V1,V2,V3toMap(String,V1,String,V2,String,V3) [javac15] V1 extends V declared in method V,V1,V2,V3toMap(String,V1,String,V2,String,V3) [javac15] V2 extends V declared in method V,V1,V2,V3toMap(String,V1,String,V2,String,V3) [javac15] V3 extends V declared in method V,V1,V2,V3toMap(String,V1,String,V2,String,V3) [javac15] 1 error [javac15] 1 warning -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4726) 9.04.02 and 10.04 releases are broken and don't install at all
[ https://issues.apache.org/jira/browse/OFBIZ-4726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225901#comment-13225901 ] Jacques Le Roux commented on OFBIZ-4726: Also I close, because we will never try to run any OFBiz version, but the trunk, into an openjdk version, if ever we do it. You could help on mentionned Jiras... 9.04.02 and 10.04 releases are broken and don't install at all -- Key: OFBIZ-4726 URL: https://issues.apache.org/jira/browse/OFBIZ-4726 Project: OFBiz Issue Type: Bug Affects Versions: Release 09.04.01, Release 10.04 Environment: linux Ubuntu 12.04, amd64, openjdk6, openjdk7 Reporter: Mark Assignee: Jacques Le Roux Fix For: Release Branch 09.04, Release Branch 10.04 ./ant run-install gives the following build/compilation error: classes: [javac15] Compiling 4 source files to /home/stier/tmp/apache-ofbiz-09.04.02/framework/security/build/classes [javac15] warning: [options] bootstrap class path not set in conjunction with -source 1.5 [javac15] /home/stier/tmp/apache-ofbiz-09.04.02/framework/security/src/org/ofbiz/security/OFBizSecurity.java:50: error: invalid inferred types for V; inferred type does not conform to declared bound(s) [javac15] public static final MapString, MapString, String simpleRoleEntity = UtilMisc.toMap( [javac15] ^ [javac15] inferred: MapString,Object [javac15] bound(s): MapString,String [javac15] where V,V1,V2,V3 are type-variables: [javac15] V extends Object declared in method V,V1,V2,V3toMap(String,V1,String,V2,String,V3) [javac15] V1 extends V declared in method V,V1,V2,V3toMap(String,V1,String,V2,String,V3) [javac15] V2 extends V declared in method V,V1,V2,V3toMap(String,V1,String,V2,String,V3) [javac15] V3 extends V declared in method V,V1,V2,V3toMap(String,V1,String,V2,String,V3) [javac15] 1 error [javac15] 1 warning -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Groovy services and a DSL for OFBiz - a POC
Hi Jacopo,
great job! Groovy as DSL is very handsome (cause i can use a debugger :-)).
In the longterm future i would support Adrians approach to create an
abstract implementation of the DSL.
Some words to the groovy speed. In (theoretically) benchmarks groovy
is slower than java. Interesting would be a comparison between
mini-lang and groovy. I think the Groovy performance will be
absolutely sufficient because of the easy integration with Java. If
something’s too slow, I do it in Java. More important using the DSL is
the maintainability, developer productivity and the tool support.
Have a good day
Sascha
2012/3/9 Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com:
Thank you Anne,
please see my comments inline:
On Mar 9, 2012, at 1:55 AM, Anne wrote:
Hi Jacopo
That is an excellent start! I used to prefer minilang to java because it
was so easy to do common tasks, but 2 things about it were so annoying that
I now only use it for the simplest tasks. But with java I have to put up
with all that extra code to get simple things done.
Your groovy approach takes the best of minilang and the best of java, and
combines them. My only concern with it is speed, but I suppose we could use
ant to compile the groovy if there is a problem?
It would be really nice to run some serious test on performance and compare
the two tools.
Currently the bytecode generated parsing Groovy is cached by OFBiz; but speed
is one aspect and we should also consider the usage of memory.
A couple of thoughts (probably you have already thought of these):
Change runService to runServiceSync, so there can also be a runServiceAsync.
Yes, this is a nice to have; I would prefer a slightly different naming like:
runService: sync calls
scheduleService or submitService or runServiceAsync: async calls
In this way we still have a very easy name, runService, for the most common
usage (calling services synchronously)
The design effort on this could combine with the current design effort on
improving minilang. Adrian's new wiki page (
https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference)
could be used to guide what functionality the new groovy DSL needs. So
there could (almost) be a one-to-one mapping between a minilang tag and a
DSL function.
That page (and effort) will be really useful to help this DSL grow in the
right direction; but in general Minilang, and most of all the huge amount of
Minilang code we have in OFBiz (some good, some bad) is really useful to
decide what we need in a Groovy DSL: in fact all the ideas I have tried to
implement in this poc are based on a careful review of Minilang (and my
experience of Minilang development).
I like the idea of preparing a page that shows the best practices for
implementing Minilang-equivalent code in Groovy: however, rather that
implementing a one-to-one method mapping between Minilang and this DSL I
would prefer to stay focused on the most common tasks only: all the other
operations can still be used using the standard support provided by
delegator, dispatcher etc... objects, or the various utils classes we have in
OFBiz.
A natural and good way to decide what we should provide as a DSL and what
(probably) not is how frequent the feature is currently used in our Minilang
code (but of course feedback from developers using it would help greatly).
For example:
the call-service operation in Minilang can take an optional attribute
require-new-transaction: if it is set to true the service will be executed
in a separate transaction.
the equivalent Groovy (DSL for OFBiz) is runService and doesn't support
this option (it runs the service in the same transaction); even if it would
be trivial to enhance the DSL to support also a runService method that takes
an additional argument (or use a different name), after reviewing the
existing code I realized that we won't probably need this feature: in all the
OFBiz applications the require-new-transaction attribute is set to true
for only 2 service calls; and for this rare occasions you can achieve the
same in Groovy using the dispatcher:
result1 = runService('someService', inputMap); // run the service in the
current transaction
result2 = dispatcher.runSync('someService', inputMap, 36000, true); // run in
a new transaction
if (ServiceUtil.isError(result)) return
error(ServiceUtil.getErrorMessage(result));
Of course we will have the flexibility to expand at will our DSL.
Another nice feature is that it is possible to extend the DSL base class and
add additional custom methods: everyone could customize the DSL and possibly
implement an industry specific (or company specific or project specific) DSL
very easily (something currently rather difficult in Minilang).
Do you intend for the DSL to work with events, as well as services?
Thanks for asking: yes my next task in my todo list is to enable it for
events and data
