OFBiz author and guru, about AJAX and SOA:
David E. Jones, one of the fathers of OFBIZ, in a recent email on the OFBIZ user list (http://article.gmane.org/gmane.comp.java.ofbiz.user/4211) is saying:
"AJAX and SOA are both _excellent_ buzzword acronyms because they are both early meaningless, or at least because they have been used out of proper context so much their meaning is watered down to the point of being mostly water. Sorry, no getting really pissed on either of these... What's also funny is that both of these kind of started out being used in an adulterated context[...]"
Wow, I am speechless. And because I respect David a lot, for who he is and for all his accomplishments, I am not going to criticize his comments; I respect him too much. But ... I do not support his comments. Sorry David.
While I am not selling my soul for just everything stamped SOA, AJAX is cool and useful, that's why, I believe OFBiz users need to see AJAX through a positive light, at least as a good addition to OFBIZ or to their career path anyway, in case that OFBIZ is not the only Java related work they do. I don't believe David's comments help them too much, with all due respect.
David, why?
:'(
Do you think OFBiz needs AJAX?
Re: OFBiz author and guru, about AJAX and SOA: "...they are both nearly meaningless"
Your question: "Do you think AJAX is what we need in OFBiz today? " is a tricky one. Don't tempt me :)
I'll try to answer to the next one: "Where do you think we could use it and make a big difference?".
Si, AJAX is about user experience first of all and properly mastered can bring real benefits to any web application. One of the biggest problems of OFBiz is exactly the UI. And while I know exactly what you're going to say (the UI in OFBiz is meant to be customized by the user) this is not as easy as it sounds. Over the time, in OFBiz, there is so much unjustified business logic added to templates, that any Designer will run away trying to change them without a Developer available; and I am speaking from my own experience. There is no clear enough separation between presentation tier and ... I'll stop at the Action tier, just to cut it short.
"AJAX it still seems too immature" ... hmmm .. but then why we're sending our kids to school? Why bother? They're all so immature?! Future, Si. Offer a chance. OFBiz is an Open Source project (and I'll not comment here about Geronimo and other "goodies" I foresee coming from the Apache .. mentors) and being an Open Source, there is place for inovation and continuing improvements, or it should be. If you accept that Google gave AJAX (the concept) a chance, why not you guys deciding about an AJAX framework you like and let it grow together with OFBiz? There are "[...]too many[...]". Well, start with DWR. I may help :)
Most of the AJAX demos including some that I saw on OFBIZ user list (the Party search lookup), are dealing with Search and keyword auto-completion. C'mon Si, *this* is immature ... is so ... last year. If you guys are looking at these demos and decide that AJAX is immature .. then you guys need to think twice.
Where in OFBiz AJAX may help? Wow, anywhere you need "no-refresh" actions and I am just throwing here few examples: adding/removing to/from shopping cart (SC), tax calculation and SC updates, communication events, any ShoppingList based artifacts (wish lists, lightboxes or such), contact mechanism management, product details presentation (especially when you have virtual products with many attributes and combinations), surveys, etc. And I don't want to attack here the screen "widgets" and other .... controls that can only kill the freedom expected by Designers.
"It seems that we need to re-think alot of the front end design to fit how users work first." - I believe that this statement should be posted on the OFBiz home page as motto! Instead of spending so much energy and skilled hands in pleasing Apache (Geronmio) why not re-writing the entire presentation tier of OFBiz? Being biased toward JPublish, I am a bit disappointed by the fact that you guys dropped it out of OFBiz without bringing anything else better in place, but this doesn't stop me developing in OFBIz (for the company I am working for). The freedom you give to a good Designer is what sells at the end a web application!
I am sorry, I may be over enthusiastic speaking about all these, but I would really like to see OFBiz being much better articulated, with a cleaner separation of roles; designers, developers and content admins, etc., eventually with a new MVC support but I know how painful that can be. It may never happen :(
My point was, that David wasn't paying enough thoughts while writing those comments. I don't even dare to ask what he believes about Rails ....
How to make OFBiz UI Better
I'm not going to tell you that the UI in OFBIz is OK because it's meant to be customized by the user. I don't think so, and I'm not happy with the state of our UI right now. I think we have some great tools for building UI, including the screen and form widget, but they have unfortunately led to a proliferation of data model-driven UI that is not intuitive to the user. Here's what I mean:
- Take a look at our OFBIZ CRM add-on (login as "DemoSalesManager" and "crmsfa"). This is all built with screen widget and form widget. I think compared to JPublish, the screen widget is actually a step forward. It allows the same separation of view and action as before but greater reuse of components across applications.
- Now click on [Accounts], go into DemoAccount1, and click on [New Order] to create an order. The order entry interface is reasonable--not beautiful, a bit complex due to the functionality it supports, but follows the logical sequence of entering an order.
- The problem children I think are interfaces like the [Quotes] tab in CRM, which is basically imported from the [Quotes] tab of order manger. It has many sub-tabs arranged according to the data model of Quotes. This is not how users like to think about quotes. This pattern is unfortunately repeated elsewhere now.
This is why I think the bigger issue is creating and organizing user interfaces around user actions, instead of our data model. Fortunately, the tools actually allow good reuse of business logic and screen components, so we can reuse a lot of things and create new "skins" or "views" into OFBiz.
The question then comes down to:
- Who wants to do it?
- How to do it?
- Where to do it?
Who does it: This becomes a question of economics. I think a project like this is large enough that it needs to be a professional effort, but it can be hard to get better UI sponsored in open source projects (though there are some great exceptions.) I see it as the problem that the users who need better UI the most are the ones who are least likely to write code. ("The Million Dollar Dilemma": if you have a 100,000 novices willing to pay $10 each for better UI, how do we put that $1 million back into an open source project?) I think perhaps the best answer is a commercial add-on to OFBiz that makes it easier to use, kind of like OS X is to FreeBSD.
How to do it: I knew that "is AJAX mature" was going to get a hailstorm thrown at me. The problem there is not whether AJAX is mature, but that I don't know enough about it, and I'm afraid of picking the wrong platform.
I think the reality is what technologies should be used to make this better UI? I think the OFBiz widgets are pretty good, but I could be too biased at this stage. Is it better that we start from scratch and try to create a front end using Ruby or PHP and an AJAX toolkit? Got any ideas here?
Last of all: "where should we do it" was not meant to be a dumb question. I'm trying to find the one thing where the reward/effort ratio could be maximized. This has to be a feature that would dramatically increase useability for the maximum number of people. This seems to mean it should be something on the front end, probably in ecommerce. Have you seen any good online store features like that?
re: How to make OFBiz UI Better
"-Who does it?" - well, it depends on how well you guys can coordinate the trend for OFBiz in its community. The simple fact that some of the heaviest OFBiz users are not returning their knowledge or own implementations back to OFBiz is showing something very simple: OFBiz as is, is not yet offering a flexible enough development recipe. And I personally believe that this is the result of the lack of project management and control.
Therefore I have a suggestion to make: publish your strategy (or convince David to do it ;) and let the community add feedback, feedback which then can be used *methodically* to influence the future of the framework. Show the users that their word matters. The clear advantage of this being that you'll gather more interest from the heaviest users/developers and you'll unify interests of single/freelance developers. By knowing your plans, they'll will try to harmonize their own strategies with yours because they'll have a guarantee that there is potential future help coming from the community in the direction they want. Eventually convince Apache (or others) to fund a core OFBIZ development group. This approach/opportunity will make a lot of us interested:)
"-How to do it?" - re AJAX, you can't be afraid of choosing the wrong platform if the first question's answer is properly articulated. The community will help if there is common interest. As in the email I privately sent you few days ago, here would be the methods I'll use if I would've have to decide for OFBiz and I apologize in advance for some radical and politically incorrect statements I'll make:
- reengineer and improve the Entity Engine or simply replace it with Hibernate.
- improve the Service Engine by adding real web services support. I made a recommendation to Andy few months ago and I know his opinion.
- replace the OFBiz Controller and rethink the need for the painful controller.xml. I am totally biased here, but I would help if you guys are willing to re-open the discussion about JPublish. On our project at work, project relying heavily on an OFBiz clone, I have very good results using a largely modified version of JPublish (which I may offer soon as an open source JPublish variant or as a new JPublish version ... there is a bit of talks to happen here). This allows me to have easily Spring integration as well as XFire (for web services) and DWR (for AJAX); pretty much everything supported through Spring. All these making an important asset for our company and in-house development trends. With the newer JPublish, I can support other types of page scripting, as supported by the latest version of BSF, not only beanshell as currently supported by OFBiz. I have beautiful results from using Janino for Action support.
- redesigning the template architecture. Freemarker/Velocity, but with a much clear separation between Views and page controllers.
- articulating the future of the application server (if this is really necessary). I have nothing against Geronimo, but for an application like OFBiz I really don't know why JBoss, or Geronimo or any other heavy app server is required? I would go with Jetty6 (and maybe Tomcat:) and let the majority of the server resources (RAM and CPU) being used by the underlining framework: OFbiz. I see no real benefits in co-hosting an ERP solution with other trivial web applications. Would you ask SAP to let you install inside an Intranet application with let's say .. employees phone extensions or a corporate holiday calendar? c'mon, the answer will be: No. You'll simply drop in a cheap server or a Mac mini to support all these:)
Scaling and Clustering? But all these are available to Tomcat and Jetty without having to install a heavier app server like JBoss, Geronimo or such. It works for us, so I am sure will work for others. I would accept JBoss as an OFBiz app container if there will be other JBoss components used internally by OFBIZ: JGroups, JBoss mbean support, etc. Then yes, I would love it. But Geronimo? This is waaaayyy too new to gather trust and support from medium/big companies. And about configuring it???? ... in my own humble opinion ... doesn't even make sense to learn about it .. unless you're paid by Apache to do it for others:) - offering OFBiz users a better way to be heard. Vox populis, vox deis :)
" ... where should we do it?" - most of the serious new OFBiz users have one first challenge: Convince the internal staff that OFBiz for internal use as an ERP is functional rich and UI friendly. Because you cannot satisfy any new user with out-of-the box OFBIZ, start from there: Hire and use a professional Designer to build a salable UI for the backend tools.
Then the next challenge is to convince the internal development team that OFBiz is using best practices, being developer friendly and flexible. Getting inside OFBiz support for trendy frameworks such as: Spring, Hibernate, AJAX, etc. will help a lot, trust me! Having all these inside, you'll not hear developers asking: Who the heck will hire me next if they'll see mostly OFBIZ inside my resume? Give them the opportunity to use Spring, AJAX, iBatis/Hibernate inside OFBiz and you'll make them happy ... and secure!
Then attack the front-end; is what the public is seeing/using. The e-commerce and e-commerce based artifacts. In my case, after the discussions we had with our financial staff and with the development team, the first thing happened next was to convince our Designers they can have back the freedom they were used to have in JPublish; our public site being supported by JPublish exclusively. Support for static pages, velocity and freemarker with writable page contexts (you hear this David? *writable page contexts*) and a very flexible way to add new URL rules and page repositories. All these without begging a java Developer for support and without asking permissions to change the frustrating controller.xml.
Si, I don't know if all these helps you, the worst case, take them simply as some feedback from an OFBiz developer and integrator. I really like most of the OFBIZ (especially the Domain model and the Service Engine) this is why I am writing all these...
Re: OFBiz author and guru, about AJAX and SOA: "...they are both nearly meaningless"
Re: OFBiz author and guru, about AJAX and SOA: "...they are both nearly meaningless"
Re: OFBiz author and guru, about AJAX and SOA: "...they are both nearly meaningless"
Re: OFBiz author and guru, about AJAX and SOA: "...they are both nearly meaningless"
Re: OFBiz author and guru, about AJAX and SOA: "...they are both nearly meaningless"
Re: OFBiz author and guru, about AJAX and SOA: "...they are both nearly meaningless"
Opentaps is a living proof that you guys realized the advantages of a slick UI and the benefits of using AJAX where needed. Today, I am not sure if David changed his mind, I hope he did.
;)