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

[Vojtech Szocs]

----- 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.

> 
> 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
> >>
>