I had a quick look at wicket and this sounds pretty interesting for the ecommerce component. Updating the ecommerce frontend UI is indeed sometimes pretty cumbersome.
Looking forward to a proof of concept? Regards, Hans On Sat, 2009-12-19 at 23:25 +0530, 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 > -- Antwebsystems.com: Quality OFBiz services for competitive rates
