I agree with you in your observation that, this problem is difficult to solve, and has factors weighing against a possible solution. So, I understand the skepticism "if points #1 and #2 that I listed above are actually possible".
I know that I am being very naive to say this, but I believe, every now and then situations arise when seemingly impossible tasks get done. I am not implying that we are going to find panacea of absolute presentation design decoupling. At the worst I am expecting solutions that take us towards the decoupling - if not with the rendering mechanism, but with a tool. A tool that reads *screens.xml, interprets the ftl and stitches response output, making some assumptions in ftl. This would enable a UI designer to debug the *html-part* without actually having to run ofbiz or understand ftl. This is the worst case scenario. But, I would see some merit in continuing the discussion to find the silver bullet for decoupling at rendering stage. :) David E Jones-4 wrote: > > > On Dec 21, 2009, at 8:12 AM, Ean Schuessler wrote: > >> David E Jones wrote: >>> 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. >>> >> Just a touch Snarky there, Mr. Jones. :-) > > You're right, I was a bit snarky there. I apologize if I offended anyone. > I guess I should have said something like: That sounds a little bit too > amazing to be true. > >> Vasanth, I have spent some time examining Wicket and its not clear to me >> that it is able to remove the problems in all but the most simple cases. >> HTML for complicated multi-state widgets would still need to be divided >> into many fragments, which are hard for the HTML designer to understand. >> It would also still not be very clear to the designer where those >> fragments need to be delineated because they do not understand the >> control flow. >> >> The deep set problem is that there will be many cases where you want to >> look at a completed HTML assembly in its populated state to see how the >> layout looks. That can only be done by editing on a live ofbiz >> environment and that is always going to be pushing the skills of a GUI >> designer. What using Wicket does achieve, however, is the elimination of >> a high level widget system. While we are not really taking advantage of >> it it is possible to have the OFBiz widgets present themselves in a >> Swing, SWT or GWT form without rebuilding the entire GUI from scratch. >> That's a pretty big strike against the Wicket approach. Wicket is also >> pretty tightly bound to Java the language, which may or may not be the >> most productive thing to use depending on your point of view (ie. PHP >> programmers are plentiful and cheap). >> >> In some problem domains like the shopping front-end we may need to accept >> that the customer use-cases are simply to variable to make the widget >> strategy add value. That's why, here at Brainfood, we've rebuilt the >> e-commerce front end on our own templating system. Wicket might also be a >> worthwhile strategy for that front end rebuild. I imagine that most of >> your HTML workload revolves around that component. If you really believe >> in it, I encourage you to build a Wicket version of the ecommerce >> component. I would be happy to review it and compare its benefits with >> our effort. > > The general idea is an interesting one, ie of really separating things by > role and eliminating dependencies. > > I like the stuff you guys at Brainfood have done with WebSlinger, and it > certainly makes things easier for people in certain roles. > > In a way I wonder if points #1 and #2 that I listed above are actually > possible. My theory over the years is that they are simply not possible, > and all attempts are guaranteed to fall short because those requirements > are not "internally consistent". It would be interesting to have a > well-funded R&D project to get feedback from a bunch of people, assemble a > number of possible designs, then implement and test those designs in > various organizations. I'm not sure if that will ever happen, and I > suppose even if it did the winning design would probably be so biased by > politicking that the stated result might not be accurate. > > Anyway, it's a tough problem. The main issues I see are kind of like what > you listed Ean, namely: > > 1. different organizations have different roles and different skills sets, > so to be effective you'd really need to document a variety of > organizations and combinations of skill sets and be flexible enough to > address at least a few of the most common ones, or the ones that should be > most easy for an organization to assemble > > 2. it's not possible to completely eliminate dependencies between what > different people in different roles are doing; there might be some things > you could do to either mitigate (handle automatically or > transparently/implicitly) or obviate (fail fast/early) the problems, but > these dependencies are an inherent part of what is being built and IMO > they simply cannot be totally eliminated, especially if you want reusable > parts of the screens, etc > > My favorite approach so far to getting people to handle this well is to > divide front-end developers into those who are mostly visually talented, > and those who have gotten into scripting and such too. These people will > have to get used to working together in order to get things done, IMO. > From time to time you'll run into a person that is great at both, but not > usually. Those who are into scripting and working with straight HTML can > usually get into using the OFBiz widgets and FTL templates and do quite > well with them (and without very much training too). But that isn't > everyone, and you certainly need someone who can break things down and > implement the technical things to drive them. > > Some tools make this easier, and therefore require less technical > knowledge, but those tools typically also restrict what you can do. If you > want to keep it cheap and simple then that's great, just do what the tool > makes easy. If you really want to be able to design and build anything > that is "internally consistent" then you're going to need more flexible > tools and more knowledgeable people. > > Or am I wrong and the silver bullet solution does exist and I just haven't > yet had the pleasure of experiencing it? > > Hopefully this time I'm less snarky, without being too depressing... :) > > -David > > > > -- View this message in context: http://n4.nabble.com/Using-Apache-Wicket-in-Ofbiz-presentation-layer-tp975468p977536.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
