Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Demonstrate window state handling in Vaadin portlets #27

Closed
ujoni opened this issue Sep 23, 2019 · 7 comments
Closed

Demonstrate window state handling in Vaadin portlets #27

ujoni opened this issue Sep 23, 2019 · 7 comments
Assignees
Labels
Milestone

Comments

@ujoni
Copy link
Contributor

ujoni commented Sep 23, 2019

Create a Vaadin portlet based on the draft created from #25 which demonstrates how the user can create a portlet which

  • Displays a single image in normal window mode
  • Displays a fictional user form in maximized view

The demonstration should seek to align itself with the new API draft but also seek ways to improve upon the API, to make the task as easy and clear for the potential user as possible.

@ujoni ujoni added the demo label Sep 23, 2019
@ujoni ujoni changed the title Demonstrate window mode handling in Vaadin portlets Demonstrate window state handling in Vaadin portlets Oct 2, 2019
@caalador caalador self-assigned this Oct 3, 2019
@caalador
Copy link
Contributor

caalador commented Oct 4, 2019

How I as a user would want to use a window state portlet.

package com.vaadin.flow.portal;

import com.vaadin.flow.component.button.Button;
import com.vaadin.flow.component.html.Image;
import com.vaadin.flow.component.textfield.TextField;

public class PortletTwo extends Div
        implements WindowStateHandler<MySecondPortlet>{

    public static final String APPLICATION_IMAGE = "data:image/png;base64,TEH_DATA_HERE";

    @Override
    void renderNormal() {
        Image image = new Image(APPLICATION_IMAGE, "Application image");
        image.addClickListener(event -> maximize());
        add(image);
    }

    @Override
    void renderMaximized() {
        TextField input = new TextField("");
        add(input, new Button("return", event -> normalize()));
    }

    @Override
    void renderMinimized() {
        // NO-OP as we have nothing to show in minimized mode.
    }
}

or public class PortletTwo extends WindowStateComponent<Div, MySecondPortlet> {

or

public class PortletTwo extends Div
        implements WindowStateHandler<MySecondPortlet>{

    public static final String APPLICATION_IMAGE = "data:image/png;base64,TEH_DATA_HERE";

    @Override
    void windowStateChange(WindowState newState) {
        if(newState.equals(WindowState.NORMAL) {
            Image image = new Image(APPLICATION_IMAGE, "Application image");
            image.addClickListener(event -> maximize());
            add(image);
        } else if(newState.equals(WindowState.MAXIMIZED)) {
            TextField input = new TextField("");
            add(input, new Button("return", event -> normalize()));
        }
    }
}

For demo see https://github.com/vaadin/portlet-support/compare/api/27_window_state

@Legioth
Copy link
Member

Legioth commented Oct 4, 2019

What is MySecondPortlet that is referenced in the composite-like example? Why aren't the other examples referencing that class?

@caalador
Copy link
Contributor

caalador commented Oct 4, 2019

In that example it is the VaadinPortletInstance that is referenced with the generic P extends WindowStatePortlet which is a vaadin portlet and it just makes the portlet handling easier for the abstract composite class as then we have a contract that we can request certain things from the portlet.

For the others the interfaces basically make assumptions of the VaadinPortlet instance.

@Legioth
Copy link
Member

Legioth commented Oct 5, 2019

How would the same association be expressed with the other alternatives?

@caalador
Copy link
Contributor

caalador commented Oct 7, 2019

Nothing blocking having them require the portlet either e.g. WindowStateHandler<MySecondPortlet>

@pleku pleku closed this as completed Oct 9, 2019
@Legioth
Copy link
Member

Legioth commented Oct 15, 2019

Nothing blocking having them require the portlet either e.g. WindowStateHandler<MySecondPortlet>

That approach does on the other hand cause some boilerplate if there's only one portlet since you cannot omit the type parameter without getting IDE warnings about using raw types.

@caalador
Copy link
Contributor

Well this has been turned around as things have been progressing as we have more need to know the PortletView in the portlet instance than knowing the portlet in the view instance.

@mehdi-vaadin mehdi-vaadin added this to the Abandoned milestone Nov 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants