So I’ve got 7.0.1, and I’m trying to tinker w/ some Vaadin 7 portlets under Liferay. Much to my chagrin, some of the things that I could depend upon in V6 are gone…
For example, the PortletListener. I used that to get to the actual request/response classes which, in turn, allows me to access the PortletPreferences instances…
So I’m like digging into the 7.0.1 source, and I can see the various VaadinPortlet* classes, but many are marked as deprecated (i.e. the VaadinPortletSession which would get me the request/response or add a PortletListener or …).
All of the comments indicate that “@deprecated As of 7.0. Will likely change or be removed in a future version”…
So what are the plans here, guys? Are you planning support for portlets in the 7.0 line? Is the comment not to be believed (since this is 7.0 and I see no other replacement code)? When are these deprecated pieces going away, and what will they be replaced with? Should we infer that 7.0 is actually just beta code when it comes to portlets?
At this point I’m really leery of migrating to Vaadin 7 for my portlets with all of these deprecated markers…
The support page for Vaadin 7 does indicate JSR-268 portlets are supported. I haven’t tried it myself because we are stuck on WS 6.1 for now
I do have some specific questions myself. For example can the Navigator included in Vaadin 7 be used with portlets? From my understanding of portlets the URI fragment wouldn’t work because porlets cannot see URL parameters. Assuming that is right are there any workarounds for using Navigator within portlet enviornment?
Not sure about how the navigator would work. Liferay does allow for the ability to get to the URI fragment as well as URL parameters even though it is not part of the standards.
Since Vaadin and Liferay have historically been tight (Liferay 6 included Vaadin 6 from the first release), I’m hoping that Vaadin 7 will have the same level of support.
If not, then I’ll stick w/ Vaadin 6, but I worry about end of life/end of support/end of patches for V6…
Vaadin 7 dropped support for the old portlet 1.0 standard which was really a big hack but has full support for portlet 2.0 (JSR-286).
There was a lot of refactoring going on in the core servlet and portlet classes for Vaadin 7.0. Unfortunately we did not manage to finish all planned refactorings in time and therefore some portlet methods still remaing marked as “will likely change” because there were planned changes that just did not make it. The changes we are talking about are mostly what the API looks like, it’s not about removing features. Today I find it very unlikely that the changes will take place in the near future (no changes are included in the plan for 7.1)
One of the core ideas for Vaadin 7 is to not hide the core servlet/portlet API from the developer. It makes little sense to hide the main portlet API and then build our own abstractions on top of it, like PortletListener. Instead we try to make the API such that you can extend the portlet class and access the core portlet API yourself whenever needed.
Vaadin 7 supports JSR-286 (Portlet 2.0), but discontinued support for the older, little used servlet based JSR-168 (Portlet 1.0).
Some of the internal and semi-internal classes have been deprecated mostly because their APIs might change and some code that is in common between servlets and portlets might be unified in future releases, but portlet support is there to stay.
PortletListener was removed, but note that at least the current request, session, UI etc. are now available otherwise throughout the request handling (see e.g. UI.getCurrent()) without any custom listeners. Some other things are better done in lower level listeners (nothing Vaadin specific) or by overriding some methods in the portlet related classes (VaadinPortlet, possibly also VaadinPortletService). If there is still much demand for PortletListener, maybe re-introducing it could be considered.
Navigator and in general URI fragment management in Vaadin works by Vaadin code accessing the URI fragment on the client side and then sending it to the server through Vaadin’s own channels - for instance Vaadin Directory uses URI fragments in a portal. (It is still running on Vaadin 6, but the there are Vaadin 7 portlets doing the same.)
That’s great to hear, Henri, thanks for the update…
Specifically I use the PortletListener interface in v6 to handle mode changes. I intercept the handleResourceRequest() method to check the request’s PortletMode and, if it has changed, manually swap out the current component w/ the one for the new mode. Since it is a listener, it gets invoked for every request and I can immediately switch modes, I don’t have to poll for a thread local at many different points in the code.
Not very elegant, but it does allow me to create Vaadin portlets that support edit mode for segregating updates to the portlet prefs to an area the portal administrator expects to find them.
Now if there is a more elegant solution for this in v7, I’m totally on board w/ dropping the PortletListener interface…
Just took a quick look, there is a PortletListener in VaadinPortletSession at least in the latest 7.0 trunk.
The containing class is deprecated and may change in future versions, but there should be a reasonable way to get the same things done it if necessary at that point.
You could use a SessionInitListener in a subclass of VaadinPortlet to add the PortletListener to every new VaadinPortletSession.
Not very elegant, but should not require many changes to migrate this part.
That’s really what snagged me though, all of the deprecation annotations… If I build a series of v7 portlets (haven’t started, but plan to) leveraging the deprecated PortletListener against other deprecated portlet classes, then I could be painting myself into a corner…
Sure I could get them done today, but I’m more worried about the classes being deprecated in, say, 7.0.2 or 7.0.3 and then I’m back in development again to resolve the changes…
I started w v6.6.4 and the portlets created there did not require any changes when I upgraded vaadin in the portal up through v6.8.9 (which I did last night). I’d like to be able to do the same for v7, create portlets using 7.0.1 and know that they’re going to accommodate the v7 upgrades (far) into the future.
The deprecated annotations do not give me the warm and fuzzies for this. I hate comparing Vaadin to other projects, but often times the @deprecated is added to give notice that code is going away, but also provides info about what you the developer should be using instead. The vaadin deprecations just say they’re going away in 7.0, but there’s no clear path about what I the developer should be using instead…
Hence the forum post…
Note I’m not trying to dig at you or Vaadin or the whole Vaadin team - I love the platform and the work being done on it is fantastic. I push Vaadin on the Liferay forums every chance I get… I’m just trying to get a clearer picture of the roadmap for portlet development so I can choose the right path to be the most forward-compatible as possible…
Can you please give a status update to the portlet support in Vaadin 7? I’m currently using Vaadin 7.1, all these deprecations still exist, the whole documentation is still for Vaadin 6 and it looks like some things essential for me are not possible any more (for example setting a portlet title dynamically).
I accompany to the question of Carsten. We also want to investigate in using Vaadin 7 in portlet mode in conjunction with Liferay. The upper posts of this thread are now 4 months old, but still we are stuck with an outdated Book of Vaadin and lots of deprecations and todos in the Vaadin code. It seems that it is more important for the Vaadin team to introduce new goodies like server-push than consolidate existing features and docs.
Vaadin Ltd itself uses quite a lot of Vaadin portlets (many of which are now on Vaadin 7) as do many of the projects the company has worked on. Most of these are deployed on Liferay. Thus, we do have a strong incentive to keep portlets working with Vaadin 7.
As server push turned out to be more challenging than originally expected, we decided to postpone its portlet support until after 7.1. However, push is also coming for portlets in the future.
The book is always somewhat behind the most current code, and Vaadin 7 introduced a lot of changes to catch up with, not only for portlets. There is a new minor revision of the book coming out soon. I’m not sure if it addresses all the portlet changes yet but the author of the book will continue to work on updating all the content for the latest Vaadin 7.x.
Unfortunately, portlet support is one of the less well documented areas also in Vaadin source code (javadoc).
VaadinPortletSession is deprecated and thus PortletListener shows as deprecated. The earlier plan was to refactor also this class more extensively and move some of the functionality elsewhere, which would also have implied documenting the code better, but now major changes will probably have to wait for Vaadin 8. Some breaking changes (e.g. moving some methods to another interface or class) might be required to support push for portlets as is currently planned for Vaadin 7.2, but those should be accompanied with a simple migration path.
If you encounter specific new issues, please
create tickets for them.
Hi Henri
I wanted to ask for which version of VAADIN I have to wait for until portlets will be properly supported again.
I tried the PortletListener and in principles it works, but the portlet mode won’t be called from the first place (only in the second request, just init method is called from from the place), which was properly working with VAADIN 6.8.x.
At the moment I stick to VAADIN 6.8 for the same reason as already mentioned in earlier comments of this discussion.
Can you give me a date or a version when portlets will be fully supported again under Version 7?
I have to agree with Günther… We started to investigate in Vaadin-Technology some months ago, so naturally we decided not to use an old version, but chose to start with V7. Some workmates of me will start to implement a Liferay portal soon, and they want to integrate Vaadin Portlets. So we need a stable and working Portal integration - not for V8, not someday in the future - we need it now. And I really don’t understand that for so many months there is no progress in code nor in the Book concerning this - because such integration topics are fundamentally important for enterprise applications.
