Vaadin Components For Liferay

[Jan Geißler, modificado 10 Anos atrás.]

Hello Liferayians!

I was wondering if anybody else is developing Portlets for Liferay with Vaadin. If so, wouldn't there be the need for some Library which contains "Liferay Components"?
Something like the Liferay Taglibs just for Vaadin.

For example I had to solve 2 Problems.
First: Localized Fields. You know, these neat little fields that are XML formatted in the Database? There is no Compoment in Vaadin which would let you do this stuff. You have to build your own.
Second example: Tags And Categories. This is a feature used throughout the Portal, and most of our self written portlets.

Now the real Question is:
Are there any more people interested in BUILDING such a library? I was thinking about doing a little OpenSource Project and am now looking for people who would like to contribute and / or give input on what Problems to solve and how ;)

I am really looking forward to hear from anybody!

So long
Jan

[Krzysztof Gołębiowski, modificado 10 Anos atrás.]

Hello Jan,
We created one Liferay x Vaadin project already and we had similar problems - all standard taglibs functionality we needed, had to be rewritten from scratch. Even so it is much more efficient to develop certain "intranet" solutions this way than using old JSP's or similar technologies. As far as I remember, the thing we missed most was an efficient Vaadin Tables (or actually Containers) integration with service builder - similar to the liferay-ui:search-container element.

So the answer is yes, I am interested in building such library. The only condition is that we get another project with business requirements that make use of Vaadin reasonable

Regards,
Krzysztof Gołębiowski

[Sampsa Sohlman, modificado 10 Anos atrás.]

Hi Jan,

First of all Happy new year. I like your idea, by having set of Vaadin components for Liferay development would a great and even better if there would be community project for that. It would be useful for the really helpfull for the Liferay developers using Vaadin.

May be would be good idea to take Liferay Boilerplate application called Jukebox, presented by Julio Camarero and Sergio Gonzalez at DevCon and may be to write UI layer with Vaadin much as we could.

As side of Liferay I can give you a limited hand and I'm somewhat experienced also with Vaadin 6.

Cheers,

Sampsa

[James Falkner, modificado 10 Anos atrás.]

Sampsa Sohlman:

Hi Jan,

First of all Happy new year. I like your idea, by having set of Vaadin components for Liferay development would a great and even better if there would be community project for that. It would be useful for the really helpfull for the Liferay developers using Vaadin.

May be would be good idea to take Liferay Boilerplate application called Jukebox, presented by Julio Camarero and Sergio Gonzalez at DevCon and may be to write UI layer with Vaadin much as we could.

As side of Liferay I can give you a limited hand and I'm somewhat experienced also with Vaadin 6.

Cheers,

Sampsa

Hey Guys, while I can't offer any development experience w/Vaadin, I can offer to help promote such a project and believe it is a wonderful idea, I know of a couple of heavy Vaadin users in our community and will reach out and get them to contact you. Happy new year, Jan and all!

[David H Nebinger, modificado 10 Anos atrás.]

Jan Geißler:

I was wondering if anybody else is developing Portlets for Liferay with Vaadin.

Yep, you can count me in!

Two questions:

1) What version are you targeting? V6 or V7?

2) Are you looking at creating Vaadin add-ons or specifically bridging Vaadin and Liferay internals?

[Jan Geißler, modificado 10 Anos atrás.]

Hi Everybody, Happy near year and all this stuff!

Sorry for the long delay. but I have been on vacation.

First of all, it is more than pleasing that so many people think that kind of Library is interesting.

@David:
For 1:
Actually I was planing on developing the components for Vaadin 6.x as for 7.x as well. We do have Projects where we have to stick with 6.x, but also some which could use Vaadin 7.x. And as far as I know, if you build the Components for 6 and then adapt them for 7 the Work that has to be done is not that much.
For 2:
I am not so shure. I have some things in my mind (and in parts already implemented) that I really would like to have.

- There is the Spring integration for Vaadin. I know there is already a Plugin, but I started to build a SuperClass that does some common things, like on Request Start, extract the themDisplay, the Locale of the User, the User and put it in the Vaadin Context.
- Like I said in my starting post, things Like Tags and Category Component
- ....

You can Imagine many things more. So the answer would be:
Everything which is useful for us or others. I would't count something out. What would you suggest?


@Krzysztof Gołębiowski and Sampsa Sohlman
Any help would be much appreciated.
Krzysztof, did you build the search-container thingy? In general I would just wrap the Liferay Service Builder Objects in BeanItemContainers. That is sufficent for most Use Cases.

@James:
If you could help us with finding some more Contributors by creating a Cummunity Project would be real nice.

@Everybody:
What would be the features you would like to have/build?

So long!
Best wishes!
Jan

[Jack Bakker, modificado 10 Anos atrás.]

This sounds exciting.

- theme coordination across Liferay and Vaadin ; a style lib that can be put in Liferay theme /css ? (where liferay style overrides Vaadin styles... hmmm)
- locale recognition from Liferay to Vaadin
- search container re-use ?
- responsive where liferay theme/layout uses twitter bootstrap-based

[David H Nebinger, modificado 10 Anos atrás.]

Jack Bakker:

- theme coordination across Liferay and Vaadin ; a style lib that can be put in Liferay theme /css ? (where liferay style overrides Vaadin styles... hmmm)

This I think would be pretty tough. Vaadin themes combine styling overrides and layout-specifics (so the gwt javascript works as expected), and Liferay has similar issues... Each one wants to own the theming and there is very little in common that they share.

Best we could get working was the Liferay theme according to what the marketing folks wanted and the colors, fonts, and minor changes adapted to the Vaadin theme so the Vaadin stuff looked similar to the OOTB portlets...

- locale recognition from Liferay to Vaadin

I actually have a library that I created for V7 that would fill this need. Leveraged identifying the change in locale and would let the Vaadin portlet adjust accordingly.

[Jack Bakker, modificado 10 Anos atrás.]

David H Nebinger:

This I think would be pretty tough. Vaadin themes combine styling overrides and layout-specifics (so the gwt javascript works as expected), and Liferay has similar issues... Each one wants to own the theming and there is very little in common that they share.

Best we could get working was the Liferay theme according to what the marketing folks wanted and the colors, fonts, and minor changes adapted to the Vaadin theme so the Vaadin stuff looked similar to the OOTB portlets...

marketing folks... yeah we need them less than they need us ? nope.. but that is a cascading of style in its own right, but I digress

does !important in a parent style override a child with same name ? if so I wonder about a full gamut of Vaadin class styles avail in a vaadin.css avail for Liferay theme reference only where then developer can add a custom_vaadin.css with !important on a per style basis ... but I have no idea if what I am saying makes any sense ; I don't really understand css that well

[David H Nebinger, modificado 10 Anos atrás.]

Jack Bakker:

does !important in a parent style override a child with same name?

no, !important only relates to specificity, and applies in the algorithm determining what particular rule wins.

So if we have:

#textheader {
  font-weight: bold !important;
}

#normal #textheader {
  font-weight: normal;
}

If you had a tag, <p id="textheader">this</p>, without the !important the 2nd rule would apply (it comes second in the file and has more specificity). The !important gives the declaration a higher specificity than it normally has and overrides the second.

If both of them had !important, then the 2nd would win and get applied.

Unfortunately, w/ the Vaadin theme you'd basically end up !important'ing every style in the file, and even then it would start getting pretty darn ugly and certainly won't result with what you're hoping for ;-)

[Jack Bakker, modificado 10 Anos atrás.]

what if Vaadin-specific theme css was ignored entirely via a portlet init-param ; where then option is to have a vaadin.css for inclusion in theme ; leaving it to developer to play

[David H Nebinger, modificado 10 Anos atrás.]

um, it is ignored. the vaadin theme is loaded when the whole widgetset is loaded, and it is through the portal by accessing /html/VAADIN/... The init params don't play a part here, at least not as much as they do in other portlet frameworks.

[Jack Bakker, modificado 10 Anos atrás.]

k so widget compile options ; that gets obtuse perhaps ; am feeling like I don't know enough about css to grok the gamut

[David H Nebinger, modificado 10 Anos atrás.]

Widget compile is actually not a problem. Use the vaadin control panel, learn where the widgets (and their dependencies) go, and how to recompile the widgetset...

It is actually all pretty darn easy, all things considered.

Now whether the components will work within the confines of the portal and the portal's wrapping theme, well that's another story

[Jan Geißler, modificado 10 Anos atrás.]

When you really invest some time it is possible to eliminate nearly all inline Styles from Vaadin. If you get this managed, you can in fact manage pure CSS Styling. I took the route via Liferay-theme. It is kind of hard, but with some careful programming it could be achieved.

[David H Nebinger, modificado 10 Anos atrás.]

Inline styles are significantly different than the vaadin theme; those styles are not inline and are in separate css file(s). As long as the vaadin class names exist and are required, I cannot see how we could merge the two themes into one w/o a great deal of work...

Don't get me wrong, I'd love to see that happen. Given the size and scope of both themes, however, I think it would be a struggle merging them and that merger process would need to be repeated on a per-theme basis...

[Jack Bakker, modificado 10 Anos atrás.]

Liferay theme has a 'main.css' then then references other .css files

what in Vaadin references all the ROOT/html/VAADIN/themes/* css ?

[Jack Bakker, modificado 10 Anos atrás.]

Jack Bakker ; IT Dolphin:

what in Vaadin references all the ROOT/html/VAADIN/themes/* css ?

silly of me to ask such a general question... as if anyone is going to answer...

I need to dig into Vaadin (v6 and v7) themes and css more to see if a custom Vaadin theme (perhaps built using Chameleon) might use @import to reference css in a Liferay theme which overrides base Vaadin css.. @import "/myliferay-theme/css/custom_vaadin.css" or something...

[David H Nebinger, modificado 10 Anos atrás.]

Jack Bakker:

I need to dig into Vaadin (v6 and v7) themes and css more to see if a custom Vaadin theme (perhaps built using Chameleon) might use @import to reference css in a Liferay theme which overrides base Vaadin css.. @import "/myliferay-theme/css/custom_vaadin.css" or something...

Ah, so you've never dug into the guts of Vaadin, huh? I've been under the hood and, while the code is really pretty organized and elegant, it does take some time to figure out when the engine is in control vs when the server is in control.

So the magic of vaadin is all managed by the bootstrap. The bootstrap will determine the vaadin theme files to load (widgetset js & css) and add the dom to the page to get them imported. The bootstrap will either use the portlet init params (if specified) or default values.

But this means that the CSS is not pulled in using the classic pattern of "include one CSS page that imports all of the child pages" thing.

This is what allows the Liferay theme to impact the Vaadin theme (and somewhat vice-versa), and it also prevents the two from being merged (or even managed) together.

[Jack Bakker, modificado 10 Anos atrás.]

Jack Bakker, IT Dolphin:

I need to dig into Vaadin (v6 and v7) themes and css more

David H Nebinger, Vaadin guts digger :

Ah, so you've never dug into the guts of Vaadin, huh?

.. note my use of the word 'more' vs your absolute 'never' ...

You may learn from this:

https://vaadin.com/book/-/page/themes.creating.html section 8.4.2:

@import "../reindeer/legacy-styles.css";

.v-app {
background: yellow;
}

so I wonder about a new custom Vaadin theme that references a Liferay css with something like the below.

@import "/mytheme-theme/css/custom_vaadin.css";
.v-app {
background: red;
}

haven't tried it so my 'more' is still on the table

[David H Nebinger, modificado 10 Anos atrás.]

Sorry about the use of the absolute, Jack, I'm kicking myself because I hate when folks use it and not mean it

Anyway, you don't have to pull in the Liferay themes at all. They are already pulled in.

The liferay theme(s) files are pulled in at the top of the page. The Vaadin themes are pulled in after the fact and extend/overwrite/undo the settings from Liferay, but since they are all class-scoped (with .v- prefixes), non-Vaadin content should not be affected.

And you should note that the book of vaadin applies at the servlet level. A lot of the content will work in the portlet context, but I don't know about the CSS imports. I mean, their whole build process undoes the imports by building a single styles.css file... So even though the book says it's possible, if they have to merge into a single file then that makes me believe they had issues w/ separate css files and the merge was necessary...

[Jack Bakker, modificado 10 Anos atrás.]

Your apology is absolutely acceptable.

The last entry in Liferay theme main.css is 'usually' custom.css, where entries therein can override other styles that came before...

So pretend the last entry is a new custom_vaadin.css and then a Vaadin theme 'myvaadin-theme' imports the custom_vaadin.css via @import "/myliferay-theme/css/custom_vaadin.css"

with this approach, wouldn't the styles in custom_vaadin.css override styles from Vaadin themes ? thus allowing a theme designer more control ?

my example idea was previously wrong tho

Jack Bakker:

@import "/mytheme-theme/css/custom_vaadin.css";
.v-app {
background: red;
}

above wouldn't do it:

but perhaps:

@import "../reindeer/legacy-styles.css";
@import "/mytheme-theme/css/custom_vaadin.css";

I guess I should just try it... so back under to feed I go...

[David H Nebinger, modificado 10 Anos atrás.]

Yeah, this fails due to ordering...

So the Liferay theme loads and finally loads custom_vaadin.css so now you have a red background for .v-app

Unfortunately the bootstrap will load and then load the Vaadin theme. Since that .v-app definition comes after yours, normally it will have higher specificity and replace your red background.

Now you can do the !important to give your red higher significance, but of course then you run the risk of eliminating something from the Vaadin theme that was provided as a bug fix (the red is not a good example, but say you did some sort of margin-right: 20px !important; but the new Vaadin release had margin-right: 10px and all of the javascript, etc., was now dependent upon the 10px margin).

[Jack Bakker, modificado 10 Anos atrás.]

David H Nebinger:

Unfortunately the bootstrap will load and then load the Vaadin theme. Since that .v-app definition comes after yours

I am thinking that my Vaadin theme will reference the liferay custom_vaadin.css ? hence it would load last ? (perhaps unfortunately twice)

[David H Nebinger, modificado 10 Anos atrás.]

I'm trying to see what difference that would make?

I mean, you'd still have theming stuff in your theme and overrides in custom_vaadin.css, so you still have duplicated files. For a deployment aspect, you're deploying a theme instead of a JSP hook...

Me, I use a JSP hook. The styles.css is the one from the Vaadin site, but I paste my theme overrides at the bottom of the file (to give them higher specificity). But I bundle the JSP hook with the theme plugin to keep the files together. All deploys as one plugin and keeps things close enough that we can ensure the theme changes are kept in sync.

[Jack Bakker, modificado 10 Anos atrás.]

Actually, no duplication if just don't reference in theme main.css

I like how Vaadin has a "v-" prefix to their style classes

Similarily, I wish Twitter bootstrap3 would have a "b-" so folks can reference with more spcfcity specifcty.. special city ? like Babylon

[David H Nebinger, modificado 10 Anos atrás.]

FYI you can only have V6 or V7 installed for Liferay, but not both. This applies at the app container level, not at an instance level.

As far as the "the Work that has to be done is not that much", I'm not sure about that myself. They did come up w/ a 'compatibility' layer to make 6 code basically compatible with 7, but since the internals between the two are so much different I don't know that I'd want to rely on that.

I think as long as we got things working under V6 we'd be well on our way to getting them work under V7, but I wouldn't want to leave people thinking it's a simple transition