David Legg wrote:
Hi Raj,
...what exactly you mean by clearly separate store front? To me it
looks clearly separate as you can create your own web application and
have your e-commerce store front as you want without keeping any
thing from the default technologies.
I don't wish to hijack DeAngelo's thread but... like him, I have my
own preferred web framework (Cocoon) into which I would like to bolt
on an estore. However, I'd rather not end up with a Frankenstein
monster with a big bolt holding it all together! I'm taking great
pains to ensure that the look and feel of the site is managed in one
place. If I bolt OfBiz on the side I will have to keep two sets of
templates in sync with each other.
To me the ideal solution would be to have a library of POJOs that
implement a storefront and a shopping basket API and use spring
configuration to establish settings like where the database is. Then
I could incorporate those beans in a JSP page or a Cocoon pipeline or
a Struts app as appropriate. I think it is the distributed nature of
the configuration which is a stumbling block at the moment.
If you want to run your application within the OFBiz container , you can
have a look at various event handlers configured in the e-commerce
controller.xml. There are event handlers for Java, SOAP etc. Thought I
have not tried, you can write your own event handler to handle the
Cocoon request pipeline. However, please note that this will need you to
write all the logic you find out of the box in the ecommerce component.
If your application runs in another container/server and it is Java, RMI
is the way to go. You can still use the service framework and reuse most
of the services of OFBiz. My suggestion is to create facade RMI services
instead of modifying the exiting one.
Thanks,
Raj
