Screen Widget Ideas
Locked
 
|
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. 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) 2. Somehow break up the remaining attributes into meaningful categories. Chris Howe suggested this for the form widget - https://issues.apache.org/jira/browse/OFBIZ-762. 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. 4. All of this will be completely backward-compatible, there will be no need to change any widget XML files. The new categories Chris Howe proposed will be supported in addition to the current methods. A warning will be logged about switching over to the new categories when reading older-style XML files. That's it for now. Let me know what you think. -Adrian |
|
|
hmmmm seems we are getting to complicated IMHO.
instead of java code to deal with the HTML attributes, would rather have a widget attribute that lets this happen free hand. sort of like on a html page, you can mix scripts with HTML. I would like to see efforts on the widgets be able to make a complicated layout simpler. A layout like the eclipse IDE but in widgets. maybe a service that can do pretty print of widgets and a validation, like w3c uses. Adrian Crum sent the following on 4/6/2007 1:54 PM: > 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. > > 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) > > 2. Somehow break up the remaining attributes into meaningful categories. > Chris Howe suggested this for the form widget - > https://issues.apache.org/jira/browse/OFBIZ-762. > > 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. > > 4. All of this will be completely backward-compatible, there will be no > need to change any widget XML files. The new categories Chris Howe > proposed will be supported in addition to the current methods. A warning > will be logged about switching over to the new categories when reading > older-style XML files. > > That's it for now. Let me know what you think. > > -Adrian > > > > |
|
|
In reply to this post by Adrian Crum
> ------- Original Message ------- > From: Adrian Crum <[hidden email]> > To: [hidden email] > 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? > 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 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. > 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? -David |
|
|
David E. Jones wrote:
> >>------- Original Message ------- >>From: Adrian Crum <[hidden email]> >>To: [hidden email] >>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. |
|
|
On Apr 9, 2007, at 6:12 PM, Adrian Crum wrote: >> 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. So, what sort of thing are you looking for to meet your particular needs? -David |
smime.p7s (3K) |
|
David E. Jones wrote:
> > On Apr 9, 2007, at 6:12 PM, Adrian Crum wrote: > >>> 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. > > > So, what sort of thing are you looking for to meet your particular needs? > > -David Here's an example: https://issues.apache.org/jira/browse/OFBIZ-875 That modification has little to do with the original message in this thread, but it demonstrates how I believe the widgets can be improved upon to make simple tasks simple. Then there is the example I gave earlier of wanting to assign IDs and styles to certain widgets. At the time it had been suggested to wrap the widget in a container, then assign an ID and a style to the container. I chose to improve the widget instead. So, little things that should be simple and straightforward are sometimes complicated or impossible. Another example: Screenlets are common repetitive visual elements in OFBiz. To compose a screenlet using the screen widgets takes a lot of XML code. So, bottom line, a simple task is made complicated. I would like to develop a screenlet widget - that would render a screenlet from a few attributes. Before I get started on that though, I would like to clean up the existing widget java code. That's what prompted this thread. -Adrian |
|
|
In reply to this post by Adrian Crum
> ------- Original Message ------- > From: Adrian Crum <[hidden email]> > To: [hidden email] > Sent: 4/10/07, 10:16:53 AM > Subject: Re: Screen Widget Ideas > > David E. Jones wrote: > > > > On Apr 9, 2007, at 6:12 PM, Adrian Crum wrote: > > > >>> 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. > > > > > > So, what sort of thing are you looking for to meet your particular needs? > > > > -David > > Here's an example: > > https://issues.apache.org/jira/browse/OFBIZ-875 > > That modification has little to do with the original message in this thread, but > it demonstrates how I believe the widgets can be improved upon to make simple > tasks simple. > > Then there is the example I gave earlier of wanting to assign IDs and styles to > certain widgets. At the time it had been suggested to wrap the widget in a > container, then assign an ID and a style to the container. I chose to improve > the widget instead. > > So, little things that should be simple and straightforward are sometimes > complicated or impossible. > > Another example: Screenlets are common repetitive visual elements in OFBiz. To > compose a screenlet using the screen widgets takes a lot of XML code. So, bottom > line, a simple task is made complicated. I would like to develop a screenlet > widget - that would render a screenlet from a few attributes. Before I get > started on that though, I would like to clean up the existing widget java code. > That's what prompted this thread. Why not just use the screenlet decorator? I guess this particular thing is not something that has come up for me as a real pain point when developing... -David |
|
|
David E. Jones wrote:
> Why not just use the screenlet decorator? That's a good suggestion, but the screenlet decorator doesn't do anything to make things simpler. Instead of wrapping screen widgets in screenlet containers, I'm wrapping them in a screenlet decorator and decorator sections. Bottom line - same amount of code. The idea behind a screenlet widget is to reduce the XML by having default behaviors and styles. |
|
|
In reply to this post by Adrian Crum
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 <[hidden email]> >>> To: [hidden email] >>> 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. > > > |
|
|
In reply to this post by David E Jones
I like widgets for their conciseness. Coupled with ftl, I can even do ajax with widgets. Is there
something I'm missing, like some new-age UI concept? While I don't mind widgets becoming more flexible (assuming they're backward-compatible), even to rival ftl, I don't see myself using them in more fancy ways than how I'm using them now. They let me put fields neatly in aligned grids. I wouldn't pit widgets against ftl. I'd leave them to specialize in their own ends of the spectrum. Jonathon David E. Jones wrote: > > On Apr 9, 2007, at 6:12 PM, Adrian Crum wrote: > >>> 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. > > So, what sort of thing are you looking for to meet your particular needs? > > -David > |
|
|
In reply to this post by Adrian Crum
Adrian,
I see your point. Hmm. I've been modifying the widget module for my own use for some time now, I didn't realize it fell short in some areas. The "id" attribute should be common for all widgets. Jonathon Adrian Crum wrote: > David E. Jones wrote: >> >> On Apr 9, 2007, at 6:12 PM, Adrian Crum wrote: >> >>>> 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. >> >> >> So, what sort of thing are you looking for to meet your particular >> needs? >> >> -David > > Here's an example: > > https://issues.apache.org/jira/browse/OFBIZ-875 > > That modification has little to do with the original message in this > thread, but it demonstrates how I believe the widgets can be improved > upon to make simple tasks simple. > > Then there is the example I gave earlier of wanting to assign IDs and > styles to certain widgets. At the time it had been suggested to wrap the > widget in a container, then assign an ID and a style to the container. I > chose to improve the widget instead. > > So, little things that should be simple and straightforward are > sometimes complicated or impossible. > > Another example: Screenlets are common repetitive visual elements in > OFBiz. To compose a screenlet using the screen widgets takes a lot of > XML code. So, bottom line, a simple task is made complicated. I would > like to develop a screenlet widget - that would render a screenlet from > a few attributes. Before I get started on that though, I would like to > clean up the existing widget java code. That's what prompted this thread. > > -Adrian > > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |