Le 28/04/2015 16:47, Adam Heath a écrit :
On 04/28/2015 03:16 AM, Jacques Le Roux wrote:
Le 24/04/2015 17:01, Adam Heath a écrit :
On 04/24/2015 09:57 AM, Jacopo Cappellato wrote:
On Apr 24, 2015, at 4:36 PM, Adam Heath <[email protected]> wrote:
src/main/java/org/ofbiz/product/
src/main/minilang/org/ofbiz/product/
src/main/groovy/...
src/test/java/org/ofbiz/product/
I haven't yet gotten to integrating a groovy compiler plugin, I see only one
.groovy in framework/service/src, for the entire project.
When I proposed this I was also thinking about to move the groovy (data preparation) scripts that are currently under WEB-INF/actions folders;
most of them could be used in non web applications.
Hmm, right. Good idea. We(Brainfood) would love it if all the action code was turned into services. But, even in that case, src/main/scripts
would be used, as I think src/main/groovy is for groovyc. I'll find out today if that is the case.
So you would like to suppress the concept of event? What about the validation and conversion with the map-processor (only in simple-method) and the
convenience of events in some cases?
https://cwiki.apache.org/confluence/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo#FAQ-Tips-Tricks-Cookbook-HowTo-DifferenceBetweenEventAndService
Way way way too much business logic is embedded and tied to events that *require* javax.servlet. This makes it hard to use ofbiz soley as a backend
api layer.
Not all servlet code can be removed. Aka, the aforementioned parameter validation/conversion logic. However, all such input methods should just
pass the munged data stream(s) to the service engine, for processing. This includes the ShoppingCart code.
Following Hans's initiative in r1163084 I used MockHttpServletRequest/Response in services but I must agree it's more a (interesting) hack than an
architecture solution
Jacques
