Brainstorming about the Framework: UI Tier

[David E. Jones-2]

If you could change anything about the user interface tier in OFBiz (basically the ControlServlet, the various widgets (Screen, Form, Menu, Tree), the separate webapps, actions in (or not in) groovy, etc), what would you change?

All comments are welcome. If there is another tool you'd like to see used instead of the Screen Widget (for example), please describe what you like about it (like "I like to orchestrate my web pages using Java classes" or "I like having fewer/more/bigger/smaller files" or "I hate having to declare every request and view" or "I wish the screens used included screens top-down instead of the bottom-up decorator pattern") instead of just mentioning the tool (like "let's use Struts!").

Why am I asking? This topic comes up every once in a while, and it's true that many suggestions never get enough support to actually happen (or on further research it is decided that the idea is not tenable), but brainstorming about them to get ideas in the open is still a great thing. The history of OFBiz is full of things like this where users and more casual contributors had ideas and saw possibilities that others, even more involved contributors, totally missed or never looked at that way. What I think would be fun, and ultimately useful too, is to keep this mostly to brainstorming and not do too much comparing of ideas.

BTW, if you want to brainstorm about another tier (ie the Data or Logic tiers) please use the other threads on those. If you'd like to discuss things that aren't specific to a tier look for the "General" thread.

-David

[Ruth Hoffman-2]

Hi David:
First, thanks for asking!
IMO:
The ControlServlet/controller.xml configuration is easy to follow and
works like a charm. Any problems with it arise when the controller.xml
file is split across multiple webapps. (But, that is just my own
personal opinion. If there are any common elements, then they can just
be duplicated in each webapp's controller.xml. Its much harder to
maintain an instance of OFBiz if controller.xml files are spread all
over the place. )

My biggest angst concerning widgets is that configuration files are all
over the place. I understand the concept of re-use across the entire UI,
but at some point, you just have to say enough is enough. The second
issue I have is that building HTML using XML is just counter-intuitive
and requires knowledge of not just HTML/CSS but also OFBiz specific
knowledge of the XML declarations necessary to build the HTML, call the
Entity Engine and/or Services etc.  But, I digress.

I wouldn't take away widgets. I'd add a tool that helps build HTML using
widgets. A graphical tool that has drag'n drop with page layouts etc.
would be nice. Once I had that working, I'd apply the "tutorial", drag'n
drop concept to the back-end applications. Trying to configure OFBiz
using the existing forms is really tough. If we had a way to build UI's
that were more user friendly (intuitive) (for example, like using the
shopping cart to place UI components in a cart as the UI builder
positions them on a web page), that would be really neat!


More to come...
Regards,
Ruth
----------------------------------------------------
Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
[hidden email]

David E Jones wrote:

> If you could change anything about the user interface tier in OFBiz (basically the ControlServlet, the various widgets (Screen, Form, Menu, Tree), the separate webapps, actions in (or not in) groovy, etc), what would you change?
>
> All comments are welcome. If there is another tool you'd like to see used instead of the Screen Widget (for example), please describe what you like about it (like "I like to orchestrate my web pages using Java classes" or "I like having fewer/more/bigger/smaller files" or "I hate having to declare every request and view" or "I wish the screens used included screens top-down instead of the bottom-up decorator pattern") instead of just mentioning the tool (like "let's use Struts!").
>
> Why am I asking? This topic comes up every once in a while, and it's true that many suggestions never get enough support to actually happen (or on further research it is decided that the idea is not tenable), but brainstorming about them to get ideas in the open is still a great thing. The history of OFBiz is full of things like this where users and more casual contributors had ideas and saw possibilities that others, even more involved contributors, totally missed or never looked at that way. What I think would be fun, and ultimately useful too, is to keep this mostly to brainstorming and not do too much comparing of ideas.
>
> BTW, if you want to brainstorm about another tier (ie the Data or Logic tiers) please use the other threads on those. If you'd like to discuss things that aren't specific to a tier look for the "General" thread.
>
> -David
>
>
>  

[BJ Freeman]

The main thrust of the UI, from a developers point of view, is to make
creating the layout simple.
but this I mean a WYSIWYG editor for widgets.
As a intermediated step to this, I have used cloudgardens app for
created Swing UI's.
it created an xml output.
I then use a transform to make it into widgets.
One of the short falls of this approach is Cloud gardens is not aware of
the entities so can not pull them up to paste them into the editor.

I see it going into the content component and we have a basic WYSIWYG
engine this would allow all the Event and view handlers to be used.

this is important enough to me to put some energy into it first at the
design level(wiki), then in coding.

the time spent, would more than be made up in the ease of editing the UI.


=========================
BJ Freeman
http://bjfreeman.elance.com
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=93>
Specialtymarket.com <http://www.specialtymarket.com/>

Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man
Linkedin
<http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro>


David E Jones sent the following on 3/10/2010 11:19 PM:

> If you could change anything about the user interface tier in OFBiz (basically the ControlServlet, the various widgets (Screen, Form, Menu, Tree), the separate webapps, actions in (or not in) groovy, etc), what would you change?
>
> All comments are welcome. If there is another tool you'd like to see used instead of the Screen Widget (for example), please describe what you like about it (like "I like to orchestrate my web pages using Java classes" or "I like having fewer/more/bigger/smaller files" or "I hate having to declare every request and view" or "I wish the screens used included screens top-down instead of the bottom-up decorator pattern") instead of just mentioning the tool (like "let's use Struts!").
>
> Why am I asking? This topic comes up every once in a while, and it's true that many suggestions never get enough support to actually happen (or on further research it is decided that the idea is not tenable), but brainstorming about them to get ideas in the open is still a great thing. The history of OFBiz is full of things like this where users and more casual contributors had ideas and saw possibilities that others, even more involved contributors, totally missed or never looked at that way. What I think would be fun, and ultimately useful too, is to keep this mostly to brainstorming and not do too much comparing of ideas.
>
> BTW, if you want to brainstorm about another tier (ie the Data or Logic tiers) please use the other threads on those. If you'd like to discuss things that aren't specific to a tier look for the "General" thread.
>
> -David
>
>

[james_sg]

Hi,

I have the following 3 suggestions.

1. As screen widgets add a layer of abstraction above html, the codes are cleaner than those in ftl.
So I wish more UI codes be written in or converted to widgets.

2. A new view handler that will take care of ajax on the fly when the screen widgets are rendered. The benefit is code reuse, any improvement to the view handler affects the whole application.

3. Even better is for this new view handler to act as a intermediary between the screen widgets and the existing view framework like wicket, echo3 etc

Regards,
James

David E Jones-4 wrote

If you could change anything about the user interface tier in OFBiz (basically the ControlServlet, the various widgets (Screen, Form, Menu, Tree), the separate webapps, actions in (or not in) groovy, etc), what would you change?

[Adrian Crum]

David E Jones wrote:
> If you could change anything about the user interface tier in OFBiz (basically the ControlServlet, the various widgets (Screen, Form, Menu, Tree), the separate webapps, actions in (or not in) groovy, etc), what would you change?

1. Reorganize the widget Java code so updates/enhancements are easier.

2. WebDAV support. Instead of using Eclipse to design the UI, use
something like Dreamweaver.

[Jacques Le Roux]

From: "Adrian Crum" <[hidden email]>
> David E Jones wrote:
>> If you could change anything about the user interface tier in OFBiz (basically the ControlServlet, the various widgets (Screen,
>> Form, Menu, Tree), the separate webapps, actions in (or not in) groovy, etc), what would you change?
>
> 1. Reorganize the widget Java code so updates/enhancements are easier.
>
> 2. WebDAV support. Instead of using Eclipse to design the UI, use something like Dreamweaver.

Have mercy, not Dreamweaver!

Jacques

[Jacques Le Roux]

From: "james_sg" <[hidden email]>
> Hi,
>
> I have the following 3 suggestions.
>
> 1. As screen widgets add a layer of abstraction above html, the codes are
> cleaner than those in ftl.
> So I wish more UI codes be written in or converted to widgets.

I second that, and for instance Bruno has begun to work on converting lookups.
Would you want to join the effort? Any help is appreciated!
https://issues.apache.org/jira/browse/OFBIZ-3541
When this will be done I will apply the layered lookup to the FLT files again, but with a better rendered quality.

Jacques

> 2. A new view handler that will take care of ajax on the fly when the screen
> widgets are rendered. The benefit is code reuse, any improvement to the view
> handler affects the whole application.
>
> 3. Even better is for this new view handler to act as a intermediary between
> the screen widgets and the existing view framework like wicket, echo3 etc
>
> Regards,
> James
>
>
> David E Jones-4 wrote:
>>
>>
>> If you could change anything about the user interface tier in OFBiz
>> (basically the ControlServlet, the various widgets (Screen, Form, Menu,
>> Tree), the separate webapps, actions in (or not in) groovy, etc), what
>> would you change?
>>
>>
>
> --
> View this message in context: http://n4.nabble.com/Brainstorming-about-the-Framework-UI-Tier-tp1588522p1589231.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
>

[Bruno Busco]

Hi David,
1) A PortalPage widget would be useful in order to easily add
user-customizable areas in every screen
2) We need a way to have components to extend the UI of the components they
depend on. See https://issues.apache.org/jira/browse/OFBIZ-3373
3) A collapsible left column (containing a PortalPage widget) would allow to
have more information on the screen
4) Generally more consistency. All the screens of all applications should be
more similar in the layout

-Bruno


2010/3/11 David E Jones <[hidden email]>

>
> If you could change anything about the user interface tier in OFBiz
> (basically the ControlServlet, the various widgets (Screen, Form, Menu,
> Tree), the separate webapps, actions in (or not in) groovy, etc), what would
> you change?
>
> All comments are welcome. If there is another tool you'd like to see used
> instead of the Screen Widget (for example), please describe what you like
> about it (like "I like to orchestrate my web pages using Java classes" or "I
> like having fewer/more/bigger/smaller files" or "I hate having to declare
> every request and view" or "I wish the screens used included screens
> top-down instead of the bottom-up decorator pattern") instead of just
> mentioning the tool (like "let's use Struts!").
>
> Why am I asking? This topic comes up every once in a while, and it's true
> that many suggestions never get enough support to actually happen (or on
> further research it is decided that the idea is not tenable), but
> brainstorming about them to get ideas in the open is still a great thing.
> The history of OFBiz is full of things like this where users and more casual
> contributors had ideas and saw possibilities that others, even more involved
> contributors, totally missed or never looked at that way. What I think would
> be fun, and ultimately useful too, is to keep this mostly to brainstorming
> and not do too much comparing of ideas.
>
> BTW, if you want to brainstorm about another tier (ie the Data or Logic
> tiers) please use the other threads on those. If you'd like to discuss
> things that aren't specific to a tier look for the "General" thread.
>
> -David
>
>

[Rodrigo Lima-2]

Hi David,

I suggest the creation of specialized handlers for the platform from Adobe,
Flex.Being practical, Remote Objects.
Even easier, create libraries of custom implementation, as are the layers
below (Screen, Form, Menu, Tree).
I am a potential contributor in this process.

Rodrigo

2010/3/11 Bruno Busco <[hidden email]>

> Hi David,
> 1) A PortalPage widget would be useful in order to easily add
> user-customizable areas in every screen
> 2) We need a way to have components to extend the UI of the components they
> depend on. See https://issues.apache.org/jira/browse/OFBIZ-3373
> 3) A collapsible left column (containing a PortalPage widget) would allow
> to
> have more information on the screen
> 4) Generally more consistency. All the screens of all applications should
> be
> more similar in the layout
>
> -Bruno
>
>
> 2010/3/11 David E Jones <[hidden email]>
>
> >
> > If you could change anything about the user interface tier in OFBiz
> > (basically the ControlServlet, the various widgets (Screen, Form, Menu,
> > Tree), the separate webapps, actions in (or not in) groovy, etc), what
> would
> > you change?
> >
> > All comments are welcome. If there is another tool you'd like to see used
> > instead of the Screen Widget (for example), please describe what you like
> > about it (like "I like to orchestrate my web pages using Java classes" or
> "I
> > like having fewer/more/bigger/smaller files" or "I hate having to declare
> > every request and view" or "I wish the screens used included screens
> > top-down instead of the bottom-up decorator pattern") instead of just
> > mentioning the tool (like "let's use Struts!").
> >
> > Why am I asking? This topic comes up every once in a while, and it's true
> > that many suggestions never get enough support to actually happen (or on
> > further research it is decided that the idea is not tenable), but
> > brainstorming about them to get ideas in the open is still a great thing.
> > The history of OFBiz is full of things like this where users and more
> casual
> > contributors had ideas and saw possibilities that others, even more
> involved
> > contributors, totally missed or never looked at that way. What I think
> would
> > be fun, and ultimately useful too, is to keep this mostly to
> brainstorming
> > and not do too much comparing of ideas.
> >
> > BTW, if you want to brainstorm about another tier (ie the Data or Logic
> > tiers) please use the other threads on those. If you'd like to discuss
> > things that aren't specific to a tier look for the "General" thread.
> >
> > -David
> >
> >
>

[james_sg]

Hi Jacques,

I am involved in an OFBiz implementation, but may join the effort once things are more managable.

Regards,
James

Jacques Le Roux wrote

From: "james_sg" <[e-mail]>
> Hi,
>
> I have the following 3 suggestions.
>
> 1. As screen widgets add a layer of abstraction above html, the codes are
> cleaner than those in ftl.
> So I wish more UI codes be written in or converted to widgets.

I second that, and for instance Bruno has begun to work on converting lookups.
Would you want to join the effort? Any help is appreciated!
https://issues.apache.org/jira/browse/OFBIZ-3541
When this will be done I will apply the layered lookup to the FLT files again, but with a better rendered quality.

Jacques

> 2. A new view handler that will take care of ajax on the fly when the screen
> widgets are rendered. The benefit is code reuse, any improvement to the view
> handler affects the whole application.
>
> 3. Even better is for this new view handler to act as a intermediary between
> the screen widgets and the existing view framework like wicket, echo3 etc
>
> Regards,
> James