(SOLVED) Mixing Vaadin with JSP, while doing portlet 2.0?

Hi!
I was wondering if there is a way to mix together Vaadin with a stone-age JSP for things like Portlet setup (Edit mode) and Portlet rendering (View mode). As for setup complex GUI, Vaadin just rules, however in many cases a View (presentation) is much faster to make in a simple JSP, since usually it requires very minimal effort without this really painful route developing own custom GWT widgets. In fact, 95% of usual Web things in Portal you want them custom and wrapped in some graphical beautification, which is just that easy with JSP, unlike GWT. On the other hand, messing around with a plain JSP on GUI part is really pain in a butt. So therefore such a combination would really blow. Here what I am thinking:


                 +-------------+
                 | Portlet 2.0 |
                 +------+------+
                        | 
                        |
             +----------+----------+
             |                     |
             |                     |
         +---+---+             +---+---+
         | View  |             | Edit  |
         +---+---+             +---+---+
             |                     |
             |                     |
         +---+---+         +-------+-------+
         |  JSP  |         | Vaadin and Co |
         +-+---+-+         +-----+---+-----+
           |   \                 /   |
           |    \   +-------+   /    |
           |     \  | RDBMS |  /     |
           |      \-+ Data  +-/      |
           |        | Base  |        |
           |        +-------+        |
           |                         |
           +------------+------------+
                        |
                        |
                +-------+-------+
                | Presentation  |
                +---------------+

For example, I want some jQuery javascript on top of few HTML elements that are rendered from the database. This can be done just like this per few moments and there is no any problems with cross-browser stuff, since jQuery takes care of it.

The only way I found so far
(the very-very ugly way)
is to use Embedded object as an iframe (an evil thing). Basically, it is as same as diagram above, just wrapped with the Vaadin and not really runs within a context, but on its own. Thus can be just anything: external URL etc. While it can be standalone JSP/whatever page, still it can not be a portlet, since it should run within the whole page at once.

Maybe there is a way to mix these stuff together, where on View part I can hook up a regular JSP with a regular Generic Portlet, and on Edit I can use Vaadin included? So far I’ve managed this by making two separate portlets: one is for administering things (Vaadin-based) another is plain JSP to view stuff. Vaadin-based shows nothing when no configuration required (Administrator or appropriate role detected) or shows a little button to call pop-up for editing. That works perfect, but just… two separate portlets to maintain and support and one is usually hidden, but still hammers a database to check what to do.

Any ideas how to combine all together? — that would be great! The reason is that when developing a portlets (these are essentially a complete little applications), then mainly you rarely (<5%) do them reusable by themselves, but a developing a complete entity that is reusable within a portal context (95%>). I think ability JSP + Vaadin would save lot of time, when you need GUI for setup, but need manual JSP on presentation, where you do the thing only for the specific particular portlet, like let’s say, a photo gallery or some slideshow etc — then you just add the application in the portal, but you don’t really make another portlet out of this one.

P.S.
Speaking with tongue-in-cheek:
the whole vaadin.com (except demo sampler) is a primary evidence of what I am saying probably does make a little sense?.. :slight_smile:

Did you notice the
HtmlModePortlet demo
? Something like that? (not JSP, but still…)

Best Regards,
Marc

If you take HtmlModePortlet as a basis, here is one example on how to dispatch a mode to JSP:

    PortletContext context = null;
    // portlet 2.0 only
    if (getContext() instanceof PortletApplicationContext2) {
        PortletApplicationContext2 ctx = (PortletApplicationContext2) getContext();
        context = ctx.getPortletSession().getPortletContext();
    }
    if (context != null) {
        PortletRequestDispatcher portletRequestDispatcher = context.getRequestDispatcher("/my_jsp_page.jsp");
        if (portletRequestDispatcher != null) {
            portletRequestDispatcher.include(request, response);
        }
    }

Marc, Henri,
thanks a lot! That’s exactly what I am looking for — I just didn’t see this demo and just had no idea these classes exists. :*) In fact, Henri, it seems like not really needed to make all these checks since getting a portlet context works fine for generic portlets. Here is a whole code together that works for me at least on a Liferay or/and Sun Webspace
(well, religion does not allows me to try this on JBoss as well as class names are quite different, LOL)
:


public class VaadinizedPortlet extends AbstractApplicationPortlet {
    @Override
    protected void writeAjaxPage(RenderRequest request,
                                 RenderResponse response,
                                 Window window,
                                 Application application)
            throws IOException,
                   MalformedURLException,
                   PortletException {

        if (PortletMode.VIEW.equals(request.getPortletMode())) {
            this.getPortletContext().getRequestDispatcher("/WEB-INF/portlet_view.jsp").include(request, response);
        } else {
            super.writeAjaxPage(request, response, window, application);
        }
    }

    @Override
    protected Class<? extends Application> getApplicationClass() throws ClassNotFoundException {
        return VeryComplexVaadinGUIApplicationForSetupVaadinizedPortlet.class;
    }
}

Also, some changes to go to portlet.xml, something like:


<portlet>
    <portlet-class>foo.bar.VaadinizedPortlet</portlet-class>
    <init-param>
        <name>application</name>
        <value>foo.bar.VeryComplexVaadinGUIApplicationForSetupVaadinizedPortlet</value>
    </init-param>

    ....

</portlet>

Many thanks, guys! Would be nice if this part appear in the Book of Vaadin somewhere?


Update
. It is also still nice to mention how to switch between the modes, in case if you want it even more flexible, e.g. your view portlet mode turns to be a Vaadin, once you have different roles etc. (well, nobody knows, just in case). So in that case, I do the following:

interface FoobarInterface {
    public FoobarInterface setSpecificMode(int mode);
}

This interface for com.vaadin.ui.Window bring together. Then:

public class PureVaadinApplication extends Application {
    public static final int VIEW_MODE = 0;
    public static final int EDIT_MODE = 1;
    public static final int PIZZA_MODE = 2;
    public static final int KARJALANPIIRAKKA_MODE = 3;

    private FoobarInterface viewWindow;
    private FoobarInterface cuisineWindow;

    @Override
    public void init() {
        this.cuisineWindow = new CuisineWindowImplementation();
        this.viewWindow = new viewWindowImplementation();
        setMainWindow(this.viewWindow);
    }

    public void setApplicationMode(int mode) {
        this.setMainWindow(mode == PureVaadinApplication.VIEW_MODE 
                           ? this.mainWindow : this.cuisineWindow.setSpecificMode(mode));
    }
}

And since now, somewhere in the “writeAjaxPage(…)” method right before “super.writeAjaxPage” (see the first source example) do something like:

((PureVaadinApplication) application)
      .setApplicationMode(PortletMode.VIEW.equals(request.getPortletMode())
             ? PureVaadinApplication.VIEW_MODE       
             : PureVaadinApplication.KARJALANPIIRAKKA_MODE); // Tasty one, BTW :)

In fact, PortletListener won’t be really handled here, since AbstractApplicationPortlet is just a GenericPortlet++.

HTH.

For the extra instanceof checks etc, I extracted the code from elsewhere and removed some additional logic, but apparently left in much now unnecessary code.

If you override getApplicationClass(), you should not need the “application” init parameter.

As for the book, dispatching a mode to a JSP page actually
is there in the HtmlHelpPortlet.java example
, just commented out as an alternative.