[jira] [Comment Edited] (OFBIZ-5040) Backend widget & application HTML clean-up

[Nicolas Malin (Jira)]

    [ https://issues.apache.org/jira/browse/OFBIZ-5040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13887601#comment-13887601 ]

Jacques Le Roux edited comment on OFBIZ-5040 at 1/31/14 10:08 AM:
------------------------------------------------------------------

== TYPO ==
What I fear, if we don't have something which keeps things together (like XML in form widgets does) is the entropy.
It ressembles the typed or not issue in languages (I worked with APL for 20 years, so I know what you can come with with untyped languages)

As soon as someone convince me things will be tighten together I will agree. I don't see people writing pages using only macro, and that's the glue between that I fear.


was (Author: jacques.le.roux):
What I fear, if we don't have something which keeps things together (like XML in form widgets does) is the entropy.
It ressembles the typed or not issue in language (I worked with APL for 20 years, so I know what you can come with with untyped languages)
AS soon as someone convince me things will be tighten together I will agree. I don't see people writing pages using only macro, and that's the glue between that I fear

> Backend widget & application HTML clean-up
> ------------------------------------------
>
>                 Key: OFBIZ-5040
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-5040
>             Project: OFBiz
>          Issue Type: Improvement
>          Components: ALL APPLICATIONS
>            Reporter: Paul Piper
>            Assignee: Jacques Le Roux
>              Labels: html, webapp, widget, widgetrendering
>
> I am sure that this is a common thing to know: the current backoffice application relies heavily on widgets. This is good, but the current standard-html-structure is not flexible enough and often lacks proper w3c implementation.
> To make matters worse, you can often find applications avoiding widgets at all and rather overriding the standards with custom ftl implementations. It is these customizations that break the html on numerous screens and make it difficult, if not tedious to create new themes for the backoffice.
> This task is hence to:
> * Find a consensus on a new widget standard
> * Go over each of the application ftls and convert these to the new standard
> * Recreate the themes and simplify/clean-up special rules
> Since redoing the theme is a rather large task, we should consider to add an additional css for now which stylises the replacement html instead of working with the old.

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[Ean Schuessler]

I disagree. Freemarker is, itself, a custom technology and one of dwindling
popularity. If we insist on using server side page templates then maybe we
should be looking at http://quercus.caucho.com/. You may think I'm nutty but
consider that we could write an adapter layer for Magento templates.

I'm convinced that the system needs to be separated into two layers, a
business logic core and a separate interface rendering layer. Even if
we have a server side rendering mechanism it should have the same access
parameters to the core as a remote swing or Javascript application. In other
words, the web actions that have privileged access to global static class
and so on need to go. The business logic that is trapped in those web actions
is tightly coupled with the specific HTML presentation they are linked with
and can't be reused elsewhere.

In fact, one of the biggest challenges we have is that the existing UI code
makes extensive use of direct delegator calls to render the interface but the
delegator is not available remotely for obvious security reasons. How is
another view technology (dynamic javascript, swing, whatever) supposed to
achieve the functionality that the existing UI provides? You have to rewrite
everything as services and many of those services don't exist because the
UI is using delegator access instead. Am I making any sense here?

----- "Paul Piper (JIRA)" <[hidden email]> wrote:

> That i can understand, jacques. And realistically speaking there is no
> way we can easily get rid of all the widgets anyhow. But you cannot
> enforce the use of a custom technology on the masses, nor should you
> in my opinion. People won't even be using our macros alot, but that's
> not a problem: The idea is for us to provide a framework that people
> can use to adapt. The easier we make it for them, the more we are
> reaching that goal...

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

[Scott Gray-2]

I agree completely regarding the need for fully exposed business logic and I think Anil's been saying the same thing.  IMO it's the first and most important step that needs to be taken towards modernizing the OFBiz UI.

Regards
Scott

On 31/01/2014, at 4:01 PM, Ean Schuessler wrote:

> I disagree. Freemarker is, itself, a custom technology and one of dwindling
> popularity. If we insist on using server side page templates then maybe we
> should be looking at http://quercus.caucho.com/. You may think I'm nutty but
> consider that we could write an adapter layer for Magento templates.
>
> I'm convinced that the system needs to be separated into two layers, a
> business logic core and a separate interface rendering layer. Even if
> we have a server side rendering mechanism it should have the same access
> parameters to the core as a remote swing or Javascript application. In other
> words, the web actions that have privileged access to global static class
> and so on need to go. The business logic that is trapped in those web actions
> is tightly coupled with the specific HTML presentation they are linked with
> and can't be reused elsewhere.
>
> In fact, one of the biggest challenges we have is that the existing UI code
> makes extensive use of direct delegator calls to render the interface but the
> delegator is not available remotely for obvious security reasons. How is
> another view technology (dynamic javascript, swing, whatever) supposed to
> achieve the functionality that the existing UI provides? You have to rewrite
> everything as services and many of those services don't exist because the
> UI is using delegator access instead. Am I making any sense here?
>
> ----- "Paul Piper (JIRA)" <[hidden email]> wrote:
>
>> That i can understand, jacques. And realistically speaking there is no
>> way we can easily get rid of all the widgets anyhow. But you cannot
>> enforce the use of a custom technology on the masses, nor should you
>> in my opinion. People won't even be using our macros alot, but that's
>> not a problem: The idea is for us to provide a framework that people
>> can use to adapt. The easier we make it for them, the more we are
>> reaching that goal...
>
> --
> Ean Schuessler, CTO
> [hidden email]
> 214-720-0700 x 315
> Brainfood, Inc.
> http://www.brainfood.com