Cool - thanks. Btw, we can drop in jars for screen widget extensions now. I haven't made the change necessary for the other widgets (forms, menus, trees), but it would be pretty easy to do by following the same factory pattern.
-Adrian --- On Sun, 1/16/11, Scott Gray <[email protected]> wrote: > My current leaning would be to > replace them with widgets implemented with Jelly and I would > like to do a PoC "single" form widget replacement when I > have a chance. The idea of being able to drop in jars > for instant widget extension really appeals to me and may > help foster new widgets and extensions outside of our code > base. > > Regards > Scott > > HotWax Media > http://www.hotwaxmedia.com > > On 10/01/2011, at 5:11 AM, Adrian Crum wrote: > > > Scott, > > > > Any more thoughts on this? > > > > -Adrian > > > > --- On Mon, 5/3/10, Adrian Crum <[email protected]> > wrote: > >> --- On Mon, 5/3/10, Scott Gray <[email protected]> > >> wrote: > >>> On 4/05/2010, at 4:23 PM, Adrian Crum > >>> wrote: > >>> > >>>> --- On Mon, 5/3/10, Adrian Crum <[email protected]> > >>> wrote: > >>>>> --- On Mon, 5/3/10, Scott Gray <[email protected]> > >>>>> wrote: > >>>>>> On 4/05/2010, at 11:32 AM, Adrian > >>>>>> Crum wrote: > >>>>>> > >>>>>>> On 5/3/2010 4:25 PM, Scott > Gray > >> wrote: > >>>>>>>> Sometimes I think using > the same > >>> schema and > >>>>> class > >>>>>> for single forms and list forms > holds us > >> back > >>> from > >>>>>> implementing features specific to > one or > >> the > >>> other and > >>>>> even > >>>>>> when we do it results in a messy > schema. > >>>>>>>> > >>>>>>>> What if we were to > separate the > >> two > >>> but have > >>>>> them > >>>>>> share a common base? We > could start by > >>> separating > >>>>> the > >>>>>> schemas and then work on the > code. > >>>>>>>> > >>>>>>>> Thoughts? > >>>>>>> > >>>>>>> Any effort to clean up and > improve > >> widget > >>> code > >>>>> gets a > >>>>>> big thumbs-up from me. > >>>>>>> > >>>>>>> While we're at it, could we > separate > >> the > >>> styling > >>>>> into > >>>>>> a separate element and Java class? > Chris > >> Howe > >>> had > >>>>> suggested > >>>>>> that some years ago. > >>>>>> > >>>>>> I'm not entirely sure what you > mean on > >> this > >>> one? > >>>>>> Could you give me an example of > what the > >>> problem is > >>>>> and how > >>>>>> this would solve it? > >>>>> > >>>>> I think it was around the beginning of > 2007. > >> The > >>> idea was > >>>>> to move all of the form widget > styling > >> attributes > >>> to a style > >>>>> element - to cut down on the amount of > form > >>> attributes. We > >>>>> made a preliminary move in that > direction by > >>> putting all of > >>>>> the form styling attributes on their > own line > >> - so > >>> that > >>>>> later they could be contained in a > separate > >>> element. > >>>> > >>>> I can't find the ml discussion, but here > is the > >>> related Jira issue: > >>>> > >>>> https://issues.apache.org/jira/browse/OFBIZ-760 > >>>> > >>>> -Adrian > >>> > >>> Okay thanks, I see what you mean now. > I'll stew on > >> it > >>> for a bit and see what I can add to the > discussion. > >> > >> There is a chance it isn't needed any more. The > problem 3 > >> years ago was that there was a form attribute to > style > >> nearly every element in the form. I introduced the > concept > >> of having a container CSS class that would style > the form > >> and all of its child elements (using descendant > selectors). > >> After that the effort to move styling to a > separate element > >> fizzled out. I don't know if that was due to lack > of > >> interest or the new container method of styling. > >> > >> -Adrian > > > > > > > > > >
