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. :-)
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.
