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
