You have summed it up well David. I am looking exactly at that problem. We had not seen these problems when we started out with Ofbiz, nor did we visualize at that time (4 years back) that we would face problems like these, in future. I think it is a typical scale-up stage issue that Ofbiz doesn't solve well where functionality and UI throughput expected is exponentially large and complete team is not as multi-disciplined as the original team was. I also think that Ofbiz presentation layer is a legacy of MVC-II paradigm, which was in vogue at the time of design of Ofbiz and which is now being *contested* by Component based frameworks like JSF, Flex and Wicket.
1) I would like to hear from others, their views on the subject 2) How have other organizations handled this issue? Are there alternatives within the existing Ofbiz framework, people have successfully employed? 3) I am not aware, how to kick-off the analysis, requirement comparison, POC etc. activities. Guidance by community gurus would be a great help. Cheers, Vasanth -----Original Message----- From: David E Jones [mailto:d...@me.com] Sent: Sunday, December 20, 2009 2:09 AM To: dev@ofbiz.apache.org Subject: Re: Using Apache Wicket in Ofbiz presentation layer To sum up: 1. you want a full separation of concerns for the different roles in your organization, something that won't require additional training beyond their existing skill set 2. you want no dependencies between different roles so they can't mess each other up or slow each other down 3. Apache Wicket will provide these things Does that sound about right? This sounds amazing! I can't wait to the see the results of an analysis and comparison for each requirement, and a proof of concept and per-activity comparison between the different approaches. -David On Dec 19, 2009, at 11:55 AM, Vasanth Kamatgi wrote: > Hi all, > > > > Firstly I would like to thank David E. Jones > <http://www.blogger.com/profile/07283017166339658819> , for his > encouragement to use the community process. > > I had previously posted a question in this community at > http://n4.nabble.com/Application-framework-technology-set-tp195713p963334.ht > ml as a very terse summary of my thoughts. After having a private > conversation with David, I thought a much in-depth discussion on the > presentation layer would be beneficial to me as well as the community and > consequently I am starting a new thread of discussion. > > > > Here is my primary complaint of Ofbiz presentation Layer - "There isn't a > STRICT separation of UI / Code in the presentation layer. Due to this > deficiency, for any revamp in the UI, even though there is no associated > change in the functionality / business logic, it takes substantial amount of > developer time. I see this as a major hindrance to a typical ecommerce > website, where UI changes are frequent as well as significant." > > > > To give more insight into why I have this complaint, let me raise some > questions (and answer them): > > > > What I think a presentation Layer does? > > ============================= > > I believe presentation layer can be divided into 6 areas of concern: > > Data Preparation - Events / Service (a.k.a actions) generate data that need > to be processed to result into a *shape* that can be directly used by a > view. Eg., only product category id exists in context, we need to display > category name as well - fetch it. > > Layout - It controls the relative position of each of the components inside > a page. Wireframes used to build the page. > > Page composition - Different areas of the page can be generated by a > separate component / screen, and the generated output needs to be stitched > together to result into a complete response > > Look and Feel - Visual properties of components of the page (css?) > > View Logic - The logic that controls the initial state of each elements of > the output - like enabling, disabling, non-display etc., of specific output > elements. Eg., if sale price exists, show it in large red font, strike > through the list price, else show list price in large font. > > Rich dynamic behaviour - the dynamic behaviour that each of the generated > output needs to provide inside user-agent's environment (javascript / dhtml) > > > > How have I set the things up in Ofbiz? > > =========================== > > 1. I have created my primary page layout a.k.a. decorator in > common-screens.xml using sections, actions, widgets, html-templates, > containers, etc. > 2. I have abstracted out the common section contents as say, > includes/header.ftl etc. > 3. I have created components of a page such as choose catalog, keyword > search box, etc. as screens (non-top level) using actions and html templates > in, say, catalog-screens.xml > 4. I create a complete response page as a screen in catalog-screens.xml > using actions, widgets, decorator-screen, decorator-section, include-screen, > etc. in, say, catalog-screens.xml > 5. I specify this top-level page as view, which I link to the > associated event / service via request map in controller.xml > > The actual response out is defined in html fragments in various files > defined in #2, #3 & #4 > > > > Exactly what is it that I find cumbersome? > > ============================== > > UI Designer prepares the prototype, hands it over to the Ofbiz developer, > who splits it into different fragments, and creates ftls for each of those > sections. Then, adds page composition, view logic and rich dynamic > behaviour to those ftls. This complete sequence of steps is irreversible. > Once handover happens from UI designer to Ofbiz developer, the html / css > ceases to exist in its native form, making it impossible for the UI designer > to "maintain" it. Any UI bug / change request cannot be fixed by UI > designer. UI designer first analyses the problem reports the possible > causes to Ofbiz developer, who figures out which ftl file to edit and goes > and edits it. If a drop down box needs to move from one widget to another, > Ofbiz developer employs a cut+paste job that can be so error-prone with > missing tag closures, quotes, duplicates etc. There have been so many > instances of Ofbiz developer trying to fix UI issues, but failing to do so > because he / she is good at writing java-like, jsp-like and javascript-like > code and not standards-compliant html / css code. He can't use visual tools > like a UI designer to improve his productivity. Throw into this mix the > cross-browser compatibility issue - the whole effort becomes very > unproductive with UI designer, Ofbiz developer working together to fix it, > when it should actually be handled by UI designer alone. > > Ofbiz supports data preparation, page composition, view logic well. But > other areas are a little troublesome. > > > > How would I like it to work? > > ==================== > > Different areas of concern, as listed in my previous paragraph, are best > worked at by different types of resources. Assuming we are using java > platform for development: > > Data Preparation - java coder > > Layout - UI designer / business analyst / SEO specialist > > Page composition - java / jsp coder > > Look and Feel - User Experience expert > > View Logic - java / jsp coder > > Rich dynamic behaviour - script coder / java coder > > Given these different areas of expertise, a software development / > maintenance model needs to be employed to enable these types of resources to > work at full productivity without tripping each other. Cutting a long story > short, I believe, Ofbiz should enable html, css, multi-media & view logic to > be developed and managed independently. UI designer should continue to fix > UI bugs by just editing his / her html code. There should be no pollution > of html and css code. View logic should be written without using tags. > > I have dived into wicket and wrote my first hello world recently and believe > wicket-like rendering would be a good enhancement to Ofbiz. I am not > claiming to be an expert of wicket, but based on the documentation I have > read, it seems to fit the scheme well. > > > > I hope I have given enough details for the community to start a > conversation. I understand that, the question begs of not only an > architectural discussion, but also of a software development / maintenance > model. > > > > Cheers, > > Vasanth
