But, the downside of this approach is - I would be losing the ofbiz community improvements in the ecommerce front end. for any change / bugfix / enhancement in the ecommerce module, I need to explicitly port it again in my own implementation, which is kind of contradictory to the reason why I had wanted to use an open source application with activity community in the first place. In fact, we had evaluated this option as well but discarded it for the reason mentioned above.
Shi Yusen wrote: > > 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:[email protected]] >> Sent: Sunday, December 20, 2009 2:09 AM >> To: [email protected] >> 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 >> > > > -- View this message in context: http://n4.nabble.com/Using-Apache-Wicket-in-Ofbiz-presentation-layer-tp975468p977524.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
