Flow: Allow dom manipulation with template elements

[manolo]

Given this code:

    <div id="div1">div1</div>
    <div id="div2">div2</div>

    @Id("div1") private Div div1;
    @Id("div2") private Div div2;

     div1.add(div2);



md5-9826d907664402046d78b9eae124bf4b



Java.lang.IllegalArgumentException: Not in the list
    at com.vaadin.flow.dom.impl.AbstractNodeStateProvider.removeChild(AbstractNodeStateProvider.java:112)
    at com.vaadin.flow.dom.Node.removeChild(Node.java:302)
    at com.vaadin.flow.dom.Element.removeFromParent(Element.java:573)
    at com.vaadin.flow.dom.Node.insertChild(Node.java:219)
    at com.vaadin.flow.dom.Node.appendChild(Node.java:138)
    at com.vaadin.flow.component.HasComponents.add(HasComponents.java:44)

[pleku]

@manolo what is the actual use case ? What value would enabling this bring ? What are you trying to achieve ?

[manolo]

I need it to prepare the content of a dialog in the template e.g:

<dom-module id="users-view">
 <template>
  <vaadin-grid id="grid></vaadin-grid>
  <vaadin-dialog id="dialog"></vaadin-dialog>

  <vaadin-form-layout id="form">
    <vaadin-form-item>
      <vaadin-text-field id="name"></vaadin-text-field>
    </vaadin-form-item>
     <!-- 
       ... more declarative code to configure all the form
      -->
     <vaadin-button id="save"></vaadin-button>
  </vaadin-form-layout>
 </template>
</dom-module>

@Tag("users-view")
public class UsersView extends PolymerTemplate<> {
  @Id("grid") Grid<User> grid;
  @Id("dialog") Dialog dialog;
  @Id("form") FormLayout form;
  @Id("name") TextField name;
  @Id("save") Button save;

  BeanValidationBinder<User> binder = new BeanValidationBinder<>(User.class);

  public UsersView( ) {
     setupEventListeners(); // set events to buttons
     setupGrid(); // configure grid

     // bind the user object to edit
     binder.bind(name, 'firstName');

     // We cannot set the dialog content in declarative, use java instead
     dialog.add(form);

  }
}

[pleku]

Thanks @manolo. Follow-up: Why do you need to do it like that ? Why don't you just open the dialog separately ? With the formlayout inside it already ?

[manolo]

we cannot put the form-layout inside the vaadin-dialog, because I need a template wrapping it, hence I loose java binding, in this example, I can bind dialog but reference to name is lost

<vaadin-dialog id="dialog">
  <template>
        <vaadin-text-field id="name"></vaadin-text-field>
    </template>
  </vaadin-dialog>

  @Id("dialog") Dialog dialog;
  @Id("name") TextField name;

[pleku]

Why do you need to the Dialog in the template in the first place? Why not just open Dialog from Java and put the template component with the formlayout in there?

[denis-anisimov]

This feature has never been considered to be implemented.
The manipulation involves elements implicitly involved : original parent of the element which needs to be moved and resulting parent.

Not the "logical" parents, but _REAL_ parents. Those parents might be are not referenced from the server side at all. So this usecase requires very special treating which might be very complicated.

So this can be considered as a request for enhancement but not as a bug. And not a hight priority.

[pleku]

We are not going to do this now since we don't feel that it is a good practice to have everything inside a template and then modifying them around from Java.

The specific use case reported here doesn't really make sense, since the templates for the form-dialog and the view that the dialog is opened in should be in different templates. The form contents can be added to the dialog and the dialog just opened programmatically from Java when needed.

[manolo]

My use case was not to use the template in dialog as I documented in my first coment, but have the dialog and the content of the dialog separatly so as I can take advantage of java @Id binding. Then in java side I append the content to the dialog.

Moving things in the dom is something that allows flow, when everything is created in java, I don't see the constrain if those flow elements are created in the template via @Id mechanism.

Obviously I can create everything in java side so as the dialog content could be in a different template, with it's own java class, but I wanted to do something very logical from the DX.

Anyways, if flow will be unable to correctly manage elements handled in templates, that should be documented somehow in the add method of components. Something like elements not created in java-side but taken from templates via Id cannot be added, and you'll get an unsupported exception ....

[denis-anisimov]

Anyways, if flow will be unable to correctly manage elements handled in templates, that should be documented somehow in the add method of components. Something like elements not created in java-side but taken from templates via Id cannot be added, and you'll get an unsupported exception ....

That's definitely true.

[denis-anisimov]

Actually (in addition) it should throw an exception which describes in details why you can't call this method in this situation. Current exception is confusing.