component in window and subwindow at the same time

I have a need to display a component in the window and on a subwindow (so the user has that component in a subwindow to compare with other component’s data while browsing in the window), so, when and if the user returns to the old component in the windowo, the application doesn’t have to remake that component in the window, reset the parent etc. and also it doesn’t have to build another component for every one that needs be extracted in a subwindow.

I figured I could just add the component to the subwindow and repaint, w/o resetting the component’s parent. I did it with reflection adding it on the “components” LinkedList in the AbstractLayout, because the addComponent() also removes it from the old parent collection and I don’t want that.
What happened is that the component painted in the subwindow and dissapeared from the window (but it’s still there, because the size of the layout is as if it’s there, and if I move back and forth between my components, it appears, while it also shows in the subwindow).

[b]

Now, the real problem is that it’s a table, and if I scroll it in the subwindow I get an Out of sync error from the server. Was it really necessary for this single UI component per single server side representation model to be? Even worse, I don’t have a clone() in Table, so I can’t override clone() and make it work properly in Table subclasses if I recall, because of all the mutable objects in it.
[/b]
Is it enough to create a new MyTable() using reflection to get the proper class at runtime and using it’s constructor that accepts a DataSource to build a “clone”? Is there any other solution?

Using reflection randomly through a big framework is a dangerous game. It may work sometime but will surely makes you end up with impossible to track down bugs and unmaintainable code.

Vaadin is using javascript on client side to update the UI.
By forcing the same component to be in 2 different places, you end up with 2 elements in the DOM tree with the same ID.
From that point on, javascript can not differentiate the 2 elements (ids are supposed to be unique in DOM tree) and the UI state validation in Vaadin panic (the out of synch error) and lock the session to prevent further damage.

There are several ways to solve your problem. The way I would do it is create a new class extending Table which does all the set up. Then you just need to instantiate this class twice and share the same datasource to lower the load on server safely.

class MyTable extends Table{
  public MyTable(){
   super();
   //set up the table
  }
}

And then :

MyTable tableInWindow = new MyTable();
//Do things
MyTable tableInSubwindow = new MyTable();
tableInSubwindow.setComponentDatasource(tableInWindow.getComponentDataSource());

Thanks for the insight, I guess I’ll use another table (actually I’ll make an object pool later).

Also, for this reason the components should have clone() implemented for making easy copies in one line.

Although this is the specification: http://www.w3.org/TR/html5/elements.html#the-id-attribute
I think it’s a legitimate use especially because it lowers resource usage if frameworks allow it.
If the framework would just accept any number of UI correspondences with the same id, it could simply have one server-side component for all of them and update all of client counterparts concurrently (as an instance it’s still up to a single user, so again, no problem), because that is exactly what I intended in this case, and is the easiest on the resources. Only “snag” would be that the framework client side terminal would need to do this, so probably that’s where the implementation needs be done - the idea being the server side component sending a response only pertaining to one id, and the client side terminal updating for all components with that id. This again shows is for the best, because it would move the computation from the server side to the client side (and up to the user’s CPU) - great for web applications. This instead could open the way for a lot more client side synchronized little things, that trades server side resources and server bandwidth resources for client resources.

EDIT: Perhaps the vaadin framework can circumvent the specification simply by making classes of ids and searching for ids starting with that same serial-like id value that are unique as a whole.

The problem is not the framework, it is javascript.
getElementById is set to return only one element (as that id is not unique). Using other methods, like getElementsByName, to find a component are a lot slower (remember that vaadin supports IE6) and would reduce the framework speed greatly for a case that doesn’t occur so often.

Mostly interface guidelines define the fact of having the same information in different places as being mostly a bad design (as the user gets confused usually) outside of few cases it is usually not so high on the list of requirements.

Also it would not improve performance.
On client side, the DOM tree would need to be populated twice and the table rendered by the browser twice in any case. But when allowing the same instance to be in different places, the server would need to keep all the “copies” in sync (as html has no such concept). Which means asking the client browser to update the first table every time the second one is touched (user click, selection, scroll, …) and not just when the data is actually modified.

… and this is one of the biggest logical reasons why you should not have the same server-side component instance map to multiple widgets on the client. Each instance typically wants to have its own state like selection, and all the state information should be on the server side in the Vaadin way of doing things.

I am not saying it would not have been possible to build Vaadin so that it would support such mappings, but it is not that common a need in most applications and was not taken as a requirement originally. Adding support for that at this point would definitely be more costly in terms of complexity, maintenance effort etc. than what we see as the value, as several design decisions would have to be changed, backwards compatibility ensured, lots of code refactored and extensively retested (beyond what the current tests cover) and more complex use cases would need to be taken into account in every component. Maybe it would be a useful feature in your application, but it is too costly for us for the limited number of users it would truly benefit.

Cloning is a similar issue - doing the cloning correctly (handling all listeners, disconnecting from the previous parent etc.) is quite complicated to get right, and would be the source of numerous problems. Add to this the confusion about the semantics of clone() in Java, and you could get as big a mess as with Object.toString(). Again, as the need is not a very common one and a lot of big applications have worked fine with the approach Mathias suggested, I would not expect changes - Mathias’ approach is both clean and safe.

Ok, I suppose it won’t happen soon perhaps, but there’s no actually reasons to be slow (it very well can be done if someone programs it):

  1. multiple client-side components per server-side component don’t actually need to synchronize with eachother on scroll, click etc. (I don’t see a need for it), just to share the same data source, which again doesn’t need to be slow (see 2. and 3.)
  2. lets suppose that multiple client-side components per server-side component would be set to synchronize if both in sight, they actually don’t need to synchronize for components that aren’t visible (if I recall that means the components don’t appear in the HTML at all).
  3. because the client side terminal inserts and removes elements (or updates them), there’s no actual need for getElementsByName, because the path where the elements are is already known (determined), so no searches would occur, only path parsing, and only on client side. I’m actually doing a synchronization that because is lacking in this feature it makes a roundtrip with the server for almost nothing, when only server side validation is needed, it returns with the updated status for both UI areas in the response when an empty message would’ve sufficed, meaning the server validation gives its ok, and then the client-side terminal would just do the changes. The way it’s working now, both the server and the client support this overhead, plus the bandwidth overhead in between.

I’m not denying that it’s expensive development -_-