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
