Grails and Broadleaf

[craigraw]

Hi,

I know Grails integration has been requested several times in the past month and I'd like to add my voice to that request. Grails is growing as a web framework, but lacks a decent eCommerce integration. I think the similarities in technologies make Broadleafcommerce a natural choice.

As a newcomer here though I would like to ask if the integration is not relatively simple - declare the core module as a dependency in Grails BuildConfig.groovy and wire up the various BL services in spring/resources.groovy. Or alternatively, simply have the Grails app communicate via the API.

Thoughts on the best way to approach this would be appreciated.

Thanks,
Craig

[phillipuniverse]

Agree 100% with most of your points.

The problem is really a matter of priorities for us. Grails shifts up in priority if there was someone willing to sponsor a Grails integration (which is how the original Broadleaf Grails module at http://grails.org/plugin/broadleaf got created). The client that was using that fell by the wayside and the Grails module did as well. If you notice, that Grails module is very very behind both in the version of Broadleaf it was built for as well the version of Grails that it targeted.

The main problem with the Grails integration is the fact that Broadleaf uses JPA and Grails uses Gorm. Broadleaf is doing a bit of trickery with merging some things together that relies on having a JPA provider that proved to be difficult with Gorm. We had it working but were relying on the JPA plugin for Grails: http://grails.org/plugin/gorm-jpa. It looks like that plugin has not been updated in 2 years and I'm not sure if it will work with the latest version of Grails.

As always, you can use the Broadleaf extensible REST services (http://www.broadleafcommerce.com/docs/c ... cepts/rest) and communicate with your Grails instance that way. That obviously does not require anything special on the Grails end; Broadleaf would run as a separate web application.

I know it's not the greatest answer but it's the only real answer we have at this point from a Broadleaf perspective.

[craigraw]

Thanks, that's useful.

Given I try the REST route, I have few further questions:

1. Would I then have 3 applications: admin, api and Grails? Or is it possible for the admin app to run the api as well?
2. In terms of creating beans to populate from the JSON, would you recommend I create my own or import classes from BL? In general, is there any API client code that would be useful importing from BL to help with the communication?
3. Is there a complete list of the API endpoints somewhere, or is there a way to work this out from the code?
4. Are there any limitations I should be aware of with the route (say, perhaps, internationalisation challenges?)

Thanks very much.
Craig

[phillipuniverse]

Thanks, that's useful.

Given I try the REST route, I have few further questions:

1. Would I then have 3 applications: admin, api and Grails? Or is it possible for the admin app to run the api as well?

Yes

2. In terms of creating beans to populate from the JSON, would you recommend I create my own or import classes from BL? In general, is there any API client code that would be useful importing from BL to help with the communication?
3. Is there a complete list of the API endpoints somewhere, or is there a way to work this out from the code?

Docs on both of these are at http://www.broadleafcommerce.com/docs/c ... cepts/rest and children of that menu item on the left. I would start at the classes Broadleaf has and extend them for your purposes (the Wrapper classes)

4. Are there any limitations I should be aware of with the route (say, perhaps, internationalisation challenges?)

Not really. The internationalization parts should be taken care of dynamically whenever you do something like product.getName() or category.getDescription().