10:30 a.m.
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
10:23 a.m.
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 -----
10:37 a.m.
----- Original Message -----
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
10:07 a.m.
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(a)redhat.com> wrote:
>
>
> ----- Original Message -----
>> From: "Vojtech Szocs" <vszocs(a)redhat.com>
>> To: "Martin Sivak" <msivak(a)redhat.com>, "Greg
Sheremeta" <gshereme(a)redhat.com>, "Alexander Wels"
<awels(a)redhat.com>
>> Cc: "engine-devel(a)ovirt.org" <devel(a)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(a)redhat.com>
>> > To: "engine-devel(a)ovirt.org" <devel(a)ovirt.org>
>> > Cc: "Moran Goldboim" <mgoldboi(a)redhat.com>, "Vojtech
Szocs"
>> > <vszocs(a)redhat.com>, "Oved Ourfali"
<oourfali(a)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(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
11:51 a.m.
----- Original Message -----
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.
12:06 p.m.
On Wed, Apr 20, 2016 at 12:51 PM, Vojtech Szocs <vszocs(a)redhat.com> wrote:
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.
--
Greg Sheremeta, MBA
Red Hat, Inc.
Sr. Software Engineer
gshereme(a)redhat.com
919-741-4016
12:52 p.m.
----- Original Message -----
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
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.)
1:20 p.m.
On Wed, Apr 20, 2016 at 1:52 PM, Vojtech Szocs <vszocs(a)redhat.com> wrote:
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.
--
Greg Sheremeta, MBA
Red Hat, Inc.
Sr. Software Engineer
gshereme(a)redhat.com
919-741-4016
10:02 a.m.
----- Original Message -----
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.
9:05 a.m.
On Fri, Apr 15, 2016 at 11:23 AM, Vojtech Szocs <vszocs(a)redhat.com> wrote:
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
--
Greg Sheremeta, MBA
Red Hat, Inc.
Sr. Software Engineer
gshereme(a)redhat.com
919-741-4016
11:47 a.m.
----- Original Message -----
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.
3273
days inactive
3281
days old
10 comments
3 participants
participants (3)
-
Greg Sheremeta -
Martin Sivak -
Vojtech Szocs