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!

Seam with JSF v. Seam with GWT

Would anyone be able to compare and contrast the two solutions? I don't know much about Seam or JSF, though I am familiar with the way GWT works and very much like the theory of it.
Primary concerns:
Scalability / performance
Cross-browser compatibility
Learning curve
Productivity
WYSIWYG UI building
Capacity to code as much as possible in Java (I can touch JS/HTML/CSS if possible, but preferably not)

Concerning the server-side implementation of your app you have to take the following point into account (pro/con is subjective, so you should decide) when using GWT instead of JSF.
As mention by #z00bs, using GWT you'll have a desktop like app. So you won't use/need page-navigation or page-action feature of Seam.
All requests from GWT to the server are short-running. That means, most of your components will be of ScopeType.EVENT or ScopeType.STATELESS and you don't need/use the conversation scope.
Using GWT instead of JSF reduces the load on the server because you hold most of the state in the client.
You cannot use the JSF/Seam-lifecycle with GWT. For instance, you lose the model validation part in the lifecycle. Model validation will only be triggered by using the entity manager or manually
All other feature, such as security, mailing, or EL, are still working when using Seam with GWT.
Since Seam is well-known for its JSF support, you should consider another framework, such as Spring roo which is strongly related to GWT, too.

Concerning the client-side development of your app we had the same decision to make.
We decided to go for GWT for the following reasons:
Most of the development can be done in java. Since we have a strong background in java development this will save us a lot of time.
We could use all the well known and beloved tools for implementing since all is done in java.
Our app was going to be a desktop like, single page web application without complete page refreshes. At this point GWT seemed to fit best for that need (and it still does).
Pushing most of the state to the client and let him do most of the time consuming processing appealed to us. This way the server can handle lots of simultaneous request and connections to the server are only needed to sync the state on the client.
The support for Unit Testing GWT code is good, in conjunction with the MVP pattern even better.
Since the introduction of UiBinder creating and styling complex UIs has gotten a lot easier and faster.
To your main concerns:
Cross-browser compatibility is mainly taken care of by GWT itself.
WYSIWYG is possible with GWT Designer (I must say I've never used it; I like building the UI myself...)
GWT is really fast because the rendering is all done on the client-side.
Productivity is high when you're used to java.
The learning curve depends mainly on the architecture you use (MVP is complex at first).
Your application will scale since the server is freed of much costly processing.
Hope that helps.
(Some considerations concerning the choice of Seam are coming soon from #kraftan).

The conversation scope offered by Seam can readily be replaced in GWT by storing long lasting transactions (like shopping carts) in memory on the client side.

Neither! dont use seam (or jsf for that matter) if you absolutely dont have to! There are so many better web techs on java.

Echo3 Framework

What are the pros and cons of echo3 framework compared to other java web frameworks?

Echo3 is still under development. Echo2 is stable (but old). The main "pro" is that you don't write javascript or html, you write Java GUI code. The main "con" is that it has not been widely adopted. I've used Echo2 5 years ago and it was a nice framework, but the development of Echo3 is slow (thought it has not stopped).
Perhaps it is worth taking a look at other similar frameworks like GWT or Vaadin.
These (Echo, GWT, Vaadin) differ from traditional frameworks (like spring mvc, struts, wicket) in the fact that you don't write HTML, css and javascript. That's why they are more suitable for highly-interactive web-applications that would resemble a desktop application. If you, for example, need to have bookmarkable URLs, want to rely on browser navigation and such browser-intrinsic things, don't go for Echo/GWT/Vaadin (although they do provide some support for these things)

I went to the Echo3 website and found an argument that discouraged me from testing it. It seems that it is a dead project:
the current version of Echo3 is 3.0.beta8, released August 6, 2009
Technically, I don't know...

Recently the final 3.0.1 version has been released. A 3.1 version (with WebSocket integration etc.) is just around the corner.
The original creator/maintainer has all but dissapeared, but there are considerable community efforts in reviving the project (and make it less dependent on a single (albeit very gifted) person).

Old question, but some people may still ask it...
I've been working with Echo3 for some time now, and the biggest problems are indeed that is is not widely adopted, as already mentioned and that the development progresses very slow.
When choosing a framework, you normally limit yourself to it's technologies, and Echo3 simply lacks a few things that I always missed in my projects. For example, the Echo3 table component offers no scrolling, no pagination and no sorting. And a table is one of the most important a components a framework can offer (Echolot has a nice table component, but it only supports text values and currently has no sorting).
So have a good look at the Echo3 showcase at http://demo.nextapp.com/echo3csjs/ and at the widget libraries at http://echo.nextapp.com/site/echo3/addons and see if that is enough for you.
Also, it changes the way you can design and layout your applications. Echo3 gives you the usual desktop components, like rows, columns, grids and panels. However, it doesn't offer layout manager concepts like Swing does and also does not have any CSS support. When having to follow exact design rules which involve exact positionings and behaviours of components you might have trouble doing this with Echo3.

recommendation for choosing a new web development stack

I work in a medium to small team ( 10 people ) developing and supporting several web enterprise applications.
We have a dozen of them built with a house-made framework with asp-classic working against ms-sql server.
We are evaluating the migration to a new development stack.
We'd like it to be open (free) and simple.
I've been looking around the java web frameworks, but all of them seem to be extremely overbloated for our needs (with the possible exception of http://www.playframework.org/, which I couldn't study yet...)
We are thinking about porting our own framework to this new stack, rather than adopting a whole new stack that we are unaware of ...
so far now, we though about the following possibilities
plain java - jsp - jsf
groovy - gsp (no grails at all)
jruby (no rails at all)
we feel really comfortable working with dynamic languages (well, as dynamic as classic asp can be) and with a lean and understandable framework...
I see no small and simple web frameworks for java, like there are for php or ruby...
I really like groovy, but I see no web implementations outside of grails... Besides the language documentation doesn't seem to be quite complete (I might be looking in the wrong place, perhaps)
php could be an option, but I think it would be hard to advocate for it in my current work...
any other option, advice, pros and cons?
thanks a lot
--
edit
some related link Can anyone recommend a simple Java web-app framework?

I'd suggest you take another look at Grails. It does use hibernate and spring under the covers, but for most situations, you don't need to know the details of those frameworks. There's a large community and lots of documentation/blogs/mailing lists for support, as well as a thriving plugin community with over 300 plugins solving pretty much any need.
If you're still put off by grails, you could look into the play framework. I don't have any experience with it, but there has been some traffic recently around it on hacker news and the like. I know it uses groovy for the templating language.

I cannot recommend anything, but strongly recommend that you consider these things:
Rapid development. Basically you want to save a page file, and reload it in the browser. Instantly! It can be done, do not settle for long deployment times.
Plain, readable text files!
Convention coding instead of explicit coding - big XML files will eventually drive one or more developers insane. The less, the better.
Good tool support (just having syntax coloring may be a big help)
Consider the long term support of your choice. You are basically remarrying with your software - will it still be maintained in 10 years? By whom? Will you have alternatives (JSR's are great - look at the amount of servlet engines)?
And WHEN you choose - get the source code for it, and ensure that it builds correctly. It will never be easier than now, and some day you WILL need to fix something inside. On short notice! (You may even consider allocating resources for donating documentation/patches/time to the open source project you are building your business on).
EDIT: A few more things:
You want to be able to verify things at compile time. One of the things that make it possible to build cathedrals in Java is that the static typechecking prevents a lot of nasty runtime errors. "Oh, THAT method? Well, it's not here, sorry. Boom!"
You want good error reporting. Built in! Try throwing a NullPointerException deep, deep down and see what 1) the user and 2) the developer is told about it. Anything that requires going to a log file to get the details WILL cause calls at 3 AM eventually.
Look into scalability from the start. Any non-trivial customer will need to and the world goes to multicores, so you might as well think about it already now. What will you do when all the magic pixie performance dust has been used and it just isn't enough: The application requires more than a single box.
And read this: http://www.pragprog.com/titles/mnee/release-it

You're forgetting about the other major player in this field: the LAMP stack (linux, Apache, MySQL and mod_perl). All components are free, there are many books available on LAMP development and each of these components, and there are vast numbers of libraries and components already available.
Apache: the Definitive Guide
Learning Perl: by SO's brian d foy
Practical mod_perl

If you are afraid of Grails and need Java, try Stripes and read the excellent Stripes book (http://www.stripesbook.com/blog/). You can buy the eBook pdf for $23. The book covers the framework in amazing detail. Stripes is a very strong, lightweight MVC framework that deals with all the common problems of web development (templates, url mapping, form validation, security, internationalization, testing) but it won't automagically create the database layer for you unless you want it to by using Stripernate. You can also use Groovy with it. You can use it standalone or with Spring.

I've had great success in simple web projects using Spring MVC with JSTL JSPs. Spring MVC is a framework that can be kept pretty darn simple (1 additional XML file used for configuration). You can eschew all the fancy options and just specify a set of JSPs that you want to associate with view names, then forward to those views by specifying their names in the controller.
Spring MVC can also easily scale up and be as complex as you need, letting you switch from JSTL to JSTL with Tiles, or Struts, or JSF, or Wicket. It can also handle complex web flows using the Spring Web Flow project. But for most projects I just keep it simple -- build a JSTL JSP, create a controller that provides the objects that JSP needs, and associate them by having the controller return that view. Once you get the project set up and you're familiar with the configuration, it takes maybe a couple minutes to wire a new page into place.

If you like Groovy but don't like Grails you could try Gaelyk, which is a lightweight Groovy framework. However, AFAIK you can only use Gaelyk if you're hosting the app on the Google App Engine
If your apps won't be hosted on GAE, and you really don't want to use Grails, another option is to use Groovlets, Groovy template servlet, GSPs.
However, personally I think it's a big mistake to dismiss Grails. It really is a great framework, and you can go a long way without knowing much about Spring and Hibernate. One of your complaints is a lack of Grails documentation. I think you must have been looking in the wrong place, because in addition to all the books available, there's a very extensive reference document and a lot of other documentation available on the website. Finally, there's a very active mailing list.

My platform of choice is JRuby - Rails (3) because of its very rich and powerful ecosystem, but mainly because:
* very easy to use
* many MANY libraries
* fast support via IRC
* deep documentation
You can also check out Scala + Lift Web Framework ( imho best static typed language, nice framework )

Difference between Apache Tapestry and Apache Wicket

Apache Wicket ( http://wicket.apache.org/ ) and Apache Tapestry ( http://wicket.apache.org/ ) are both component oriented web frameworks - contrary to action based frameworks like Stripes - by the Apache Foundation. Both allow you to build your application from components in Java. They both look very similar to me.
What are the differences between those two frameworks? Has someone experience in both? Specifically:
How is their performance, how much can state handling be customized, can they be used stateless?
What is the difference in their component model?
What would you choose for which applications?
How do they integrate with Guice, Spring, JSR 299?
Edit: I have read the documentation for both and I have used both. The questions cannot be answered sufficently from reading the documentation, but from the experience from using these for some time, e.g. how to use Wicket in a stateless mode for high performance sites. Thanks.

Some relevant differences as I see them:
Tapestry uses a semi-static page
structure, where you can work with
conditionals and loops to achieve
dynamic behavior. Wicket is
completely dynamic; you can load
components dynamically, replace them
at runtime, etc. The consequences of
this are that Tapestry is easier to
optimize, and that Wicket is more
flexible in it's use.
Both frameworks
are roughly equally efficient in
execution, but Wicket relies on
server side storage (by default the
current page in session, and past
pages in a 'second level cache' which
is default a temp file in the file
system). If that bothers you, think
about how many concurrent sessions
you expect to have at peak times and
calculate with say ~100kb per session
(which is probably on the high side).
That means that you can run roughly
support 20k concurrent sessions for
2GB. Say 15k because you need that
memory for other things as well. Of
course, a disadvantage of storing
state is that it'll only work well
with session affinity, so that's a
limitation when using Wicket. The
framework provides you with a means
to implement stateless pages, but if
you're developing fully stateless
applications you might consider a
different framework.
Wicket's goal is to support static typing to the fullest extent, whereas Tapestry is more about saving lines of code. So with Tapestry your code base is likely smaller, which is good for maintenance, and with Wicket, you much is statically typed, which makes it easier to navigate with an IDE and check with a compiler, which also is good for maintenance. Something to say for both imho.
I have read a few times by now that people think Wicket works through inheritance a lot. I would like to stress that you have a choice. There is a hierarchy of components, but Wicket also supports composition though constructs like IBehavior (on top of which e.g. Wicket's Ajax support is built). On top of that you have things like converters and validators, which you add to components, globally, or even as a cross cutting concern using some of the phase listeners Wicket provides.

REVISED after studying Tapestry 5.
Wicket's goal is an attempt to make web development similar to desktop GUI one. They managed to do it really well at the expense of memory usage ( HTTPSession ).
Tapestry 5's goal is to make very optimized (for CPU and memory) component oriented web framework.
The really big pitfall for me was responses "Wicket supports stateless component!" to the arguments "Wicket is memory hungry". While Wicket indeed supports stateless components they are not "a focus of Wicket development". For example a bug in StatelessForm was not fixed for a very long time - see StatelessForm - problem with parameters after validation fails.
IMHO using Wicket is a bit eaiser until you are going to optimize/ fine-tune web application parameters
IMHO Wicket is harder to study if you have programmed web applications and want to think in terms of request processing
Tapestry 5 automatically reloads component classes as soon as you change them. Both frameworks reload component markup.
Wicket forces markup/ code separation, Tapestry 5 just give you this ability. You can also use less verbose syntax in Tapestry 5. As always this freedom requires more cautions to be taken.
Wicket's core is easier to debug: user components are based on inheritance while Tapestry 5 user components are based on annotations. From the other side that could make transitions to the future versions easier for Tapestry then for Wicket.
Unfortunately Tapestry 5 tutorial does not stress that Tapestry code example like 't:loop source="1..10"...' can be a bad practice. So some effort should be put into writing Tapestry usage conventions/ good practices if your team is not very small.
My recommendations:
Use Wicket when your pages structure is very dynamic and you can afford spending 10-200 Kbs of HttpSession memory per user (these are rough numbers).
Use Tapestry 5 in cases when you need more efficient usage of resources

Here's a pretty thorough comparison from IBM's Developer Works.
http://www.ibm.com/developerworks/java/library/os-tapestrywicket/index.html?ca=drs
Update: link is dead, but you can find the page on http://web.archive.org/web/20131011174338/http://www.ibm.com/developerworks/java/library/os-tapestrywicket/index.html?ca=drs

I think Wicket is a simpler framework to use.
Also, Wicket does allow for class reloading via your IDE's hot-code replace system. This is all that is required for Wicket to run off modified versions of a currently running application's classes. The usual restrictions apply for hot-code replace, such as having to run in Debug mode (Eclipse) and not being able to change structural aspects of a class (i.e. class name, changing method signatures etc...).

I don't like the Tapestry programming model and I know of many developers leaving Tapestry because of too much changes and incompatibilities in development. See: http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails/

Wicket is very good web framework. Best from all what i'm know. I'm use it since version 1.3 and always get what i'm want.
Wicket has excellent integration with Spring - just use #SpringBean annotation in you code to inject any spring bean to your classes.

Try http://incubator.apache.org/click/ .
It is amazing java web framework.
Some people call it “Wicket made right” ;-)

As I said when 4.1 was the official stable release:
You should take a very good look at the development history of Tapestry before committing to use it. Tapestry has done a lot of non-compatible upgrades, with no continuation of support of older versions. Patches to 4.1 are not processed anymore within a reasonable timeframe. That is in my point of view not acceptable for the official stable version.
Committing to use Tapestry 5 means:
you should become a committer;
you need to keep up with all new development, abandon old versions as fast as possible;
maintain stable versions yourself.