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

From: "Greg Sheremeta" <gshereme(a)redhat.com&gt; To: "Vojtech Szocs" <vszocs(a)redhat.com&gt; Cc: "Martin Sivak" <msivak(a)redhat.com&gt;, "Alexander Wels" <awels(a)redhat.com&gt;, &quot;engine-devel(a)ovirt.org&quot; <devel(a)ovirt.org&gt; Sent: Wednesday, April 20, 2016 8:20:11 PM Subject: Re: [ovirt-devel] UI plugins - access to engine styles and libraries On Wed, Apr 20, 2016 at 1:52 PM, Vojtech Szocs <vszocs(a)redhat.com&gt; wrote: > > > ----- Original Message ----- > > From: "Greg Sheremeta" <gshereme(a)redhat.com&gt; > > To: "Vojtech Szocs" <vszocs(a)redhat.com&gt; > > Cc: "Martin Sivak" <msivak(a)redhat.com&gt;, "Alexander Wels" < > awels(a)redhat.com&gt;, &quot;engine-devel(a)ovirt.org&quot; > > <devel(a)ovirt.org&gt; > > 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(a)redhat.com&gt; > wrote: > > > > > > > > > > > ----- Original Message ----- > > > > From: "Martin Sivak" <msivak(a)redhat.com&gt; > > > > To: "Vojtech Szocs" <vszocs(a)redhat.com&gt; > > > > Cc: "Greg Sheremeta" <gshereme(a)redhat.com&gt;, "Alexander Wels" < > > > awels(a)redhat.com&gt;, &quot;engine-devel(a)ovirt.org&quot; > > > > <devel(a)ovirt.org&gt; > > > > 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(a)redhat.com&gt; > > > wrote: > > > > > > > > > > > > > > > ----- Original Message ----- > > > > >> From: "Vojtech Szocs" <vszocs(a)redhat.com&gt; > > > > >> To: "Martin Sivak" <msivak(a)redhat.com&gt;, "Greg Sheremeta" > > > > >> <gshereme(a)redhat.com&gt;, "Alexander Wels" <awels(a)redhat.com&gt; > > > > >> Cc: &quot;engine-devel(a)ovirt.org&quot; <devel(a)ovirt.org&gt; > > > > >> 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(a)redhat.com&gt; > > > > >> > To: &quot;engine-devel(a)ovirt.org&quot; <devel(a)ovirt.org&gt; > > > > >> > Cc: "Moran Goldboim" <mgoldboi(a)redhat.com&gt;, "Vojtech Szocs" > > > > >> > <vszocs(a)redhat.com&gt;, "Oved Ourfali" <oourfali(a)redhat.com&gt; > > > > >> > 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(a)ovirt.org > > > > >> http://lists.ovirt.org/mailman/listinfo/devel > > > > >> > > > > > > > > > > > > > > > -- > > Greg Sheremeta, MBA > > Red Hat, Inc. > > Sr. Software Engineer > > gshereme(a)redhat.com > > 919-741-4016 > > > -- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme(a)redhat.com 919-741-4016