That sounds cool, I'll check it out at some point. Note though that with Jelly you could in theory drop in/override virtually any tag and not just entire widgets i.e. a custom field type for forms (although I'm not sure that what you've described doesn't allow for something like that).
Regards Scott On 17/01/2011, at 12:41 PM, Adrian Crum wrote: > 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 >>> >>> >>> >>> >> >> > > >
smime.p7s
Description: S/MIME cryptographic signature
