Re: Splitting out single and list into separate form widgets
Locked
Re: Splitting out single and list into separate form widgets
 
|
Re: Splitting out single and list into separate form widgets
|
|
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 <[hidden email]> wrote: >> --- On Mon, 5/3/10, Scott Gray <[hidden email]> >> wrote: >>> On 4/05/2010, at 4:23 PM, Adrian Crum >>> wrote: >>> >>>> --- On Mon, 5/3/10, Adrian Crum <[hidden email]> >>> wrote: >>>>> --- On Mon, 5/3/10, Scott Gray <[hidden email]> >>>>> 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 (3K)
Re: Splitting out single and list into separate form widgets
|
|
Re: Splitting out single and list into separate form widgets
|
|
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 <[hidden email]> 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 <[hidden email]> >> wrote: >>>> --- On Mon, 5/3/10, Scott Gray <[hidden email]> >>>> wrote: >>>>> On 4/05/2010, at 4:23 PM, Adrian Crum >>>>> wrote: >>>>> >>>>>> --- On Mon, 5/3/10, Adrian Crum <[hidden email]> >>>>> wrote: >>>>>>> --- On Mon, 5/3/10, Scott Gray <[hidden email]> >>>>>>> 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 >>> >>> >>> >>> >> >> > > > |
Re: Splitting out single and list into separate form widgets
|
|
| Free forum by Nabble | Edit this page |