Will, I hear you :-) For a quick-and-dirty e-Shop I am using the Mg/KK module provided by Headwire. I customized a couple of things (e.g. created a paragraph to provide CMS authored texts in the 4 available languages). So far so good. But for a "professional" full-customed e-Shop it will be cumbersome to adapt and maintain.
While FreeMarker is interesting, it's no option for me (too many tweaks, e.g. image processing). For most standard solutions however, FreeMarker may be interesting. The beauty of a JCR based shop-backend is the hierarchical content structure. This allows to modularize basically any shop process (e.g. create a payment module, a cart module). If we bind the content to the API we can make the logic fully modular, and independent of any e-Shop business process. For example: I can build my own checkout process based on the API. In fact, I could even use OpenWFE to "send the order to the ware house and package/ship the order". And yes, you are right: The e-Shop module will need to come with some prepared admin pages, which of course can be customized. Agreed, it's a vision, but I have architected most of it. But then I will need to build the whole thing and that's another story.... /giancarlo On Feb 21, 2011, at 8:03 AM, Will Scheidegger wrote: Giancarlo Solution 4 sounds very interesting of course... and it would be great if we could combine this with Solution 3 - the magnolia shop module. It was my plan to separate the shop business logic from the front end, but putting it in a completely separate JCR app would be nice of course too. However: The "business logic" of an e-shop is not rocket science. Of course once you add a complex cross-selling algorithm, coupons or automatic shipping cost calculator based on weight, size and destination then it might get a bit complex. The biggest task IMO is a good, easy to use GUI for the admin... and we're quite far from that yet with the magnolia shop module. -will On 21.02.2011, at 16:50, Giancarlo F. Berner wrote: > Hi Andrea > > Here are my 2cts: > In general: The available shops are all based on RDBMS and built the > "classic" way. Usually the front-end is based on the shop's framework and > quite tricky to customize. Honestly, I am quite surprised that today's > e-Shops don't "go CMS"... > > - Solution 1: If you want a quick-and-dirty e-Shop, this works fine. > Customization is a little tricky in the beginning, but once you understand > that the KK paragraph references a JSP in /WEB-INF, you can adapt these JSPs > to fit your design. But if you want full customized multi-shop solution you > will byte dust (e.g. I had to write a text/image paragraph with a control for > each language) > - Solution 2: If you know you will need e-Shops in the future I would look > into building some WSDL type interface (e.g. using SOAP). There is a > "OpenCMS" module you might want to study. Since you will put a lot of effort > in the interfacing of both, the KK and MG world, you will have to invest > quite some time. The result is though a very flexible solution. Another > option is to communicate with KK via RMI. Any way, I don't like the idea of > having to interact to a proprietary system this way. > - Solution 3: My personal favorite. While the approach of using the > underlying JCR to store the data is hype, the solution per se is still under > construction. A first version is available. If that works, give it a try! > > Solution 4: My favorite solution is to build a JCR based e-Shop backend, > providing an API to build the front-end. The idea is that you can integrate a > JAR either via OSGi or simply drop it into any APP server and it you can > build Mg paragraphs using the API. The solution will be available for any JCR > based systems (e.g Mg, Day Communique, etc.). HOWEVER: While I am almost done > with the architecture, development/testing did not start yet, so it will NOT > BE AVAILABLE until around end of year. > > To summarize: Be prepared to get your hands dirty! > > /giancarlo > > On Feb 21, 2011, at 7:06 AM, Andrea Castelli wrote: > > Hi everybody. > I'm evaluating different solutions to build a shop online on Magnolia. > I analyzed the following: > Konakart + konakart-module (by Headwire) > Konakart API and integration made by myself. > Magnolia Shop Module. > I would like to choice solutions 1 or 3 because seems that I should work > less. <35C.png> > > But: > Solution 1 is built upon Struts and the preferred MVC of Magnolia is Spring. > (I don't like to spend my time in a framework that is not on the main road) > The code seems to be not a very multisite by default. A change to the basic > Magnolia chain filter is required (I don't like to change the default > behaviour of Magnolia). What do you think about it? But it is the only one > ready to start.(This is a great value). > Solution 2 is based on the API of Konakart. Anyone has experience on it? Any > advice? > Solution 3 stores very complex data on JCR, I need a flexible solution so I > don't investigate further and I don't know the state of the art. > Did I miss something? > Can you help me in this market evaluation? > > Thank you. > Best regards. > Andrea > > > > ---------------------------------------------------------------- > For list details see > http://www.magnolia-cms.com/home/community/mailing-lists.html > To unsubscribe, E-mail to: <[email protected]> > ---------------------------------------------------------------- ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ---------------------------------------------------------------- ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
