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
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
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
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
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
[
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
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
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
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
[
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
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
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
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
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
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
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.
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
+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
[
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
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
Why are the service engine tests in the common component? Shouldn't they
be in the service component?
-Adrian
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
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
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,
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
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
[
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
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.
[
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
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,
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
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...
32 matches
Mail list logo
