ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Taher Alkhateeb <slidingfilame...@gmail.com>
Subject Re: [Discussion] Introduction of Bootstrap and Vue.js
Date Mon, 21 May 2018 18:03:12 GMT
Hello Gavin, Your timing is pretty good actually and we can gain from
your experience. Comments and questions inline ...

On Mon, May 21, 2018 at 1:03 PM, Gavin Mabie <kwikstore@gmail.com> wrote:
> Hi guys
>
> I've been away for a while so my input maybe a bit behind the curve.
> Having said that, I have some useful Bootstrap-with-Ofbiz experience under
> the belt which may be relevant to this discussion:
> 1.  Bootstrap is mainly CSS. It's pretty, but with limited JavaScript
> functionality. In-fact JS in Bootstrap is entirely optional because it
> doesn't pretend to be a JS Framework.

Perhaps this is a point in favor of Bootstrap. The less JavaScript the
less messy things are.

> 2.  You will be required to mine 3rd party plugins/widgets to cover
> functionalities absent from Bootstrap - and those may not be
> well-maintained. Risky!

What would we need? And why would we need it? Why _must_ it be a plugin?

> 3. Autocomplete and Date Picking functions specifically - frequently used
> in Ofbiz, but not "native" in Bootstrap. This sometimes leads to all manner
> of conflicts and complicates manageability.

Can you elaborate please? Do you have an example of a problem that we
will would face should we adopt Bootstrap?

>
> If your only criteria for Bootstrap is grid-layout capabilities, consider
> that grid is quite easily attainable with pure CSS through the @media

That's a lot of work! That's like saying let's write a desktop app in
Assembly. I mean you can do it, but why! The "@media" is just a
building block.

> selector used with break points. Secondly, "Grid" will become a standard in
> CSS  (see https://www.w3.org/TR/css-grid-2/). The investment in a
> "framework" for "Grid" only - that's an overkill.

Well, naturally, if you implement bootstrap then you get all the
goodies with it, not just the grid, otherwise you can choose a simple
Grid library (many out there)

>
> My 2 Cents:
> 1. How about jQuery Mobile(JQM)? It's part of the jQuery family.  We
> already use jQuery as JavaScript framework, to use JQM would be a logical
> extension.
> 2. JQM covers SPA - an important functionality identified by some in this
> thread.
> 3. JQM fits in nicely with jQuery UI - something which we are already using
> in Ofbiz with autocomplete/suggest, date picking and modals.
>
> Final thoughts - Cleaner separation between JS and Freemarker using HTML
> elements:
> 1. We are not using new outlining and sectioning elements like <section>,
> <article>, <nav>, <header>, <footer>, or <aside> in our
templates. They
> hold obvious advantages.
> 2.  Global data-* attributes.  We're not using this at all.  It can help us
> to reduce JS in Freemarker templates.
>
> Regards
>
> Gavin
>
>
>
>
>
> On Mon, May 21, 2018 at 5:17 AM, Shi Jinghai <huaruhai@hotmail.com> wrote:
>
>> +1.
>>
>> Excellent.
>>
>> -----邮件原件-----
>> 发件人: Taher Alkhateeb [mailto:slidingfilaments@gmail.com]
>> 发送时间: 2018年5月20日 2:31
>> 收件人: OFBIZ Development Mailing List
>> 主题: Re: [Discussion] Introduction of Bootstrap and Vue.js
>>
>> This was a thought provoking and interesting discussion and I learned
>> new stuff from it, so thank you all for your valuable input.
>>
>> On further reflection and after thinking about your comments, I think
>> Vue.js would be influenced in its design if we have a REST API in
>> place, however, something like Bootstrap is not relevant because it is
>> just a pure CSS / Javascript library to offer a grid system and some
>> user interface widgets. It has no model to bind to nor does it require
>> any back-end traffic (SPA stuff).
>>
>> So I recommend proceeding with Bootstrap, and we can delay something
>> like Vue.js while we proceed in implementing the Web Services API.
>> I'll start or find another thread for that discussion.
>>
>> WDYT?
>>
>> On Fri, May 18, 2018 at 10:43 AM, innate Genius
>> <innate.passion@gmail.com> wrote:
>> > Hi,
>> >
>> > +1 For Jacques, Scot & Rajesh’s View Point.
>> >
>> >> "I feel most of the modern UI frameworks  consume JSON and
>> >> if we have yet another adapter to the rich catalog of WebServices
>> >> ( in addition to XML/RPC and SOAP) it shall benefit   both UI developers
>> >> and
>> >> system integrators / framework users."
>> >
>> > This is been discussed in few other threads but this is a issue that is
>> long due. And would love to see the community to finally address this.
>> >
>> > @Taher: Webservice to consume JSON would be the most beneficial and
>> desired enhancement to the framework.
>> >
>> > Thx & Rgds,
>> >
>> > Pratiek
>> >
>> >> On 17-May-2018, at 9:27 PM, Rajesh Mallah <mallah.rajesh@gmail.com>
>> wrote:
>> >>
>> >> Hi List ,
>> >>
>> >> The default UI of OFBiz does look aged but I feel it does a great job
>> >> of being  productive. As discussed before also ERP being a serious
>> >> backroom software and mostly operated by staff to whom all the bells
>> >> and whistles of modern  frameworks may not make any difference.
>> >>
>> >> But since adoption of OFBiz to enterprises is dependent on decision
>> makers/
>> >> influencer who may not even know the nuances of UI and its relation to
>> >> productivity it is important to look modern and shiny and which is the
>> >> reason of
>> >> this thread by Mr. Taher.
>> >>
>> >>
>> >> Hence IMHO its good and required for OFBiz.
>> >>
>> >> At the same time we need to increase the comfort level of system
>> integrators
>> >> and people  who use ofbiz as  a framework.
>> >>
>> >> I feel most of the modern UI frameworks  consume JSON and
>> >> if we have yet another adapter to the rich catalog of WebServices
>> >> ( in addition to XML/RPC and SOAP) it shall benefit   both UI developers
>> >> and
>> >> system integrators / framework users.
>> >>
>> >> I also humbly feel while this modernization is done, the existing
>> interface
>> >> should
>> >> not be done away with as people develop very strange and innovative
>> comfort
>> >> zones with software UIs which are difficult to anticipate by developers.
>> >>
>> >> my 2cents.
>> >>
>> >>
>> >> regds
>> >> mallah.
>> >>
>> >>
>> >> On Wed, May 16, 2018 at 5:30 PM, Jacques Le Roux <
>> >> jacques.le.roux@les7arts.com> wrote:
>> >>
>> >>> Hi Scott, Taher,
>> >>>
>> >>> I think you are both right, and maybe because you are mostly working
>> for 2
>> >>> different markets or have different types of clients.
>> >>>
>> >>> Anyway, what I mean is:
>> >>>
>> >>> 1. Form widgets are not of much use when you have to deploy a new UI
>> for
>> >>> an ecommerce or alike project (frontend).
>> >>> 2. They are very useful when you are working on a backend project (ie
>> ERP
>> >>> part) where people don't care much about bells and whistle (even if
>> that's
>> >>>   less and less happening) but want a fast ROI ("time-to-market
>> reasons"
>> >>> as said Taher)
>> >>>
>> >>> I don't know if Mathieu will get enough time to succeed on his project.
>> >>> But obviously if we had the possibility to generate RESTful web
>> services
>> >>> from OFBiz services, with the export attribute like for SOAP and RMI,
>> then
>> >>> Scott's idea would be fulfilled and that would help much, not only in
>> the
>> >>> UI area of course.
>> >>>
>> >>> Now for widgets, the form part could maybe slowly replaced by using
>> tools
>> >>> like Bootstrap and Vue.js. Or the new flavor in some years and that
>> must be
>> >>> very seriously taken into account to not have to redo it again, in few
>> >>> years...
>> >>>
>> >>> Jacques
>> >>>
>> >>>
>> >>>
>> >>> Le 15/05/2018 à 12:18, Taher Alkhateeb a écrit :
>> >>>
>> >>>> Ahhh, I understand clearly now. Thank you!
>> >>>>
>> >>>> So more or less, the heart of your message as I understand it is
that
>> >>>> we should decouple the rendering of the user interface from data
>> >>>> fetching and manipulation. This makes perfect sense and is a good
>> >>>> strategy.
>> >>>>
>> >>>> A bit contrary to your experience though, most of our work relies
>> >>>> heavily on the widget system for time-to-market reasons. It has
been
>> >>>> immensely beneficial to get something out the door quickly. However,
>> >>>> of course the system falls short when it comes to heavy customizations
>> >>>> or the need to integrate with other systems.
>> >>>>
>> >>>> So I would suggest that perhaps your comment in this thread that
>> >>>> "having prebuilt APIs would have reduced the workload" is applicable
>> >>>> in case of custom work. Otherwise, perhaps the faster route is through
>> >>>> the widget system. Therefore I think it is reasonable to apply both
>> >>>> strategies: 1) use good modern UI tools 2) build powerful flexible
web
>> >>>> APIs. But for standard screens, I see no reason to use web service
>> >>>> calls instead of <action>...</action> tags to do quick
and obvious
>> >>>> things unless perhaps you make the web API call part of the widget
>> >>>> system itself (also a good idea!)
>> >>>>
>> >>>> Anyway, you're making me think more seriously of pushing forward
the
>> >>>> implementation of web services, but I think introducing these
>> >>>> frameworks is going to be beneficial either way.
>> >>>>
>> >>>> On Tue, May 15, 2018 at 12:44 PM, Scott Gray
>> >>>> <scott.gray@hotwaxsystems.com> wrote:
>> >>>>
>> >>>>> Hi Taher,
>> >>>>>
>> >>>>> I'm simply saying that if we were to provide a complete suite
web
>> APIs to
>> >>>>> access the full functionality of ofbiz, then the project's choice
of
>> UI
>> >>>>> technology no longer matters so much in the grand scheme of
things.
>> No
>> >>>>> one
>> >>>>> would be forced to live by our choice of UI frameworks because
they
>> could
>> >>>>> build anything they liked using the APIs without ever touching
the
>> >>>>> server-side code.
>> >>>>>
>> >>>>> Right now our data gathering logic is tightly coupled to our
UI,
>> >>>>> inaccessible to other servers and apps, the vast majority of
our
>> services
>> >>>>> are built to be run internally by ofbiz.  Without heavy modification
>> of
>> >>>>> the
>> >>>>> server side code, I can't build a custom SPA, I can't send orders
to
>> >>>>> ofbiz
>> >>>>> from another application, I can't really do anything without
>> interacting
>> >>>>> with the OFBiz UI.
>> >>>>>
>> >>>>> The majority of the client projects I've worked on always involve
a
>> >>>>> completely custom UI and with web APIs I could pick up any flavor
of
>> the
>> >>>>> month UI framework to build it with.
>> >>>>>
>> >>>>> All I'm trying to add to this conversation is that it would
be nice
>> if
>> >>>>> any
>> >>>>> UI overhaul started with making APIs available that could be
used
>> both by
>> >>>>> our framework of choice and be externally accessible to anyone
else's
>> >>>>> framework of choice.
>> >>>>>
>> >>>>> Regards
>> >>>>> Scott
>> >>>>>
>> >>>>>
>> >>>>> On Tue, 15 May 2018, 20:27 Taher Alkhateeb, <
>> slidingfilaments@gmail.com>
>> >>>>> wrote:
>> >>>>>
>> >>>>> Hi Scott,
>> >>>>>>
>> >>>>>> Again thank you for the input, intriguing. I'm not sure
if I fully
>> >>>>>> understand though. Are you saying we can introduce web services
>> that can
>> >>>>>> sort of do away with the widget system to code directly
in html and
>> >>>>>> weaving
>> >>>>>> in web service calls? How does that make coding faster?
What is
>> >>>>>> inefficient
>> >>>>>> in the widget system? What kind of architecture should we
have in
>> place?
>> >>>>>> What is the routing workflow that you're suggesting?
>> >>>>>>
>> >>>>>> I would appreciate a bit more elaboration to get a better
>> understanding
>> >>>>>> of
>> >>>>>> your point of view since this seems to be a critical architectural
>> >>>>>> decision.
>> >>>>>>
>> >>>>>>
>> >>>>>> On Mon, May 14, 2018, 9:39 PM Scott Gray <
>> scott.gray@hotwaxsystems.com>
>> >>>>>> wrote:
>> >>>>>>
>> >>>>>> On Mon, 14 May 2018, 20:38 Taher Alkhateeb, <
>> slidingfilaments@gmail.com
>> >>>>>>>>
>> >>>>>>> wrote:
>> >>>>>>>
>> >>>>>>> Hello Scott, thank you for your thoughts, inline ...
>> >>>>>>>>
>> >>>>>>>> On Mon, May 14, 2018 at 10:45 AM, Scott Gray
>> >>>>>>>> <scott.gray@hotwaxsystems.com> wrote:
>> >>>>>>>>
>> >>>>>>>>> I think no matter what we use someone will always
want something
>> >>>>>>>>>
>> >>>>>>>> different.
>> >>>>>>>>
>> >>>>>>>>> I'm beginning to lose count of the number of
custom APIs I've
>> written
>> >>>>>>>>>
>> >>>>>>>> over
>> >>>>>>>>
>> >>>>>>>>> the years to support custom UIs.
>> >>>>>>>>>
>> >>>>>>>>> I think the bigger win would be to start providing
APIs and
>> rewriting
>> >>>>>>>>>
>> >>>>>>>> our
>> >>>>>>>
>> >>>>>>>> existing screens to use them. From there we could
start looking at
>> >>>>>>>>>
>> >>>>>>>> new
>> >>>>>>
>> >>>>>>> UI
>> >>>>>>>
>> >>>>>>>> frameworks.
>> >>>>>>>>>
>> >>>>>>>> Do you mean by APIs rewriting our XSD files and
model objects? Why
>> >>>>>>>> rewrite? Why not just enhance them for new / missing
>> functionality?
>> >>>>>>>> What are the flaws you'd like to redesign?
>> >>>>>>>>
>> >>>>>>>> No, I'm talking about web services. With well designed
web
>> services
>> >>>>>>>
>> >>>>>> custom
>> >>>>>>
>> >>>>>>> projects would be able to build out new user interfaces
in a lot
>> less
>> >>>>>>>
>> >>>>>> time
>> >>>>>>
>> >>>>>>> and we'd be able to poc new interfaces for the community
project
>> >>>>>>> without
>> >>>>>>> even touching the existing codebase.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Most of the projects I've worked on have needed huge
amounts of UI
>> >>>>>>>>> customization and having prebuilt APIs would
have reduced the
>> >>>>>>>>>
>> >>>>>>>> workload
>> >>>>>>
>> >>>>>>> much
>> >>>>>>>>
>> >>>>>>>>> more than having a shinier UI that still needs
to be completely
>> >>>>>>>>>
>> >>>>>>>> rewritten,
>> >>>>>>>>
>> >>>>>>>>> although I'll admit the latter would probably
help the sales
>> process.
>> >>>>>>>>>
>> >>>>>>>> The "shiny" part is a plus, but not the core of
my suggestion. The
>> >>>>>>>> reasons I suggested these libraries are:
>> >>>>>>>> - bootstrap: the grid system, this is the cake for
me. You have a
>> >>>>>>>> powerful responsive grid system for better layouts.
The buttons,
>> >>>>>>>> tables and other bling bling are icing on the cake.
>> >>>>>>>> - Vue: The core of this technology is to allow binding
of your
>> context
>> >>>>>>>> model to the DOM so that you don't write oodles
of JavaScript and
>> >>>>>>>> Jquery to create dynamic behavior. It's really old
school in 2018
>> to
>> >>>>>>>> keep jumping between many pages to get something
done.
>> >>>>>>>>
>> >>>>>>>> Does it not worry anyone else that our service engine
still only
>> >>>>>>>>>
>> >>>>>>>> defines
>> >>>>>>>
>> >>>>>>>> a
>> >>>>>>>>
>> >>>>>>>>> basic map for in/out parameters when the rest
of the world is
>> using
>> >>>>>>>>>
>> >>>>>>>> the
>> >>>>>>
>> >>>>>>> likes of swagger and restful APIs?
>> >>>>>>>>>
>> >>>>>>>> Of course it worries me, and if you start an initiative
I will be
>> the
>> >>>>>>>> first to jump in and volunteer. In fact it's on
my todo list, and
>> I
>> >>>>>>>> was looking at multiple options lately and I'm very
attracted to
>> >>>>>>>> GraphQL for example because of the reduced visits
to the backend.
>> >>>>>>>> However, I don't see this as being related to my
proposal here,
>> I'm
>> >>>>>>>> just setting my own priorities of what to work on
next. What's
>> wrong
>> >>>>>>>> with starting _both_ initiatives for that matter?
>> >>>>>>>>
>> >>>>>>>> Nothing is wrong with both, but as you pointed out
many
>> discussions
>> >>>>>>> and
>> >>>>>>> efforts have begun and then floundered. I'm simply offering
some
>> >>>>>>> thoughts
>> >>>>>>> on where I see the most potential benefit from a large
scale
>> effort.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Regards
>> >>>>>>>>> Scott
>> >>>>>>>>>
>> >>>>>>>>> On Sun, 13 May 2018, 06:03 Taher Alkhateeb,
<
>> >>>>>>>>>
>> >>>>>>>> slidingfilaments@gmail.com>
>> >>>>>>>
>> >>>>>>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>> Hello Everyone,
>> >>>>>>>>>>
>> >>>>>>>>>> Recently, we at Pythys had some interactions
with clients, and
>> the
>> >>>>>>>>>> user interface proved to be a sour point.
It is functioning
>> well,
>> >>>>>>>>>>
>> >>>>>>>>> but
>> >>>>>>
>> >>>>>>> looks too classic, too rigid, too 2000s really :) We
had many
>> >>>>>>>>>> discussion and attempts in the past like
[1] [2] [3] [4] [5]
>> [6] [7]
>> >>>>>>>>>> [8] [9] [10] just to name a few all of which
seemed not to
>> follow
>> >>>>>>>>>> through.
>> >>>>>>>>>>
>> >>>>>>>>>> So what is the problem? Why is this hard
to get right? I'm not
>> sure
>> >>>>>>>>>>
>> >>>>>>>>> I
>> >>>>>>
>> >>>>>>> have the magic answer, but it seems to me like part
of the problem
>> >>>>>>>>>>
>> >>>>>>>>> is
>> >>>>>>
>> >>>>>>> simply .. TOO BIG
>> >>>>>>>>>>
>> >>>>>>>>>> So I was thinking about a possible solution,
and after some
>> initial
>> >>>>>>>>>> research, I think maybe the solution (like
everything else)
>> needs to
>> >>>>>>>>>> be slow, incremental and evolutionary rather
than
>> revolutionary. So
>> >>>>>>>>>>
>> >>>>>>>>> I
>> >>>>>>
>> >>>>>>> am suggesting the following ideas to try and move forward:
>> >>>>>>>>>>
>> >>>>>>>>>> - We include the assets for Bootstrap in
the common theme.
>> Bootstrap
>> >>>>>>>>>> will give us the Grid system which allows
for a responsive
>> website
>> >>>>>>>>>> that works on all devices, it will also
give us beautiful
>> widgets to
>> >>>>>>>>>> work with.
>> >>>>>>>>>> - We include Vue.js assets in the common
theme. Vue.js is an
>> >>>>>>>>>>
>> >>>>>>>>> excellent
>> >>>>>>
>> >>>>>>> framework for creating Single Page Applications (SPAs)
to give
>> >>>>>>>>>>
>> >>>>>>>>> dynamic
>> >>>>>>
>> >>>>>>> behavior to our pages and create ajax-heavy pages
>> >>>>>>>>>> - We slowly migrate our old CSS to bootstrap
constructs. We can
>> >>>>>>>>>>
>> >>>>>>>>> begin
>> >>>>>>
>> >>>>>>> for example by replacing our menus, then tables, then
headers, then
>> >>>>>>>>>> buttons etc ..
>> >>>>>>>>>> - We slowly introduce dynamic screens using
controller logic in
>> >>>>>>>>>>
>> >>>>>>>>> Vue.js
>> >>>>>>
>> >>>>>>> - We slowly update our macro library to migrate to the
above
>> >>>>>>>>>>
>> >>>>>>>>> mentioned
>> >>>>>>
>> >>>>>>> libraries and widgets
>> >>>>>>>>>> - We do all of this live in Trunk, without
branching. This means
>> >>>>>>>>>>
>> >>>>>>>>> that
>> >>>>>>
>> >>>>>>> for some period of time, there will be transitional
code (a little
>> >>>>>>>>>>
>> >>>>>>>>> bit
>> >>>>>>
>> >>>>>>> of bootstrap and a little bit of our current code)
>> >>>>>>>>>>
>> >>>>>>>>>> We can start with an initial proof of concept
skeleton, and if
>> that
>> >>>>>>>>>> gets consensus, then we can move forward
with a full
>> implementation
>> >>>>>>>>>>
>> >>>>>>>>> in
>> >>>>>>
>> >>>>>>> trunk. I think this issue is many years over due. Our
interface
>> >>>>>>>>>>
>> >>>>>>>>> looks
>> >>>>>>
>> >>>>>>> oooooooooooooold and really needs a face lift.
>> >>>>>>>>>>
>> >>>>>>>>>> What do you think? Ideas? Suggestions?
>> >>>>>>>>>>
>> >>>>>>>>>> [1] https://s.apache.org/rf94
>> >>>>>>>>>> [2] https://s.apache.org/g5zr
>> >>>>>>>>>> [3] https://s.apache.org/XpBO
>> >>>>>>>>>> [4] https://s.apache.org/YIL1
>> >>>>>>>>>> [5] https://s.apache.org/836D
>> >>>>>>>>>> [6] https://s.apache.org/DhyB
>> >>>>>>>>>> [7] https://s.apache.org/Lv9E
>> >>>>>>>>>> [8] https://s.apache.org/zKIo
>> >>>>>>>>>> [9] https://s.apache.org/D6jx
>> >>>>>>>>>> [10] https://issues.apache.org/jira/browse/OFBIZ-5840
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>
>> >
>>

Mime
View raw message