I guess you're doing what we did at our beginning. David is a superman, we are not, so we have to do it in another way.
We decided to use OpenCms as the frontend several years ago, and then the developers can be divided into 3 groups: UI developers (require JSP only), OpenCms module developers (reusable GUIs and functions), OFBiz service developers (extend OFBiz RMI/data to support OpenCms modules). Now we also use portlets and flashes as UI. Fish-bone diagram is helpful to analyse a business and implement it in OFBiz. "Old OFBiz Standard Floating Layout" is more helpful to combine consultant works with the OFBiz UI. My 2 cents, Shi Yusen/Beijing Langhua Ltd. 在 2009-12-20日的 09:02 +0530，Vasanth Kamatgi写道： > 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 >
