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
