Adrian,
Just a quick note, after having gone through the widget form and screen codes.
There is certainly some duplication in some widget classes. However, I don't see enough similarity
among all widgets to warrant any exercise in "mathematically rigorous reduction". I can't fathom
having to spend large amounts of time to boil down all widgets into a single formula.
But still, I agree that some cleaning up can be done.
IMHO, the codes there are clean enough. Look at the way the widgets are funneled through
readSubWidgets() or something.
The rendering in HtmlFormRenderer may seem messy, but that's probably because the same attributes
for different widgets are supposed to be rendered quite differently. That layer is too close to
the front-end to benefit from a reduction.
Jonathon
Adrian Crum wrote:
David E. Jones wrote:
------- Original Message -------
From: Adrian Crum <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: 4/6/07, 4:54:11 PM
Subject: Screen Widget Ideas
I've been playing around with the screen widget java code to
implement a few enhancements. One thing I noticed is there is a lot
of redundant code and the widgets aren't consistent in how they are
constructed/used.
What parts of the code are you finding redundant? I guess in other
words... Could you be more specific?
They all load the same basic set of attributes. They also have a number
of methods in common.
I would like to refactor the widgets to make better use of OOP -
which will reduce code and make the widgets more consistent. Before I
get started, I would like to put some of my ideas on the mailing list
to see what everyone thinks.
1. Have all widgets contain a common set of attributes (or
properties). Since the widgets are used mostly for HTML output, they
should at least contain the standard HTML attributes. The standard
attributes might not have meaning to other rendering methods or some
types of widgets.
(HTML standard attributes -
http://www.w3schools.com/tags/ref_standardattributes.asp)
I am 100% against this. Once we make it as complex and verbose as html
we will have destyoyed the point of the tool.
The problem I ran into during the UI refactor was this - some widgets
supported IDs and styles, others did not. At the time I added those
attributes to the widgets I was targeting, but ideally those attributes
should be a part of all of them.
The goal for all ofbiz tools is to do 90% of what you need efficiently
and generically and quickly, not 100% of what you need pooy. The form
wigdet is not and never will be html or fill the same need.
The funny thing about the widgets is, they make complex tasks simple,
and at the same time they make simple tasks complex. In my opinion, the
widgets get a C in doing 90% of what I need efficiently.
3. Create base classes for the model widgets and renderer classes.
The base classes would contain the code that all of the model
widgets/renderers share, and each type of model widget/renderer will
be derived from the common base class.
We need more details here... What, for example at least, would go into
these base classes?
I agree there needs to be more detail. I worked on my ideas over the
weekend. I hope to have the base classes submitted to Jira within a few
days. They will be there for everyone to analyze and critique.
As I mentioned, the base classes would contain the code that all of the
widgets seem to share.
