We Keep Coding

Why Broadleaf Commerce over Magento or ZenCart?

I have a site made in java-spring-hibernate we made our self from scratch, it shows a catalog of product and i have the logic for it. I can also manage content and product/categories with it with an administrator we have made in flex. We probably shouldn´t have gone to all the trouble since there are so many cms out there, but what's done it's done. The site renders the content managed in flex in html with jstl.
Thing is now i want to add a ecommerce to it, for that we would have to add all the payment,shipment, orders logic to the administrator and the front end (cart/user). How ever, since there are already things like magento store, i was thinking maybe i should switch and leave my beautiful app to die :/. As i was researching i stumbled upon broadleaf commerce which is an ecommerce back end made in flex-spring-hibernate. It´s relatively new and it supposed to have an active development team. So i guess my question is, Why? if there are so many opensource commerce solutions do they make this kind of effort in developing ? i mean you still have to build the GUI for the users side. Whats their difference with magento, what are the pros ? should i try to integrate with broadleaf ? what are the assests oder then keeping my loved old app ?

Let me start off by identifying myself as an employee of Broadleaf Commerce, so I may be somewhat biased. The reason for developing Broadleaf really has everything to do with the platform itself. If you look at the open source e-commerce solutions out there, you are correct in that there are a number of them. However, when you start to filter them by various parameters, including Java, Spring, Hibernate - the list becomes very small. It was always our intent to come up with a compelling e-commerce platform targeted at today's enterprise users. With that theme in mind, we knew we had to go with Java, Spring and Hibernate. This is the core technology stack that is preferred by much of the development community, especially in the enterprise segment. Also, to satisfy the complex domain and integration requirements of these users, we designed the system from the ground up with extensibility in mind. We think of extensibility as a natural extension of the Object Oriented programming techniques you already practice daily. This translates into leveraging the power of Hibernate extension and polymorphism for the domain, as well as the ability to override, tweak or completely replace every service, DAO and entity in the codebase. Our configuration is also extensible, and goes beyond standard Spring application context override to provide more configuration merge capabilities that allow us to pull away some of the additional Broadleaf configuration complexity so you can focus on the configuration that matters for your app. So while the end results may be similar between our software and others, we believe the decision on what path to take to achieve that end goal is an important one and Broadleaf Commerce offers a powerful and flexible way to get there.
I feel I should also briefly mention, since you mention Flex above, that we are currently in development of our 1.5 release, which includes a re-worked administrative application based on GWT that will replace our current Flex-based admin. This choice has allowed us to propagate the same theme of extensibility that we already embrace in the core platform to our administrative platform. The new admin will offer the same flexibility for override and replacement through Object Oriented programming paradigms that developers already enjoy in the core platform. In addition, the admin application automatically recognizes your entity extensions and includes your additional fields in the admin interface without any coding effort on your behalf. The admin interface also honors entity polymorphism and will adjust the editing interface according to each type (think of a media product that has two extensions in the form of book and movie - even though they are both media entities, they each have unique fields and the admin interface honors this distinction). We're also working on changesets and some other interesting features for 1.5. We're targeting milestone releases beginning around April, so stay tuned for more.

What Spring and Hibernate are missing is a proper datamodel and erp application so everybody starts building their own.
We are all building together on the same application and framework.
That is just OFBiz: framework and a proper datamodel and application. You know the best part? It is not controlled by a single company but by the biggest open source foundation in the world: The Apache foundation sponsored by all large IT companies.
Anybody starting his own implementation of either erp of ecommerce should really reconsider.
More info on Apache ofbiz?
http://www.ofbiz.info
http://ofbiz.apache.org
Regards,
Hans

There is one Java Connector for Magento's API called as Magja.
Note: No support after 2012!

WordPress, CMS Made Simple or other?

I'm a Java/.NET developer but on my spare time I've started looking into WordPress (for personal projects). I'm not as good in PHP as I am in Java or C# but I manage. With that said, I accept tips from either language (since it's personal projects I prefer to go open source cause it's free).
What I'm trying to do is creating a small multi-language business web site with standard pages (home, about us, contact us and so on), news, a simple web shop (just listing the products is good enough in the beginning) and a photo gallery.
What I like about WordPress is that it's very flexible with custom post types and so on (since I'm gonna need news entries, products and different content types on the same site). A set back is the admin interface for a "client" with minor computer knowledge, they have to "Create a Post" with post type product instead of the menu saying "Create Product" or "Create News Entry".
So basically my needs are:
Standard Pages (Start page, contact form page and so on)
Multi-Language (In both content and pages)
Web Shop (Really simple one)
Photo Gallery (Simple as well)
News
"Company Admin" (A user that can only access publishing stuff. Create news, pages and so on. Not install plugins or manage layout)
Simplify Admin GUI ("Create Product" instead of "Create Post" with product as post type)
The question is: What CMS should I use?
Hope I made it clear enough what I'm trying to achieve!
Any input is welcome! Thanks in advance!

I've had good results with both Silverstripe and Concrete 5. They both have user management and an interface that can be used by novice users. What's more, they are both built upon a custom MVC framework and expect customization to be done by a programmer rather than in the CMS itself. This way, the interface contains less distracting configuration stuff.
If this doesn't work for you, there's always Drupal, which is very customizable and specialized in custom page types as well.
Good luck!

I just read that you chose for Silverstripe. I'd love to hear about your experiences with it as I myself have never tried that one.
However, I too would have recommended CMS made Simple™ if I had seen your post sooner. I have made dozens of sites with it. Compared to some of its brothers and sisters the admin interface is very intuitive and easy to manage. I usually even say "heaven for the digital illiterate end customer".
However, for the person who builds a site powered by CMSMS it's a must to know his/her way around (x)html and css. The same goes for basic knowledge of installing databases and permissions on folders.
The system is basically intended for designers and developers with a professional background and does not provide you with hundreds of ready made templates. It's up to you to make them yourself if you want to create something original. However, if one has the upper mentioned knowledge, freedom is at hand. No restrictions in layout :-)
Last note: if you want to do a multilingual site in CMSMS, I recommend you look here: http://www.i-do-this.com/blog/25/Another-method-of-Multilingual-CMSMS-Page. This method gives you extreme control over SEO and the URL structure. I point you to this as some time ago the MLE fork takien was telling about in his post has been proclaimed unsupported by the core dev team. The reason for this is that they cannot guarantee breakdown on updates to newer versions as it is actually a third party fork of CMSMS. The developer (Alberto Benati) who made the fork has moved the project to his own site.

Modern CMSs with the addition of their plugins and extensions are more or less doing what you need. I've used Joomla before to build up sites with most of your requirements with minimal effort. I also have a Java background and I've found Liferay, which is written in Java, very interesting. At this stage it's a mature product with extensive user/group customization and Portal development in the form of portlets.
Concerning Joomla addressing your requirements:
Joomfish for multilanguage support
Home page treated specially, contact and form pages in the form of modules
VirtueMart for shopping cart
Lots of photo galleries to choose from in the form of extensions
I think built-in News functionality as module (not sure) but as well lots of extensions
"Company Admin" as you describe can be a lower privileged users.For Joomla Admin separation have a look here
Not sure what you mean by simplify Admin GUI. A user with lower privileges will have fewer settings in the site after they login.

Please don't use Joomla! I've been using it for years and it gets the job of putting together simple sites done quite well, but if you want to change any of the aspects about how your site works, it stops being simple to use. You will end up hacking PHP files to achieve things that are possibly very easy in other CMSses.
I had very good experiences with Drupal, where you can define your own Classes of "posts", so, for example, "Products", which will have special fields that are only associated to products. Joomla will never be able to do that!
Apart from that, Silverstripe is a good CMS that's very easy to handle. Wordpress might not get you far as I'm concerned with building shops, but I haven't looked into it.

for your needs, I would like to recommend yo to choose CMS Made Simple (CMSMS) rather than Wordpress. CMSMS has multi language feature (choose multilanguage package) which is very easy to setup and manage.Don't worry about customization, CMSMS is easy to use, nice admin page, easy to make your own themes.
I'm not disfigure Wordpress, but since peoples not good in PHP, their site would be just another Wordpress blog. :D

There has been a new module added to CMSMS that makes multi lingual setup much smoother. More information can be found at this very useful blog:
http://blog.arvixe.com/creating-a-multilingual-cmsms-site-using-mlecms-module/

For the gallery for wordpress, the best solution in my opinion is to use an outside gallery, hosted on Picasa or Flickr for instance, and a simple plugin (you have a few to choose from) for that platform.
For translation, all the plugins I haved tried are very easy to break with other plugins or with WP upgrades if the plugin is not upgraded with it. For just two languages, I would just use a category based language organization. Not a perfect solution, and you will need to tweak the templates a bit, but it have worked for me.
Having said that, I would probably prefer to use Joomla if this were a project for myself, you would only miss the simplicity of Wordpress for plugin or template modifications (or even creation from scratch). And Joomfish is much better than any language support in WP as far as I can tell. And the same goes for VirtueMart, which is simple, easy to install, easy to use and have been there for years (= lots of modules, support, documentation, etc).

How do I decide between a using a Swing GUI or a light-weight web client for the user front end of my Java application?

I always seem to have this internal struggle when it comes to user interface. I build up an application "engine" and tend to defer user interface to after I get my algorithms working. Then I go back and forth trying to decide how to let a user interact with my program. Personally, I'm a fan of the command line, but I can't expect that of my users generally.
I really like what's possible in the browser in the age of web 2.0 and ajax. On the other hand it's not so hard to make a Swing front-end either, and you can generally count on a more consistent presentation to the user (though using a good javascript framework like YUI or jQuery goes a long way toward normalizing browsers).
Clearly both approaches have their merits and drawbacks. So, what criteria / parameters / situations should lead me to use a lightweight (e.g. web-based) GUI? What criteria / parameters / situations should lead me to use a heavier (e.g. Swing-based) GUI?
It is not my intent to start a flame war, merely interested in the community's constructive/objective opinions.
Edit #1
In light of the first few responses, I would like to clarify that I would like to deploy my application regardless, not host it on some internet server necessarily. So I would have to deploy with a light-weight web-server infrastructure a la Jetty/Tomcat or similar.

It depends on the application and this is essentially a usability driven question (though there are considerations like data storage and platform requirements). Think of the pros and cons.
Pros of a lightweight Web UI:
Ease of distribution
Platform independent
Ease of maintenance
Cons of a lightweight Web UI:
Less environmental control
Markup standards vary between browsers
Requires a web server and everything that goes with it
Pros of an executable UI
More environmental control (i.e.: full screen applications, etc)
Not necessarily subject to latency and outages
Cons of an executable UI
Pushing updates may be more difficult
Requires installation
Potential platform requirements (frameworks, packages, etc)
Potentially requires knowledge of advanced networking topics (web services, etc)

One small factor you may want to consider is that the user will have go through some type of installation (albeit minimal) if you distribute a swing application.
Also a web application will allow you to accurately track the usage of your application (via google analytics or something similar). Not sure if that's a concern but it may be useful to you in the future.

If it is a client-server application I would normally go for a web frontend for the application.
You will save yourself of countless problems with things like installed JRE versions, distributing upgrades, application permissions, disappeared shortcuts...

You need to break the requirements of the application down to decide this...
Do the users have Java of sufficient version installed? It will need to be, to run a Swing GUI.
Do you have a web server?
Do you need the flexibility of a Swing GUI or the accessibility of the web interface?
Is Java Webstart and option, if so, you can distribute a Swing GUI via the web.
Does your application perform extensive calculations or processing? If so, a client app may be the answer.
There are a million questions such as these. I would suggest a brain storming session and keeping track of all the pros and cons of each, adding a point score, than throwing it all away and going with your gut feeling :)

If you anticipate there being frequent updates to the app then web based may be better since the user would not have to update the client or install a new client containing the updates.
If you think that the user may need the ability to use the app while not conencted to the internet then swing would be better.
Just two things off the top of my head.

Think about the users and use cases of your project.
Do users expect to have access to it when they're disconnected from the Internet (for example, on an airplane or in a coffee shop with no Internet access)? Use Swing.
Do you want users to be able to access the same tool from different computers (for example, both at work and at home)? Use a web UI.
Also consider whether the user needs to save and load data, and whether the tool produces data files that some might consider sensitive (if so, storage on the web might be an issue).

Do make a quick guess I often try to ask myself/customers if the application has a high "write" demand.
For a mostly read-only application a thin-client solution is perfectly well suited.
But if a lot write actions are needed then a swing desktop application has more flexibility.
Personally I always prever a swing desktop application. It can easily deployed using Java Webstart.

Not knowing anything about your application I can not give the best recommendation possible. However I can state from personal/professional experience that installing an application on clients machines is a LOT more of a pain in the ass than it seems.
With AJAX/web you really only have to worry about supporting like three browsers. Installation messes/updates are only felt once when you deploy the product to the web server.
With like a stand-along Swing app, you get to deal with the really really big mess that is installing the application onto unknown systems. This mess was so bad that things like AJAX were really pushed along to make web apps behave/feel like a real native app.

How is using portlets any better than just using server side includes?

The idea behind portlets is that a website/page can be comprised of a number of applications that are developed individually. They are then fit together on a page by a portal much like a jig-saw puzzle. This allows functionality to be created independently and slotted together at a later date. This has many obvious benefits.
However. I cannot see how the portlet specification improves upon older ideas like server-side includes, from the point of view of a developer who needs to get something done, as opposed to publish a paper or make a keynote address.
The tone might be a bit negative, but my first foray into the world of portlets has left me thoroughly disenchanted.

From the point of view of the job of just 'including' some dynamic/static content on a web page, you're correct.
However there are a number of conveniences implemented, such as support for personalisation of the portlet (at the portlet/'include' level) and storing this info, a more rigid workflow for configuring what is displayed in the portlet and so on.
Plus obviously there's all the portlet arrangement code that you would have to write otherwise. Some portlet servers do a lot on the client side for arrangement (drag and drop of portlets etc).
You may find some of the discussion at the below URL helpful:
http://www.ibm.com/developerworks/ibm/library/i-portletintro/

For sure, the portals create the view essentially by doing lots of server side includes.
The portlet specs (JSR-168, 286) just define how to code a portlet so it fits into a portal. They only define things necesary for portlets to co-exist on the same portal page, things that are not a part of J2EE servlet or JSP definitions.
Without the specs, it would be hardly possible to use portlets from different development teams, or even different vendors on a single portal page.
Even a single J2EE application with a portal-styled UI can benefit from use of a portlet container - it can help to accomplish many typical UI-related tasks.
Consider e.g. these features defined by portal specs (just a very few):
Portlet lifecycle, isolated from other portlets.
Isolated URL spaces for each portlet
Portlet modes and window states
Portlet session scropes
Personalization, portlet preferences. Users configure apperance of their's portal pages by positioning and setting individual portlets.
Raising / comsuming of events (JSR-286)
...
The specs are not a rocket science, and also they do not pose a paradigm in UI design or so - to me, the most revolutionary about portals was the idea of a user's desktop brought into web applications.

Pros and cons of Java Portlets?

I have a project in which my client is asking me to use portlets 1.0 spec and Websphere Portal Server 6.0. I haven't worked with portlets before but what I've heard of them always have been bad critiques. What are the reasons besides the obvious of using them? If not reasons, what arguments could I use to avoid them?

As someone who has had several jobs (including my current one) developing Java portlets, I'd say don't use them.
Here's the problem:
If you just wanted to use the pre-existing functionality of the portal you are choosing, then use a portal.
If your use of portlets is just to construct a small, light, primarily read-only web-based dashboard where you can quickly look at disparate information, then that's fine.
But if you (or more likely someone higher up on the org chart) thinks of portlets as a way to put a bunch of different web apps on a page and have it all "just work", then you are headed for a world of hurt. Portlets are highly-restricted, self-contained islands of functionality, not web apps in tiny squares on a page.
Every one of my portlet-based jobs has made this mistake, and there's no light at the end of the tunnel. As a portlet developer, here's a small list of things you're used to doing in regular web apps, that you can't reliably do in portlets:
Generate URLs to other pages. You'll need a vendor-specific way to do that, since the Portlet API only allows you to generate URLs that target the portlet that generated them.
Read and set HTTP headers or set the HTTP response code (so no redirects or HTTP caching, since you don't own the page your portlet will be placed on)
Having to namespace all identifiers in the generated page. This means HTML id attributes and JavaScript function names. Since the namespace has to be determined at runtime to ensure uniqueness, you can't have these Javascript functions reside in a separate browser-cachable file they have to be in the response body for your portlet.
Portlets feel as if they were designed for the state of web development as it was in the mid to late 90s (pre-AJAX). But they are ill-suited for today's web development environments (AJAX, single-page rich web apps, etc.) that assume you have complete control of the request/response cycle.

The problems I have with portlets remind me of the same problems as EJBs-
portlets require you to write special code that can only be hosted and run in a special server;
every portlet server vendor has custom extensions/configurations/additional abilities so it's not trivial to change server vendors;
portlets seem to be overly complex to cover functionality that 90% of people wanting to use it don't need
I'd suggest something like Google Gadgets as the Hibernate to portlet's EJB -
Javascript framework - server-side pieces can be written in any language, hosted on any server.
simpler to use
lots of portal servers support it, and it's more portable across vendors because it's not as complex, and it's not a spec for vendors to implement (and extend)

Portlets are attractive to a business because of the promise of flexibility, you an allow customers to tweak and rearrange components on the page, and if you are primarily serving content then they are an effective means of doing that.
In my opinion portals are well suited to aggregating portlets that are either pure content, functionally independent or simply related (e.g when you pick an item from a list in one portlet, you update another to show the details).
Portlets can also enable reuse, because you can configure them into multiple pages/locations fairly simply.
Where the problems can start is when you are trying to decompose complex business functions with multiple steps and interactions. In this scenario determining the granularity of the portlets is more of an art than a science, and careful consideration needs to be given to the interactions between the portlets.
You also need to consider the flexibility of the UI. If you have a set of portlet building blocks your business need to be clear that they can rearrange those blocks, but moving items between portlets involves a rewrite. For example moving the submit button from one portlet to the bottom of the page is not trivial.
So in summary, I guess it depends on what you are trying to do and how much reuse you anticipate of the components. It may be simpler to manage the reuse by creating technical components that IT build into servlets, or it may be that portlets are perfect for your business. There's no right answer, you just need to carefully consider what you are trying to achieve. If you do decide on portlets, you need to embrace the full lifecycle, and avoid any temptation to work around them, you can quickly find yourself in a bad place with all the overheads and restrictions of portlets, without being able to realise the advantages.