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 > > > >
smime.p7s
Description: S/MIME cryptographic signature
