Having the ability to replace individual sub-widgets would be possible, but it 
really isn't necessary. Just replace the container widget with your custom 
implementation, delegate OFBiz standard sub-widgets to existing code, and use 
custom code for your custom sub-widgets.

http://ci.apache.org/projects/ofbiz/site/javadocs/org/ofbiz/widget/WidgetFactory.html

-Adrian

--- On Sun, 1/16/11, Scott Gray <[email protected]> wrote:
> 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
> >>> 
> >>> 
> >>> 
> >>> 
> >> 
> >> 
> > 
> > 
> > 
> 
> 



Reply via email to