Re: Implementing JSR-223
On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote:
It seems to me if there is a security issue using Groovy, then there would be
an issue using any scripting language.
Yes, but what we would bundle ootb would be a secured packaged ready to run
Groovy scripts in a secure way and already packaged with hundreds of scripts.
If the user will add a new jar to support a different script (and the user will
also have to implement the custom scripts) then this will be less secure but
there isn't much we could do as we delegate to JSR-223 the implementation of
security.
Why can't we put the friendly methods in the context, so all scripting
languages can use them?
I am not sure I understand what you are proposing (the method would be language
specific) but for now we can postpone this discussion at when (if it will ever
happen) we will discuss about this approach.
Jacopo
-Adrian
On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
The code changes tested fine.
I noticed in your code comments that Groovy should be handled independently
from other scripting languages. Why do you think that?
First of all, I apologize for having added my personal opinion to those
comments :-) but I thought that in this way it was easier to exchange design
ideas; the comments can actually be removed.
The reasons I think we could treat Groovy in a special way (but I don't have
a strong opinion on this) are:
* ootb OFBiz will still be packaged with Groovy jars (they are required by
all the existing scripts and by some other code like the implementation of
Groovy service engine and Groovy event handler) and so the dependency on
Groovy will still be there even if we run it with JSR-223
* the code to run Groovy in the special way is now all contained in the
ScriptUtil class and there are actually a few lines of code to maintain for
it
* keeping a custom way for Groovy has two main advantages that are not
currently used but I would like to consider in the short term (and I don't
think they are supported thru JSR-223... but I am not sure):
** security: I would like to restrict the JVM security settings for dynamic
Groovy snippets like ${groovy: ...}; I have some concerns in this area that
I will address in a separate email soon; in this way we will secure the
ootb system (packaged with several groovy scripts and the groovy jars) but
of course if the user will add to it jars files for a new scripting language
(executed using JSR-223) then the security issue will still be there, but at
least the user will know about it
** I would like to inject some OFBiz friendly methods to all Groovy scripts,
so that they can be used by Groovy scripts to run services, use the
delegator etc...
We should also consider the impact on performance, even if the best way to
go is probably to run some performance tests on the system running Groovy
with current code and with the system running Groovy using a custom method
and then compare the results.
Jacopo
-Adrian
On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
My changes are in commit 1296762
Help with reviews and tests will be very much appreciated.
Jacopo
On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
As far as I know, most scripting engines have some sort of embedded
cache. The problem will be that we can't clear the embedded cache like
we can with our own cache implementation. I don't see that as a show
stopper - it's mostly inconvenient.
I can help out with the conversion. I don't think the task will be that
hard.
Adrian, FYI I am enhancing some of the existing framework code that uses
the GroovyUtil class to simplify this task.
I will commit my code changes today.
Regards,
Jacopo
Re: Implementing JSR-223
On Mar 5, 2012, at 8:57 AM, Adrian Crum wrote:
Btw, expressions should go in the from-field attribute, not the value
attribute.
Well, the mechanism value=${groovy: ...} is actually used a lot currently;
and in the from-field attribute the ${groovy: is not required.
Jacopo
Re: Implementing JSR-223
If you don't mind, I would like to get all of the issues resolved during
the design phase.
I will wait for the private email to understand what you mean by a
secure scripting package.
What I was suggesting is a script utility object that can be put in the
context so that all scripting languages can use it. Whatever methods you
have in mind could be implemented in a generic way and reused.
Personally, I would like to use something like:
// Groovy, JavaScript
partyValue = script.entityOne(Party);
if (partyValue)...
In other words, have an object in the context that gives us the
convenience of mini-language.
-Adrian
On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote:
It seems to me if there is a security issue using Groovy, then there would be
an issue using any scripting language.
Yes, but what we would bundle ootb would be a secured packaged ready to run Groovy
scripts in a secure way and already packaged with hundreds of scripts.
If the user will add a new jar to support a different script (and the user will
also have to implement the custom scripts) then this will be less secure but
there isn't much we could do as we delegate to JSR-223 the implementation of
security.
Why can't we put the friendly methods in the context, so all scripting
languages can use them?
I am not sure I understand what you are proposing (the method would be language
specific) but for now we can postpone this discussion at when (if it will ever
happen) we will discuss about this approach.
Jacopo
-Adrian
On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
The code changes tested fine.
I noticed in your code comments that Groovy should be handled independently
from other scripting languages. Why do you think that?
First of all, I apologize for having added my personal opinion to those
comments :-) but I thought that in this way it was easier to exchange design
ideas; the comments can actually be removed.
The reasons I think we could treat Groovy in a special way (but I don't have a
strong opinion on this) are:
* ootb OFBiz will still be packaged with Groovy jars (they are required by all the existing scripts
and by some other code like the implementation of Groovy service engine and
Groovy event handler) and so the dependency on Groovy will still be there even if we
run it with JSR-223
* the code to run Groovy in the special way is now all contained in the
ScriptUtil class and there are actually a few lines of code to maintain for it
* keeping a custom way for Groovy has two main advantages that are not
currently used but I would like to consider in the short term (and I don't
think they are supported thru JSR-223... but I am not sure):
** security: I would like to restrict the JVM security settings for dynamic Groovy
snippets like ${groovy: ...}; I have some concerns in this area that I will address in a
separate email soon; in this way we will secure the ootb system (packaged
with several groovy scripts and the groovy jars) but of course if the user will add to it
jars files for a new scripting language (executed using JSR-223) then the security issue
will still be there, but at least the user will know about it
** I would like to inject some OFBiz friendly methods to all Groovy scripts, so
that they can be used by Groovy scripts to run services, use the delegator
etc...
We should also consider the impact on performance, even if the best way to go
is probably to run some performance tests on the system running Groovy with
current code and with the system running Groovy using a custom method and then
compare the results.
Jacopo
-Adrian
On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
My changes are in commit 1296762
Help with reviews and tests will be very much appreciated.
Jacopo
On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
As far as I know, most scripting engines have some sort of embedded cache. The
problem will be that we can't clear the embedded cache like we can with our own
cache implementation. I don't see that as a show stopper - it's mostly
inconvenient.
I can help out with the conversion. I don't think the task will be that hard.
Adrian, FYI I am enhancing some of the existing framework code that uses the
GroovyUtil class to simplify this task.
I will commit my code changes today.
Regards,
Jacopo
Re: Implementing JSR-223
From: Adrian Crum adrian.c...@sandglass-software.com
Okay, we can give it a try and see if we run into any problems.
Btw, expressions should go in the from-field attribute, not the value attribute.
Why? I'd prefer to stay the same than now. I agree it's a convention, but from-field makes less sense to me for evaluated
expressions (being in a script or inlined)
Jacques
-Adrian
On 3/5/2012 7:53 AM, Jacopo Cappellato wrote:
Yes, this is fine and I was thinking about a similar solution; however I would
like to find a simpler convention because
[script:groovy] is a lot of typing and could be difficult to read when the code in buried in the
value attribute of a set
element.
Something like:
${script:jython code_here}
${script:groovy code_here}
${script: code_here} this could use the default language set in some properties file
(i.e. groovy); this follows the
configuration by exception pattern (specify the script only if you want to
use a non default one).
But we should also consider a shortcut where the script word is abbreviated, for
example by the s word:
${s:jython code_here}
${s:groovy code_here}
${s: code_here}
Jacopo
On Mar 5, 2012, at 8:41 AM, Adrian Crum wrote:
I was thinking we could use something like ${[script:groovy]...}
${[script:jython]...} etc. I'm concerned that looking for a
string followed by a colon can lead to errors.
-Adrian
On 3/5/2012 6:22 AM, Jacopo Cappellato wrote:
I would like to clarify that in this first pass I focused on moving code
around keeping the same exact behavior currently
implemented: now all the code that had a dependency on Groovy or Beanshell
packages has been converted to be only dependent on
ScriptUtil class.
In order to implement JSR-223 we may have to change some of the current
behavior (the different way Beanshell and Groovy are
preparsed/executed) and also check if we can always assume that if the code
inside of ${...} starts with a string (no spaces)
followed by a colon (and a blank character?) then the string is the scripting
language: I didn't check the impact on existing
scripts but it should be easy to write a reg exp to find all of them (I expect
that the number will be small) and modify them
to be compatible with the convention. I intentionally didn't focus on this
second step.
Jacopo
On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
I must says I only cursorily reviewed the code Jacopo committed and did not
look into JSR-223 details.
So I thought at some point you have to check which language wich is used?
Like in
+if (groovy.equals(language)) {
+if (scriptClass == null) {
+scriptClass = ScriptUtil.parseScript(language, script);
+}
+if (scriptClass != null) {
+result = InvokerHelper.createScript(scriptClass,
GroovyUtil.getBinding(inputMap)).run();
+}
+} else if (bsh.equals(language)) {
+result = BshUtil.eval(script, UtilMisc.makeMapWritable(inputMap));
+}
In other words from Jacopo's code here, it seems you have to differentiate how
scritps are parsed?
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
Groovy supports JSR-223, so there is no reason to treat it differently. My
question has nothing to do with which scripting
engine
is supplied with OFBiz.
-Adrian
On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
I don't want to interfer with Jacopo's answer, but I guess it's because Groovy
will be implemented OOTB. The others could be
but
Groovy is already part of the framework (the inital subject from Erwan was to
completely remove BeanShell OOTB usage), I
mean
it's the idea and what Jacopo said already.
I second this idea. Everybody can use her/his preferred scripting language in
custom projects. But using only one language
OOTB
seems to be common sense. We chose groovy...
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
The code changes tested fine.
I noticed in your code comments that Groovy should be handled independently
from other scripting languages. Why do you
think
that?
-Adrian
On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
My changes are in commit 1296762
Help with reviews and tests will be very much appreciated.
Jacopo
On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
As far as I know, most scripting engines have some sort of embedded cache. The
problem will be that we can't clear the
embedded
cache like we can with our own cache implementation. I don't see that as a show
stopper - it's mostly inconvenient.
I can help out with the conversion. I don't think the task will be that hard.
Adrian, FYI I am enhancing some of the existing framework code that uses the
GroovyUtil class to simplify this task.
I will commit my code changes today.
Regards,
Jacopo
Re: Implementing JSR-223
Because the value attribute is supposed to represent a string constant
(that can be converted to another type via the type attribute), and the
from-field attribute is supposed to represent a variable.
My preference is to have a from-expression attribute to make things clearer.
From my perspective, the main reason mini-language has such strange and
quirky behavior is because the syntax has not been clearly expressed or
implemented.
-Adrian
On 3/5/2012 8:51 AM, Jacques Le Roux wrote:
From: Adrian Crum adrian.c...@sandglass-software.com
Okay, we can give it a try and see if we run into any problems.
Btw, expressions should go in the from-field attribute, not the value
attribute.
Why? I'd prefer to stay the same than now. I agree it's a convention,
but from-field makes less sense to me for evaluated expressions (being
in a script or inlined)
Jacques
-Adrian
On 3/5/2012 7:53 AM, Jacopo Cappellato wrote:
Yes, this is fine and I was thinking about a similar solution;
however I would like to find a simpler convention because
[script:groovy] is a lot of typing and could be difficult to read
when the code in buried in the value attribute of a set
element.
Something like:
${script:jython code_here}
${script:groovy code_here}
${script: code_here} this could use the default language set in
some properties file (i.e. groovy); this follows the
configuration by exception pattern (specify the script only if you
want to use a non default one).
But we should also consider a shortcut where the script word is
abbreviated, for example by the s word:
${s:jython code_here}
${s:groovy code_here}
${s: code_here}
Jacopo
On Mar 5, 2012, at 8:41 AM, Adrian Crum wrote:
I was thinking we could use something like ${[script:groovy]...}
${[script:jython]...} etc. I'm concerned that looking for a
string followed by a colon can lead to errors.
-Adrian
On 3/5/2012 6:22 AM, Jacopo Cappellato wrote:
I would like to clarify that in this first pass I focused on
moving code around keeping the same exact behavior currently
implemented: now all the code that had a dependency on Groovy or
Beanshell packages has been converted to be only dependent on
ScriptUtil class.
In order to implement JSR-223 we may have to change some of the
current behavior (the different way Beanshell and Groovy are
preparsed/executed) and also check if we can always assume that if
the code inside of ${...} starts with a string (no spaces)
followed by a colon (and a blank character?) then the string is
the scripting language: I didn't check the impact on existing
scripts but it should be easy to write a reg exp to find all of
them (I expect that the number will be small) and modify them
to be compatible with the convention. I intentionally didn't focus
on this second step.
Jacopo
On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
I must says I only cursorily reviewed the code Jacopo committed
and did not look into JSR-223 details.
So I thought at some point you have to check which language wich
is used?
Like in
+if (groovy.equals(language)) {
+if (scriptClass == null) {
+scriptClass = ScriptUtil.parseScript(language,
script);
+}
+if (scriptClass != null) {
+result = InvokerHelper.createScript(scriptClass,
GroovyUtil.getBinding(inputMap)).run();
+}
+} else if (bsh.equals(language)) {
+result = BshUtil.eval(script,
UtilMisc.makeMapWritable(inputMap));
+}
In other words from Jacopo's code here, it seems you have to
differentiate how scritps are parsed?
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
Groovy supports JSR-223, so there is no reason to treat it
differently. My question has nothing to do with which scripting
engine
is supplied with OFBiz.
-Adrian
On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
I don't want to interfer with Jacopo's answer, but I guess it's
because Groovy will be implemented OOTB. The others could be
but
Groovy is already part of the framework (the inital subject
from Erwan was to completely remove BeanShell OOTB usage), I
mean
it's the idea and what Jacopo said already.
I second this idea. Everybody can use her/his preferred
scripting language in custom projects. But using only one language
OOTB
seems to be common sense. We chose groovy...
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
The code changes tested fine.
I noticed in your code comments that Groovy should be handled
independently from other scripting languages. Why do you
think
that?
-Adrian
On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
My changes are in commit 1296762
Help with reviews and tests will be very much appreciated.
Jacopo
On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
As far as I know, most scripting engines have some sort of
embedded cache. The problem will be that we can't clear the
embedded
[jira] [Commented] (OFBIZ-2628) No Url encoding for get parameters
[ https://issues.apache.org/jira/browse/OFBIZ-2628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1335#comment-1335 ] Sascha Rodekamp commented on OFBIZ-2628: Hi Jacques, yes i think hard coding UTF-8 is sufficient, first i thought of getting it from an property file, but as you mentioned the World Wide Web Consortium recommended also UTF-8. Thanks for reviewing Have a good day Sascha 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 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
Re: Implementing JSR-223
Le 05/03/2012 10:08, Adrian Crum a écrit :
Because the value attribute is supposed to represent a string constant
(that can be converted to another type via the type attribute), and
the from-field attribute is supposed to represent a variable.
My preference is to have a from-expression attribute to make things
clearer.
Same opinion, the from-expression miss to separate the value origin:
* from-field : provide only from existent context field
* value : only given value (Parsing by the given type)
* from-expression : calling script interface to resolve value.
From my perspective, the main reason mini-language has such strange
and quirky behavior is because the syntax has not been clearly
expressed or implemented.
-Adrian
On 3/5/2012 8:51 AM, Jacques Le Roux wrote:
From: Adrian Crum adrian.c...@sandglass-software.com
Okay, we can give it a try and see if we run into any problems.
Btw, expressions should go in the from-field attribute, not the
value attribute.
Why? I'd prefer to stay the same than now. I agree it's a convention,
but from-field makes less sense to me for evaluated expressions
(being in a script or inlined)
Jacques
-Adrian
On 3/5/2012 7:53 AM, Jacopo Cappellato wrote:
Yes, this is fine and I was thinking about a similar solution;
however I would like to find a simpler convention because
[script:groovy] is a lot of typing and could be difficult to read
when the code in buried in the value attribute of a set
element.
Something like:
${script:jython code_here}
${script:groovy code_here}
${script: code_here} this could use the default language set in
some properties file (i.e. groovy); this follows the
configuration by exception pattern (specify the script only if
you want to use a non default one).
But we should also consider a shortcut where the script word is
abbreviated, for example by the s word:
${s:jython code_here}
${s:groovy code_here}
${s: code_here}
Jacopo
On Mar 5, 2012, at 8:41 AM, Adrian Crum wrote:
I was thinking we could use something like ${[script:groovy]...}
${[script:jython]...} etc. I'm concerned that looking for a
string followed by a colon can lead to errors.
-Adrian
On 3/5/2012 6:22 AM, Jacopo Cappellato wrote:
I would like to clarify that in this first pass I focused on
moving code around keeping the same exact behavior currently
implemented: now all the code that had a dependency on Groovy or
Beanshell packages has been converted to be only dependent on
ScriptUtil class.
In order to implement JSR-223 we may have to change some of the
current behavior (the different way Beanshell and Groovy are
preparsed/executed) and also check if we can always assume that
if the code inside of ${...} starts with a string (no spaces)
followed by a colon (and a blank character?) then the string is
the scripting language: I didn't check the impact on existing
scripts but it should be easy to write a reg exp to find all of
them (I expect that the number will be small) and modify them
to be compatible with the convention. I intentionally didn't
focus on this second step.
Jacopo
On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
I must says I only cursorily reviewed the code Jacopo committed
and did not look into JSR-223 details.
So I thought at some point you have to check which language wich
is used?
Like in
+if (groovy.equals(language)) {
+if (scriptClass == null) {
+scriptClass = ScriptUtil.parseScript(language,
script);
+}
+if (scriptClass != null) {
+result =
InvokerHelper.createScript(scriptClass,
GroovyUtil.getBinding(inputMap)).run();
+}
+} else if (bsh.equals(language)) {
+result = BshUtil.eval(script,
UtilMisc.makeMapWritable(inputMap));
+}
In other words from Jacopo's code here, it seems you have to
differentiate how scritps are parsed?
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
Groovy supports JSR-223, so there is no reason to treat it
differently. My question has nothing to do with which scripting
engine
is supplied with OFBiz.
-Adrian
On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
I don't want to interfer with Jacopo's answer, but I guess
it's because Groovy will be implemented OOTB. The others could be
but
Groovy is already part of the framework (the inital subject
from Erwan was to completely remove BeanShell OOTB usage), I
mean
it's the idea and what Jacopo said already.
I second this idea. Everybody can use her/his preferred
scripting language in custom projects. But using only one
language
OOTB
seems to be common sense. We chose groovy...
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
The code changes tested fine.
I noticed in your code comments that Groovy should be handled
independently from other scripting languages. Why do you
think
that?
-Adrian
On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
My changes are in commit 1296762
Help
Re: Implementing JSR-223
Mmm... from-expression indeed This remembered me a discussion we had already
http://markmail.org/message/dzljmdhg2c3i52aq
No time to re-read at the moment, but yes from-expression sounds good to me and
not that hard to change in current code.
Jacques
From: Adrian Crum adrian.c...@sandglass-software.com
Because the value attribute is supposed to represent a string constant
(that can be converted to another type via the type attribute), and the
from-field attribute is supposed to represent a variable.
My preference is to have a from-expression attribute to make things clearer.
From my perspective, the main reason mini-language has such strange and
quirky behavior is because the syntax has not been clearly expressed or
implemented.
-Adrian
On 3/5/2012 8:51 AM, Jacques Le Roux wrote:
From: Adrian Crum adrian.c...@sandglass-software.com
Okay, we can give it a try and see if we run into any problems.
Btw, expressions should go in the from-field attribute, not the value
attribute.
Why? I'd prefer to stay the same than now. I agree it's a convention,
but from-field makes less sense to me for evaluated expressions (being
in a script or inlined)
Jacques
-Adrian
On 3/5/2012 7:53 AM, Jacopo Cappellato wrote:
Yes, this is fine and I was thinking about a similar solution;
however I would like to find a simpler convention because
[script:groovy] is a lot of typing and could be difficult to read
when the code in buried in the value attribute of a set
element.
Something like:
${script:jython code_here}
${script:groovy code_here}
${script: code_here} this could use the default language set in
some properties file (i.e. groovy); this follows the
configuration by exception pattern (specify the script only if you
want to use a non default one).
But we should also consider a shortcut where the script word is
abbreviated, for example by the s word:
${s:jython code_here}
${s:groovy code_here}
${s: code_here}
Jacopo
On Mar 5, 2012, at 8:41 AM, Adrian Crum wrote:
I was thinking we could use something like ${[script:groovy]...}
${[script:jython]...} etc. I'm concerned that looking for a
string followed by a colon can lead to errors.
-Adrian
On 3/5/2012 6:22 AM, Jacopo Cappellato wrote:
I would like to clarify that in this first pass I focused on
moving code around keeping the same exact behavior currently
implemented: now all the code that had a dependency on Groovy or
Beanshell packages has been converted to be only dependent on
ScriptUtil class.
In order to implement JSR-223 we may have to change some of the
current behavior (the different way Beanshell and Groovy are
preparsed/executed) and also check if we can always assume that if
the code inside of ${...} starts with a string (no spaces)
followed by a colon (and a blank character?) then the string is
the scripting language: I didn't check the impact on existing
scripts but it should be easy to write a reg exp to find all of
them (I expect that the number will be small) and modify them
to be compatible with the convention. I intentionally didn't focus
on this second step.
Jacopo
On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
I must says I only cursorily reviewed the code Jacopo committed
and did not look into JSR-223 details.
So I thought at some point you have to check which language wich
is used?
Like in
+if (groovy.equals(language)) {
+if (scriptClass == null) {
+scriptClass = ScriptUtil.parseScript(language,
script);
+}
+if (scriptClass != null) {
+result = InvokerHelper.createScript(scriptClass,
GroovyUtil.getBinding(inputMap)).run();
+}
+} else if (bsh.equals(language)) {
+result = BshUtil.eval(script,
UtilMisc.makeMapWritable(inputMap));
+}
In other words from Jacopo's code here, it seems you have to
differentiate how scritps are parsed?
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
Groovy supports JSR-223, so there is no reason to treat it
differently. My question has nothing to do with which scripting
engine
is supplied with OFBiz.
-Adrian
On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
I don't want to interfer with Jacopo's answer, but I guess it's
because Groovy will be implemented OOTB. The others could be
but
Groovy is already part of the framework (the inital subject
from Erwan was to completely remove BeanShell OOTB usage), I
mean
it's the idea and what Jacopo said already.
I second this idea. Everybody can use her/his preferred
scripting language in custom projects. But using only one language
OOTB
seems to be common sense. We chose groovy...
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
The code changes tested fine.
I noticed in your code comments that Groovy should be handled
independently from other scripting languages. Why do you
think
that?
-Adrian
On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
My changes are in commit
Re: Framework refactor
Hi Jacopo, Interesting discussion :) Like you said, the selected solution will have all the features we need. At this time Apache OFBiz offering a great functional framework with technical interface, this allows to functional developer to stay focused on their needsand don't waste on technical problem. It's really important to don't lose it. My feedback between Neogia and OFBiz (since we have in the same case that choice 3) and 4)) * Fork : easier to improve the framework, but really difficult to back improvements to original project. Many waste time to realize improvement in parallel. I don't recommend it * Synchronize by repository : import a external framework release, provides flexibility to update the external source and show own improvement. But with time past, the differences grow, increasing the synchro time and decreasing the back improvement quality. We stop this solution there are two years. * At this time, with develop addon manager system to separate each improvement on dedicate addon. This simplify the synchronization with external source, keep back improvement quality. We lost in commit celerit, it's a little more complicated to improve an addon than only commit in a repository. Whatever solution, I am available to help you. Nicolas Le 02/03/2012 09:28, Jacopo Cappellato a écrit : On Mar 2, 2012, at 7:50 AM, Hans Bakker wrote: Jacopo, You would even consider forking? From Wikipedia [*]: [...] More recently, distributed revision control (DVCS) tools have popularised a less emotive use of the term fork, blurring the distinction with branch. With a DVCS such as Mercurial or Git, the normal way to contribute to a project is to first branch the repository, and later seek to have your changes integrated with the main repository. Sites such as Github, Bitbucket and Launchpad provide free DVCS hosting expressly supporting independent branches, such that the technical, social and financial barriers to forking a source code repository are massively reduced. In order of preference (descending), here are the options I see for the future of the OFBiz framework: 1) develop a great Apache OFBiz framework 2.0 within the OFBiz community; then release it separately from the Apache OFBiz ERP 2) greatly clean up and improve the existing framework (I was not sure if this could go at #1) 3) if the above will not be possible (frankly speaking, in the committers group, apart from David, none of us ever implemented with success an open source framework) we should also consider to drop the existing code and have our community focusing on the ERP part (as Hans seems to advocate); at this point Moqui would be the most natural choice; if we will ever go with this path a great exchange of information will have to happen between the two projects: for example OFBiz will probably have to ask the Moqui framework to evolve some of its features; given the current nature of the Moqui project, I doubt that the OFBiz committers will be ever invited as committers there; if Moqui will be our choice, I see two possibilities: 3.a) we base the Apache OFBiz ERP on a release of Moqui: this will only be possible if Moqui release will have all the features we need (and if Moqui community will be interested in getting contribution to evolve in the direction required by OFBzi) 3.b) if 3.a will not be possible because OFBiz will need some features that Moqui community will not consider as a good fit for Moqui, then, under the guidance and bless of David, we could work on a fork: get the code from a Moqui release, import in our repository and add to it, in a controlled way, the features we need; of course this should be always kept as close as possible to the original code; we could synch our custom code with every new Moqui release; I was not thinking about *stealing* code to Moqui and the fact that David is both the founder of OFBiz and of Moqui and he is both in the OFBiz PMC and the leader of the Moqui project will definitely facilitate this; but it will be still an ugly solution but for example when you said: My proposal is that Apache OFBiz will be in the future just the ERP system based on many opensource products like birt and also Moqui you are actually implying that the ERP applications will be able to use Birt... but this requires some sort of framework and what would you do if Moqui will not think that Birt is a good fit for them? 4) if Moqui will not be a good option we may consider other frameworks (?), but it will be difficult, or continue with what we have Jacopo [*]: http://en.wikipedia.org/wiki/Fork_(software_development) -- Nicolas MALIN Consultant Tél : 06.17.66.40.06 Site projet : http://www.neogia.org/ --- Société LibrenBerry Tél : 02.48.02.56.12 Site : http://www.librenberry.net/
[jira] [Commented] (OFBIZ-4602) Null values are not synchronized in http mode
[ https://issues.apache.org/jira/browse/OFBIZ-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1361#comment-1361 ] Nicolas Malin commented on OFBIZ-4602: -- Hi Jacques, I tested the entity-sync process, and I confirm the [null-field] break it when an entity field is an other type that String. I not solve it, I will check it if I need implement the entity-sync. Null values are not synchronized in http mode - Key: OFBIZ-4602 URL: https://issues.apache.org/jira/browse/OFBIZ-4602 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release 4.0, Release 09.04, Release 09.04.01, Release 10.04, SVN trunk Environment: Using entity synchronization over HTTP (not RMI) Reporter: Patrick Antivackis Assignee: Jacques Le Roux Fix For: Release Branch 4.0, Release Branch 09.04, Release Branch 10.04, Release Branch 11.04, SVN trunk Attachments: patch-OFBIZ-4602.txt In order to send over http the values to create, store and remove, Ofbiz is Xml serializing the values. GenericValue xml serialization is managed in GenericEntity.makeXmlElement, unfortunately this method just don't serialized null valued fields. -- 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: svn commit: r1295029 - in /ofbiz/trunk: applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java specialpurpose/ecommerce/widget/EmailOrderScreens.xml
Hey Hans, (and all OFBiz committers in general)
I would like to stress the importance to address reviews on commits (especially
if they come from committers, like me, because we have veto on commits) asap
by improving the code or reverting it.
Actually the etiquette when a committer complains about a commit and motivates
the concerns (as I did) should be:
1) immediately improve the code according to the committer's review
2) or immediately provide additional information if you think that the code is
good and that, with the additional details, the reviewer will be satisfied; if
the discussion takes longer then the commit should be reverted until the
agreement is found
3) or immediately revert it
The fact that we use a commit then review approach doesn't mean that every
committers has the power to commit what he wants ignoring the others... the
opposite is actually true: every time we do a commit we should be ready to
receive feedback and improve the code; only at that point the code will become
official.
I hope this is the last time I have to state this fundamental rule,
Jacopo
On Feb 29, 2012, at 10:40 AM, Jacopo Cappellato wrote:
Hi Hans,
I don't like the assumption about the string control: this is a
configurable value (in web.xml) and we should not have it hardcoded in our
code.
I know there are already few examples of this bad pattern and in fact we
should work and fix them as well.
Jacopo
On Feb 29, 2012, at 10:23 AM, hans...@apache.org wrote:
Author: hansbak
Date: Wed Feb 29 09:23:36 2012
New Revision: 1295029
URL: http://svn.apache.org/viewvc?rev=1295029view=rev
Log:
correct url generation for seo friendly url's
Modified:
ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java
ofbiz/trunk/specialpurpose/ecommerce/widget/EmailOrderScreens.xml
Modified:
ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java?rev=1295029r1=1295028r2=1295029view=diff
==
---
ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java
(original)
+++
ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java
Wed Feb 29 09:23:36 2012
@@ -102,6 +102,7 @@ public class OfbizCatalogAltUrlTransform
String productCategoryId = getStringArg(args,
productCategoryId);
String productId = getStringArg(args, productId);
String url = ;
+String CONTROL_MOUNT_POINT = control;
Object prefix = env.getVariable(urlPrefix);
String viewSize = getStringArg(args, viewSize);
@@ -127,14 +128,19 @@ public class OfbizCatalogAltUrlTransform
Delegator delegator =
FreeMarkerWorker.getWrappedObject(delegator, env);
LocalDispatcher dispatcher =
FreeMarkerWorker.getWrappedObject(dispatcher, env);
Locale locale = (Locale) args.get(locale);
+String prefixUrl = prefix.toString();
+// remove control path from the prefix URL
+if(prefixUrl.contains(CONTROL_MOUNT_POINT)){
+prefixUrl =
prefixUrl.replaceAll(/+CONTROL_MOUNT_POINT, );
+}
if (UtilValidate.isNotEmpty(productId)) {
GenericValue product =
delegator.findOne(Product, UtilMisc.toMap(productId, productId), false);
ProductContentWrapper wrapper = new
ProductContentWrapper(dispatcher, product, locale, text/html);
-url =
CatalogUrlFilter.makeProductUrl(delegator, wrapper, null, ((StringModel)
prefix).getAsString(), previousCategoryId, productCategoryId, productId);
+url =
CatalogUrlFilter.makeProductUrl(delegator, wrapper, null, prefixUrl,
previousCategoryId, productCategoryId, productId);
} else {
GenericValue productCategory =
delegator.findOne(ProductCategory, UtilMisc.toMap(productCategoryId,
productCategoryId), false);
CategoryContentWrapper wrapper = new
CategoryContentWrapper(dispatcher, productCategory, locale, text/html);
-url =
CatalogUrlFilter.makeCategoryUrl(delegator, wrapper, null, ((StringModel)
prefix).getAsString(), previousCategoryId, productCategoryId, productId,
viewSize, viewIndex, viewSort, searchString);
+url =
CatalogUrlFilter.makeCategoryUrl(delegator, wrapper, null, prefixUrl,
previousCategoryId, productCategoryId, productId,
Re: svn commit: r1295029 - in /ofbiz/trunk: applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java specialpurpose/ecommerce/widget/EmailOrderScreens.xml
Jacopo,
in general i honor all comments although it can take some time, also
this one it is comming
Regards,
Hans
On 03/05/2012 05:57 PM, Jacopo Cappellato wrote:
Hey Hans, (and all OFBiz committers in general)
I would like to stress the importance to address reviews on commits (especially if they
come from committers, like me, because we have veto on commits) asap by
improving the code or reverting it.
Actually the etiquette when a committer complains about a commit and motivates
the concerns (as I did) should be:
1) immediately improve the code according to the committer's review
2) or immediately provide additional information if you think that the code is
good and that, with the additional details, the reviewer will be satisfied; if
the discussion takes longer then the commit should be reverted until the
agreement is found
3) or immediately revert it
The fact that we use a commit then review approach doesn't mean that every committers
has the power to commit what he wants ignoring the others... the opposite is actually true: every
time we do a commit we should be ready to receive feedback and improve the code; only at that point
the code will become official.
I hope this is the last time I have to state this fundamental rule,
Jacopo
On Feb 29, 2012, at 10:40 AM, Jacopo Cappellato wrote:
Hi Hans,
I don't like the assumption about the string control: this is a configurable
value (in web.xml) and we should not have it hardcoded in our code.
I know there are already few examples of this bad pattern and in fact we should
work and fix them as well.
Jacopo
On Feb 29, 2012, at 10:23 AM, hans...@apache.org wrote:
Author: hansbak
Date: Wed Feb 29 09:23:36 2012
New Revision: 1295029
URL: http://svn.apache.org/viewvc?rev=1295029view=rev
Log:
correct url generation for seo friendly url's
Modified:
ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java
ofbiz/trunk/specialpurpose/ecommerce/widget/EmailOrderScreens.xml
Modified:
ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java?rev=1295029r1=1295028r2=1295029view=diff
==
---
ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java
(original)
+++
ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java
Wed Feb 29 09:23:36 2012
@@ -102,6 +102,7 @@ public class OfbizCatalogAltUrlTransform
String productCategoryId = getStringArg(args,
productCategoryId);
String productId = getStringArg(args, productId);
String url = ;
+String CONTROL_MOUNT_POINT = control;
Object prefix = env.getVariable(urlPrefix);
String viewSize = getStringArg(args, viewSize);
@@ -127,14 +128,19 @@ public class OfbizCatalogAltUrlTransform
Delegator delegator =
FreeMarkerWorker.getWrappedObject(delegator, env);
LocalDispatcher dispatcher =
FreeMarkerWorker.getWrappedObject(dispatcher, env);
Locale locale = (Locale) args.get(locale);
+String prefixUrl = prefix.toString();
+// remove control path from the prefix URL
+if(prefixUrl.contains(CONTROL_MOUNT_POINT)){
+prefixUrl = prefixUrl.replaceAll(/+CONTROL_MOUNT_POINT,
);
+}
if (UtilValidate.isNotEmpty(productId)) {
GenericValue product = delegator.findOne(Product,
UtilMisc.toMap(productId, productId), false);
ProductContentWrapper wrapper = new
ProductContentWrapper(dispatcher, product, locale, text/html);
-url = CatalogUrlFilter.makeProductUrl(delegator,
wrapper, null, ((StringModel) prefix).getAsString(), previousCategoryId,
productCategoryId, productId);
+url = CatalogUrlFilter.makeProductUrl(delegator,
wrapper, null, prefixUrl, previousCategoryId, productCategoryId, productId);
} else {
GenericValue productCategory =
delegator.findOne(ProductCategory, UtilMisc.toMap(productCategoryId,
productCategoryId), false);
CategoryContentWrapper wrapper = new
CategoryContentWrapper(dispatcher, productCategory, locale, text/html);
-url = CatalogUrlFilter.makeCategoryUrl(delegator,
wrapper, null, ((StringModel) prefix).getAsString(), previousCategoryId,
productCategoryId, productId, viewSize, viewIndex, viewSort, searchString);
+url =
Re: svn commit: r1295029 - in /ofbiz/trunk: applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java specialpurpose/ecommerce/widget/EmailOrderScreens.xml
Thank Hans,
from now on please revert the commit until you find time to commit a better
version.
Regards,
Jacopo
On Mar 5, 2012, at 12:01 PM, Hans Bakker wrote:
Jacopo,
in general i honor all comments although it can take some time, also this one
it is comming
Regards,
Hans
On 03/05/2012 05:57 PM, Jacopo Cappellato wrote:
Hey Hans, (and all OFBiz committers in general)
I would like to stress the importance to address reviews on commits
(especially if they come from committers, like me, because we have veto on
commits) asap by improving the code or reverting it.
Actually the etiquette when a committer complains about a commit and
motivates the concerns (as I did) should be:
1) immediately improve the code according to the committer's review
2) or immediately provide additional information if you think that the code
is good and that, with the additional details, the reviewer will be
satisfied; if the discussion takes longer then the commit should be reverted
until the agreement is found
3) or immediately revert it
The fact that we use a commit then review approach doesn't mean that every
committers has the power to commit what he wants ignoring the others... the
opposite is actually true: every time we do a commit we should be ready to
receive feedback and improve the code; only at that point the code will
become official.
I hope this is the last time I have to state this fundamental rule,
Jacopo
On Feb 29, 2012, at 10:40 AM, Jacopo Cappellato wrote:
Hi Hans,
I don't like the assumption about the string control: this is a
configurable value (in web.xml) and we should not have it hardcoded in our
code.
I know there are already few examples of this bad pattern and in fact we
should work and fix them as well.
Jacopo
On Feb 29, 2012, at 10:23 AM, hans...@apache.org wrote:
Author: hansbak
Date: Wed Feb 29 09:23:36 2012
New Revision: 1295029
URL: http://svn.apache.org/viewvc?rev=1295029view=rev
Log:
correct url generation for seo friendly url's
Modified:
ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java
ofbiz/trunk/specialpurpose/ecommerce/widget/EmailOrderScreens.xml
Modified:
ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java?rev=1295029r1=1295028r2=1295029view=diff
==
---
ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java
(original)
+++
ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java
Wed Feb 29 09:23:36 2012
@@ -102,6 +102,7 @@ public class OfbizCatalogAltUrlTransform
String productCategoryId = getStringArg(args,
productCategoryId);
String productId = getStringArg(args, productId);
String url = ;
+String CONTROL_MOUNT_POINT = control;
Object prefix = env.getVariable(urlPrefix);
String viewSize = getStringArg(args, viewSize);
@@ -127,14 +128,19 @@ public class OfbizCatalogAltUrlTransform
Delegator delegator =
FreeMarkerWorker.getWrappedObject(delegator, env);
LocalDispatcher dispatcher =
FreeMarkerWorker.getWrappedObject(dispatcher, env);
Locale locale = (Locale) args.get(locale);
+String prefixUrl = prefix.toString();
+// remove control path from the prefix URL
+if(prefixUrl.contains(CONTROL_MOUNT_POINT)){
+prefixUrl =
prefixUrl.replaceAll(/+CONTROL_MOUNT_POINT, );
+}
if (UtilValidate.isNotEmpty(productId)) {
GenericValue product =
delegator.findOne(Product, UtilMisc.toMap(productId, productId),
false);
ProductContentWrapper wrapper = new
ProductContentWrapper(dispatcher, product, locale, text/html);
-url =
CatalogUrlFilter.makeProductUrl(delegator, wrapper, null, ((StringModel)
prefix).getAsString(), previousCategoryId, productCategoryId, productId);
+url =
CatalogUrlFilter.makeProductUrl(delegator, wrapper, null, prefixUrl,
previousCategoryId, productCategoryId, productId);
} else {
GenericValue productCategory =
delegator.findOne(ProductCategory, UtilMisc.toMap(productCategoryId,
productCategoryId), false);
CategoryContentWrapper wrapper = new
CategoryContentWrapper(dispatcher, productCategory, locale, text/html);
-
Re: svn commit: r1295029 - in /ofbiz/trunk: applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java specialpurpose/ecommerce/widget/EmailOrderScreens.xml
Maybe then sending back a word saying that it's a WIP would help ;o)
Jacques
From: Hans Bakker mailingl...@antwebsystems.com
Jacopo,
in general i honor all comments although it can take some time, also this one
it is comming
Regards,
Hans
On 03/05/2012 05:57 PM, Jacopo Cappellato wrote:
Hey Hans, (and all OFBiz committers in general)
I would like to stress the importance to address reviews on commits (especially if they come from committers, like me, because we
have veto on commits) asap by improving the code or reverting it.
Actually the etiquette when a committer complains about a commit and motivates
the concerns (as I did) should be:
1) immediately improve the code according to the committer's review
2) or immediately provide additional information if you think that the code is good and that, with the additional details, the
reviewer will be satisfied; if the discussion takes longer then the commit should be reverted until the agreement is found
3) or immediately revert it
The fact that we use a commit then review approach doesn't mean that every committers has the power to commit what he wants
ignoring the others... the opposite is actually true: every time we do a commit we should be ready to receive feedback and
improve the code; only at that point the code will become official.
I hope this is the last time I have to state this fundamental rule,
Jacopo
On Feb 29, 2012, at 10:40 AM, Jacopo Cappellato wrote:
Hi Hans,
I don't like the assumption about the string control: this is a configurable value (in web.xml) and we should not have it
hardcoded in our code.
I know there are already few examples of this bad pattern and in fact we should
work and fix them as well.
Jacopo
On Feb 29, 2012, at 10:23 AM, hans...@apache.org wrote:
Author: hansbak
Date: Wed Feb 29 09:23:36 2012
New Revision: 1295029
URL: http://svn.apache.org/viewvc?rev=1295029view=rev
Log:
correct url generation for seo friendly url's
Modified:
ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java
ofbiz/trunk/specialpurpose/ecommerce/widget/EmailOrderScreens.xml
Modified:
ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java?rev=1295029r1=1295028r2=1295029view=diff
==
---
ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java
(original)
+++
ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java
Wed Feb 29 09:23:36 2012
@@ -102,6 +102,7 @@ public class OfbizCatalogAltUrlTransform
String productCategoryId = getStringArg(args,
productCategoryId);
String productId = getStringArg(args, productId);
String url = ;
+String CONTROL_MOUNT_POINT = control;
Object prefix = env.getVariable(urlPrefix);
String viewSize = getStringArg(args, viewSize);
@@ -127,14 +128,19 @@ public class OfbizCatalogAltUrlTransform
Delegator delegator =
FreeMarkerWorker.getWrappedObject(delegator, env);
LocalDispatcher dispatcher =
FreeMarkerWorker.getWrappedObject(dispatcher, env);
Locale locale = (Locale) args.get(locale);
+String prefixUrl = prefix.toString();
+// remove control path from the prefix URL
+if(prefixUrl.contains(CONTROL_MOUNT_POINT)){
+prefixUrl = prefixUrl.replaceAll(/+CONTROL_MOUNT_POINT,
);
+}
if (UtilValidate.isNotEmpty(productId)) {
GenericValue product = delegator.findOne(Product,
UtilMisc.toMap(productId, productId), false);
ProductContentWrapper wrapper = new ProductContentWrapper(dispatcher, product, locale,
text/html);
-url = CatalogUrlFilter.makeProductUrl(delegator, wrapper, null, ((StringModel)
prefix).getAsString(), previousCategoryId, productCategoryId, productId);
+url = CatalogUrlFilter.makeProductUrl(delegator, wrapper, null, prefixUrl, previousCategoryId,
productCategoryId, productId);
} else {
GenericValue productCategory = delegator.findOne(ProductCategory,
UtilMisc.toMap(productCategoryId, productCategoryId), false);
CategoryContentWrapper wrapper = new CategoryContentWrapper(dispatcher, productCategory, locale,
text/html);
-url = CatalogUrlFilter.makeCategoryUrl(delegator, wrapper, null, ((StringModel)
prefix).getAsString(), previousCategoryId,
Re: svn commit: r1295029 - in /ofbiz/trunk: applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java specialpurpose/ecommerce/widget/EmailOrderScreens.xml
Yes, *reverting* and then sending a word back that an improved version is in progress would also be fine. Jacopo On Mar 5, 2012, at 12:10 PM, Jacques Le Roux wrote: Maybe then sending back a word saying that it's a WIP would help ;o) Jacques
Re: Implementing JSR-223
From: Nicolas Malin malin.nico...@librenberry.net
Le 05/03/2012 10:08, Adrian Crum a écrit :
Because the value attribute is supposed to represent a string constant (that can be converted to another type via the type
attribute), and the from-field attribute is supposed to represent a variable.
My preference is to have a from-expression attribute to make things clearer.
Same opinion, the from-expression miss to separate the value origin:
I guess you meant from-field above ;o)
Jacques
* from-field : provide only from existent context field
* value : only given value (Parsing by the given type)
* from-expression : calling script interface to resolve value.
From my perspective, the main reason mini-language has such strange and quirky behavior is because the syntax has not been
clearly expressed or implemented.
-Adrian
On 3/5/2012 8:51 AM, Jacques Le Roux wrote:
From: Adrian Crum adrian.c...@sandglass-software.com
Okay, we can give it a try and see if we run into any problems.
Btw, expressions should go in the from-field attribute, not the value attribute.
Why? I'd prefer to stay the same than now. I agree it's a convention, but from-field makes less sense to me for evaluated
expressions (being in a script or inlined)
Jacques
-Adrian
On 3/5/2012 7:53 AM, Jacopo Cappellato wrote:
Yes, this is fine and I was thinking about a similar solution; however I would
like to find a simpler convention because
[script:groovy] is a lot of typing and could be difficult to read when the code in buried in the
value attribute of a set
element.
Something like:
${script:jython code_here}
${script:groovy code_here}
${script: code_here} this could use the default language set in some properties file
(i.e. groovy); this follows the
configuration by exception pattern (specify the script only if you want to
use a non default one).
But we should also consider a shortcut where the script word is abbreviated, for
example by the s word:
${s:jython code_here}
${s:groovy code_here}
${s: code_here}
Jacopo
On Mar 5, 2012, at 8:41 AM, Adrian Crum wrote:
I was thinking we could use something like ${[script:groovy]...}
${[script:jython]...} etc. I'm concerned that looking for a
string followed by a colon can lead to errors.
-Adrian
On 3/5/2012 6:22 AM, Jacopo Cappellato wrote:
I would like to clarify that in this first pass I focused on moving code
around keeping the same exact behavior currently
implemented: now all the code that had a dependency on Groovy or Beanshell packages has been converted to be only dependent
on
ScriptUtil class.
In order to implement JSR-223 we may have to change some of the current
behavior (the different way Beanshell and Groovy are
preparsed/executed) and also check if we can always assume that if the code inside of ${...} starts with a string (no
spaces)
followed by a colon (and a blank character?) then the string is the scripting language: I didn't check the impact on
existing
scripts but it should be easy to write a reg exp to find all of them (I expect that the number will be small) and modify
them
to be compatible with the convention. I intentionally didn't focus on this
second step.
Jacopo
On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
I must says I only cursorily reviewed the code Jacopo committed and did not
look into JSR-223 details.
So I thought at some point you have to check which language wich is used?
Like in
+if (groovy.equals(language)) {
+if (scriptClass == null) {
+scriptClass = ScriptUtil.parseScript(language, script);
+}
+if (scriptClass != null) {
+result = InvokerHelper.createScript(scriptClass,
GroovyUtil.getBinding(inputMap)).run();
+}
+} else if (bsh.equals(language)) {
+result = BshUtil.eval(script, UtilMisc.makeMapWritable(inputMap));
+}
In other words from Jacopo's code here, it seems you have to differentiate how
scritps are parsed?
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
Groovy supports JSR-223, so there is no reason to treat it differently. My
question has nothing to do with which scripting
engine
is supplied with OFBiz.
-Adrian
On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
I don't want to interfer with Jacopo's answer, but I guess it's because Groovy will be implemented OOTB. The others could
be
but
Groovy is already part of the framework (the inital subject from Erwan was to
completely remove BeanShell OOTB usage), I
mean
it's the idea and what Jacopo said already.
I second this idea. Everybody can use her/his preferred scripting language in custom projects. But using only one
language
OOTB
seems to be common sense. We chose groovy...
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
The code changes tested fine.
I noticed in your code comments that Groovy should be handled independently
from other scripting languages. Why do you
think
that?
-Adrian
On
Re: svn commit: r1295029 - in /ofbiz/trunk: applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java specialpurpose/ecommerce/widget/EmailOrderScreens.xml
I agree about reverting when someone specially ask about it, moreover it's easy to do, easier/quicker than fixing which can be done later. So I see no reasons to not do it (anyway Hans just did it :o) I wanted also to emphasize that often miscommunication is the root of problems. It's just about respecting each other... we can dot it, I'm sure ... Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com Yes, *reverting* and then sending a word back that an improved version is in progress would also be fine. Jacopo On Mar 5, 2012, at 12:10 PM, Jacques Le Roux wrote: Maybe then sending back a word saying that it's a WIP would help ;o) Jacques
Re: Framework refactor
+1 to 3.a). On 2012-3-2, at 下午4:28, Jacopo Cappellato wrote: On Mar 2, 2012, at 7:50 AM, Hans Bakker wrote: Jacopo, You would even consider forking? From Wikipedia [*]: [...] More recently, distributed revision control (DVCS) tools have popularised a less emotive use of the term fork, blurring the distinction with branch. With a DVCS such as Mercurial or Git, the normal way to contribute to a project is to first branch the repository, and later seek to have your changes integrated with the main repository. Sites such as Github, Bitbucket and Launchpad provide free DVCS hosting expressly supporting independent branches, such that the technical, social and financial barriers to forking a source code repository are massively reduced. In order of preference (descending), here are the options I see for the future of the OFBiz framework: 1) develop a great Apache OFBiz framework 2.0 within the OFBiz community; then release it separately from the Apache OFBiz ERP 2) greatly clean up and improve the existing framework (I was not sure if this could go at #1) 3) if the above will not be possible (frankly speaking, in the committers group, apart from David, none of us ever implemented with success an open source framework) we should also consider to drop the existing code and have our community focusing on the ERP part (as Hans seems to advocate); at this point Moqui would be the most natural choice; if we will ever go with this path a great exchange of information will have to happen between the two projects: for example OFBiz will probably have to ask the Moqui framework to evolve some of its features; given the current nature of the Moqui project, I doubt that the OFBiz committers will be ever invited as committers there; if Moqui will be our choice, I see two possibilities: 3.a) we base the Apache OFBiz ERP on a release of Moqui: this will only be possible if Moqui release will have all the features we need (and if Moqui community will be interested in getting contribution to evolve in the direction required by OFBzi) 3.b) if 3.a will not be possible because OFBiz will need some features that Moqui community will not consider as a good fit for Moqui, then, under the guidance and bless of David, we could work on a fork: get the code from a Moqui release, import in our repository and add to it, in a controlled way, the features we need; of course this should be always kept as close as possible to the original code; we could synch our custom code with every new Moqui release; I was not thinking about *stealing* code to Moqui and the fact that David is both the founder of OFBiz and of Moqui and he is both in the OFBiz PMC and the leader of the Moqui project will definitely facilitate this; but it will be still an ugly solution but for example when you said: My proposal is that Apache OFBiz will be in the future just the ERP system based on many opensource products like birt and also Moqui you are actually implying that the ERP applications will be able to use Birt... but this requires some sort of framework and what would you do if Moqui will not think that Birt is a good fit for them? 4) if Moqui will not be a good option we may consider other frameworks (?), but it will be difficult, or continue with what we have Jacopo [*]: http://en.wikipedia.org/wiki/Fork_(software_development)
[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 Fix Version/s: SVN trunk Release Branch 11.04 Release Branch 10.04 Thanks Markus for the initial Patch i committed my modified version in: Trunk @Rev 1297006 10.04 @Rev 1297030 11.04 @Rev 1297031 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
Discussion: Mini-language Overhaul
Mini-language has evolved a lot over the years. Most of the development has occurred on an as-needed basis, so there is no clear design or implementation - things just get tacked on over time. A recent discussion has opened up the possibility to rework the mini-language set element. From my perspective, that task is long overdue. Also, the schemas are out of date, and they are unnecessarily complicated. So, those need a thorough going over. While we are at it, why don't we create a draft design document based on the current implementation, and then use it to look for other ways mini-language can be improved? We can all offer suggestions and comments, agree on a final design, finalize the draft, and then implement it in code. The design document then becomes the developer's reference. What do you think? -Adrian
Question About Service Engine Tests
Why are the service engine tests in the common component? Shouldn't they be in the service component? -Adrian
Re: Discussion: Mini-language Overhaul
Adrian, Thanks for starting this thread. While we all love mini-lang, I am wondering if we should really ask ourselves if we really want to overhaul mini-lang or should we consider alternates. From what I know, Not many people like to build application using mini lang. Many end up using Java or Groovy. Thanks and Regards Anil Patel HotWax Media Inc On Mar 5, 2012, at 9:47 AM, Adrian Crum wrote: Mini-language has evolved a lot over the years. Most of the development has occurred on an as-needed basis, so there is no clear design or implementation - things just get tacked on over time. A recent discussion has opened up the possibility to rework the mini-language set element. From my perspective, that task is long overdue. Also, the schemas are out of date, and they are unnecessarily complicated. So, those need a thorough going over. While we are at it, why don't we create a draft design document based on the current implementation, and then use it to look for other ways mini-language can be improved? We can all offer suggestions and comments, agree on a final design, finalize the draft, and then implement it in code. The design document then becomes the developer's reference. What do you think? -Adrian
Re: Discussion: Mini-language Overhaul
I think having a scripting language that can be expressed in markup and managed via an xsd schema is a powerful feature. I would hate to see it go away. -Al On Mon, Mar 5, 2012 at 12:46 PM, Anil Patel anil.pa...@hotwaxmedia.com wrote: Adrian, Thanks for starting this thread. While we all love mini-lang, I am wondering if we should really ask ourselves if we really want to overhaul mini-lang or should we consider alternates. From what I know, Not many people like to build application using mini lang. Many end up using Java or Groovy. Thanks and Regards Anil Patel HotWax Media Inc On Mar 5, 2012, at 9:47 AM, Adrian Crum wrote: Mini-language has evolved a lot over the years. Most of the development has occurred on an as-needed basis, so there is no clear design or implementation - things just get tacked on over time. A recent discussion has opened up the possibility to rework the mini-language set element. From my perspective, that task is long overdue. Also, the schemas are out of date, and they are unnecessarily complicated. So, those need a thorough going over. While we are at it, why don't we create a draft design document based on the current implementation, and then use it to look for other ways mini-language can be improved? We can all offer suggestions and comments, agree on a final design, finalize the draft, and then implement it in code. The design document then becomes the developer's reference. What do you think? -Adrian
Re: Discussion: Mini-language Overhaul
And by go away, I mean not get enhanced. -Heinz On Mon, Mar 5, 2012 at 12:53 PM, Al Byers bye...@automationgroups.com wrote: I think having a scripting language that can be expressed in markup and managed via an xsd schema is a powerful feature. I would hate to see it go away. -Al On Mon, Mar 5, 2012 at 12:46 PM, Anil Patel anil.pa...@hotwaxmedia.com wrote: Adrian, Thanks for starting this thread. While we all love mini-lang, I am wondering if we should really ask ourselves if we really want to overhaul mini-lang or should we consider alternates. From what I know, Not many people like to build application using mini lang. Many end up using Java or Groovy. Thanks and Regards Anil Patel HotWax Media Inc On Mar 5, 2012, at 9:47 AM, Adrian Crum wrote: Mini-language has evolved a lot over the years. Most of the development has occurred on an as-needed basis, so there is no clear design or implementation - things just get tacked on over time. A recent discussion has opened up the possibility to rework the mini-language set element. From my perspective, that task is long overdue. Also, the schemas are out of date, and they are unnecessarily complicated. So, those need a thorough going over. While we are at it, why don't we create a draft design document based on the current implementation, and then use it to look for other ways mini-language can be improved? We can all offer suggestions and comments, agree on a final design, finalize the draft, and then implement it in code. The design document then becomes the developer's reference. What do you think? -Adrian
Re: Discussion: Mini-language Overhaul
I am not one of those people. I use mini-lang almost exclusively. -Adrian On 3/5/2012 7:46 PM, Anil Patel wrote: Adrian, Thanks for starting this thread. While we all love mini-lang, I am wondering if we should really ask ourselves if we really want to overhaul mini-lang or should we consider alternates. From what I know, Not many people like to build application using mini lang. Many end up using Java or Groovy. Thanks and Regards Anil Patel HotWax Media Inc On Mar 5, 2012, at 9:47 AM, Adrian Crum wrote: Mini-language has evolved a lot over the years. Most of the development has occurred on an as-needed basis, so there is no clear design or implementation - things just get tacked on over time. A recent discussion has opened up the possibility to rework the mini-languageset element. From my perspective, that task is long overdue. Also, the schemas are out of date, and they are unnecessarily complicated. So, those need a thorough going over. While we are at it, why don't we create a draft design document based on the current implementation, and then use it to look for other ways mini-language can be improved? We can all offer suggestions and comments, agree on a final design, finalize the draft, and then implement it in code. The design document then becomes the developer's reference. What do you think? -Adrian
[jira] [Created] (OFBIZ-4723) Support validation of resource xml files
Support validation of resource xml files Key: OFBIZ-4723 URL: https://issues.apache.org/jira/browse/OFBIZ-4723 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Environment: REV 1297286 Reporter: Anne Jessel Priority: Minor The xsd for the resource xml files is invalid. In addition, the format of the value of the xml:lang attribute in resource xml files is invalid, according to the xml standard. The attached patch: * provides a valid xsd * updates UtilProperties and the Label Manager to deal with the correct formatting of the xml:lang value, while still working with the old format, following Adrian Crum's recommendation on the mailing list * includes simple unit tests for UtilProperties to ensure it does work with both formats * changes the Label Manager to include a reference to the new xsd, and to use the correct format of the xml:lang value, when writing a resource xml file. This problem exists in released versions, but I doubt it is important enough to back port. -- 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] [Updated] (OFBIZ-4723) Support validation of resource xml files
[ https://issues.apache.org/jira/browse/OFBIZ-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anne Jessel updated OFBIZ-4723: --- Attachment: OFBIZ-4723_support-validation-resource-xml.patch Support validation of resource xml files Key: OFBIZ-4723 URL: https://issues.apache.org/jira/browse/OFBIZ-4723 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Environment: REV 1297286 Reporter: Anne Jessel Priority: Minor Attachments: OFBIZ-4723_support-validation-resource-xml.patch The xsd for the resource xml files is invalid. In addition, the format of the value of the xml:lang attribute in resource xml files is invalid, according to the xml standard. The attached patch: * provides a valid xsd * updates UtilProperties and the Label Manager to deal with the correct formatting of the xml:lang value, while still working with the old format, following Adrian Crum's recommendation on the mailing list * includes simple unit tests for UtilProperties to ensure it does work with both formats * changes the Label Manager to include a reference to the new xsd, and to use the correct format of the xml:lang value, when writing a resource xml file. This problem exists in released versions, but I doubt it is important enough to back port. -- 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: Preferred solution to non-validating xml:lang?
Thanks Adrian. Have provided a patch for this as https://issues.apache.org/jira/browse/OFBIZ-4723 While working on this, I noticed org.ofbiz.webtools.labelmanager.LabelManagerFactory.java and org.ofbiz.webtools.labelmanager.LabelReferences.java have hard-coded references to the shark component. This doesn't seem appropriate, especially for an optional component. Cheers, Anne. On 29 February 2012 19:54, Adrian Crum adrian.c...@sandglass-software.comwrote: I would recommend that we support both versions of the xml:lang attribute. The UtilProperties class and the Label Manager application can be updated to read either version and write the correct version. That way we will have an upgrade path without breaking backward compatibility. -Adrian On 2/29/2012 4:17 AM, Anne wrote: The schema at framework/base/dtd/ofbiz-**properties.xsd is intended for the labels xml files. Currently those files do not to refer to a schema. So I tried to change that. However the ofbiz-properties.xsd itself wouldn't validate, so I fixed that, and then added it as the schema to a sample labels.xml file for testing. Now I have a different problem relating to the xml:lang attribute. I need a solution or there is no point me submitting a patch. The existing code in UtilProperties compares the string generated by Locale's toString() with the value of the xml:lang attribute. An example string generated by Locale's toString() is pt_BR. Therefore that is the format of the string currently used with xml:lang in the labels.xml files. The xml:lang attribute definition (according to both the xml standard and the relevant xsd) states the value must be of the form pt-BR. That is, a - and not a _. This is incompatible with current usage in OFBiz. If I apply a schema to an existing labels.xml file, the xml will not validate. If I fix the xml so it validates, it of course won't work in OFBiz unless I also change UtilProperties. One solution would be to change UtilProperties: stop using Locale's toString(), and instead create a string with a '-' using Locale's getCountry() and getLanguage() methods (is the Locale variant used anywhere?). Then all the labels.xml files would need to have their value of xml:lang updated to use '-' instead of '_'. What is the community's preferred solution? Cheers, Anne. -- 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] [Updated] (OFBIZ-4723) Support validation of resource xml files
[ https://issues.apache.org/jira/browse/OFBIZ-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anne Jessel updated OFBIZ-4723: --- Attachment: OFBIZ-4723_code_cleanups.patch While creating the main patch, I made some minor code cleanups to these files. Including as a separate patch to aid review. Patch should be applied after main one. Support validation of resource xml files Key: OFBIZ-4723 URL: https://issues.apache.org/jira/browse/OFBIZ-4723 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Environment: REV 1297286 Reporter: Anne Jessel Priority: Minor Attachments: OFBIZ-4723_code_cleanups.patch, OFBIZ-4723_support-validation-resource-xml.patch The xsd for the resource xml files is invalid. In addition, the format of the value of the xml:lang attribute in resource xml files is invalid, according to the xml standard. The attached patch: * provides a valid xsd * updates UtilProperties and the Label Manager to deal with the correct formatting of the xml:lang value, while still working with the old format, following Adrian Crum's recommendation on the mailing list * includes simple unit tests for UtilProperties to ensure it does work with both formats * changes the Label Manager to include a reference to the new xsd, and to use the correct format of the xml:lang value, when writing a resource xml file. This problem exists in released versions, but I doubt it is important enough to back port. -- 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: svn commit: r1297006 - in /ofbiz/trunk/framework: webapp/src/org/ofbiz/webapp/control/RequestHandler.java widget/src/org/ofbiz/widget/WidgetWorker.java
There is a problem with this patch. URLs which are encoded could not
redirect from HTTP to HTTPS. The error is shown on the demo site, for
example, http://demo-trunk.ofbiz.apache.org:8080/ecommerce/ which the
Login link does not work.
Regards,
Chatree Srichart
On Mon, Mar 5, 2012 at 6:13 PM, sascharodek...@apache.org wrote:
Author: sascharodekamp
Date: Mon Mar 5 11:13:29 2012
New Revision: 1297006
URL: http://svn.apache.org/viewvc?rev=1297006view=rev
Log:
No Url encoding for get parameters (
https://issues.apache.org/jira/browse/OFBIZ-2628) using the URLEncoder to
encode and render URLs with special Chars. The encoding is always UTF-8
Modified:
ofbiz/trunk/framework/webapp/src/org/ofbiz/webapp/control/RequestHandler.java
ofbiz/trunk/framework/widget/src/org/ofbiz/widget/WidgetWorker.java
Modified:
ofbiz/trunk/framework/webapp/src/org/ofbiz/webapp/control/RequestHandler.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/webapp/src/org/ofbiz/webapp/control/RequestHandler.java?rev=1297006r1=1297005r2=1297006view=diff
==
---
ofbiz/trunk/framework/webapp/src/org/ofbiz/webapp/control/RequestHandler.java
(original)
+++
ofbiz/trunk/framework/webapp/src/org/ofbiz/webapp/control/RequestHandler.java
Mon Mar 5 11:13:29 2012
@@ -24,6 +24,8 @@ import java.io.IOException;
import java.io.Serializable;
import java.io.UnsupportedEncodingException;
import java.net.URL;
+import java.net.URLEncoder;
+import java.nio.charset.Charset;
import java.security.cert.X509Certificate;
import java.util.Enumeration;
import java.util.List;
@@ -1113,7 +1115,13 @@ public class RequestHandler {
newURL.insert(questionIndex, sessionId);
}
}
-encodedUrl = newURL.toString();
+
+try {
+encodedUrl = URLEncoder.encode(newURL.toString(),
Charset.forName(UTF-8).displayName());
+} catch (UnsupportedEncodingException e) {
+Debug.logError(e, module);
+encodedUrl = newURL.toString();
+}
}
} else {
encodedUrl = newURL.toString();
Modified:
ofbiz/trunk/framework/widget/src/org/ofbiz/widget/WidgetWorker.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/widget/src/org/ofbiz/widget/WidgetWorker.java?rev=1297006r1=1297005r2=1297006view=diff
==
--- ofbiz/trunk/framework/widget/src/org/ofbiz/widget/WidgetWorker.java
(original)
+++ ofbiz/trunk/framework/widget/src/org/ofbiz/widget/WidgetWorker.java
Mon Mar 5 11:13:29 2012
@@ -20,7 +20,10 @@ package org.ofbiz.widget;
import java.io.IOException;
import java.io.StringWriter;
+import java.io.UnsupportedEncodingException;
import java.math.BigDecimal;
+import java.net.URLEncoder;
+import java.nio.charset.Charset;
import java.text.DateFormat;
import java.util.Map;
import java.util.TimeZone;
@@ -339,7 +342,12 @@ public class WidgetWorker {
public String getValue(MapString, Object context) {
if (this.value != null) {
-return this.value.expandString(context);
+try {
+return
URLEncoder.encode(this.value.expandString(context),
Charset.forName(UTF-8).displayName());
+} catch (UnsupportedEncodingException e) {
+Debug.logError(e, module);
+return this.value.expandString(context);
+}
}
Object retVal = null;
@@ -370,7 +378,11 @@ public class WidgetWorker {
DateFormat df = UtilDateTime.toDateTimeFormat(EEE MMM
dd hh:mm:ss z , timeZone, null);
returnValue = df.format((java.util.Date) retVal);
} else {
-returnValue = retVal.toString();
+try {
+returnValue =
URLEncoder.encode(retVal.toString(),
Charset.forName(UTF-8).displayName());
+} catch (UnsupportedEncodingException e) {
+Debug.logError(e, module);
+}
}
return returnValue;
} else {
Re: Discussion: Mini-language Overhaul
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 the
approach suggested by Adrian.
In my opinion, a good way to define a new version of the set operation could
be that of analyzing how we are currently using the operation in OFBiz: as a
starting point we could start by searching all occurrences of set string in
OFBiz, then review them and see different patterns; discuss and define the few
ones that we like more, convert all code to use them consistently, then (or in
the same phase) define the new element to better implement the patterns that we
like.
And now I am switching to the brainstorming mode :-)
Kind regards,
Jacopo
brainstorming
I would like to have a set operation that implements some of the ideas of the
configure by exception concept.
As regards the type supported, but pending the review of existing usage, we may
consider to only support these:
* Object
* List
* Map
* BigDecimal/BigInteger (all numbers in Minilang should be treated as
BigDecimal; no support for Integer, Float etc...)
* String (expander i.e. the equivalent of GString in Groovy)
* a date object
Then we could get rid of the from-field attribute and replace it with a
from attribute that can take as input a single field (as it is now) or an
expression; some examples (all the following are evaluated using Groovy except
where a different language is specified i.e. default scripting language):
set field=field1 from=parameters.inputField1/ // field1 will have the
same type of inputField1
set field=field2 from=parameters.inputField1 + parameters.inputField2/ //
if inputField1 and inputField2 are numbers then field2 will be the BigDecimal
sum of the two
set field=field3 from=parameters.inputField1 * 10/
set field=field4 from=script:bsh parameters.inputField1 + 10/ // use
Beanshell
set field=field5 from=parameters.inputField1 type=BigDecimal/ // if
inputField1 is a string representation of a number we can convert with the
explicit definition of the type
For the constant values (I am not sure if it is a good idea, but for now I will
throw it out):
set field=stringField value=This is a string/
set field=stringField value=This is a string with a ${variable}/
// the following two are equivalent
set field=bigDecimalField value=100/ // the system attempt to parse 100
as a number first (BigDecimal) and then as a string
set field=bigDecimalField value=100 type=BigDecimal/
set field=stringField value=100 type=String/ // treat the field as a
string
/brainstorming
On Mar 5, 2012, at 9:07 PM, Adrian Crum wrote:
I am not one of those people. I use mini-lang almost exclusively.
-Adrian
On 3/5/2012 7:46 PM, Anil Patel wrote:
Adrian,
Thanks for starting this thread.
While we all love mini-lang, I am wondering if we should really ask
ourselves if we really want to overhaul mini-lang or should we consider
alternates. From what I know, Not many people like to build application
using mini lang. Many end up using Java or Groovy.
Thanks and Regards
Anil Patel
HotWax Media Inc
On Mar 5, 2012, at 9:47 AM, Adrian Crum wrote:
Mini-language has evolved a lot over the years. Most of the development has
occurred on an as-needed basis, so there is no clear design or
implementation - things just get tacked on over time.
A recent discussion has opened up the possibility to rework the
mini-languageset element. From my perspective, that task is long overdue.
Also, the schemas are out of date, and they are unnecessarily complicated.
So, those need a thorough going over.
While we are at it, why don't we create a draft design document based on
the current implementation, and then use it to look for other ways
mini-language can be improved? We can all offer suggestions and comments,
agree on a final design, finalize the draft, and then implement it in code.
The design document then becomes the developer's reference.
What do you think?
-Adrian
Re: Implementing JSR-223
This could work but I was thinking to something more like having some core
packages (like entity and service) always imported in groovy scripts/services;
or having the delegator and dispatcher objects properly casted to their
interfaces (to take advantage of IDE autocompletion features); etc...
But I don't have a clear list at the moment so please do not consider my notes
a blocker.
I am working at a POC for a best practice Groovy service implementation and
this should end up with a wish list of features I would like to have. Then we
can discuss the best way to achieve this.
Jacopo
On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
If you don't mind, I would like to get all of the issues resolved during the
design phase.
I will wait for the private email to understand what you mean by a secure
scripting package.
What I was suggesting is a script utility object that can be put in the
context so that all scripting languages can use it. Whatever methods you have
in mind could be implemented in a generic way and reused. Personally, I would
like to use something like:
// Groovy, JavaScript
partyValue = script.entityOne(Party);
if (partyValue)...
In other words, have an object in the context that gives us the convenience
of mini-language.
-Adrian
On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote:
It seems to me if there is a security issue using Groovy, then there would
be an issue using any scripting language.
Yes, but what we would bundle ootb would be a secured packaged ready to run
Groovy scripts in a secure way and already packaged with hundreds of
scripts.
If the user will add a new jar to support a different script (and the user
will also have to implement the custom scripts) then this will be less
secure but there isn't much we could do as we delegate to JSR-223 the
implementation of security.
Why can't we put the friendly methods in the context, so all scripting
languages can use them?
I am not sure I understand what you are proposing (the method would be
language specific) but for now we can postpone this discussion at when (if
it will ever happen) we will discuss about this approach.
Jacopo
-Adrian
On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
The code changes tested fine.
I noticed in your code comments that Groovy should be handled
independently from other scripting languages. Why do you think that?
First of all, I apologize for having added my personal opinion to those
comments :-) but I thought that in this way it was easier to exchange
design ideas; the comments can actually be removed.
The reasons I think we could treat Groovy in a special way (but I don't
have a strong opinion on this) are:
* ootb OFBiz will still be packaged with Groovy jars (they are required by
all the existing scripts and by some other code like the implementation of
Groovy service engine and Groovy event handler) and so the dependency
on Groovy will still be there even if we run it with JSR-223
* the code to run Groovy in the special way is now all contained in the
ScriptUtil class and there are actually a few lines of code to maintain
for it
* keeping a custom way for Groovy has two main advantages that are not
currently used but I would like to consider in the short term (and I don't
think they are supported thru JSR-223... but I am not sure):
** security: I would like to restrict the JVM security settings for
dynamic Groovy snippets like ${groovy: ...}; I have some concerns in this
area that I will address in a separate email soon; in this way we will
secure the ootb system (packaged with several groovy scripts and the
groovy jars) but of course if the user will add to it jars files for a new
scripting language (executed using JSR-223) then the security issue will
still be there, but at least the user will know about it
** I would like to inject some OFBiz friendly methods to all Groovy
scripts, so that they can be used by Groovy scripts to run services, use
the delegator etc...
We should also consider the impact on performance, even if the best way to
go is probably to run some performance tests on the system running Groovy
with current code and with the system running Groovy using a custom method
and then compare the results.
Jacopo
-Adrian
On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
My changes are in commit 1296762
Help with reviews and tests will be very much appreciated.
Jacopo
On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
As far as I know, most scripting engines have some sort of embedded
cache. The problem will be that we can't clear the embedded cache like
we can with our own cache implementation. I don't see that as a show
stopper - it's mostly inconvenient.
I can help out with the
