[
https://issues.apache.org/jira/browse/OFBIZ-4724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
K Sharad Bhushan updated OFBIZ-4724:
Attachment: ecommerce-shopping-cart-script.patch
Attaching patch now..
Shopping Cart - One Page Checkout - not continuing
--
Key: OFBIZ-4724
URL: https://issues.apache.org/jira/browse/OFBIZ-4724
Project: OFBiz
Issue Type: Bug
Components:
Shark should soon no longer be a problem as we we want to put it aside from the
trunk repositories
Jacques
From: Anne a...@cohsoft.com.au
Thanks Adrian. Have provided a patch for this as
https://issues.apache.org/jira/browse/OFBIZ-4723
While working on this, I noticed
I don't currently use minilang because of the restrictions of the project I'm
working on. But I'm also a fan. It's so much easier as
long as you don't get into too much complicated things. And contrary as it's
often said, not that hard to learn.
Brainstorming later...
Jacques
From: Jacopo
I don't understand what you mean by supporting a limited number of
types. Currently, mini-lang supports any type - thanks to the conversion
framework.
I like the idea of changing the from-field attribute to from. I would
like to see a from-script attribute added:
set field=field4
Update: I added a generic ScriptEngine to the service engine in rev 1297323.
I haven't updated screen widgets and mini-lang to use JSR-223 because
there is a compatibility problem. In JSR-223, the context binding is
reserved for the ScriptContext object, so any script code that uses the
On Mar 6, 2012, at 9:32 AM, Adrian Crum wrote:
I don't understand what you mean by supporting a limited number of types.
Currently, mini-lang supports any type - thanks to the conversion framework.
The conversion framework is fine; I was thinking that we could implicitly (by
default) treat
I would be in favor of bulk renaming all the context variables in our
scripts... maybe we could wait after the creation of the 12.04 release
branch... but I would be in favor even if we do this earlier.
Jacopo
On Mar 6, 2012, at 9:47 AM, Adrian Crum wrote:
Update: I added a generic
Replacing FSE with Groovy is a bad idea. Adam and I optimized FSE so
that it is very lightweight and fast. I also optimized the UEL
integration so there is very little overhead in the evaluation process.
Switching everything to Groovy will slow things down and increase memory
usage. Also keep
I'm a mini-lang supporter too :)
At the begin I used java code generation for service but with the time I
found mini-lang more effective and simple to maintain.
On mini-lang review, I propose to unify attribute name that have same
purpose.
ex : set field=field1 ...
while
entity-and
I was thinking of using _context. I know we try to stay away from
leading underscores as a general practice, but in this case I thought it
would make the replacement (and learning curve) easier.
-Adrian
On 3/6/2012 8:57 AM, Jacopo Cappellato wrote:
I would be in favor of bulk renaming all
On Mar 6, 2012, at 10:03 AM, Adrian Crum wrote:
Replacing FSE with Groovy is a bad idea. Adam and I optimized FSE so that it
is very lightweight and fast. I also optimized the UEL integration so there
is very little overhead in the evaluation process. Switching everything to
Groovy will
set field=field4 from=parameters.inputField1 + 10/ !-- use Minilang
built-in and efficient support: not currently supported but maybe something to consider in the future --
The from attribute contains a UEL expression, so it is currently supported.
-Adrian
On 3/6/2012 9:33 AM, Jacopo
The EntityConditionBuilder class I wrote a while back is a good example of a
groovy specific utility class, it takes advantage of groovy's language syntax
features and couldn't be used in any other scripting language (well, not in the
intended manner anyway).
A possible solution could be to
Hi Chatree, i reverted the patch, the redirect should work again.
Thanks
Regards,
Sascha
2012/3/6 Chatree Srichart chatree.srich...@gmail.com:
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,
[
https://issues.apache.org/jira/browse/OFBIZ-2628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sascha Rodekamp reopened OFBIZ-2628:
The patch breaks the http -- https redirect. Which could be seen when using
the ecommerce
The EntityConditionBuilder class is a good example of how we can make
scripting more convenient.
Different scripting languages will have varying support for Java
classes. It was my hope that we could come up with a Java-based script
helper class that can be used by a variety of scripting
I'm not sure I follow what you're saying. I'm sure a java based script helper
class in the context could be useful but I don't think it should preclude the
ability to include classes in the context that assist with language specific
features.
I don't really see how giving users the ability
Fair enough. Users of other scripting languages can adapt the code to
suit their language.
-Adrian
On 3/6/2012 11:49 PM, Scott Gray wrote:
I'm not sure I follow what you're saying. I'm sure a java based script helper
class in the context could be useful but I don't think it should preclude
Yes, I agree with the general strategy: OFBiz will be (or it is) flexible and
ready to be used with alternative tools; our effort as a community will be that
of opening it up and slimming it down instead of trying to include all the
possible alternative tools in our package; and the work that
20 matches
Mail list logo
