OFBiz › OFBiz - Dev

Using Apache Wicket in Ofbiz presentation layer

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

24 messages Options

Vasanth Kamatgi

Using Apache Wicket in Ofbiz presentation layer

Hi all,

Firstly I would like to thank David E. Jones
<http://www.blogger.com/profile/07283017166339658819> , for his
encouragement to use the community process.

I had previously posted a question in this community at
http://n4.nabble.com/Application-framework-technology-set-tp195713p963334.ht
ml as a very terse summary of my thoughts. After having a private
conversation with David, I thought a much in-depth discussion on the
presentation layer would be beneficial to me as well as the community and
consequently I am starting a new thread of discussion.

Here is my primary complaint of Ofbiz presentation Layer - "There isn't a
STRICT separation of UI / Code in the presentation layer. Due to this
deficiency, for any revamp in the UI, even though there is no associated
change in the functionality / business logic, it takes substantial amount of
developer time. I see this as a major hindrance to a typical ecommerce
website, where UI changes are frequent as well as significant."

To give more insight into why I have this complaint, let me raise some
questions (and answer them):

What I think a presentation Layer does?

=============================

I believe presentation layer can be divided into 6 areas of concern:

Data Preparation - Events / Service (a.k.a actions) generate data that need
to be processed to result into a *shape* that can be directly used by a
view. Eg., only product category id exists in context, we need to display
category name as well - fetch it.

Layout - It controls the relative position of each of the components inside
a page. Wireframes used to build the page.

Page composition - Different areas of the page can be generated by a
separate component / screen, and the generated output needs to be stitched
together to result into a complete response

Look and Feel - Visual properties of components of the page (css?)

View Logic - The logic that controls the initial state of each elements of
the output - like enabling, disabling, non-display etc., of specific output
elements. Eg., if sale price exists, show it in large red font, strike
through the list price, else show list price in large font.

Rich dynamic behaviour - the dynamic behaviour that each of the generated
output needs to provide inside user-agent's environment (javascript / dhtml)

How have I set the things up in Ofbiz?

===========================

1. I have created my primary page layout a.k.a. decorator in
common-screens.xml using sections, actions, widgets, html-templates,
containers, etc.
2. I have abstracted out the common section contents as say,
includes/header.ftl etc.
3. I have created components of a page such as choose catalog, keyword
search box, etc. as screens (non-top level) using actions and html templates
in, say, catalog-screens.xml
4. I create a complete response page as a screen in catalog-screens.xml
using actions, widgets, decorator-screen, decorator-section, include-screen,
etc. in, say, catalog-screens.xml
5. I specify this top-level page as view, which I link to the
associated event / service via request map in controller.xml

The actual response out is defined in html fragments in various files
defined in #2, #3 & #4

Exactly what is it that I find cumbersome?

==============================

UI Designer prepares the prototype, hands it over to the Ofbiz developer,
who splits it into different fragments, and creates ftls for each of those
sections. Then, adds page composition, view logic and rich dynamic
behaviour to those ftls. This complete sequence of steps is irreversible.
Once handover happens from UI designer to Ofbiz developer, the html / css
ceases to exist in its native form, making it impossible for the UI designer
to "maintain" it. Any UI bug / change request cannot be fixed by UI
designer. UI designer first analyses the problem reports the possible
causes to Ofbiz developer, who figures out which ftl file to edit and goes
and edits it. If a drop down box needs to move from one widget to another,
Ofbiz developer employs a cut+paste job that can be so error-prone with
missing tag closures, quotes, duplicates etc. There have been so many
instances of Ofbiz developer trying to fix UI issues, but failing to do so
because he / she is good at writing java-like, jsp-like and javascript-like
code and not standards-compliant html / css code. He can't use visual tools
like a UI designer to improve his productivity. Throw into this mix the
cross-browser compatibility issue - the whole effort becomes very
unproductive with UI designer, Ofbiz developer working together to fix it,
when it should actually be handled by UI designer alone.

Ofbiz supports data preparation, page composition, view logic well. But
other areas are a little troublesome.

How would I like it to work?

====================

Different areas of concern, as listed in my previous paragraph, are best
worked at by different types of resources. Assuming we are using java
platform for development:

Data Preparation - java coder

Layout - UI designer / business analyst / SEO specialist

Page composition - java / jsp coder

Look and Feel - User Experience expert

View Logic - java / jsp coder

Rich dynamic behaviour - script coder / java coder

Given these different areas of expertise, a software development /
maintenance model needs to be employed to enable these types of resources to
work at full productivity without tripping each other. Cutting a long story
short, I believe, Ofbiz should enable html, css, multi-media & view logic to
be developed and managed independently. UI designer should continue to fix
UI bugs by just editing his / her html code. There should be no pollution
of html and css code. View logic should be written without using tags.

I have dived into wicket and wrote my first hello world recently and believe
wicket-like rendering would be a good enhancement to Ofbiz. I am not
claiming to be an expert of wicket, but based on the documentation I have
read, it seems to fit the scheme well.

I hope I have given enough details for the community to start a
conversation. I understand that, the question begs of not only an
architectural discussion, but also of a software development / maintenance
model.

Cheers,

Vasanth

David E. Jones-2

Re: Using Apache Wicket in Ofbiz presentation layer

To sum up:

1. you want a full separation of concerns for the different roles in your organization, something that won't require additional training beyond their existing skill set

2. you want no dependencies between different roles so they can't mess each other up or slow each other down

3. Apache Wicket will provide these things

Does that sound about right?

This sounds amazing! I can't wait to the see the results of an analysis and comparison for each requirement, and a proof of concept and per-activity comparison between the different approaches.

-David

On Dec 19, 2009, at 11:55 AM, Vasanth Kamatgi wrote:

> Hi all,
>
>
>
> Firstly I would like to thank David E. Jones
> <http://www.blogger.com/profile/07283017166339658819> , for his
> encouragement to use the community process.
>
> I had previously posted a question in this community at
> http://n4.nabble.com/Application-framework-technology-set-tp195713p963334.ht
> ml as a very terse summary of my thoughts. After having a private
> conversation with David, I thought a much in-depth discussion on the
> presentation layer would be beneficial to me as well as the community and
> consequently I am starting a new thread of discussion.
>
>
>
> Here is my primary complaint of Ofbiz presentation Layer - "There isn't a
> STRICT separation of UI / Code in the presentation layer. Due to this
> deficiency, for any revamp in the UI, even though there is no associated
> change in the functionality / business logic, it takes substantial amount of
> developer time. I see this as a major hindrance to a typical ecommerce
> website, where UI changes are frequent as well as significant."
>
>
>
> To give more insight into why I have this complaint, let me raise some
> questions (and answer them):
>
>
>
> What I think a presentation Layer does?
>
> =============================
>
> I believe presentation layer can be divided into 6 areas of concern:
>
> Data Preparation - Events / Service (a.k.a actions) generate data that need
> to be processed to result into a *shape* that can be directly used by a
> view. Eg., only product category id exists in context, we need to display
> category name as well - fetch it.
>
> Layout - It controls the relative position of each of the components inside
> a page. Wireframes used to build the page.
>
> Page composition - Different areas of the page can be generated by a
> separate component / screen, and the generated output needs to be stitched
> together to result into a complete response
>
> Look and Feel - Visual properties of components of the page (css?)
>
> View Logic - The logic that controls the initial state of each elements of
> the output - like enabling, disabling, non-display etc., of specific output
> elements. Eg., if sale price exists, show it in large red font, strike
> through the list price, else show list price in large font.
>
> Rich dynamic behaviour - the dynamic behaviour that each of the generated
> output needs to provide inside user-agent's environment (javascript / dhtml)
>
>
>
> How have I set the things up in Ofbiz?
>
> ===========================
>
> 1. I have created my primary page layout a.k.a. decorator in
> common-screens.xml using sections, actions, widgets, html-templates,
> containers, etc.
> 2. I have abstracted out the common section contents as say,
> includes/header.ftl etc.
> 3. I have created components of a page such as choose catalog, keyword
> search box, etc. as screens (non-top level) using actions and html templates
> in, say, catalog-screens.xml
> 4. I create a complete response page as a screen in catalog-screens.xml
> using actions, widgets, decorator-screen, decorator-section, include-screen,
> etc. in, say, catalog-screens.xml
> 5. I specify this top-level page as view, which I link to the
> associated event / service via request map in controller.xml
>
> The actual response out is defined in html fragments in various files
> defined in #2, #3 & #4
>
>
>
> Exactly what is it that I find cumbersome?
>
> ==============================
>
> UI Designer prepares the prototype, hands it over to the Ofbiz developer,
> who splits it into different fragments, and creates ftls for each of those
> sections. Then, adds page composition, view logic and rich dynamic
> behaviour to those ftls. This complete sequence of steps is irreversible.
> Once handover happens from UI designer to Ofbiz developer, the html / css
> ceases to exist in its native form, making it impossible for the UI designer
> to "maintain" it. Any UI bug / change request cannot be fixed by UI
> designer. UI designer first analyses the problem reports the possible
> causes to Ofbiz developer, who figures out which ftl file to edit and goes
> and edits it. If a drop down box needs to move from one widget to another,
> Ofbiz developer employs a cut+paste job that can be so error-prone with
> missing tag closures, quotes, duplicates etc. There have been so many
> instances of Ofbiz developer trying to fix UI issues, but failing to do so
> because he / she is good at writing java-like, jsp-like and javascript-like
> code and not standards-compliant html / css code. He can't use visual tools
> like a UI designer to improve his productivity. Throw into this mix the
> cross-browser compatibility issue - the whole effort becomes very
> unproductive with UI designer, Ofbiz developer working together to fix it,
> when it should actually be handled by UI designer alone.
>
> Ofbiz supports data preparation, page composition, view logic well. But
> other areas are a little troublesome.
>
>
>
> How would I like it to work?
>
> ====================
>
> Different areas of concern, as listed in my previous paragraph, are best
> worked at by different types of resources. Assuming we are using java
> platform for development:
>
> Data Preparation - java coder
>
> Layout - UI designer / business analyst / SEO specialist
>
> Page composition - java / jsp coder
>
> Look and Feel - User Experience expert
>
> View Logic - java / jsp coder
>
> Rich dynamic behaviour - script coder / java coder
>
> Given these different areas of expertise, a software development /
> maintenance model needs to be employed to enable these types of resources to
> work at full productivity without tripping each other. Cutting a long story
> short, I believe, Ofbiz should enable html, css, multi-media & view logic to
> be developed and managed independently. UI designer should continue to fix
> UI bugs by just editing his / her html code. There should be no pollution
> of html and css code. View logic should be written without using tags.
>
> I have dived into wicket and wrote my first hello world recently and believe
> wicket-like rendering would be a good enhancement to Ofbiz. I am not
> claiming to be an expert of wicket, but based on the documentation I have
> read, it seems to fit the scheme well.
>
>
>
> I hope I have given enough details for the community to start a
> conversation. I understand that, the question begs of not only an
> architectural discussion, but also of a software development / maintenance
> model.
>
>
>
> Cheers,
>
> Vasanth
>

hans_bakker

Re: Using Apache Wicket in Ofbiz presentation layer

In reply to this post by Vasanth Kamatgi

I had a quick look at wicket and this sounds pretty interesting for the
ecommerce component. Updating the ecommerce frontend UI is indeed
sometimes pretty cumbersome.

Looking forward to a proof of concept?

Regards,
Hans

On Sat, 2009-12-19 at 23:25 +0530, Vasanth Kamatgi wrote:

--
Antwebsystems.com: Quality OFBiz services for competitive rates

Vasanth Kamatgi-2

RE: Using Apache Wicket in Ofbiz presentation layer

In reply to this post by David E. Jones-2

You have summed it up well David. I am looking exactly at that problem.

We had not seen these problems when we started out with Ofbiz, nor did we
visualize at that time (4 years back) that we would face problems like
these, in future. I think it is a typical scale-up stage issue that Ofbiz
doesn't solve well where functionality and UI throughput expected is
exponentially large and complete team is not as multi-disciplined as the
original team was. I also think that Ofbiz presentation layer is a legacy
of MVC-II paradigm, which was in vogue at the time of design of Ofbiz and
which is now being *contested* by Component based frameworks like JSF, Flex
and Wicket.

1) I would like to hear from others, their views on the subject
2) How have other organizations handled this issue? Are there alternatives
within the existing Ofbiz framework, people have successfully employed?
3) I am not aware, how to kick-off the analysis, requirement comparison, POC
etc. activities. Guidance by community gurus would be a great help.

Cheers,
Vasanth

-----Original Message-----
From: David E Jones [mailto:[hidden email]]
Sent: Sunday, December 20, 2009 2:09 AM
To: [hidden email]
Subject: Re: Using Apache Wicket in Ofbiz presentation layer

To sum up:

1. you want a full separation of concerns for the different roles in your
organization, something that won't require additional training beyond their
existing skill set

2. you want no dependencies between different roles so they can't mess each
other up or slow each other down

3. Apache Wicket will provide these things

Does that sound about right?

This sounds amazing! I can't wait to the see the results of an analysis and
comparison for each requirement, and a proof of concept and per-activity
comparison between the different approaches.

-David

On Dec 19, 2009, at 11:55 AM, Vasanth Kamatgi wrote:

http://n4.nabble.com/Application-framework-technology-set-tp195713p963334.ht

> ml as a very terse summary of my thoughts. After having a private
> conversation with David, I thought a much in-depth discussion on the
> presentation layer would be beneficial to me as well as the community and
> consequently I am starting a new thread of discussion.
>
>
>
> Here is my primary complaint of Ofbiz presentation Layer - "There isn't a
> STRICT separation of UI / Code in the presentation layer. Due to this
> deficiency, for any revamp in the UI, even though there is no associated
> change in the functionality / business logic, it takes substantial amount

> developer time. I see this as a major hindrance to a typical ecommerce
> website, where UI changes are frequent as well as significant."
>
>
>
> To give more insight into why I have this complaint, let me raise some
> questions (and answer them):
>
>
>
> What I think a presentation Layer does?
>
> =============================
>
> I believe presentation layer can be divided into 6 areas of concern:
>
> Data Preparation - Events / Service (a.k.a actions) generate data that

need
> to be processed to result into a *shape* that can be directly used by a
> view. Eg., only product category id exists in context, we need to display
> category name as well - fetch it.
>
> Layout - It controls the relative position of each of the components
inside

> a page. Wireframes used to build the page.
>
> Page composition - Different areas of the page can be generated by a
> separate component / screen, and the generated output needs to be stitched
> together to result into a complete response
>
> Look and Feel - Visual properties of components of the page (css?)
>
> View Logic - The logic that controls the initial state of each elements of
> the output - like enabling, disabling, non-display etc., of specific

output
> elements. Eg., if sale price exists, show it in large red font, strike
> through the list price, else show list price in large font.
>
> Rich dynamic behaviour - the dynamic behaviour that each of the generated
> output needs to provide inside user-agent's environment (javascript /
dhtml)

>
>
>
> How have I set the things up in Ofbiz?
>
> ===========================
>
> 1. I have created my primary page layout a.k.a. decorator in
> common-screens.xml using sections, actions, widgets, html-templates,
> containers, etc.
> 2. I have abstracted out the common section contents as say,
> includes/header.ftl etc.
> 3. I have created components of a page such as choose catalog, keyword
> search box, etc. as screens (non-top level) using actions and html

templates
> in, say, catalog-screens.xml
> 4. I create a complete response page as a screen in catalog-screens.xml
> using actions, widgets, decorator-screen, decorator-section,
include-screen,

> etc. in, say, catalog-screens.xml
> 5. I specify this top-level page as view, which I link to the
> associated event / service via request map in controller.xml
>
> The actual response out is defined in html fragments in various files
> defined in #2, #3 & #4
>
>
>
> Exactly what is it that I find cumbersome?
>
> ==============================
>
> UI Designer prepares the prototype, hands it over to the Ofbiz developer,
> who splits it into different fragments, and creates ftls for each of those
> sections. Then, adds page composition, view logic and rich dynamic
> behaviour to those ftls. This complete sequence of steps is irreversible.
> Once handover happens from UI designer to Ofbiz developer, the html / css
> ceases to exist in its native form, making it impossible for the UI

designer
> to "maintain" it. Any UI bug / change request cannot be fixed by UI
> designer. UI designer first analyses the problem reports the possible
> causes to Ofbiz developer, who figures out which ftl file to edit and goes
> and edits it. If a drop down box needs to move from one widget to
another,
> Ofbiz developer employs a cut+paste job that can be so error-prone with
> missing tag closures, quotes, duplicates etc. There have been so many
> instances of Ofbiz developer trying to fix UI issues, but failing to do so
> because he / she is good at writing java-like, jsp-like and
javascript-like
> code and not standards-compliant html / css code. He can't use visual
tools

> like a UI designer to improve his productivity. Throw into this mix the
> cross-browser compatibility issue - the whole effort becomes very
> unproductive with UI designer, Ofbiz developer working together to fix it,
> when it should actually be handled by UI designer alone.
>
> Ofbiz supports data preparation, page composition, view logic well. But
> other areas are a little troublesome.
>
>
>
> How would I like it to work?
>
> ====================
>
> Different areas of concern, as listed in my previous paragraph, are best
> worked at by different types of resources. Assuming we are using java
> platform for development:
>
> Data Preparation - java coder
>
> Layout - UI designer / business analyst / SEO specialist
>
> Page composition - java / jsp coder
>
> Look and Feel - User Experience expert
>
> View Logic - java / jsp coder
>
> Rich dynamic behaviour - script coder / java coder
>
> Given these different areas of expertise, a software development /
> maintenance model needs to be employed to enable these types of resources

to
> work at full productivity without tripping each other. Cutting a long
story
> short, I believe, Ofbiz should enable html, css, multi-media & view logic
to
> be developed and managed independently. UI designer should continue to
fix
> UI bugs by just editing his / her html code. There should be no pollution
> of html and css code. View logic should be written without using tags.
>
> I have dived into wicket and wrote my first hello world recently and
believe

> wicket-like rendering would be a good enhancement to Ofbiz. I am not
> claiming to be an expert of wicket, but based on the documentation I have
> read, it seems to fit the scheme well.
>
>
>
> I hope I have given enough details for the community to start a
> conversation. I understand that, the question begs of not only an
> architectural discussion, but also of a software development / maintenance
> model.
>
>
>
> Cheers,
>
> Vasanth

Vasanth Kamatgi

RE: Using Apache Wicket in Ofbiz presentation layer

In reply to this post by David E. Jones-2

http://n4.nabble.com/Application-framework-technology-set-tp195713p963334.ht

templates
> in, say, catalog-screens.xml
> 4. I create a complete response page as a screen in catalog-screens.xml
> using actions, widgets, decorator-screen, decorator-section,
include-screen,

David E. Jones-2

Re: Using Apache Wicket in Ofbiz presentation layer

On Dec 19, 2009, at 9:32 PM, Vasanth Kamatgi wrote:

> 3) I am not aware, how to kick-off the analysis, requirement comparison, POC
> etc. activities. Guidance by community gurus would be a great help.

This is what I use with clients to do requirements gathering, design, etc for business applications, and it works just as well for development tools:

http://www.dejc.com/home/HEMP.html

-David

Shi Yusen

RE: Using Apache Wicket in Ofbiz presentation layer

In reply to this post by Vasanth Kamatgi

I guess you're doing what we did at our beginning.

David is a superman, we are not, so we have to do it in another way.

We decided to use OpenCms as the frontend several years ago, and then
the developers can be divided into 3 groups: UI developers (require JSP
only), OpenCms module developers (reusable GUIs and functions), OFBiz
service developers (extend OFBiz RMI/data to support OpenCms modules).
Now we also use portlets and flashes as UI.

Fish-bone diagram is helpful to analyse a business and implement it in
OFBiz. "Old OFBiz Standard Floating Layout" is more helpful to combine
consultant works with the OFBiz UI.

My 2 cents,

Shi Yusen/Beijing Langhua Ltd.

在 2009-12-20日的 09:02 +0530，Vasanth Kamatgi写道：

> You have summed it up well David. I am looking exactly at that problem.
>
> We had not seen these problems when we started out with Ofbiz, nor did we
> visualize at that time (4 years back) that we would face problems like
> these, in future. I think it is a typical scale-up stage issue that Ofbiz
> doesn't solve well where functionality and UI throughput expected is
> exponentially large and complete team is not as multi-disciplined as the
> original team was. I also think that Ofbiz presentation layer is a legacy
> of MVC-II paradigm, which was in vogue at the time of design of Ofbiz and
> which is now being *contested* by Component based frameworks like JSF, Flex
> and Wicket.
>
> 1) I would like to hear from others, their views on the subject
> 2) How have other organizations handled this issue? Are there alternatives
> within the existing Ofbiz framework, people have successfully employed?
> 3) I am not aware, how to kick-off the analysis, requirement comparison, POC
> etc. activities. Guidance by community gurus would be a great help.
>
> Cheers,
> Vasanth
>
> -----Original Message-----
> From: David E Jones [mailto:[hidden email]]
> Sent: Sunday, December 20, 2009 2:09 AM
> To: [hidden email]
> Subject: Re: Using Apache Wicket in Ofbiz presentation layer
>
>
> To sum up:
>
> 1. you want a full separation of concerns for the different roles in your
> organization, something that won't require additional training beyond their
> existing skill set
>
> 2. you want no dependencies between different roles so they can't mess each
> other up or slow each other down
>
> 3. Apache Wicket will provide these things
>
> Does that sound about right?
>
> This sounds amazing! I can't wait to the see the results of an analysis and
> comparison for each requirement, and a proof of concept and per-activity
> comparison between the different approaches.
>
> -David
>
>
> On Dec 19, 2009, at 11:55 AM, Vasanth Kamatgi wrote:
>
> > Hi all,
> >
> >
> >
> > Firstly I would like to thank David E. Jones
> > <http://www.blogger.com/profile/07283017166339658819> , for his
> > encouragement to use the community process.
> >
> > I had previously posted a question in this community at
> >
> http://n4.nabble.com/Application-framework-technology-set-tp195713p963334.ht
> > ml as a very terse summary of my thoughts. After having a private
> > conversation with David, I thought a much in-depth discussion on the
> > presentation layer would be beneficial to me as well as the community and
> > consequently I am starting a new thread of discussion.
> >
> >
> >
> > Here is my primary complaint of Ofbiz presentation Layer - "There isn't a
> > STRICT separation of UI / Code in the presentation layer. Due to this
> > deficiency, for any revamp in the UI, even though there is no associated
> > change in the functionality / business logic, it takes substantial amount
> of
> > developer time. I see this as a major hindrance to a typical ecommerce
> > website, where UI changes are frequent as well as significant."
> >
> >
> >
> > To give more insight into why I have this complaint, let me raise some
> > questions (and answer them):
> >
> >
> >
> > What I think a presentation Layer does?
> >
> > =============================
> >
> > I believe presentation layer can be divided into 6 areas of concern:
> >
> > Data Preparation - Events / Service (a.k.a actions) generate data that
> need
> > to be processed to result into a *shape* that can be directly used by a
> > view. Eg., only product category id exists in context, we need to display
> > category name as well - fetch it.
> >
> > Layout - It controls the relative position of each of the components
> inside
> > a page. Wireframes used to build the page.
> >
> > Page composition - Different areas of the page can be generated by a
> > separate component / screen, and the generated output needs to be stitched
> > together to result into a complete response
> >
> > Look and Feel - Visual properties of components of the page (css?)
> >
> > View Logic - The logic that controls the initial state of each elements of
> > the output - like enabling, disabling, non-display etc., of specific
> output
> > elements. Eg., if sale price exists, show it in large red font, strike
> > through the list price, else show list price in large font.
> >
> > Rich dynamic behaviour - the dynamic behaviour that each of the generated
> > output needs to provide inside user-agent's environment (javascript /
> dhtml)
> >
> >
> >
> > How have I set the things up in Ofbiz?
> >
> > ===========================
> >
> > 1. I have created my primary page layout a.k.a. decorator in
> > common-screens.xml using sections, actions, widgets, html-templates,
> > containers, etc.
> > 2. I have abstracted out the common section contents as say,
> > includes/header.ftl etc.
> > 3. I have created components of a page such as choose catalog, keyword
> > search box, etc. as screens (non-top level) using actions and html
> templates
> > in, say, catalog-screens.xml
> > 4. I create a complete response page as a screen in catalog-screens.xml
> > using actions, widgets, decorator-screen, decorator-section,
> include-screen,
> > etc. in, say, catalog-screens.xml
> > 5. I specify this top-level page as view, which I link to the
> > associated event / service via request map in controller.xml
> >
> > The actual response out is defined in html fragments in various files
> > defined in #2, #3 & #4
> >
> >
> >
> > Exactly what is it that I find cumbersome?
> >
> > ==============================
> >
> > UI Designer prepares the prototype, hands it over to the Ofbiz developer,
> > who splits it into different fragments, and creates ftls for each of those
> > sections. Then, adds page composition, view logic and rich dynamic
> > behaviour to those ftls. This complete sequence of steps is irreversible.
> > Once handover happens from UI designer to Ofbiz developer, the html / css
> > ceases to exist in its native form, making it impossible for the UI
> designer
> > to "maintain" it. Any UI bug / change request cannot be fixed by UI
> > designer. UI designer first analyses the problem reports the possible
> > causes to Ofbiz developer, who figures out which ftl file to edit and goes
> > and edits it. If a drop down box needs to move from one widget to
> another,
> > Ofbiz developer employs a cut+paste job that can be so error-prone with
> > missing tag closures, quotes, duplicates etc. There have been so many
> > instances of Ofbiz developer trying to fix UI issues, but failing to do so
> > because he / she is good at writing java-like, jsp-like and
> javascript-like
> > code and not standards-compliant html / css code. He can't use visual
> tools
> > like a UI designer to improve his productivity. Throw into this mix the
> > cross-browser compatibility issue - the whole effort becomes very
> > unproductive with UI designer, Ofbiz developer working together to fix it,
> > when it should actually be handled by UI designer alone.
> >
> > Ofbiz supports data preparation, page composition, view logic well. But
> > other areas are a little troublesome.
> >
> >
> >
> > How would I like it to work?
> >
> > ====================
> >
> > Different areas of concern, as listed in my previous paragraph, are best
> > worked at by different types of resources. Assuming we are using java
> > platform for development:
> >
> > Data Preparation - java coder
> >
> > Layout - UI designer / business analyst / SEO specialist
> >
> > Page composition - java / jsp coder
> >
> > Look and Feel - User Experience expert
> >
> > View Logic - java / jsp coder
> >
> > Rich dynamic behaviour - script coder / java coder
> >
> > Given these different areas of expertise, a software development /
> > maintenance model needs to be employed to enable these types of resources
> to
> > work at full productivity without tripping each other. Cutting a long
> story
> > short, I believe, Ofbiz should enable html, css, multi-media & view logic
> to
> > be developed and managed independently. UI designer should continue to
> fix
> > UI bugs by just editing his / her html code. There should be no pollution
> > of html and css code. View logic should be written without using tags.
> >
> > I have dived into wicket and wrote my first hello world recently and
> believe
> > wicket-like rendering would be a good enhancement to Ofbiz. I am not
> > claiming to be an expert of wicket, but based on the documentation I have
> > read, it seems to fit the scheme well.
> >
> >
> >
> > I hope I have given enough details for the community to start a
> > conversation. I understand that, the question begs of not only an
> > architectural discussion, but also of a software development / maintenance
> > model.
> >
> >
> >
> > Cheers,
> >
> > Vasanth
>

Ean Schuessler

Re: Using Apache Wicket in Ofbiz presentation layer

In reply to this post by David E. Jones-2

David E Jones wrote:

> To sum up:
>
> 1. you want a full separation of concerns for the different roles in your organization, something that won't require additional training beyond their existing skill set
>
> 2. you want no dependencies between different roles so they can't mess each other up or slow each other down
>
> 3. Apache Wicket will provide these things
>
> Does that sound about right?
>
> This sounds amazing! I can't wait to the see the results of an analysis and comparison for each requirement, and a proof of concept and per-activity comparison between the different approaches.
>

Just a touch Snarky there, Mr. Jones. :-)

Vasanth, I have spent some time examining Wicket and its not clear to me
that it is able to remove the problems in all but the most simple cases.
HTML for complicated multi-state widgets would still need to be divided
into many fragments, which are hard for the HTML designer to understand.
It would also still not be very clear to the designer where those
fragments need to be delineated because they do not understand the
control flow.

The deep set problem is that there will be many cases where you want to
look at a completed HTML assembly in its populated state to see how the
layout looks. That can only be done by editing on a live ofbiz
environment and that is always going to be pushing the skills of a GUI
designer. What using Wicket does achieve, however, is the elimination of
a high level widget system. While we are not really taking advantage of
it it is possible to have the OFBiz widgets present themselves in a
Swing, SWT or GWT form without rebuilding the entire GUI from scratch.
That's a pretty big strike against the Wicket approach. Wicket is also
pretty tightly bound to Java the language, which may or may not be the
most productive thing to use depending on your point of view (ie. PHP
programmers are plentiful and cheap).

In some problem domains like the shopping front-end we may need to
accept that the customer use-cases are simply to variable to make the
widget strategy add value. That's why, here at Brainfood, we've rebuilt
the e-commerce front end on our own templating system. Wicket might also
be a worthwhile strategy for that front end rebuild. I imagine that most
of your HTML workload revolves around that component. If you really
believe in it, I encourage you to build a Wicket version of the
ecommerce component. I would be happy to review it and compare its
benefits with our effort.

David E. Jones-2

Re: Using Apache Wicket in Ofbiz presentation layer

On Dec 21, 2009, at 8:12 AM, Ean Schuessler wrote:

> David E Jones wrote:
>> To sum up:
>>
>> 1. you want a full separation of concerns for the different roles in your organization, something that won't require additional training beyond their existing skill set
>>
>> 2. you want no dependencies between different roles so they can't mess each other up or slow each other down
>>
>> 3. Apache Wicket will provide these things
>>
>> Does that sound about right?
>>
>> This sounds amazing! I can't wait to the see the results of an analysis and comparison for each requirement, and a proof of concept and per-activity comparison between the different approaches.
>>
> Just a touch Snarky there, Mr. Jones. :-)

You're right, I was a bit snarky there. I apologize if I offended anyone. I guess I should have said something like: That sounds a little bit too amazing to be true.

> Vasanth, I have spent some time examining Wicket and its not clear to me that it is able to remove the problems in all but the most simple cases. HTML for complicated multi-state widgets would still need to be divided into many fragments, which are hard for the HTML designer to understand. It would also still not be very clear to the designer where those fragments need to be delineated because they do not understand the control flow.
>
> The deep set problem is that there will be many cases where you want to look at a completed HTML assembly in its populated state to see how the layout looks. That can only be done by editing on a live ofbiz environment and that is always going to be pushing the skills of a GUI designer. What using Wicket does achieve, however, is the elimination of a high level widget system. While we are not really taking advantage of it it is possible to have the OFBiz widgets present themselves in a Swing, SWT or GWT form without rebuilding the entire GUI from scratch. That's a pretty big strike against the Wicket approach. Wicket is also pretty tightly bound to Java the language, which may or may not be the most productive thing to use depending on your point of view (ie. PHP programmers are plentiful and cheap).
>
> In some problem domains like the shopping front-end we may need to accept that the customer use-cases are simply to variable to make the widget strategy add value. That's why, here at Brainfood, we've rebuilt the e-commerce front end on our own templating system. Wicket might also be a worthwhile strategy for that front end rebuild. I imagine that most of your HTML workload revolves around that component. If you really believe in it, I encourage you to build a Wicket version of the ecommerce component. I would be happy to review it and compare its benefits with our effort.

The general idea is an interesting one, ie of really separating things by role and eliminating dependencies.

I like the stuff you guys at Brainfood have done with WebSlinger, and it certainly makes things easier for people in certain roles.

In a way I wonder if points #1 and #2 that I listed above are actually possible. My theory over the years is that they are simply not possible, and all attempts are guaranteed to fall short because those requirements are not "internally consistent". It would be interesting to have a well-funded R&D project to get feedback from a bunch of people, assemble a number of possible designs, then implement and test those designs in various organizations. I'm not sure if that will ever happen, and I suppose even if it did the winning design would probably be so biased by politicking that the stated result might not be accurate.

Anyway, it's a tough problem. The main issues I see are kind of like what you listed Ean, namely:

1. different organizations have different roles and different skills sets, so to be effective you'd really need to document a variety of organizations and combinations of skill sets and be flexible enough to address at least a few of the most common ones, or the ones that should be most easy for an organization to assemble

2. it's not possible to completely eliminate dependencies between what different people in different roles are doing; there might be some things you could do to either mitigate (handle automatically or transparently/implicitly) or obviate (fail fast/early) the problems, but these dependencies are an inherent part of what is being built and IMO they simply cannot be totally eliminated, especially if you want reusable parts of the screens, etc

My favorite approach so far to getting people to handle this well is to divide front-end developers into those who are mostly visually talented, and those who have gotten into scripting and such too. These people will have to get used to working together in order to get things done, IMO. From time to time you'll run into a person that is great at both, but not usually. Those who are into scripting and working with straight HTML can usually get into using the OFBiz widgets and FTL templates and do quite well with them (and without very much training too). But that isn't everyone, and you certainly need someone who can break things down and implement the technical things to drive them.

Some tools make this easier, and therefore require less technical knowledge, but those tools typically also restrict what you can do. If you want to keep it cheap and simple then that's great, just do what the tool makes easy. If you really want to be able to design and build anything that is "internally consistent" then you're going to need more flexible tools and more knowledgeable people.

Or am I wrong and the silver bullet solution does exist and I just haven't yet had the pleasure of experiencing it?

Hopefully this time I'm less snarky, without being too depressing... :)

-David

Abdullah Shaikh

Re: Using Apache Wicket in Ofbiz presentation layer

Hi All,

When I was working on ecommerce I also found it difficult/troublesome to
change the UI, so regarding having separation of UI / Code in the
presentation layer, below are my thoughts, but I hadn't implemented them,
because I needed to complete the project and had no time for this.

What I feel is we can have all the data preparation in Groovy itself and
just the displaying part in FTL page, this would reduce the complexity in
FTL pages and would I guess provide the UI separation from code.

For example, currently FTL pages are some what like this,

if(this == that ) {
<table>data goes here</table>
} else {
<table>data goes here</table>
}

What we can do is, put this logic in groovy and let the ftl display the
data.

Groovy :
if(this == that) {
context.put("data", data goes here);
} else {
context.put("data", other data goes here);
}

FTL :

<table> data from context </table>

This way the FTL pages will be free of any logic and will just render the
data provided through context from Groovy.

If using this technique,

1) Every FTL page will require a Groovy file for data preparation logic
2) Any changes can be does easily as Groovy won't require server restart
3) Changes in the UI can be done easily as we just need to paste the new UI
code and get appropriate data from context and display it where ever you
require.

We can decide on a model for passing data to FTL pages, for example

Groovy :

data.put("userdetails", userdetails);
data.put("paymentsinfo" paymentinfo);
data.put"shoppingcart", shoppingcart);
context.put("data", data);

FTL :

<table data.get("userdetails")</table>
<table>data.get("paymentinfo", paymentinfo)</table>
<table>data.get("shoppingcart" shoppintcart);

This are just my thoughts on how can we separate UI from Code (display
logic), I haven't seen or used Apache Wicket so no idea about how that will
work or integrate in OFBiz.

But this approach wont require any new integration or any POC as Groovy &
FTL are already part of OFBiz.

Let me know your thoughts or anything that I am missing.

- Abdullah

On Mon, Dec 21, 2009 at 11:06 PM, David E Jones <[hidden email]> wrote:

>
> On Dec 21, 2009, at 8:12 AM, Ean Schuessler wrote:
>
> > David E Jones wrote:
> >> To sum up:
> >>
> >> 1. you want a full separation of concerns for the different roles in
> your organization, something that won't require additional training beyond
> their existing skill set
> >>
> >> 2. you want no dependencies between different roles so they can't mess
> each other up or slow each other down
> >>
> >> 3. Apache Wicket will provide these things
> >>
> >> Does that sound about right?
> >>
> >> This sounds amazing! I can't wait to the see the results of an analysis
> and comparison for each requirement, and a proof of concept and per-activity
> comparison between the different approaches.
> >>
> > Just a touch Snarky there, Mr. Jones. :-)
>
> You're right, I was a bit snarky there. I apologize if I offended anyone. I
> guess I should have said something like: That sounds a little bit too
> amazing to be true.
>
> > Vasanth, I have spent some time examining Wicket and its not clear to me
> that it is able to remove the problems in all but the most simple cases.
> HTML for complicated multi-state widgets would still need to be divided into
> many fragments, which are hard for the HTML designer to understand. It would
> also still not be very clear to the designer where those fragments need to
> be delineated because they do not understand the control flow.
> >
> > The deep set problem is that there will be many cases where you want to
> look at a completed HTML assembly in its populated state to see how the
> layout looks. That can only be done by editing on a live ofbiz environment
> and that is always going to be pushing the skills of a GUI designer. What
> using Wicket does achieve, however, is the elimination of a high level
> widget system. While we are not really taking advantage of it it is possible
> to have the OFBiz widgets present themselves in a Swing, SWT or GWT form
> without rebuilding the entire GUI from scratch. That's a pretty big strike
> against the Wicket approach. Wicket is also pretty tightly bound to Java the
> language, which may or may not be the most productive thing to use depending
> on your point of view (ie. PHP programmers are plentiful and cheap).
> >
> > In some problem domains like the shopping front-end we may need to accept
> that the customer use-cases are simply to variable to make the widget
> strategy add value. That's why, here at Brainfood, we've rebuilt the
> e-commerce front end on our own templating system. Wicket might also be a
> worthwhile strategy for that front end rebuild. I imagine that most of your
> HTML workload revolves around that component. If you really believe in it, I
> encourage you to build a Wicket version of the ecommerce component. I would
> be happy to review it and compare its benefits with our effort.
>
> The general idea is an interesting one, ie of really separating things by
> role and eliminating dependencies.
>
> I like the stuff you guys at Brainfood have done with WebSlinger, and it
> certainly makes things easier for people in certain roles.
>
> In a way I wonder if points #1 and #2 that I listed above are actually
> possible. My theory over the years is that they are simply not possible, and
> all attempts are guaranteed to fall short because those requirements are not
> "internally consistent". It would be interesting to have a well-funded R&D
> project to get feedback from a bunch of people, assemble a number of
> possible designs, then implement and test those designs in various
> organizations. I'm not sure if that will ever happen, and I suppose even if
> it did the winning design would probably be so biased by politicking that
> the stated result might not be accurate.
>
> Anyway, it's a tough problem. The main issues I see are kind of like what
> you listed Ean, namely:
>
> 1. different organizations have different roles and different skills sets,
> so to be effective you'd really need to document a variety of organizations
> and combinations of skill sets and be flexible enough to address at least a
> few of the most common ones, or the ones that should be most easy for an
> organization to assemble
>
> 2. it's not possible to completely eliminate dependencies between what
> different people in different roles are doing; there might be some things
> you could do to either mitigate (handle automatically or
> transparently/implicitly) or obviate (fail fast/early) the problems, but
> these dependencies are an inherent part of what is being built and IMO they
> simply cannot be totally eliminated, especially if you want reusable parts
> of the screens, etc
>
> My favorite approach so far to getting people to handle this well is to
> divide front-end developers into those who are mostly visually talented, and
> those who have gotten into scripting and such too. These people will have to
> get used to working together in order to get things done, IMO. From time to
> time you'll run into a person that is great at both, but not usually. Those
> who are into scripting and working with straight HTML can usually get into
> using the OFBiz widgets and FTL templates and do quite well with them (and
> without very much training too). But that isn't everyone, and you certainly
> need someone who can break things down and implement the technical things to
> drive them.
>
> Some tools make this easier, and therefore require less technical
> knowledge, but those tools typically also restrict what you can do. If you
> want to keep it cheap and simple then that's great, just do what the tool
> makes easy. If you really want to be able to design and build anything that
> is "internally consistent" then you're going to need more flexible tools and
> more knowledgeable people.
>
> Or am I wrong and the silver bullet solution does exist and I just haven't
> yet had the pleasure of experiencing it?
>
> Hopefully this time I'm less snarky, without being too depressing... :)
>
> -David
>
>
>

Malin Nicolas

Re: Using Apache Wicket in Ofbiz presentation layer

Hi Abdullah,

It's a good Idea It's is possible to disable some calcul.

If your groovy compile some information, do findList, getRelated ... ,
if you deploy for a customer a screen that don't use all information,
you generate unnecessary work to your database.

So +1 for your suggestion with warn on "big process"

Nicolas

Abdullah Shaikh a écrit :

> Hi All,
>
> When I was working on ecommerce I also found it difficult/troublesome to
> change the UI, so regarding having separation of UI / Code in the
> presentation layer, below are my thoughts, but I hadn't implemented them,
> because I needed to complete the project and had no time for this.
>
> What I feel is we can have all the data preparation in Groovy itself and
> just the displaying part in FTL page, this would reduce the complexity in
> FTL pages and would I guess provide the UI separation from code.
>
> For example, currently FTL pages are some what like this,
>
> if(this == that ) {
> <table>data goes here</table>
> } else {
> <table>data goes here</table>
> }
>
> What we can do is, put this logic in groovy and let the ftl display the
> data.
>
> Groovy :
> if(this == that) {
> context.put("data", data goes here);
> } else {
> context.put("data", other data goes here);
> }
>
> FTL :
>
> <table> data from context </table>
>
> This way the FTL pages will be free of any logic and will just render the
> data provided through context from Groovy.
>
> If using this technique,
>
> 1) Every FTL page will require a Groovy file for data preparation logic
> 2) Any changes can be does easily as Groovy won't require server restart
> 3) Changes in the UI can be done easily as we just need to paste the new UI
> code and get appropriate data from context and display it where ever you
> require.
>
> We can decide on a model for passing data to FTL pages, for example
>
> Groovy :
>
> data.put("userdetails", userdetails);
> data.put("paymentsinfo" paymentinfo);
> data.put"shoppingcart", shoppingcart);
> context.put("data", data);
>
> FTL :
>
> <table data.get("userdetails")</table>
> <table>data.get("paymentinfo", paymentinfo)</table>
> <table>data.get("shoppingcart" shoppintcart);
>
>
> This are just my thoughts on how can we separate UI from Code (display
> logic), I haven't seen or used Apache Wicket so no idea about how that will
> work or integrate in OFBiz.
>
> But this approach wont require any new integration or any POC as Groovy &
> FTL are already part of OFBiz.
>
> Let me know your thoughts or anything that I am missing.
>
> - Abdullah
>
> On Mon, Dec 21, 2009 at 11:06 PM, David E Jones <[hidden email]> wrote:
>
>
>> On Dec 21, 2009, at 8:12 AM, Ean Schuessler wrote:
>>
>>
>>> David E Jones wrote:
>>>
>>>> To sum up:
>>>>
>>>> 1. you want a full separation of concerns for the different roles in
>>>>
>> your organization, something that won't require additional training beyond
>> their existing skill set
>>
>>>> 2. you want no dependencies between different roles so they can't mess
>>>>
>> each other up or slow each other down
>>
>>>> 3. Apache Wicket will provide these things
>>>>
>>>> Does that sound about right?
>>>>
>>>> This sounds amazing! I can't wait to the see the results of an analysis
>>>>
>> and comparison for each requirement, and a proof of concept and per-activity
>> comparison between the different approaches.
>>
>>> Just a touch Snarky there, Mr. Jones. :-)
>>>
>> You're right, I was a bit snarky there. I apologize if I offended anyone. I
>> guess I should have said something like: That sounds a little bit too
>> amazing to be true.
>>
>>
>>> Vasanth, I have spent some time examining Wicket and its not clear to me
>>>
>> that it is able to remove the problems in all but the most simple cases.
>> HTML for complicated multi-state widgets would still need to be divided into
>> many fragments, which are hard for the HTML designer to understand. It would
>> also still not be very clear to the designer where those fragments need to
>> be delineated because they do not understand the control flow.
>>
>>> The deep set problem is that there will be many cases where you want to
>>>
>> look at a completed HTML assembly in its populated state to see how the
>> layout looks. That can only be done by editing on a live ofbiz environment
>> and that is always going to be pushing the skills of a GUI designer. What
>> using Wicket does achieve, however, is the elimination of a high level
>> widget system. While we are not really taking advantage of it it is possible
>> to have the OFBiz widgets present themselves in a Swing, SWT or GWT form
>> without rebuilding the entire GUI from scratch. That's a pretty big strike
>> against the Wicket approach. Wicket is also pretty tightly bound to Java the
>> language, which may or may not be the most productive thing to use depending
>> on your point of view (ie. PHP programmers are plentiful and cheap).
>>
>>> In some problem domains like the shopping front-end we may need to accept
>>>
>> that the customer use-cases are simply to variable to make the widget
>> strategy add value. That's why, here at Brainfood, we've rebuilt the
>> e-commerce front end on our own templating system. Wicket might also be a
>> worthwhile strategy for that front end rebuild. I imagine that most of your
>> HTML workload revolves around that component. If you really believe in it, I
>> encourage you to build a Wicket version of the ecommerce component. I would
>> be happy to review it and compare its benefits with our effort.
>>
>> The general idea is an interesting one, ie of really separating things by
>> role and eliminating dependencies.
>>
>> I like the stuff you guys at Brainfood have done with WebSlinger, and it
>> certainly makes things easier for people in certain roles.
>>
>> In a way I wonder if points #1 and #2 that I listed above are actually
>> possible. My theory over the years is that they are simply not possible, and
>> all attempts are guaranteed to fall short because those requirements are not
>> "internally consistent". It would be interesting to have a well-funded R&D
>> project to get feedback from a bunch of people, assemble a number of
>> possible designs, then implement and test those designs in various
>> organizations. I'm not sure if that will ever happen, and I suppose even if
>> it did the winning design would probably be so biased by politicking that
>> the stated result might not be accurate.
>>
>> Anyway, it's a tough problem. The main issues I see are kind of like what
>> you listed Ean, namely:
>>
>> 1. different organizations have different roles and different skills sets,
>> so to be effective you'd really need to document a variety of organizations
>> and combinations of skill sets and be flexible enough to address at least a
>> few of the most common ones, or the ones that should be most easy for an
>> organization to assemble
>>
>> 2. it's not possible to completely eliminate dependencies between what
>> different people in different roles are doing; there might be some things
>> you could do to either mitigate (handle automatically or
>> transparently/implicitly) or obviate (fail fast/early) the problems, but
>> these dependencies are an inherent part of what is being built and IMO they
>> simply cannot be totally eliminated, especially if you want reusable parts
>> of the screens, etc
>>
>> My favorite approach so far to getting people to handle this well is to
>> divide front-end developers into those who are mostly visually talented, and
>> those who have gotten into scripting and such too. These people will have to
>> get used to working together in order to get things done, IMO. From time to
>> time you'll run into a person that is great at both, but not usually. Those
>> who are into scripting and working with straight HTML can usually get into
>> using the OFBiz widgets and FTL templates and do quite well with them (and
>> without very much training too). But that isn't everyone, and you certainly
>> need someone who can break things down and implement the technical things to
>> drive them.
>>
>> Some tools make this easier, and therefore require less technical
>> knowledge, but those tools typically also restrict what you can do. If you
>> want to keep it cheap and simple then that's great, just do what the tool
>> makes easy. If you really want to be able to design and build anything that
>> is "internally consistent" then you're going to need more flexible tools and
>> more knowledgeable people.
>>
>> Or am I wrong and the silver bullet solution does exist and I just haven't
>> yet had the pleasure of experiencing it?
>>
>> Hopefully this time I'm less snarky, without being too depressing... :)
>>
>> -David
>>
>>
>>
>>
>
>

--
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/

Abdullah Shaikh

Re: Using Apache Wicket in Ofbiz presentation layer

Hi Nicolas

"If your groovy compile some information, do findList, getRelated ... , if
you deploy for a customer a screen that don't use all information, you
generate unnecessary work to your database."

But in groovy you will need to get only that data from database which will
be required for the FTL page

It's like if an existing FTL gets "xyz" data from database, using this
approach it will be like, groovy get "xyz" data from the database and
putting it inside the context, FTL will get this data from the context.

- Abdullah

On Tue, Dec 22, 2009 at 2:04 PM, Nicolas Malin <
[hidden email]> wrote:

> Hi Abdullah,
>
> It's a good Idea It's is possible to disable some calcul.
>
> If your groovy compile some information, do findList, getRelated ... , if
> you deploy for a customer a screen that don't use all information, you
> generate unnecessary work to your database.
>
> So +1 for your suggestion with warn on "big process"
>
> Nicolas
>
> Abdullah Shaikh a écrit :
>
> Hi All,
>>
>> When I was working on ecommerce I also found it difficult/troublesome to
>> change the UI, so regarding having separation of UI / Code in the
>> presentation layer, below are my thoughts, but I hadn't implemented them,
>> because I needed to complete the project and had no time for this.
>>
>> What I feel is we can have all the data preparation in Groovy itself and
>> just the displaying part in FTL page, this would reduce the complexity in
>> FTL pages and would I guess provide the UI separation from code.
>>
>> For example, currently FTL pages are some what like this,
>>
>> if(this == that ) {
>> <table>data goes here</table>
>> } else {
>> <table>data goes here</table>
>> }
>>
>> What we can do is, put this logic in groovy and let the ftl display the
>> data.
>>
>> Groovy :
>> if(this == that) {
>> context.put("data", data goes here);
>> } else {
>> context.put("data", other data goes here);
>> }
>>
>> FTL :
>>
>> <table> data from context </table>
>>
>> This way the FTL pages will be free of any logic and will just render the
>> data provided through context from Groovy.
>>
>> If using this technique,
>>
>> 1) Every FTL page will require a Groovy file for data preparation logic
>> 2) Any changes can be does easily as Groovy won't require server restart
>> 3) Changes in the UI can be done easily as we just need to paste the new
>> UI
>> code and get appropriate data from context and display it where ever you
>> require.
>>
>> We can decide on a model for passing data to FTL pages, for example
>>
>> Groovy :
>>
>> data.put("userdetails", userdetails);
>> data.put("paymentsinfo" paymentinfo);
>> data.put"shoppingcart", shoppingcart);
>> context.put("data", data);
>>
>> FTL :
>>
>> <table data.get("userdetails")</table>
>> <table>data.get("paymentinfo", paymentinfo)</table>
>> <table>data.get("shoppingcart" shoppintcart);
>>
>>
>> This are just my thoughts on how can we separate UI from Code (display
>> logic), I haven't seen or used Apache Wicket so no idea about how that
>> will
>> work or integrate in OFBiz.
>>
>> But this approach wont require any new integration or any POC as Groovy &
>> FTL are already part of OFBiz.
>>
>> Let me know your thoughts or anything that I am missing.
>>
>> - Abdullah
>>
>> On Mon, Dec 21, 2009 at 11:06 PM, David E Jones <[hidden email]> wrote:
>>
>>
>>
>>> On Dec 21, 2009, at 8:12 AM, Ean Schuessler wrote:
>>>
>>>
>>>
>>>> David E Jones wrote:
>>>>
>>>>
>>>>> To sum up:
>>>>>
>>>>> 1. you want a full separation of concerns for the different roles in
>>>>>
>>>>>
>>>> your organization, something that won't require additional training
>>> beyond
>>> their existing skill set
>>>
>>>
>>>> 2. you want no dependencies between different roles so they can't mess
>>>>>
>>>>>
>>>> each other up or slow each other down
>>>
>>>
>>>> 3. Apache Wicket will provide these things
>>>>>
>>>>> Does that sound about right?
>>>>>
>>>>> This sounds amazing! I can't wait to the see the results of an analysis
>>>>>
>>>>>
>>>> and comparison for each requirement, and a proof of concept and
>>> per-activity
>>> comparison between the different approaches.
>>>
>>>
>>>> Just a touch Snarky there, Mr. Jones. :-)
>>>>
>>>>
>>> You're right, I was a bit snarky there. I apologize if I offended anyone.
>>> I
>>> guess I should have said something like: That sounds a little bit too
>>> amazing to be true.
>>>
>>>
>>>
>>>> Vasanth, I have spent some time examining Wicket and its not clear to me
>>>>
>>>>
>>> that it is able to remove the problems in all but the most simple cases.
>>> HTML for complicated multi-state widgets would still need to be divided
>>> into
>>> many fragments, which are hard for the HTML designer to understand. It
>>> would
>>> also still not be very clear to the designer where those fragments need
>>> to
>>> be delineated because they do not understand the control flow.
>>>
>>>
>>>> The deep set problem is that there will be many cases where you want to
>>>>
>>>>
>>> look at a completed HTML assembly in its populated state to see how the
>>> layout looks. That can only be done by editing on a live ofbiz
>>> environment
>>> and that is always going to be pushing the skills of a GUI designer. What
>>> using Wicket does achieve, however, is the elimination of a high level
>>> widget system. While we are not really taking advantage of it it is
>>> possible
>>> to have the OFBiz widgets present themselves in a Swing, SWT or GWT form
>>> without rebuilding the entire GUI from scratch. That's a pretty big
>>> strike
>>> against the Wicket approach. Wicket is also pretty tightly bound to Java
>>> the
>>> language, which may or may not be the most productive thing to use
>>> depending
>>> on your point of view (ie. PHP programmers are plentiful and cheap).
>>>
>>>
>>>> In some problem domains like the shopping front-end we may need to
>>>> accept
>>>>
>>>>
>>> that the customer use-cases are simply to variable to make the widget
>>> strategy add value. That's why, here at Brainfood, we've rebuilt the
>>> e-commerce front end on our own templating system. Wicket might also be a
>>> worthwhile strategy for that front end rebuild. I imagine that most of
>>> your
>>> HTML workload revolves around that component. If you really believe in
>>> it, I
>>> encourage you to build a Wicket version of the ecommerce component. I
>>> would
>>> be happy to review it and compare its benefits with our effort.
>>>
>>> The general idea is an interesting one, ie of really separating things by
>>> role and eliminating dependencies.
>>>
>>> I like the stuff you guys at Brainfood have done with WebSlinger, and it
>>> certainly makes things easier for people in certain roles.
>>>
>>> In a way I wonder if points #1 and #2 that I listed above are actually
>>> possible. My theory over the years is that they are simply not possible,
>>> and
>>> all attempts are guaranteed to fall short because those requirements are
>>> not
>>> "internally consistent". It would be interesting to have a well-funded
>>> R&D
>>> project to get feedback from a bunch of people, assemble a number of
>>> possible designs, then implement and test those designs in various
>>> organizations. I'm not sure if that will ever happen, and I suppose even
>>> if
>>> it did the winning design would probably be so biased by politicking that
>>> the stated result might not be accurate.
>>>
>>> Anyway, it's a tough problem. The main issues I see are kind of like what
>>> you listed Ean, namely:
>>>
>>> 1. different organizations have different roles and different skills
>>> sets,
>>> so to be effective you'd really need to document a variety of
>>> organizations
>>> and combinations of skill sets and be flexible enough to address at least
>>> a
>>> few of the most common ones, or the ones that should be most easy for an
>>> organization to assemble
>>>
>>> 2. it's not possible to completely eliminate dependencies between what
>>> different people in different roles are doing; there might be some things
>>> you could do to either mitigate (handle automatically or
>>> transparently/implicitly) or obviate (fail fast/early) the problems, but
>>> these dependencies are an inherent part of what is being built and IMO
>>> they
>>> simply cannot be totally eliminated, especially if you want reusable
>>> parts
>>> of the screens, etc
>>>
>>> My favorite approach so far to getting people to handle this well is to
>>> divide front-end developers into those who are mostly visually talented,
>>> and
>>> those who have gotten into scripting and such too. These people will have
>>> to
>>> get used to working together in order to get things done, IMO. From time
>>> to
>>> time you'll run into a person that is great at both, but not usually.
>>> Those
>>> who are into scripting and working with straight HTML can usually get
>>> into
>>> using the OFBiz widgets and FTL templates and do quite well with them
>>> (and
>>> without very much training too). But that isn't everyone, and you
>>> certainly
>>> need someone who can break things down and implement the technical things
>>> to
>>> drive them.
>>>
>>> Some tools make this easier, and therefore require less technical
>>> knowledge, but those tools typically also restrict what you can do. If
>>> you
>>> want to keep it cheap and simple then that's great, just do what the tool
>>> makes easy. If you really want to be able to design and build anything
>>> that
>>> is "internally consistent" then you're going to need more flexible tools
>>> and
>>> more knowledgeable people.
>>>
>>> Or am I wrong and the silver bullet solution does exist and I just
>>> haven't
>>> yet had the pleasure of experiencing it?
>>>
>>> Hopefully this time I'm less snarky, without being too depressing... :)
>>>
>>> -David
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
> --
> Nicolas MALIN
> Consultant
> Tél : 06.17.66.40.06
> Site projet : http://www.neogia.org/
> -------
> Société LibrenBerry
> Tél : 02.48.02.56.12
> Site : http://www.librenberry.net/
>
>

David E. Jones-2

Re: Using Apache Wicket in Ofbiz presentation layer

In reply to this post by Abdullah Shaikh

Maybe I'm not understanding what you propose in this message... but how is this different from the current common practice?

-David

On Dec 22, 2009, at 1:47 AM, Abdullah Shaikh wrote:

> Hi All,
>
> When I was working on ecommerce I also found it difficult/troublesome to
> change the UI, so regarding having separation of UI / Code in the
> presentation layer, below are my thoughts, but I hadn't implemented them,
> because I needed to complete the project and had no time for this.
>
> What I feel is we can have all the data preparation in Groovy itself and
> just the displaying part in FTL page, this would reduce the complexity in
> FTL pages and would I guess provide the UI separation from code.
>
> For example, currently FTL pages are some what like this,
>
> if(this == that ) {
> <table>data goes here</table>
> } else {
> <table>data goes here</table>
> }
>
> What we can do is, put this logic in groovy and let the ftl display the
> data.
>
> Groovy :
> if(this == that) {
> context.put("data", data goes here);
> } else {
> context.put("data", other data goes here);
> }
>
> FTL :
>
> <table> data from context </table>
>
> This way the FTL pages will be free of any logic and will just render the
> data provided through context from Groovy.
>
> If using this technique,
>
> 1) Every FTL page will require a Groovy file for data preparation logic
> 2) Any changes can be does easily as Groovy won't require server restart
> 3) Changes in the UI can be done easily as we just need to paste the new UI
> code and get appropriate data from context and display it where ever you
> require.
>
> We can decide on a model for passing data to FTL pages, for example
>
> Groovy :
>
> data.put("userdetails", userdetails);
> data.put("paymentsinfo" paymentinfo);
> data.put"shoppingcart", shoppingcart);
> context.put("data", data);
>
> FTL :
>
> <table data.get("userdetails")</table>
> <table>data.get("paymentinfo", paymentinfo)</table>
> <table>data.get("shoppingcart" shoppintcart);
>
>
> This are just my thoughts on how can we separate UI from Code (display
> logic), I haven't seen or used Apache Wicket so no idea about how that will
> work or integrate in OFBiz.
>
> But this approach wont require any new integration or any POC as Groovy &
> FTL are already part of OFBiz.
>
> Let me know your thoughts or anything that I am missing.
>
> - Abdullah
>
> On Mon, Dec 21, 2009 at 11:06 PM, David E Jones <[hidden email]> wrote:
>
>>
>> On Dec 21, 2009, at 8:12 AM, Ean Schuessler wrote:
>>
>>> David E Jones wrote:
>>>> To sum up:
>>>>
>>>> 1. you want a full separation of concerns for the different roles in
>> your organization, something that won't require additional training beyond
>> their existing skill set
>>>>
>>>> 2. you want no dependencies between different roles so they can't mess
>> each other up or slow each other down
>>>>
>>>> 3. Apache Wicket will provide these things
>>>>
>>>> Does that sound about right?
>>>>
>>>> This sounds amazing! I can't wait to the see the results of an analysis
>> and comparison for each requirement, and a proof of concept and per-activity
>> comparison between the different approaches.
>>>>
>>> Just a touch Snarky there, Mr. Jones. :-)
>>
>> You're right, I was a bit snarky there. I apologize if I offended anyone. I
>> guess I should have said something like: That sounds a little bit too
>> amazing to be true.
>>
>>> Vasanth, I have spent some time examining Wicket and its not clear to me
>> that it is able to remove the problems in all but the most simple cases.
>> HTML for complicated multi-state widgets would still need to be divided into
>> many fragments, which are hard for the HTML designer to understand. It would
>> also still not be very clear to the designer where those fragments need to
>> be delineated because they do not understand the control flow.
>>>
>>> The deep set problem is that there will be many cases where you want to
>> look at a completed HTML assembly in its populated state to see how the
>> layout looks. That can only be done by editing on a live ofbiz environment
>> and that is always going to be pushing the skills of a GUI designer. What
>> using Wicket does achieve, however, is the elimination of a high level
>> widget system. While we are not really taking advantage of it it is possible
>> to have the OFBiz widgets present themselves in a Swing, SWT or GWT form
>> without rebuilding the entire GUI from scratch. That's a pretty big strike
>> against the Wicket approach. Wicket is also pretty tightly bound to Java the
>> language, which may or may not be the most productive thing to use depending
>> on your point of view (ie. PHP programmers are plentiful and cheap).
>>>
>>> In some problem domains like the shopping front-end we may need to accept
>> that the customer use-cases are simply to variable to make the widget
>> strategy add value. That's why, here at Brainfood, we've rebuilt the
>> e-commerce front end on our own templating system. Wicket might also be a
>> worthwhile strategy for that front end rebuild. I imagine that most of your
>> HTML workload revolves around that component. If you really believe in it, I
>> encourage you to build a Wicket version of the ecommerce component. I would
>> be happy to review it and compare its benefits with our effort.
>>
>> The general idea is an interesting one, ie of really separating things by
>> role and eliminating dependencies.
>>
>> I like the stuff you guys at Brainfood have done with WebSlinger, and it
>> certainly makes things easier for people in certain roles.
>>
>> In a way I wonder if points #1 and #2 that I listed above are actually
>> possible. My theory over the years is that they are simply not possible, and
>> all attempts are guaranteed to fall short because those requirements are not
>> "internally consistent". It would be interesting to have a well-funded R&D
>> project to get feedback from a bunch of people, assemble a number of
>> possible designs, then implement and test those designs in various
>> organizations. I'm not sure if that will ever happen, and I suppose even if
>> it did the winning design would probably be so biased by politicking that
>> the stated result might not be accurate.
>>
>> Anyway, it's a tough problem. The main issues I see are kind of like what
>> you listed Ean, namely:
>>
>> 1. different organizations have different roles and different skills sets,
>> so to be effective you'd really need to document a variety of organizations
>> and combinations of skill sets and be flexible enough to address at least a
>> few of the most common ones, or the ones that should be most easy for an
>> organization to assemble
>>
>> 2. it's not possible to completely eliminate dependencies between what
>> different people in different roles are doing; there might be some things
>> you could do to either mitigate (handle automatically or
>> transparently/implicitly) or obviate (fail fast/early) the problems, but
>> these dependencies are an inherent part of what is being built and IMO they
>> simply cannot be totally eliminated, especially if you want reusable parts
>> of the screens, etc
>>
>> My favorite approach so far to getting people to handle this well is to
>> divide front-end developers into those who are mostly visually talented, and
>> those who have gotten into scripting and such too. These people will have to
>> get used to working together in order to get things done, IMO. From time to
>> time you'll run into a person that is great at both, but not usually. Those
>> who are into scripting and working with straight HTML can usually get into
>> using the OFBiz widgets and FTL templates and do quite well with them (and
>> without very much training too). But that isn't everyone, and you certainly
>> need someone who can break things down and implement the technical things to
>> drive them.
>>
>> Some tools make this easier, and therefore require less technical
>> knowledge, but those tools typically also restrict what you can do. If you
>> want to keep it cheap and simple then that's great, just do what the tool
>> makes easy. If you really want to be able to design and build anything that
>> is "internally consistent" then you're going to need more flexible tools and
>> more knowledgeable people.
>>
>> Or am I wrong and the silver bullet solution does exist and I just haven't
>> yet had the pleasure of experiencing it?
>>
>> Hopefully this time I'm less snarky, without being too depressing... :)
>>
>> -David
>>
>>
>>

Ean Schuessler

Re: Using Apache Wicket in Ofbiz presentation layer

In reply to this post by David E. Jones-2

David E Jones wrote:
> The general idea is an interesting one, ie of really separating things by role and eliminating dependencies.
>
> I like the stuff you guys at Brainfood have done with WebSlinger, and it certainly makes things easier for people in certain roles.
>
Webslinger definitely makes certain things easier but it also destroys
the portability proposition of the widget system. We are currently
looking at supporting form widgets as a native document type in
webslinger, which may restore some of that portability.

One thing I have been curious about is building a XUL renderer, which
should be pretty thin.
> In a way I wonder if points #1 and #2 that I listed above are actually possible. My theory over the years is that they are simply not possible, and all attempts are guaranteed to fall short because those requirements are not "internally consistent". It would be interesting to have a well-funded R&D project to get feedback from a bunch of people, assemble a number of possible designs, then implement and test those designs in various organizations. I'm not sure if that will ever happen, and I suppose even if it did the winning design would probably be so biased by politicking that the stated result might not be accurate.
>
Actually I think this is essentially going on and has for some time. I
think the difficulty of the problem is why there are so many "web
frameworks". There is no clear solution so people keep throwing things
up to see if they will stick.

I think the fundamental disconnect is analogous to automobile body
design -vs- powertrain design. On the one hand, you have people that
want to draw pictures of awesome looking cars and on the other hand you
have people who want to tackle physics problems to deliver power in a
system. Making those things blend together seamlessly, as you indicated,
requires an understanding of all the principals involved. Great
industrial design combines the intuition of art with the rigid demands
of engineering and you can't really get one or the other for free.

> Anyway, it's a tough problem. The main issues I see are kind of like what you listed Ean, namely:
>
> 1. different organizations have different roles and different skills sets, so to be effective you'd really need to document a variety of organizations and combinations of skill sets and be flexible enough to address at least a few of the most common ones, or the ones that should be most easy for an organization to assemble
>
> 2. it's not possible to completely eliminate dependencies between what different people in different roles are doing; there might be some things you could do to either mitigate (handle automatically or transparently/implicitly) or obviate (fail fast/early) the problems, but these dependencies are an inherent part of what is being built and IMO they simply cannot be totally eliminated, especially if you want reusable parts of the screens, etc
>
> My favorite approach so far to getting people to handle this well is to divide front-end developers into those who are mostly visually talented, and those who have gotten into scripting and such too. These people will have to get used to working together in order to get things done, IMO. From time to time you'll run into a person that is great at both, but not usually. Those who are into scripting and working with straight HTML can usually get into using the OFBiz widgets and FTL templates and do quite well with them (and without very much training too). But that isn't everyone, and you certainly need someone who can break things down and implement the technical things to drive them.
>
> Some tools make this easier, and therefore require less technical knowledge, but those tools typically also restrict what you can do. If you want to keep it cheap and simple then that's great, just do what the tool makes easy. If you really want to be able to design and build anything that is "internally consistent" then you're going to need more flexible tools and more knowledgeable people.
>
> Or am I wrong and the silver bullet solution does exist and I just haven't yet had the pleasure of experiencing it?
>

Even HTML is almost still too far into the engineering realm. The truly
beautiful tool is Photoshop, which makes the process of image creation
almost totally artistic and lets you forget that you are manipulating
data structures. In the free software world, Inkscape is actually quite
impressive in this way. You can totally forget that you are manipulating
SVG and simply draw. There is really no analog for this in the HTML
world, especially because of CSS.

In some ways, SquareSpace.com's online web design tool approaches what
I'd like to see a tool do, though it introduces many limitations. I'd
encourage everyone to look at its demo video. If we could provide a CMS
tool that acts like that and expose the power of the OFBiz business
logic into it, the world would be ours.
> Hopefully this time I'm less snarky, without being too depressing... :)
>
A tough problem can be fun.

Ean Schuessler

Re: Using Apache Wicket in Ofbiz presentation layer

In reply to this post by Abdullah Shaikh

Abdullah Shaikh wrote:

> This way the FTL pages will be free of any logic and will just render the
> data provided through context from Groovy.
>
> If using this technique,
>
> 1) Every FTL page will require a Groovy file for data preparation logic
> 2) Any changes can be does easily as Groovy won't require server restart
> 3) Changes in the UI can be done easily as we just need to paste the new UI
> code and get appropriate data from context and display it where ever you
> require.
>
> We can decide on a model for passing data to FTL pages, for example
>
> Groovy :
>
> data.put("userdetails", userdetails);
> data.put("paymentsinfo" paymentinfo);
> data.put"shoppingcart", shoppingcart);
> context.put("data", data);
>
> FTL :
>
> <table data.get("userdetails")</table>
> <table>data.get("paymentinfo", paymentinfo)</table>
> <table>data.get("shoppingcart" shoppintcart);
>

I think the danger here is that you are going to move HTML from the view
up into the logic. At that point, editing the Groovy file is totally out
of the designer's reach. If those data elements can be made extremely
generic and provide good CSS hooks then maybe it is a solution and helps
make the FTL less fragile. Handled incorrectly it will just require
design changes to be implemented by the programmer in the Groovy file.

Tim Ruppert

Re: Using Apache Wicket in Ofbiz presentation layer

In reply to this post by Ean Schuessler

This is definitely the goal - it has some limitations, but that UI and usage is downright awesome.

Cheers,

Ruppert

Tim Ruppert

HotWax Media

http://www.hotwaxmedia.com

o:801.649.6594

f:801.649.6595

On Dec 22, 2009, at 11:25 AM, Ean Schuessler wrote:

In some ways, SquareSpace.com's online web design tool approaches what I'd like to see a tool do, though it introduces many limitations. I'd encourage everyone to look at its demo video. If we could provide a CMS tool that acts like that and expose the power of the OFBiz business logic into it, the world would be ours.

smime.p7s (3K) Download Attachment

Ean Schuessler

Re: Using Apache Wicket in Ofbiz presentation layer

In reply to this post by Abdullah Shaikh

Abdullah Shaikh wrote:

> "If your groovy compile some information, do findList, getRelated ... , if
> you deploy for a customer a screen that don't use all information, you
> generate unnecessary work to your database."
>
> But in groovy you will need to get only that data from database which will
> be required for the FTL page
>
> It's like if an existing FTL gets "xyz" data from database, using this
> approach it will be like, groovy get "xyz" data from the database and
> putting it inside the context, FTL will get this data from the context.

If you use closures then the calls will only occur when they are used...

Groovy:

context.userDetails = {
def user = dispatcher.runSync("getSpecialUser", [])
if (user.entityName == "Person") return """
<tr>
<td>
<span class="firstname">$user.firstName</span>
<span class="lastname">$user.lastName</span>
is definitely a person.
</td>
</tr>
""" else return """
<tr>
<td>
<span class="notperson">User is not a person.</span>
</td>
</tr>
"""
}

FTL:

<table>
$userDetails.call()
</table>

This way the work of generating the user details is never done unless
the FTL pulls them in. This approach is useful for all kinds of
formatting chores.

Vasanth Kamatgi

RE: Using Apache Wicket in Ofbiz presentation layer

In reply to this post by Shi Yusen

But, the downside of this approach is - I would be losing the ofbiz community improvements in the ecommerce front end. for any change / bugfix / enhancement in the ecommerce module, I need to explicitly port it again in my own implementation, which is kind of contradictory to the reason why I had wanted to use an open source application with activity community in the first place. In fact, we had evaluated this option as well but discarded it for the reason mentioned above.

Shi Yusen wrote

I guess you're doing what we did at our beginning.

David is a superman, we are not, so we have to do it in another way.

We decided to use OpenCms as the frontend several years ago, and then
the developers can be divided into 3 groups: UI developers (require JSP
only), OpenCms module developers (reusable GUIs and functions), OFBiz
service developers (extend OFBiz RMI/data to support OpenCms modules).
Now we also use portlets and flashes as UI.

Fish-bone diagram is helpful to analyse a business and implement it in
OFBiz. "Old OFBiz Standard Floating Layout" is more helpful to combine
consultant works with the OFBiz UI.

My 2 cents,

Shi Yusen/Beijing Langhua Ltd.

在 2009-12-20日的 09:02 +0530，Vasanth Kamatgi写道：
> You have summed it up well David. I am looking exactly at that problem.
>
> We had not seen these problems when we started out with Ofbiz, nor did we
> visualize at that time (4 years back) that we would face problems like
> these, in future. I think it is a typical scale-up stage issue that Ofbiz
> doesn't solve well where functionality and UI throughput expected is
> exponentially large and complete team is not as multi-disciplined as the
> original team was. I also think that Ofbiz presentation layer is a legacy
> of MVC-II paradigm, which was in vogue at the time of design of Ofbiz and
> which is now being *contested* by Component based frameworks like JSF, Flex
> and Wicket.
>
> 1) I would like to hear from others, their views on the subject
> 2) How have other organizations handled this issue? Are there alternatives
> within the existing Ofbiz framework, people have successfully employed?
> 3) I am not aware, how to kick-off the analysis, requirement comparison, POC
> etc. activities. Guidance by community gurus would be a great help.
>
> Cheers,
> Vasanth
>
> -----Original Message-----
> From: David E Jones [mailto:dejc@me.com]
> Sent: Sunday, December 20, 2009 2:09 AM
> To: dev@ofbiz.apache.org
> Subject: Re: Using Apache Wicket in Ofbiz presentation layer
>
>
> To sum up:
>
> 1. you want a full separation of concerns for the different roles in your
> organization, something that won't require additional training beyond their
> existing skill set
>
> 2. you want no dependencies between different roles so they can't mess each
> other up or slow each other down
>
> 3. Apache Wicket will provide these things
>
> Does that sound about right?
>
> This sounds amazing! I can't wait to the see the results of an analysis and
> comparison for each requirement, and a proof of concept and per-activity
> comparison between the different approaches.
>
> -David
>
>
> On Dec 19, 2009, at 11:55 AM, Vasanth Kamatgi wrote:
>
> > Hi all,
> >
> >
> >
> > Firstly I would like to thank David E. Jones
> > <http://www.blogger.com/profile/07283017166339658819> , for his
> > encouragement to use the community process.
> >
> > I had previously posted a question in this community at
> >
> http://n4.nabble.com/Application-framework-technology-set-tp195713p963334.ht
> > ml as a very terse summary of my thoughts. After having a private
> > conversation with David, I thought a much in-depth discussion on the
> > presentation layer would be beneficial to me as well as the community and
> > consequently I am starting a new thread of discussion.
> >
> >
> >
> > Here is my primary complaint of Ofbiz presentation Layer - "There isn't a
> > STRICT separation of UI / Code in the presentation layer. Due to this
> > deficiency, for any revamp in the UI, even though there is no associated
> > change in the functionality / business logic, it takes substantial amount
> of
> > developer time. I see this as a major hindrance to a typical ecommerce
> > website, where UI changes are frequent as well as significant."
> >
> >
> >
> > To give more insight into why I have this complaint, let me raise some
> > questions (and answer them):
> >
> >
> >
> > What I think a presentation Layer does?
> >
> > =============================
> >
> > I believe presentation layer can be divided into 6 areas of concern:
> >
> > Data Preparation - Events / Service (a.k.a actions) generate data that
> need
> > to be processed to result into a *shape* that can be directly used by a
> > view. Eg., only product category id exists in context, we need to display
> > category name as well - fetch it.
> >
> > Layout - It controls the relative position of each of the components
> inside
> > a page. Wireframes used to build the page.
> >
> > Page composition - Different areas of the page can be generated by a
> > separate component / screen, and the generated output needs to be stitched
> > together to result into a complete response
> >
> > Look and Feel - Visual properties of components of the page (css?)
> >
> > View Logic - The logic that controls the initial state of each elements of
> > the output - like enabling, disabling, non-display etc., of specific
> output
> > elements. Eg., if sale price exists, show it in large red font, strike
> > through the list price, else show list price in large font.
> >
> > Rich dynamic behaviour - the dynamic behaviour that each of the generated
> > output needs to provide inside user-agent's environment (javascript /
> dhtml)
> >
> >
> >
> > How have I set the things up in Ofbiz?
> >
> > ===========================
> >
> > 1. I have created my primary page layout a.k.a. decorator in
> > common-screens.xml using sections, actions, widgets, html-templates,
> > containers, etc.
> > 2. I have abstracted out the common section contents as say,
> > includes/header.ftl etc.
> > 3. I have created components of a page such as choose catalog, keyword
> > search box, etc. as screens (non-top level) using actions and html
> templates
> > in, say, catalog-screens.xml
> > 4. I create a complete response page as a screen in catalog-screens.xml
> > using actions, widgets, decorator-screen, decorator-section,
> include-screen,
> > etc. in, say, catalog-screens.xml
> > 5. I specify this top-level page as view, which I link to the
> > associated event / service via request map in controller.xml
> >
> > The actual response out is defined in html fragments in various files
> > defined in #2, #3 & #4
> >
> >
> >
> > Exactly what is it that I find cumbersome?
> >
> > ==============================
> >
> > UI Designer prepares the prototype, hands it over to the Ofbiz developer,
> > who splits it into different fragments, and creates ftls for each of those
> > sections. Then, adds page composition, view logic and rich dynamic
> > behaviour to those ftls. This complete sequence of steps is irreversible.
> > Once handover happens from UI designer to Ofbiz developer, the html / css
> > ceases to exist in its native form, making it impossible for the UI
> designer
> > to "maintain" it. Any UI bug / change request cannot be fixed by UI
> > designer. UI designer first analyses the problem reports the possible
> > causes to Ofbiz developer, who figures out which ftl file to edit and goes
> > and edits it. If a drop down box needs to move from one widget to
> another,
> > Ofbiz developer employs a cut+paste job that can be so error-prone with
> > missing tag closures, quotes, duplicates etc. There have been so many
> > instances of Ofbiz developer trying to fix UI issues, but failing to do so
> > because he / she is good at writing java-like, jsp-like and
> javascript-like
> > code and not standards-compliant html / css code. He can't use visual
> tools
> > like a UI designer to improve his productivity. Throw into this mix the
> > cross-browser compatibility issue - the whole effort becomes very
> > unproductive with UI designer, Ofbiz developer working together to fix it,
> > when it should actually be handled by UI designer alone.
> >
> > Ofbiz supports data preparation, page composition, view logic well. But
> > other areas are a little troublesome.
> >
> >
> >
> > How would I like it to work?
> >
> > ====================
> >
> > Different areas of concern, as listed in my previous paragraph, are best
> > worked at by different types of resources. Assuming we are using java
> > platform for development:
> >
> > Data Preparation - java coder
> >
> > Layout - UI designer / business analyst / SEO specialist
> >
> > Page composition - java / jsp coder
> >
> > Look and Feel - User Experience expert
> >
> > View Logic - java / jsp coder
> >
> > Rich dynamic behaviour - script coder / java coder
> >
> > Given these different areas of expertise, a software development /
> > maintenance model needs to be employed to enable these types of resources
> to
> > work at full productivity without tripping each other. Cutting a long
> story
> > short, I believe, Ofbiz should enable html, css, multi-media & view logic
> to
> > be developed and managed independently. UI designer should continue to
> fix
> > UI bugs by just editing his / her html code. There should be no pollution
> > of html and css code. View logic should be written without using tags.
> >
> > I have dived into wicket and wrote my first hello world recently and
> believe
> > wicket-like rendering would be a good enhancement to Ofbiz. I am not
> > claiming to be an expert of wicket, but based on the documentation I have
> > read, it seems to fit the scheme well.
> >
> >
> >
> > I hope I have given enough details for the community to start a
> > conversation. I understand that, the question begs of not only an
> > architectural discussion, but also of a software development / maintenance
> > model.
> >
> >
> >
> > Cheers,
> >
> > Vasanth
>

Ean Schuessler

Re: Using Apache Wicket in Ofbiz presentation layer

Vasanth Kamatgi wrote:
> But, the downside of this approach is - I would be losing the ofbiz community
> improvements in the ecommerce front end. for any change / bugfix /
> enhancement in the ecommerce module, I need to explicitly port it again in
> my own implementation, which is kind of contradictory to the reason why I
> had wanted to use an open source application with activity community in the
> first place. In fact, we had evaluated this option as well but discarded it
> for the reason mentioned above.
>
There is a risk but that risk is smaller than the community moving
arbitrarily to Wicket. If you feel that a Wicket solution would be so
strong that it would sway the opinion of the whole community then it is
your responsibility to undertake that risk. The community is very
unlikely to undertake such a risk based on someone saying "hey, I think
this is a great idea". We have undertaken a similar risk with our own
internal build-outs (worse, actually, since we built a new templating
framework instead of using an existing one).

Really, conducted properly, the risk you outline is not so high. In
theory, your Wicket solution will be a thin binding layer between the
core OFBiz logic (which won't need to change) and your customer's HTML
(which must be custom).

--
Ean Schuessler, CTO
[hidden email]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

Vasanth Kamatgi

Re: Using Apache Wicket in Ofbiz presentation layer

In reply to this post by David E. Jones-2

I agree with you in your observation that, this problem is difficult to solve, and has factors weighing against a possible solution. So, I understand the skepticism "if points #1 and #2 that I listed above are actually possible".

I know that I am being very naive to say this, but I believe, every now and then situations arise when seemingly impossible tasks get done. I am not implying that we are going to find panacea of absolute presentation design decoupling. At the worst I am expecting solutions that take us towards the decoupling - if not with the rendering mechanism, but with a tool. A tool that reads *screens.xml, interprets the ftl and stitches response output, making some assumptions in ftl. This would enable a UI designer to debug the *html-part* without actually having to run ofbiz or understand ftl. This is the worst case scenario. But, I would see some merit in continuing the discussion to find the silver bullet for decoupling at rendering stage. :)

David E Jones-4 wrote

On Dec 21, 2009, at 8:12 AM, Ean Schuessler wrote:

> David E Jones wrote:
>> To sum up:
>>
>> 1. you want a full separation of concerns for the different roles in your organization, something that won't require additional training beyond their existing skill set
>>
>> 2. you want no dependencies between different roles so they can't mess each other up or slow each other down
>>
>> 3. Apache Wicket will provide these things
>>
>> Does that sound about right?
>>
>> This sounds amazing! I can't wait to the see the results of an analysis and comparison for each requirement, and a proof of concept and per-activity comparison between the different approaches.
>>
> Just a touch Snarky there, Mr. Jones. :-)

You're right, I was a bit snarky there. I apologize if I offended anyone. I guess I should have said something like: That sounds a little bit too amazing to be true.

> Vasanth, I have spent some time examining Wicket and its not clear to me that it is able to remove the problems in all but the most simple cases. HTML for complicated multi-state widgets would still need to be divided into many fragments, which are hard for the HTML designer to understand. It would also still not be very clear to the designer where those fragments need to be delineated because they do not understand the control flow.
>
> The deep set problem is that there will be many cases where you want to look at a completed HTML assembly in its populated state to see how the layout looks. That can only be done by editing on a live ofbiz environment and that is always going to be pushing the skills of a GUI designer. What using Wicket does achieve, however, is the elimination of a high level widget system. While we are not really taking advantage of it it is possible to have the OFBiz widgets present themselves in a Swing, SWT or GWT form without rebuilding the entire GUI from scratch. That's a pretty big strike against the Wicket approach. Wicket is also pretty tightly bound to Java the language, which may or may not be the most productive thing to use depending on your point of view (ie. PHP programmers are plentiful and cheap).
>
> In some problem domains like the shopping front-end we may need to accept that the customer use-cases are simply to variable to make the widget strategy add value. That's why, here at Brainfood, we've rebuilt the e-commerce front end on our own templating system. Wicket might also be a worthwhile strategy for that front end rebuild. I imagine that most of your HTML workload revolves around that component. If you really believe in it, I encourage you to build a Wicket version of the ecommerce component. I would be happy to review it and compare its benefits with our effort.

The general idea is an interesting one, ie of really separating things by role and eliminating dependencies.

I like the stuff you guys at Brainfood have done with WebSlinger, and it certainly makes things easier for people in certain roles.

In a way I wonder if points #1 and #2 that I listed above are actually possible. My theory over the years is that they are simply not possible, and all attempts are guaranteed to fall short because those requirements are not "internally consistent". It would be interesting to have a well-funded R&D project to get feedback from a bunch of people, assemble a number of possible designs, then implement and test those designs in various organizations. I'm not sure if that will ever happen, and I suppose even if it did the winning design would probably be so biased by politicking that the stated result might not be accurate.

Anyway, it's a tough problem. The main issues I see are kind of like what you listed Ean, namely:

1. different organizations have different roles and different skills sets, so to be effective you'd really need to document a variety of organizations and combinations of skill sets and be flexible enough to address at least a few of the most common ones, or the ones that should be most easy for an organization to assemble

2. it's not possible to completely eliminate dependencies between what different people in different roles are doing; there might be some things you could do to either mitigate (handle automatically or transparently/implicitly) or obviate (fail fast/early) the problems, but these dependencies are an inherent part of what is being built and IMO they simply cannot be totally eliminated, especially if you want reusable parts of the screens, etc

My favorite approach so far to getting people to handle this well is to divide front-end developers into those who are mostly visually talented, and those who have gotten into scripting and such too. These people will have to get used to working together in order to get things done, IMO. From time to time you'll run into a person that is great at both, but not usually. Those who are into scripting and working with straight HTML can usually get into using the OFBiz widgets and FTL templates and do quite well with them (and without very much training too). But that isn't everyone, and you certainly need someone who can break things down and implement the technical things to drive them.

Some tools make this easier, and therefore require less technical knowledge, but those tools typically also restrict what you can do. If you want to keep it cheap and simple then that's great, just do what the tool makes easy. If you really want to be able to design and build anything that is "internally consistent" then you're going to need more flexible tools and more knowledgeable people.

Or am I wrong and the silver bullet solution does exist and I just haven't yet had the pleasure of experiencing it?

Hopefully this time I'm less snarky, without being too depressing... :)

-David