OFBiz › OFBiz - Dev

Screen Widget Ideas

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

11 messages Options

Adrian Crum-2

Screen Widget Ideas

I've been thinking about some improvements to the screen widgets, and I thought I would offer some ideas and see if there is any interest. I'm kind of thinking out loud here, so the ideas are not fully developed. Please comment or add your suggestions.

1. Use the factory pattern to create model widgets. Right now model widget construction is handled internally with a pre-defined set of classes. The idea is to move the model widget creation to a factory method that accepts a candidate XML element. If a matching model widget is found, return it, otherwise throw an exception. The factory supports user-created model widgets, so the screen widgets are extensible. In other words, you can create your own model widgets, register them with the factory, and the screen renderer will use them just like any other widget. You could even create your own replacement implentations of existing OFBiz screen widgets. User-created widgets can use namespaces on the XML side to avoid XML parsing errors.

2. Add Groovy support to the <include-screen> widget. If the location attribute ends with ".groovy" pass control to the specified Groovy script. The script would behave like a screen widget and it will have access to all model widgets - so existing widget code can still be used. This could help in certain cases where screen widgets can't fulfill a particular need. It has been suggested that CDATA elements be allowed in screen widgets so that free-form code can be inserted in widget XML - this is an alternative solution to that. The benefit is you can leverage the power of Groovy in controlling screen output. The drawback is any such script will break the structure of screen widgets and it will start to look like JSP - where data preparation code is mixed with presentation code.

What do you think? Any other suggestions for improvements?

-Adrian

Scott Gray-2

Re: Screen Widget Ideas

On 15/05/2010, at 3:43 PM, Adrian Crum wrote:

> I've been thinking about some improvements to the screen widgets, and I thought I would offer some ideas and see if there is any interest. I'm kind of thinking out loud here, so the ideas are not fully developed. Please comment or add your suggestions.
>
> 1. Use the factory pattern to create model widgets. Right now model widget construction is handled internally with a pre-defined set of classes. The idea is to move the model widget creation to a factory method that accepts a candidate XML element. If a matching model widget is found, return it, otherwise throw an exception. The factory supports user-created model widgets, so the screen widgets are extensible. In other words, you can create your own model widgets, register them with the factory, and the screen renderer will use them just like any other widget. You could even create your own replacement implentations of existing OFBiz screen widgets. User-created widgets can use namespaces on the XML side to avoid XML parsing errors.

That's crazy, I've been looking into this today. I had figured on using an include-widget tag.
I was also thinking about the PITA way that we pass widget renderers around and wondering if we couldn't just have a render method on the model that takes a writer, the context and a content type. The model then has an internal factory that gets the configured renderer based on the content type.

> 2. Add Groovy support to the <include-screen> widget. If the location attribute ends with ".groovy" pass control to the specified Groovy script. The script would behave like a screen widget and it will have access to all model widgets - so existing widget code can still be used. This could help in certain cases where screen widgets can't fulfill a particular need. It has been suggested that CDATA elements be allowed in screen widgets so that free-form code can be inserted in widget XML - this is an alternative solution to that. The benefit is you can leverage the power of Groovy in controlling screen output. The drawback is any such script will break the structure of screen widgets and it will start to look like JSP - where data preparation code is mixed with presentation code.

This sounds more like a custom renderer rather than something that should go into the model.

Regards
Scott

smime.p7s (3K) Download Attachment

Adrian Crum-2

Re: Screen Widget Ideas

--- On Fri, 5/14/10, Scott Gray <[hidden email]> wrote:

> On 15/05/2010, at 3:43 PM, Adrian
> Crum wrote:
>
> > I've been thinking about some improvements to the
> screen widgets, and I thought I would offer some ideas and
> see if there is any interest. I'm kind of thinking out loud
> here, so the ideas are not fully developed. Please comment
> or add your suggestions.
> >
> > 1. Use the factory pattern to create model widgets.
> Right now model widget construction is handled internally
> with a pre-defined set of classes. The idea is to move the
> model widget creation to a factory method that accepts a
> candidate XML element. If a matching model widget is found,
> return it, otherwise throw an exception. The factory
> supports user-created model widgets, so the screen widgets
> are extensible. In other words, you can create your own
> model widgets, register them with the factory, and the
> screen renderer will use them just like any other widget.
> You could even create your own replacement implentations of
> existing OFBiz screen widgets. User-created widgets can use
> namespaces on the XML side to avoid XML parsing errors.
>
> That's crazy, I've been looking into this today. I
> had figured on using an include-widget tag.
> I was also thinking about the PITA way that we pass widget
> renderers around and wondering if we couldn't just have a
> render method on the model that takes a writer, the context
> and a content type. The model then has an internal
> factory that gets the configured renderer based on the
> content type.

At least we're basically on the same page. My perspective all along is that the screen widgets should be nothing more than data structures in memory that support the visitor pattern. Renderers implement the visitor interface. Implementations of the visitor interface could be anything: HTML renderers, Swing renderers, artifact gatherers, layout managers (an intermediate form of renderer), pretty printers, etc.

There is so much room for improvement, but experience has shown that the screen widgets have become a sort of sacred cow, so changes like that will be met with a lot of resistance.

> > 2. Add Groovy support to the <include-screen>
> widget. If the location attribute ends with ".groovy" pass
> control to the specified Groovy script. The script would
> behave like a screen widget and it will have access to all
> model widgets - so existing widget code can still be used.
> This could help in certain cases where screen widgets can't
> fulfill a particular need. It has been suggested that CDATA
> elements be allowed in screen widgets so that free-form code
> can be inserted in widget XML - this is an alternative
> solution to that. The benefit is you can leverage the power
> of Groovy in controlling screen output. The drawback is any
> such script will break the structure of screen widgets and
> it will start to look like JSP - where data preparation code
> is mixed with presentation code.
>
> This sounds more like a custom renderer rather than
> something that should go into the model.

It's not a custom renderer - the output is still the same as the original view. It's just a different way of looking at screen rendering. Instead of screen widgets calling scripts, a script calls screen widgets. In other words, instead of XML-generated-widgets being in charge of Groovy, Groovy is in charge of the XML-generated-widgets. Think about it.

-Adrian

Marc Morin

Re: Screen Widget Ideas

Pure model objects with no behavior in them, and a visitor pattern to externalize the behavior.... man, that's music to my ears!

We've added a visitor pattern to all the "model" objects, screens, forms, menus, entity,....

It has proven invaluable to enable walking and manipulating the model, without increasing the complexity of the underlying model objects.

Also, as your specific example indicates, the "renderers" are a perfect use case for visitors, as the rendered is technically and interpreter of the model objects.

Marc
----- "Adrian Crum" <[hidden email]> wrote:

> --- On Fri, 5/14/10, Scott Gray <[hidden email]> wrote:
> > On 15/05/2010, at 3:43 PM, Adrian
> > Crum wrote:
> >
> > > I've been thinking about some improvements to the
> > screen widgets, and I thought I would offer some ideas and
> > see if there is any interest. I'm kind of thinking out loud
> > here, so the ideas are not fully developed. Please comment
> > or add your suggestions.
> > >
> > > 1. Use the factory pattern to create model widgets.
> > Right now model widget construction is handled internally
> > with a pre-defined set of classes. The idea is to move the
> > model widget creation to a factory method that accepts a
> > candidate XML element. If a matching model widget is found,
> > return it, otherwise throw an exception. The factory
> > supports user-created model widgets, so the screen widgets
> > are extensible. In other words, you can create your own
> > model widgets, register them with the factory, and the
> > screen renderer will use them just like any other widget.
> > You could even create your own replacement implentations of
> > existing OFBiz screen widgets. User-created widgets can use
> > namespaces on the XML side to avoid XML parsing errors.
> >
> > That's crazy, I've been looking into this today. I
> > had figured on using an include-widget tag.
> > I was also thinking about the PITA way that we pass widget
> > renderers around and wondering if we couldn't just have a
> > render method on the model that takes a writer, the context
> > and a content type. The model then has an internal
> > factory that gets the configured renderer based on the
> > content type.
>
> At least we're basically on the same page. My perspective all along is
> that the screen widgets should be nothing more than data structures in
> memory that support the visitor pattern. Renderers implement the
> visitor interface. Implementations of the visitor interface could be
> anything: HTML renderers, Swing renderers, artifact gatherers, layout
> managers (an intermediate form of renderer), pretty printers, etc.
>
> There is so much room for improvement, but experience has shown that
> the screen widgets have become a sort of sacred cow, so changes like
> that will be met with a lot of resistance.
>
> > > 2. Add Groovy support to the <include-screen>
> > widget. If the location attribute ends with ".groovy" pass
> > control to the specified Groovy script. The script would
> > behave like a screen widget and it will have access to all
> > model widgets - so existing widget code can still be used.
> > This could help in certain cases where screen widgets can't
> > fulfill a particular need. It has been suggested that CDATA
> > elements be allowed in screen widgets so that free-form code
> > can be inserted in widget XML - this is an alternative
> > solution to that. The benefit is you can leverage the power
> > of Groovy in controlling screen output. The drawback is any
> > such script will break the structure of screen widgets and
> > it will start to look like JSP - where data preparation code
> > is mixed with presentation code.
> >
> > This sounds more like a custom renderer rather than
> > something that should go into the model.
>
> It's not a custom renderer - the output is still the same as the
> original view. It's just a different way of looking at screen
> rendering. Instead of screen widgets calling scripts, a script calls
> screen widgets. In other words, instead of XML-generated-widgets being
> in charge of Groovy, Groovy is in charge of the XML-generated-widgets.
> Think about it.
>
> -Adrian

Adrian Crum-2

Re: Screen Widget Ideas

Marc,

Do you have any thoughts on the first two ideas I proposed?

-Adrian

--- On Sat, 5/15/10, Marc Morin <[hidden email]> wrote:

> From: Marc Morin <[hidden email]>
> Subject: Re: Screen Widget Ideas
> To: [hidden email]
> Date: Saturday, May 15, 2010, 4:11 AM
> Pure model objects with no behavior
> in them, and a visitor pattern to externalize the
> behavior.... man, that's music to my ears!
>
> We've added a visitor pattern to all the "model" objects,
> screens, forms, menus, entity,....
>
> It has proven invaluable to enable walking and manipulating
> the model, without increasing the complexity of the
> underlying model objects.
>
> Also, as your specific example indicates, the "renderers"
> are a perfect use case for visitors, as the rendered is
> technically and interpreter of the model objects.
>
> Marc
> ----- "Adrian Crum" <[hidden email]>
> wrote:
>
> > --- On Fri, 5/14/10, Scott Gray <[hidden email]>
> wrote:
> > > On 15/05/2010, at 3:43 PM, Adrian
> > > Crum wrote:
> > >
> > > > I've been thinking about some improvements
> to the
> > > screen widgets, and I thought I would offer some
> ideas and
> > > see if there is any interest. I'm kind of
> thinking out loud
> > > here, so the ideas are not fully developed.
> Please comment
> > > or add your suggestions.
> > > >
> > > > 1. Use the factory pattern to create model
> widgets.
> > > Right now model widget construction is handled
> internally
> > > with a pre-defined set of classes. The idea is to
> move the
> > > model widget creation to a factory method that
> accepts a
> > > candidate XML element. If a matching model widget
> is found,
> > > return it, otherwise throw an exception. The
> factory
> > > supports user-created model widgets, so the
> screen widgets
> > > are extensible. In other words, you can create
> your own
> > > model widgets, register them with the factory,
> and the
> > > screen renderer will use them just like any other
> widget.
> > > You could even create your own replacement
> implentations of
> > > existing OFBiz screen widgets. User-created
> widgets can use
> > > namespaces on the XML side to avoid XML parsing
> errors.
> > >
> > > That's crazy, I've been looking into this
> today. I
> > > had figured on using an include-widget tag.
> > > I was also thinking about the PITA way that we
> pass widget
> > > renderers around and wondering if we couldn't
> just have a
> > > render method on the model that takes a writer,
> the context
> > > and a content type. The model then has an
> internal
> > > factory that gets the configured renderer based
> on the
> > > content type.
> >
> > At least we're basically on the same page. My
> perspective all along is
> > that the screen widgets should be nothing more than
> data structures in
> > memory that support the visitor pattern. Renderers
> implement the
> > visitor interface. Implementations of the visitor
> interface could be
> > anything: HTML renderers, Swing renderers, artifact
> gatherers, layout
> > managers (an intermediate form of renderer), pretty
> printers, etc.
> >
> > There is so much room for improvement, but experience
> has shown that
> > the screen widgets have become a sort of sacred cow,
> so changes like
> > that will be met with a lot of resistance.
> >
> > > > 2. Add Groovy support to the
> <include-screen>
> > > widget. If the location attribute ends with
> ".groovy" pass
> > > control to the specified Groovy script. The
> script would
> > > behave like a screen widget and it will have
> access to all
> > > model widgets - so existing widget code can still
> be used.
> > > This could help in certain cases where screen
> widgets can't
> > > fulfill a particular need. It has been suggested
> that CDATA
> > > elements be allowed in screen widgets so that
> free-form code
> > > can be inserted in widget XML - this is an
> alternative
> > > solution to that. The benefit is you can leverage
> the power
> > > of Groovy in controlling screen output. The
> drawback is any
> > > such script will break the structure of screen
> widgets and
> > > it will start to look like JSP - where data
> preparation code
> > > is mixed with presentation code.
> > >
> > > This sounds more like a custom renderer rather
> than
> > > something that should go into the model.
> >
> > It's not a custom renderer - the output is still the
> same as the
> > original view. It's just a different way of looking at
> screen
> > rendering. Instead of screen widgets calling scripts,
> a script calls
> > screen widgets. In other words, instead of
> XML-generated-widgets being
> > in charge of Groovy, Groovy is in charge of the
> XML-generated-widgets.
> > Think about it.
> >
> > -Adrian
>

Marc Morin

Re: Screen Widget Ideas

Factory for creating model objects is a good idea. Allows opportunity to subclass them.

Marc Morin
Emforium Group Inc.
ALL-IN Software
519-772-6824 ext 201
[hidden email]

----- "Adrian Crum" <[hidden email]> wrote:

> Marc,
>
> Do you have any thoughts on the first two ideas I proposed?
>
> -Adrian
>
> --- On Sat, 5/15/10, Marc Morin <[hidden email]> wrote:
>
> > From: Marc Morin <[hidden email]>
> > Subject: Re: Screen Widget Ideas
> > To: [hidden email]
> > Date: Saturday, May 15, 2010, 4:11 AM
> > Pure model objects with no behavior
> > in them, and a visitor pattern to externalize the
> > behavior.... man, that's music to my ears!
> >
> > We've added a visitor pattern to all the "model" objects,
> > screens, forms, menus, entity,....
> >
> > It has proven invaluable to enable walking and manipulating
> > the model, without increasing the complexity of the
> > underlying model objects.
> >
> > Also, as your specific example indicates, the "renderers"
> > are a perfect use case for visitors, as the rendered is
> > technically and interpreter of the model objects.
> >
> > Marc
> > ----- "Adrian Crum" <[hidden email]>
> > wrote:
> >
> > > --- On Fri, 5/14/10, Scott Gray <[hidden email]>
> > wrote:
> > > > On 15/05/2010, at 3:43 PM, Adrian
> > > > Crum wrote:
> > > >
> > > > > I've been thinking about some improvements
> > to the
> > > > screen widgets, and I thought I would offer some
> > ideas and
> > > > see if there is any interest. I'm kind of
> > thinking out loud
> > > > here, so the ideas are not fully developed.
> > Please comment
> > > > or add your suggestions.
> > > > >
> > > > > 1. Use the factory pattern to create model
> > widgets.
> > > > Right now model widget construction is handled
> > internally
> > > > with a pre-defined set of classes. The idea is to
> > move the
> > > > model widget creation to a factory method that
> > accepts a
> > > > candidate XML element. If a matching model widget
> > is found,
> > > > return it, otherwise throw an exception. The
> > factory
> > > > supports user-created model widgets, so the
> > screen widgets
> > > > are extensible. In other words, you can create
> > your own
> > > > model widgets, register them with the factory,
> > and the
> > > > screen renderer will use them just like any other
> > widget.
> > > > You could even create your own replacement
> > implentations of
> > > > existing OFBiz screen widgets. User-created
> > widgets can use
> > > > namespaces on the XML side to avoid XML parsing
> > errors.
> > > >
> > > > That's crazy, I've been looking into this
> > today. I
> > > > had figured on using an include-widget tag.
> > > > I was also thinking about the PITA way that we
> > pass widget
> > > > renderers around and wondering if we couldn't
> > just have a
> > > > render method on the model that takes a writer,
> > the context
> > > > and a content type. The model then has an
> > internal
> > > > factory that gets the configured renderer based
> > on the
> > > > content type.
> > >
> > > At least we're basically on the same page. My
> > perspective all along is
> > > that the screen widgets should be nothing more than
> > data structures in
> > > memory that support the visitor pattern. Renderers
> > implement the
> > > visitor interface. Implementations of the visitor
> > interface could be
> > > anything: HTML renderers, Swing renderers, artifact
> > gatherers, layout
> > > managers (an intermediate form of renderer), pretty
> > printers, etc.
> > >
> > > There is so much room for improvement, but experience
> > has shown that
> > > the screen widgets have become a sort of sacred cow,
> > so changes like
> > > that will be met with a lot of resistance.
> > >
> > > > > 2. Add Groovy support to the
> > <include-screen>
> > > > widget. If the location attribute ends with
> > ".groovy" pass
> > > > control to the specified Groovy script. The
> > script would
> > > > behave like a screen widget and it will have
> > access to all
> > > > model widgets - so existing widget code can still
> > be used.
> > > > This could help in certain cases where screen
> > widgets can't
> > > > fulfill a particular need. It has been suggested
> > that CDATA
> > > > elements be allowed in screen widgets so that
> > free-form code
> > > > can be inserted in widget XML - this is an
> > alternative
> > > > solution to that. The benefit is you can leverage
> > the power
> > > > of Groovy in controlling screen output. The
> > drawback is any
> > > > such script will break the structure of screen
> > widgets and
> > > > it will start to look like JSP - where data
> > preparation code
> > > > is mixed with presentation code.
> > > >
> > > > This sounds more like a custom renderer rather
> > than
> > > > something that should go into the model.
> > >
> > > It's not a custom renderer - the output is still the
> > same as the
> > > original view. It's just a different way of looking at
> > screen
> > > rendering. Instead of screen widgets calling scripts,
> > a script calls
> > > screen widgets. In other words, instead of
> > XML-generated-widgets being
> > > in charge of Groovy, Groovy is in charge of the
> > XML-generated-widgets.
> > > Think about it.
> > >
> > > -Adrian
> >

Marc Morin

Re: Screen Widget Ideas

In reply to this post by Adrian Crum-2

Google Guice seems really interesting approach to handling "factories". Anyone had any experience with it?

Marc
----- "Adrian Crum" <[hidden email]> wrote:

Adrian Crum-2

Re: Screen Widget Ideas

How would we use dependency injection in the screen widgets?

-Adrian

--- On Sat, 5/15/10, Marc Morin <[hidden email]> wrote:

> Google Guice seems really interesting
> approach to handling "factories". Anyone had any
> experience with it?
>
> Marc
> ----- "Adrian Crum" <[hidden email]>
> wrote:
>
> > Marc,
> >
> > Do you have any thoughts on the first two ideas I
> proposed?
> >
> > -Adrian
> >
> > --- On Sat, 5/15/10, Marc Morin <[hidden email]>
> wrote:
> >
> > > From: Marc Morin <[hidden email]>
> > > Subject: Re: Screen Widget Ideas
> > > To: [hidden email]
> > > Date: Saturday, May 15, 2010, 4:11 AM
> > > Pure model objects with no behavior
> > > in them, and a visitor pattern to externalize
> the
> > > behavior.... man, that's music to my ears!
> > >
> > > We've added a visitor pattern to all the "model"
> objects,
> > > screens, forms, menus, entity,....
> > >
> > > It has proven invaluable to enable walking and
> manipulating
> > > the model, without increasing the complexity of
> the
> > > underlying model objects.
> > >
> > > Also, as your specific example indicates, the
> "renderers"
> > > are a perfect use case for visitors, as the
> rendered is
> > > technically and interpreter of the model
> objects.
> > >
> > > Marc
> > > ----- "Adrian Crum" <[hidden email]>
> > > wrote:
> > >
> > > > --- On Fri, 5/14/10, Scott Gray <[hidden email]>
> > > wrote:
> > > > > On 15/05/2010, at 3:43 PM, Adrian
> > > > > Crum wrote:
> > > > >
> > > > > > I've been thinking about some
> improvements
> > > to the
> > > > > screen widgets, and I thought I would
> offer some
> > > ideas and
> > > > > see if there is any interest. I'm kind
> of
> > > thinking out loud
> > > > > here, so the ideas are not fully
> developed.
> > > Please comment
> > > > > or add your suggestions.
> > > > > >
> > > > > > 1. Use the factory pattern to
> create model
> > > widgets.
> > > > > Right now model widget construction is
> handled
> > > internally
> > > > > with a pre-defined set of classes. The
> idea is to
> > > move the
> > > > > model widget creation to a factory
> method that
> > > accepts a
> > > > > candidate XML element. If a matching
> model widget
> > > is found,
> > > > > return it, otherwise throw an
> exception. The
> > > factory
> > > > > supports user-created model widgets, so
> the
> > > screen widgets
> > > > > are extensible. In other words, you can
> create
> > > your own
> > > > > model widgets, register them with the
> factory,
> > > and the
> > > > > screen renderer will use them just like
> any other
> > > widget.
> > > > > You could even create your own
> replacement
> > > implentations of
> > > > > existing OFBiz screen widgets.
> User-created
> > > widgets can use
> > > > > namespaces on the XML side to avoid XML
> parsing
> > > errors.
> > > > >
> > > > > That's crazy, I've been looking into
> this
> > > today. I
> > > > > had figured on using an include-widget
> tag.
> > > > > I was also thinking about the PITA way
> that we
> > > pass widget
> > > > > renderers around and wondering if we
> couldn't
> > > just have a
> > > > > render method on the model that takes a
> writer,
> > > the context
> > > > > and a content type. The model then
> has an
> > > internal
> > > > > factory that gets the configured
> renderer based
> > > on the
> > > > > content type.
> > > >
> > > > At least we're basically on the same page.
> My
> > > perspective all along is
> > > > that the screen widgets should be nothing
> more than
> > > data structures in
> > > > memory that support the visitor pattern.
> Renderers
> > > implement the
> > > > visitor interface. Implementations of the
> visitor
> > > interface could be
> > > > anything: HTML renderers, Swing renderers,
> artifact
> > > gatherers, layout
> > > > managers (an intermediate form of renderer),
> pretty
> > > printers, etc.
> > > >
> > > > There is so much room for improvement, but
> experience
> > > has shown that
> > > > the screen widgets have become a sort of
> sacred cow,
> > > so changes like
> > > > that will be met with a lot of resistance.
> > > >
> > > > > > 2. Add Groovy support to the
> > > <include-screen>
> > > > > widget. If the location attribute ends
> with
> > > ".groovy" pass
> > > > > control to the specified Groovy script.
> The
> > > script would
> > > > > behave like a screen widget and it will
> have
> > > access to all
> > > > > model widgets - so existing widget code
> can still
> > > be used.
> > > > > This could help in certain cases where
> screen
> > > widgets can't
> > > > > fulfill a particular need. It has been
> suggested
> > > that CDATA
> > > > > elements be allowed in screen widgets
> so that
> > > free-form code
> > > > > can be inserted in widget XML - this is
> an
> > > alternative
> > > > > solution to that. The benefit is you
> can leverage
> > > the power
> > > > > of Groovy in controlling screen output.
> The
> > > drawback is any
> > > > > such script will break the structure of
> screen
> > > widgets and
> > > > > it will start to look like JSP - where
> data
> > > preparation code
> > > > > is mixed with presentation code.
> > > > >
> > > > > This sounds more like a custom renderer
> rather
> > > than
> > > > > something that should go into the
> model.
> > > >
> > > > It's not a custom renderer - the output is
> still the
> > > same as the
> > > > original view. It's just a different way of
> looking at
> > > screen
> > > > rendering. Instead of screen widgets calling
> scripts,
> > > a script calls
> > > > screen widgets. In other words, instead of
> > > XML-generated-widgets being
> > > > in charge of Groovy, Groovy is in charge of
> the
> > > XML-generated-widgets.
> > > > Think about it.
> > > >
> > > > -Adrian
> > >
>

Adrian Crum-2

Re: Screen Widget Ideas

In reply to this post by Adrian Crum-2

Revision 944898 contains an initial implementation of the screen widget factory. Right now it only works with screen sub-widgets. It could be extended to add a form field factory - so users could create custom field widgets.

It would be nice if we could take all of the sub-widget classes out of ModelScreenWidget.java and move them to a SubWidgets.java file. SubWidgets could implement WidgetLoader to register all of the contained classes with the factory. ModelScreenWidget.java would then be nothing more than an abstract class. Those changes would really help organize some of the widget code, but moving the classes around could be an issue for some users.

-Adrian

--- On Fri, 5/14/10, Adrian Crum <[hidden email]> wrote:

> From: Adrian Crum <[hidden email]>
> Subject: Screen Widget Ideas
> To: [hidden email]
> Date: Friday, May 14, 2010, 8:43 PM
> I've been thinking about some
> improvements to the screen widgets, and I thought I would
> offer some ideas and see if there is any interest. I'm kind
> of thinking out loud here, so the ideas are not fully
> developed. Please comment or add your suggestions.
>
> 1. Use the factory pattern to create model widgets. Right
> now model widget construction is handled internally with a
> pre-defined set of classes. The idea is to move the model
> widget creation to a factory method that accepts a candidate
> XML element. If a matching model widget is found, return it,
> otherwise throw an exception. The factory supports
> user-created model widgets, so the screen widgets are
> extensible. In other words, you can create your own model
> widgets, register them with the factory, and the screen
> renderer will use them just like any other widget. You could
> even create your own replacement implentations of existing
> OFBiz screen widgets. User-created widgets can use
> namespaces on the XML side to avoid XML parsing errors.
>
> 2. Add Groovy support to the <include-screen> widget.
> If the location attribute ends with ".groovy" pass control
> to the specified Groovy script. The script would behave like
> a screen widget and it will have access to all model widgets
> - so existing widget code can still be used. This could help
> in certain cases where screen widgets can't fulfill a
> particular need. It has been suggested that CDATA elements
> be allowed in screen widgets so that free-form code can be
> inserted in widget XML - this is an alternative solution to
> that. The benefit is you can leverage the power of Groovy in
> controlling screen output. The drawback is any such script
> will break the structure of screen widgets and it will start
> to look like JSP - where data preparation code is mixed with
> presentation code.
>
> What do you think? Any other suggestions for improvements?
>
> -Adrian
>
>
>
>
>

Adrian Crum

Re: Screen Widget Ideas

In reply to this post by Marc Morin

I created a Jira issue for this subject:

https://issues.apache.org/jira/browse/OFBIZ-3774

-Adrian

On 5/15/2010 4:11 AM, Marc Morin wrote:

> Pure model objects with no behavior in them, and a visitor pattern to externalize the behavior.... man, that's music to my ears!
>
> We've added a visitor pattern to all the "model" objects, screens, forms, menus, entity,....
>
> It has proven invaluable to enable walking and manipulating the model, without increasing the complexity of the underlying model objects.
>
> Also, as your specific example indicates, the "renderers" are a perfect use case for visitors, as the rendered is technically and interpreter of the model objects.
>
> Marc
> ----- "Adrian Crum"<[hidden email]> wrote:
>
>> --- On Fri, 5/14/10, Scott Gray<[hidden email]> wrote:
>>> On 15/05/2010, at 3:43 PM, Adrian
>>> Crum wrote:
>>>
>>>> I've been thinking about some improvements to the
>>> screen widgets, and I thought I would offer some ideas and
>>> see if there is any interest. I'm kind of thinking out loud
>>> here, so the ideas are not fully developed. Please comment
>>> or add your suggestions.
>>>>
>>>> 1. Use the factory pattern to create model widgets.
>>> Right now model widget construction is handled internally
>>> with a pre-defined set of classes. The idea is to move the
>>> model widget creation to a factory method that accepts a
>>> candidate XML element. If a matching model widget is found,
>>> return it, otherwise throw an exception. The factory
>>> supports user-created model widgets, so the screen widgets
>>> are extensible. In other words, you can create your own
>>> model widgets, register them with the factory, and the
>>> screen renderer will use them just like any other widget.
>>> You could even create your own replacement implentations of
>>> existing OFBiz screen widgets. User-created widgets can use
>>> namespaces on the XML side to avoid XML parsing errors.
>>>
>>> That's crazy, I've been looking into this today. I
>>> had figured on using an include-widget tag.
>>> I was also thinking about the PITA way that we pass widget
>>> renderers around and wondering if we couldn't just have a
>>> render method on the model that takes a writer, the context
>>> and a content type. The model then has an internal
>>> factory that gets the configured renderer based on the
>>> content type.
>>
>> At least we're basically on the same page. My perspective all along is
>> that the screen widgets should be nothing more than data structures in
>> memory that support the visitor pattern. Renderers implement the
>> visitor interface. Implementations of the visitor interface could be
>> anything: HTML renderers, Swing renderers, artifact gatherers, layout
>> managers (an intermediate form of renderer), pretty printers, etc.
>>
>> There is so much room for improvement, but experience has shown that
>> the screen widgets have become a sort of sacred cow, so changes like
>> that will be met with a lot of resistance.
>>
>>>> 2. Add Groovy support to the<include-screen>
>>> widget. If the location attribute ends with ".groovy" pass
>>> control to the specified Groovy script. The script would
>>> behave like a screen widget and it will have access to all
>>> model widgets - so existing widget code can still be used.
>>> This could help in certain cases where screen widgets can't
>>> fulfill a particular need. It has been suggested that CDATA
>>> elements be allowed in screen widgets so that free-form code
>>> can be inserted in widget XML - this is an alternative
>>> solution to that. The benefit is you can leverage the power
>>> of Groovy in controlling screen output. The drawback is any
>>> such script will break the structure of screen widgets and
>>> it will start to look like JSP - where data preparation code
>>> is mixed with presentation code.
>>>
>>> This sounds more like a custom renderer rather than
>>> something that should go into the model.
>>
>> It's not a custom renderer - the output is still the same as the
>> original view. It's just a different way of looking at screen
>> rendering. Instead of screen widgets calling scripts, a script calls
>> screen widgets. In other words, instead of XML-generated-widgets being
>> in charge of Groovy, Groovy is in charge of the XML-generated-widgets.
>> Think about it.
>>
>> -Adrian
>

Harmeet Bedi

Re: Screen Widget Ideas

In reply to this post by Adrian Crum-2

Few ideas
- You could externalize sub-widget injection to be outside the widgets.
Currently ModelScreenWidget has list of subWidgets - a somewhat weakly
typed collection. If you want dependencies to be more specific, may help
clean things up to externalize.. or externalization may help set pattern
up for making dependencies specific.
- Helps test. esp. if bulk of system is DI based.
- A nice pattern to follow. makes system more passive(IOC ish) and
pluggable.

Harmeet

On 15/05/10 10:15 PM, Adrian Crum wrote:
> How would we use dependency injection in the screen widgets?
>
> -Adrian