Address book demonstration version 2.0

[ujoni]

Reiterate Address book demonstration (#19) to use the newer iteration of Vaadin portlet API defined by #25. Use the request parameter based IPC.

Address book has two portlets that communicate using Portlet spec IPC.

• Portlets:
  • Address entry listing portlet (grid)
  • Address information view (form)
• Functionality in Address information view:
  • View mode should only show data in the form but does not allow editing.
  • Edit mode allows the user to edit the address data being displayed.
  • Deleting the user is allowed only when in Edit mode and Admin role.

[ujoni]

The branch https://github.com/vaadin/portlet-support/tree/addressbook2 has the API demonstrations under vaadin-portlet-demo/address-book.

This is a recycled example provided by @denis-anisimov, reusing the Form.java and GridView.java. All the API is mock, and the file are under /fakeapi.

The approach uses RenderParameters to provide IPC backbone for this example. While Portlet Hub would likely be less cumbersome for most users, I felt that covering the 2.0 compatible basic approach would be a good idea. The Portlet Hub approach can formalized for one of the communication actions.

The VaadinPortlet interface (and its subsets) provide life-cycle hooks where the normal xxxRequest and xxxResponse parameters are replaced by PortletRequestContext. Since the life-cycles of Vaadin components do not follow that of the portlets', having an integration point in between which makes more sense to a Vaadin application feels sensible. It should allow access to the portlet's native state, but also provides short-hands for communication, such as:

public class Form extends FormLayout implements HandlesPortletModes {
    // ...
    @Override
    public void handleHelpMode(PortletRequestContext context) {
        context.respondWith(FormHelpDisplay.class);
    }
    // ...

context provides a respondWith method which allows the user to define a component to render instead of the actual component, which implements portlet interfaces.

The Vaadin portlet implementation is done via interface implementations as I feel the core experience a developer would want is to "just make a Vaadin component". The interfaces add a few methods the developer needs to implement (and provides few convenience methods) but otherwise the development would focus on building the actual components.

IPC
To facilitate RenderRequest communication via component event callbacks, the VaadinPortlet interface provides a method makeRenderRequest():

    // Form.java
    private void save() {
        Contact contact = binder.getBean();

        ContactService.getDemoService().save(contact);

        makeRenderRequest().withParameter(Constants.RP_SAVED_CONTACT,
                contact.getId());
    }

The would aim to hide the "create a new render request url from the mutable render request parameters received from the current render response object and print a link to the page". Vaadin's Portlet integration would hide all that, allowing the users to make render requests as a response to a button click. This would need to register some listener to render requests (or have the latest render request stored) to be able to construct a new render request from that context. Then we would need to be able to actually invoke the render request from server side. To be 100% honest, I did not have time to figure out if that is actually feasible.

The receiving (Vaadin) portlet would handle the render request with the public parameter:

    // GridView.java
    @Override
    public void handleViewMode(PortletRequestContext context) {
        String contact = context.publicParameters().get(Constants.RP_SAVED_CONTACT);

        if (contact != null) {
            // lets pretend the parse does not throw
            int id = Integer.parseInt(contact);
            refresh(id);
        }
    }

[Legioth]

context.respondWith(FormHelpDisplay.class); means that an instance of the Form component would have to be created just for the purpose of discarding that instance and showing some other component instance instead. Aside from the runtime overhead, this does also feel slightly weird since the same class has multiple responsibilities. It is convenient to have everything in one class, until it isn't.

this.makeRenderRequest() that references a default method from an implemented interface does in my experience go against what developers expect. In addition, there's also the open question about whether it's actually possible to implement all the necessary functionality in a sensible way without storing state in instance fields?

I'm not entirely sure how makeRenderRequest() is actually supposed to work, but it looks to me like a terminal action would also be needed. How can the implementation otherwise know whether it should still keep waiting for further withParameter invocations?