[ovirt-devel] UI plugins - access to engine styles and libraries

Wed Apr 20 18:20:11 UTC 2016

On Wed, Apr 20, 2016 at 1:52 PM, Vojtech Szocs <vszocs at redhat.com> wrote:

>
>
> ----- Original Message -----
> > From: "Greg Sheremeta" <gshereme at redhat.com>
> > To: "Vojtech Szocs" <vszocs at redhat.com>
> > Cc: "Martin Sivak" <msivak at redhat.com>, "Alexander Wels" <
> awels at redhat.com>, "engine-devel at ovirt.org"
> > <devel at ovirt.org>
> > Sent: Wednesday, April 20, 2016 7:06:13 PM
> > Subject: Re: [ovirt-devel] UI plugins - access to engine styles and
> libraries
> >
> > On Wed, Apr 20, 2016 at 12:51 PM, Vojtech Szocs <vszocs at redhat.com>
> wrote:
> >
> > >
> > >
> > > ----- Original Message -----
> > > > From: "Martin Sivak" <msivak at redhat.com>
> > > > To: "Vojtech Szocs" <vszocs at redhat.com>
> > > > Cc: "Greg Sheremeta" <gshereme at redhat.com>, "Alexander Wels" <
> > > awels at redhat.com>, "engine-devel at ovirt.org"
> > > > <devel at ovirt.org>
> > > > Sent: Tuesday, April 19, 2016 5:07:52 PM
> > > > Subject: Re: [ovirt-devel] UI plugins - access to engine styles and
> > > libraries
> > > >
> > > > > With this (static linking) approach, you don't need those CSS
> > > > > or JS resources at runtime; your webapp is self-contained and
> > > > > optimized (containing only stuff it really uses).
> > > >
> > > > Right, but I won't get the same look and feel as the styles might be
> > > > different.
> > >
> > > If `ovirt.brand` is RPM-packaged, you could depend on it
> > > when building your webapp (UI plugin), but I don't think
> > > we have such RPM.
> > >
> > > > I was looking for a way to use the same colors and styles
> > > > to make the UI plugin look right in both RHEV and oVirt.
> > >
> > > Understood, just use the URL that exposes branding files,
> > > it's perfectly fine to load CSS and other stuff at runtime.
> > >
> >
> > But much of the CSS is obfuscated by GWT. There's no way to hook into it.
>
> That's correct.
>
> All I wanted to say is that we have some base CSS files
> (see "webadmin_css" in ovirt.brand/branding.properties)
> and some of them could be of use to Martin. For example,
> vanilla PatternFly CSS:
>
> - patternfly/css/styles.min.css
> - patternfly-ovirt.css
>
> >
> > My idea is completely different. I wanted to stop using GWT for all CSS,
> > and instead use LESS or SASS. Then any plugins could simply use the
> > LESS/SASS files as needed.
>
> I like that idea.
>
> In general, we should extract *all* styling (including
> <ui:style> in ui.xml templates) into separate CSS files
>

Yes.

> and access that through appropriate Java interfaces in
> our GWT applications.
>

What do you see as the benefit of continuing to wrap CSS classes in Java
interfaces? We could just stop doing that, too. I don't think it buys us
much. I see it as just more code to maintain for no good reason. When we
access PatternFly classes, we just hardcode the strings. I think that's
pretty typical with CSS, and ok.

>
> There should be no CSS styling outside of 'css' files.
>
> The GWT build would involve an extra step, if needed:
> take Less/Sass files and compile them into CSS files.
>
> GWT Java interfaces would link to these CSS files and
> GWT compiler could still do its obfuscate/minification
> thing. We *could* disable CSS selector obfuscation if
> we wanted to, using "@external" as we do for branding.
>
> However, the main point is because we'd already have
> CSS styling isolated into dedicated files, we could
> simply expose those CSS files via HTTP/servlet.
>
> So assuming we have everything in CSS files:
>
>   interface MyCss extends CssResource {
>     String className();
>   }
>
>   interface MyResources extends ClientBundle {
>     @Source("my.css")
>     MyCss css();
>   }
>
>   // inside ui.xml template
>   <ui:style type="org.ovirt.engine.ui.example.MyCss">
>   </style>
>
> (Note that <ui:style> above is empty on purpose.)
>
> >
> > There's no way that could make 4.0 now, though.
> >
> >
> > >
> > > >
> > > > Martin
> > > >
> > > > On Fri, Apr 15, 2016 at 5:37 PM, Vojtech Szocs <vszocs at redhat.com>
> > > wrote:
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > >> From: "Vojtech Szocs" <vszocs at redhat.com>
> > > > >> To: "Martin Sivak" <msivak at redhat.com>, "Greg Sheremeta"
> > > > >> <gshereme at redhat.com>, "Alexander Wels" <awels at redhat.com>
> > > > >> Cc: "engine-devel at ovirt.org" <devel at ovirt.org>
> > > > >> Sent: Friday, April 15, 2016 5:23:08 PM
> > > > >> Subject: Re: [ovirt-devel] UI plugins - access to engine styles
> and
> > > > >> libraries
> > > > >>
> > > > >> Hi Martin,
> > > > >>
> > > > >> (adding Greg and Alex in case they have any thoughts)
> > > > >>
> > > > >> if you build your UI plugin in a way that requires CSS styles,
> > > > >> JS libraries etc. at runtime (dynamic linking), you can utilize
> > > > >> oVirt branding servlet [a] to serve branding-related resources.
> > > > >
> > > > > Just a note - another way of building your UI plugin is to use
> > > > > tools that take your CSS styles and JS sources (including 3rd
> > > > > party ones) and produce a self-contained bundle for deployment.
> > > > >
> > > > > oVirt Dashboard, for example, follows this approach:
> > > > >
> > > > >   https://github.com/vojtechszocs/ovirt-dashboard-ui-plugin
> > > > >
> > > > > (soon, we'll sync it with ovirt-engine-dashboard on our gerrit
> > > > > and continue developing the project there)
> > > > >
> > > > > With this (static linking) approach, you don't need those CSS
> > > > > or JS resources at runtime; your webapp is self-contained and
> > > > > optimized (containing only stuff it really uses).
> > > > >
> > > > > We also have two RPM packages (initiated by Juan) for building
> > > > > (oVirt) webapps that require a JS build step, utilizing tools
> > > > > around the Node.js platform:
> > > > >
> > > > >   ovirt-engine-nodejs [Node.js runtime]
> > > > >   ovirt-engine-nodejs-modules [all frontend dependencies]
> > > > >
> > > > > Regards,
> > > > > Vojtech
> > > > >
> > > > >>
> > > > >>   [a] org.ovirt.engine.core.branding.BrandingServlet
> > > > >>
> > > > >> By default, oVirt Engine ships with single branding package:
> > > > >>
> > > > >>   $ ls /etc/ovirt-engine/branding/
> > > > >>   00-ovirt.brand
> > > > >>
> > > > >> That `00-ovirt.brand` directory symlinks to:
> > > > >>
> > > > >>   /usr/share/ovirt-engine/branding/ovirt.brand
> > > > >>
> > > > >> containing all branding-related resources.
> > > > >>
> > > > >> To fetch them, use the following URL:
> > > > >>
> > > > >>   http://example.com/ovirt-engine/webadmin/theme/<path_to_file>
> > > > >>
> > > > >> where <path_to_file> is relative to `ovirt.brand` directory.
> > > > >>
> > > > >> In your UI plugin, you can use the newly introduced API to
> > > > >> construct this URL more easily [b]:
> > > > >>
> > > > >>   var url = api.engineBaseUrl() + 'webadmin/theme/' + pathToFile
> > > > >>
> > > > >>   [b] https://gerrit.ovirt.org/#/c/55694/
> > > > >>
> > > > >> WebAdmin UI itself loads following CSS styles (in this order):
> > > > >>
> > > > >> - web_admin.css
> > > > >> - common.css
> > > > >> - gwt_common.css
> > > > >> - patternfly/css/styles.min.css
> > > > >> - patternfly-ovirt.css
> > > > >> - ovirt-patternfly-compat.css
> > > > >> - ovirt.css
> > > > >>
> > > > >> For starters, you can load PatternFly-specific CSS only.
> > > > >>
> > > > >> As for JS libraries, these are typically provided through
> > > > >> PatternFly RPM, to which `patternfly` directory symlinks.
> > > > >>
> > > > >> For starters, you can use stuff under `patternfly/js` and
> > > > >> `patternfly/components` (these are PF's own dependencies).
> > > > >>
> > > > >> oVirt ships its own version of jQuery (v1.11) + Bootstrap
> > > > >> (v3.3.6) -- please don't use them!! If you're wondering
> > > > >> why we use custom jQuery and Bootstrap, see here:
> > > > >>
> > > > >>   https://gerrit.ovirt.org/#/c/41228/
> > > > >>   https://gerrit.ovirt.org/#/c/55546/
> > > > >>
> > > > >> (@Greg, any plans for upgrading to PF-provided jQuery?)
> > > > >>
> > > > >> Regards,
> > > > >> Vojtech
> > > > >>
> > > > >>
> > > > >> ----- Original Message -----
> > > > >> > From: "Martin Sivak" <msivak at redhat.com>
> > > > >> > To: "engine-devel at ovirt.org" <devel at ovirt.org>
> > > > >> > Cc: "Moran Goldboim" <mgoldboi at redhat.com>, "Vojtech Szocs"
> > > > >> > <vszocs at redhat.com>, "Oved Ourfali" <oourfali at redhat.com>
> > > > >> > Sent: Wednesday, April 13, 2016 5:30:49 PM
> > > > >> > Subject: UI plugins - access to engine styles and libraries
> > > > >> >
> > > > >> > Hi everybody,
> > > > >> >
> > > > >> > there is one piece I always missed when developing my optimizer
> > > plugin
> > > > >> > and that is the access to the engine css styles.
> > > > >> >
> > > > >> > I feel it might be pretty easy and good for both bandwidth and
> > > > >> > branding to expose them using some "well known" url from the
> engine.
> > > > >> > All plugins would be then able to (re-)use the same styling
> > > > >> > information and basic javascript libraries (jQuery, angular,
> > > whatever
> > > > >> > you decide the core engine will use).
> > > > >> >
> > > > >> > So far, each UI plugin has to link to its own version of
> libraries
> > > and
> > > > >> > define (and maintain) custom color theme.
> > > > >> >
> > > > >> > Do you think this would be doable for 4.0?
> > > > >> >
> > > > >> > Best regards
> > > > >> >
> > > > >> > --
> > > > >> > Martin Sivak
> > > > >> > SLA / oVirt
> > > > >> >
> > > > >> _______________________________________________
> > > > >> Devel mailing list
> > > > >> Devel at ovirt.org
> > > > >> http://lists.ovirt.org/mailman/listinfo/devel
> > > > >>
> > > >
> > >
> >
> >
> >
> > --
> > Greg Sheremeta, MBA
> > Red Hat, Inc.
> > Sr. Software Engineer
> > gshereme at redhat.com
> > 919-741-4016
> >
>

-- 
Greg Sheremeta, MBA
Red Hat, Inc.
Sr. Software Engineer
gshereme at redhat.com
919-741-4016
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20160420/92432fa3/attachment.html>