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
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. [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@redhat.com> To: "engine-devel@ovirt.org" <devel@ovirt.org> Cc: "Moran Goldboim" <mgoldboi@redhat.com>, "Vojtech Szocs" <vszocs@redhat.com>, "Oved Ourfali" <oourfali@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
----- Original Message -----
From: "Vojtech Szocs" <vszocs@redhat.com> To: "Martin Sivak" <msivak@redhat.com>, "Greg Sheremeta" <gshereme@redhat.com>, "Alexander Wels" <awels@redhat.com> Cc: "engine-devel@ovirt.org" <devel@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@redhat.com> To: "engine-devel@ovirt.org" <devel@ovirt.org> Cc: "Moran Goldboim" <mgoldboi@redhat.com>, "Vojtech Szocs" <vszocs@redhat.com>, "Oved Ourfali" <oourfali@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
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. 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. Martin On Fri, Apr 15, 2016 at 5:37 PM, Vojtech Szocs <vszocs@redhat.com> wrote:
----- Original Message -----
From: "Vojtech Szocs" <vszocs@redhat.com> To: "Martin Sivak" <msivak@redhat.com>, "Greg Sheremeta" <gshereme@redhat.com>, "Alexander Wels" <awels@redhat.com> Cc: "engine-devel@ovirt.org" <devel@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@redhat.com> To: "engine-devel@ovirt.org" <devel@ovirt.org> Cc: "Moran Goldboim" <mgoldboi@redhat.com>, "Vojtech Szocs" <vszocs@redhat.com>, "Oved Ourfali" <oourfali@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
----- Original Message -----
From: "Martin Sivak" <msivak@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "Greg Sheremeta" <gshereme@redhat.com>, "Alexander Wels" <awels@redhat.com>, "engine-devel@ovirt.org" <devel@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@redhat.com> wrote:
----- Original Message -----
From: "Vojtech Szocs" <vszocs@redhat.com> To: "Martin Sivak" <msivak@redhat.com>, "Greg Sheremeta" <gshereme@redhat.com>, "Alexander Wels" <awels@redhat.com> Cc: "engine-devel@ovirt.org" <devel@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@redhat.com> To: "engine-devel@ovirt.org" <devel@ovirt.org> Cc: "Moran Goldboim" <mgoldboi@redhat.com>, "Vojtech Szocs" <vszocs@redhat.com>, "Oved Ourfali" <oourfali@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On Wed, Apr 20, 2016 at 12:51 PM, Vojtech Szocs <vszocs@redhat.com> wrote:
From: "Martin Sivak" <msivak@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "Greg Sheremeta" <gshereme@redhat.com>, "Alexander Wels" < awels@redhat.com>, "engine-devel@ovirt.org" <devel@ovirt.org> Sent: Tuesday, April 19, 2016 5:07:52 PM Subject: Re: [ovirt-devel] UI plugins - access to engine styles and
----- Original Message ----- 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. 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. There's no way that could make 4.0 now, though.
Martin
On Fri, Apr 15, 2016 at 5:37 PM, Vojtech Szocs <vszocs@redhat.com>
----- Original Message -----
From: "Vojtech Szocs" <vszocs@redhat.com> To: "Martin Sivak" <msivak@redhat.com>, "Greg Sheremeta" <gshereme@redhat.com>, "Alexander Wels" <awels@redhat.com> Cc: "engine-devel@ovirt.org" <devel@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@redhat.com> To: "engine-devel@ovirt.org" <devel@ovirt.org> Cc: "Moran Goldboim" <mgoldboi@redhat.com>, "Vojtech Szocs" <vszocs@redhat.com>, "Oved Ourfali" <oourfali@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
wrote: 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com 919-741-4016
----- Original Message -----
From: "Greg Sheremeta" <gshereme@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "Martin Sivak" <msivak@redhat.com>, "Alexander Wels" <awels@redhat.com>, "engine-devel@ovirt.org" <devel@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@redhat.com> wrote:
From: "Martin Sivak" <msivak@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "Greg Sheremeta" <gshereme@redhat.com>, "Alexander Wels" < awels@redhat.com>, "engine-devel@ovirt.org" <devel@ovirt.org> Sent: Tuesday, April 19, 2016 5:07:52 PM Subject: Re: [ovirt-devel] UI plugins - access to engine styles and
----- Original Message ----- 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 and access that through appropriate Java interfaces in our GWT applications. 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@redhat.com>
----- Original Message -----
From: "Vojtech Szocs" <vszocs@redhat.com> To: "Martin Sivak" <msivak@redhat.com>, "Greg Sheremeta" <gshereme@redhat.com>, "Alexander Wels" <awels@redhat.com> Cc: "engine-devel@ovirt.org" <devel@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@redhat.com> To: "engine-devel@ovirt.org" <devel@ovirt.org> Cc: "Moran Goldboim" <mgoldboi@redhat.com>, "Vojtech Szocs" <vszocs@redhat.com>, "Oved Ourfali" <oourfali@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
wrote: 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com 919-741-4016
On Wed, Apr 20, 2016 at 1:52 PM, Vojtech Szocs <vszocs@redhat.com> wrote:
From: "Greg Sheremeta" <gshereme@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "Martin Sivak" <msivak@redhat.com>, "Alexander Wels" < awels@redhat.com>, "engine-devel@ovirt.org" <devel@ovirt.org> Sent: Wednesday, April 20, 2016 7:06:13 PM Subject: Re: [ovirt-devel] UI plugins - access to engine styles and
----- Original Message ----- libraries
On Wed, Apr 20, 2016 at 12:51 PM, Vojtech Szocs <vszocs@redhat.com>
wrote:
From: "Martin Sivak" <msivak@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "Greg Sheremeta" <gshereme@redhat.com>, "Alexander Wels" < awels@redhat.com>, "engine-devel@ovirt.org" <devel@ovirt.org> Sent: Tuesday, April 19, 2016 5:07:52 PM Subject: Re: [ovirt-devel] UI plugins - access to engine styles and
----- Original Message ----- 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@redhat.com>
wrote:
----- Original Message -----
From: "Vojtech Szocs" <vszocs@redhat.com> To: "Martin Sivak" <msivak@redhat.com>, "Greg Sheremeta" <gshereme@redhat.com>, "Alexander Wels" <awels@redhat.com> Cc: "engine-devel@ovirt.org" <devel@ovirt.org> Sent: Friday, April 15, 2016 5:23:08 PM Subject: Re: [ovirt-devel] UI plugins - access to engine styles
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@redhat.com> > To: "engine-devel@ovirt.org" <devel@ovirt.org> > Cc: "Moran Goldboim" <mgoldboi@redhat.com>, "Vojtech Szocs" > <vszocs@redhat.com>, "Oved Ourfali" <oourfali@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
and 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com 919-741-4016
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com 919-741-4016
----- Original Message -----
From: "Greg Sheremeta" <gshereme@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "Martin Sivak" <msivak@redhat.com>, "Alexander Wels" <awels@redhat.com>, "engine-devel@ovirt.org" <devel@ovirt.org> 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@redhat.com> wrote:
From: "Greg Sheremeta" <gshereme@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "Martin Sivak" <msivak@redhat.com>, "Alexander Wels" < awels@redhat.com>, "engine-devel@ovirt.org" <devel@ovirt.org> Sent: Wednesday, April 20, 2016 7:06:13 PM Subject: Re: [ovirt-devel] UI plugins - access to engine styles and
----- Original Message ----- libraries
On Wed, Apr 20, 2016 at 12:51 PM, Vojtech Szocs <vszocs@redhat.com>
wrote:
From: "Martin Sivak" <msivak@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "Greg Sheremeta" <gshereme@redhat.com>, "Alexander Wels" < awels@redhat.com>, "engine-devel@ovirt.org" <devel@ovirt.org> Sent: Tuesday, April 19, 2016 5:07:52 PM Subject: Re: [ovirt-devel] UI plugins - access to engine styles and
----- Original Message ----- 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.
GWT is centered around the Java language, providing (Java) abstraction for everything that relates to web technologies. There's an abstraction for DOM elements, widgets (on top of DOM elements), web APIs (such as local storage), etc. etc. GWT's CssResource interface is the standard way of working with CSS. GWT's ClientBundle interface is the standard way of grouping all webapp's resources (CSS, images etc.) into resource "bundle" that gets optimized during compilation. That said, I understand your point and I agree that having a Java interface for every CSS file is extra maintenance. If we agree we don't need GWT compiler's CSS optimization (because we'll use Less/Sass anyway), we can completely remove all CssResource interfaces and simply have some Java class to contain string constants referring to CSS class names. // in Java code myWidget.addStyleName(CssClassNames.FOO_CLASS); // in ui.xml template <ui:with field="css" type='com.example.CssClassNames' /> <MyWidget addStyleNames="{css.FOO_CLASS}"> However, this will inevitably cause refactoring of our existing GWT code as we already depend on the notion of working with CssResource interface. This effort is not trivial, we should proceed in smaller steps to avoid "big bang" risky changes.
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@redhat.com>
wrote:
----- Original Message ----- > From: "Vojtech Szocs" <vszocs@redhat.com> > To: "Martin Sivak" <msivak@redhat.com>, "Greg Sheremeta" > <gshereme@redhat.com>, "Alexander Wels" <awels@redhat.com> > Cc: "engine-devel@ovirt.org" <devel@ovirt.org> > Sent: Friday, April 15, 2016 5:23:08 PM > Subject: Re: [ovirt-devel] UI plugins - access to engine styles
> 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@redhat.com> > > To: "engine-devel@ovirt.org" <devel@ovirt.org> > > Cc: "Moran Goldboim" <mgoldboi@redhat.com>, "Vojtech Szocs" > > <vszocs@redhat.com>, "Oved Ourfali" <oourfali@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
and 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@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel >
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com 919-741-4016
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com 919-741-4016
On Fri, Apr 15, 2016 at 11:23 AM, Vojtech Szocs <vszocs@redhat.com> wrote:
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.
[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?)
No plans to switch to the libraries that PatternFly provides -- and I'm not all that sure we should. We got burned by it, so we moved away from it intentionally in [https://gerrit.ovirt.org/#/c/41228/]. Probably best to chat about that in another thread. Greg
Regards, Vojtech
----- Original Message -----
From: "Martin Sivak" <msivak@redhat.com> To: "engine-devel@ovirt.org" <devel@ovirt.org> Cc: "Moran Goldboim" <mgoldboi@redhat.com>, "Vojtech Szocs" < vszocs@redhat.com>, "Oved Ourfali" <oourfali@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
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com 919-741-4016
----- Original Message -----
From: "Greg Sheremeta" <gshereme@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "Martin Sivak" <msivak@redhat.com>, "Alexander Wels" <awels@redhat.com>, "engine-devel@ovirt.org" <devel@ovirt.org>, "Moran Goldboim" <mgoldboi@redhat.com>, "Oved Ourfali" <oourfali@redhat.com> Sent: Saturday, April 16, 2016 4:05:56 PM Subject: Re: UI plugins - access to engine styles and libraries
On Fri, Apr 15, 2016 at 11:23 AM, Vojtech Szocs <vszocs@redhat.com> wrote:
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.
[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?)
No plans to switch to the libraries that PatternFly provides -- and I'm not all that sure we should. We got burned by it, so we moved away from it intentionally in [https://gerrit.ovirt.org/#/c/41228/]. Probably best to chat about that in another thread.
OK, thanks for the update. I thought that we're using jQuery 1.x solely for IE8 support. According to [ms]: " Beginning January 12, 2016, only the most current version of Internet Explorer available for a supported operating system will receive technical supports and security updates. Internet Explorer 11 is the last version of Internet Explorer... " [ms] https://www.microsoft.com/en-us/WindowsForBusiness/End-of-IE-support Agreed - let's discuss this separately.
Greg
Regards, Vojtech
----- Original Message -----
From: "Martin Sivak" <msivak@redhat.com> To: "engine-devel@ovirt.org" <devel@ovirt.org> Cc: "Moran Goldboim" <mgoldboi@redhat.com>, "Vojtech Szocs" < vszocs@redhat.com>, "Oved Ourfali" <oourfali@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
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com 919-741-4016
participants (3)
-
Greg Sheremeta -
Martin Sivak -
Vojtech Szocs