[Geoserver-devel] Layer/Resource page Wicket headaches

GeoServer GeoServer Developer
1

Hi,
so I've been fighting with this page for quite a bit,
due to a number of different reasons, and I came
to realize there are fundamental problems in the
way it's setup.

Generally speaking, trying to put togheter a
tabbed form in Wicket is source of headaches.
The thing is, each tab has to be a form of its
own, and you have to make modifications to the
way the tabbed panel operates in order to
submit the current page form before switching
to the other, failing to do so makes all modifications
die (this is because on switch the subforms are
not submitted, and thus

Which basically means, when the user switches
the page, the stuff is written inside the layer/resource
info (since so catalog.save is called, actually
the modification proxy is holding the diff).

But it gets funnier. We know that it's bad practice
to keep around a heavy model, and that we should use
a loadable model instead. Well, think about it,
if we do so, the changes are written inside
the modification proxy wrapping the layer/resource,
then the page is serialized and the model is detached,
making the modification proxy go the way of the dodo.
Result: if we play by the book we loose the
edits even if we make the tab submit each subform
on tab switch. Aagh.

What to do? Well, the easy way is to kill the
tabs and have everything in a single looong page.
Longer than it used to be, because now it's nicely
organised in section with tabs, and the form component
labels are placed above each form component.

Alternatively... hmm... I guess the loadable/detachable
model has to detach the actual resource, but somehow
keep around the modification proxies with their
rich load of modified fields.
Or, alternatively, don't play by the book and really
serialize the resource, so that when the other tab
loads, the _same_ object is provided, and so on
when we go back.

All the issue boils down to trying to simulate
a javascripty UI. A ext UI would a full copy of
the resource client side, edit it at will,
and submit it to the server in a single shot.
If we do the same, we're safe, if we don't, bye bye.
But we have to accept serializing the whole baby.

I may try to explore other avenues, but if I fail,
what would you prefer we do?

Thoughts?
Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

2

Question. Is this not an issue with any page that has multiple form submits?

But yes, sounds like a headache indeed. So I guess the choices are 1) make ModificationProxy serializable and 2) make a model that knows it dealing with a proxy.

Both seem doable. Following good wicket practice I guess means doing number 2. So we need a LoadableDetachableModel which does what the regular ones do, ie hold onto the id the object and load it on demand, but it also has to maintain the state of the proxy. Am i correct?

And that is more the edit case, I guess the new case makes things more complicated because you are not dealing with a proxy, but the object itself?

Andrea Aime wrote:

Hi,
so I've been fighting with this page for quite a bit,
due to a number of different reasons, and I came
to realize there are fundamental problems in the
way it's setup.

Generally speaking, trying to put togheter a
tabbed form in Wicket is source of headaches.
The thing is, each tab has to be a form of its
own, and you have to make modifications to the
way the tabbed panel operates in order to
submit the current page form before switching
to the other, failing to do so makes all modifications
die (this is because on switch the subforms are
not submitted, and thus

Which basically means, when the user switches
the page, the stuff is written inside the layer/resource
info (since so catalog.save is called, actually
the modification proxy is holding the diff).

But it gets funnier. We know that it's bad practice
to keep around a heavy model, and that we should use
a loadable model instead. Well, think about it,
if we do so, the changes are written inside
the modification proxy wrapping the layer/resource,
then the page is serialized and the model is detached,
making the modification proxy go the way of the dodo.
Result: if we play by the book we loose the
edits even if we make the tab submit each subform
on tab switch. Aagh.

What to do? Well, the easy way is to kill the
tabs and have everything in a single looong page.
Longer than it used to be, because now it's nicely
organised in section with tabs, and the form component
labels are placed above each form component.

Alternatively... hmm... I guess the loadable/detachable
model has to detach the actual resource, but somehow
keep around the modification proxies with their
rich load of modified fields.
Or, alternatively, don't play by the book and really
serialize the resource, so that when the other tab
loads, the _same_ object is provided, and so on
when we go back.

All the issue boils down to trying to simulate
a javascripty UI. A ext UI would a full copy of
the resource client side, edit it at will,
and submit it to the server in a single shot.
If we do the same, we're safe, if we don't, bye bye.
But we have to accept serializing the whole baby.

I may try to explore other avenues, but if I fail,
what would you prefer we do?

Thoughts?
Cheers
Andrea

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

3

Justin Deoliveira ha scritto:

Question. Is this not an issue with any page that has multiple form submits?

I believe so, yeah.

But yes, sounds like a headache indeed. So I guess the choices are 1) make ModificationProxy serializable and 2) make a model that knows it dealing with a proxy.

ModificationProxy is serializable. The problem were:
- do we want to serialize the whole baby? (answer, yes, found no other
   simple solution)
- how do we reattach the deserialized xxxInfo to the catalog? (answer,
   adding attach(xxxInfo) methods into the Catalog or the CatalogBuilder).

Both seem doable. Following good wicket practice I guess means doing number 2. So we need a LoadableDetachableModel which does what the regular ones do, ie hold onto the id the object and load it on demand, but it also has to maintain the state of the proxy. Am i correct?

And that is more the edit case, I guess the new case makes things more complicated because you are not dealing with a proxy, but the object itself?

Right, that's why I did not go down this path.
Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

4

Andrea Aime wrote:

Justin Deoliveira ha scritto:

Question. Is this not an issue with any page that has multiple form submits?

I believe so, yeah.

But yes, sounds like a headache indeed. So I guess the choices are 1) make ModificationProxy serializable and 2) make a model that knows it dealing with a proxy.

ModificationProxy is serializable. The problem were:
- do we want to serialize the whole baby? (answer, yes, found no other
  simple solution)
- how do we reattach the deserialized xxxInfo to the catalog? (answer,
  adding attach(xxxInfo) methods into the Catalog or the CatalogBuilder).

Both seem doable. Following good wicket practice I guess means doing number 2. So we need a LoadableDetachableModel which does what the regular ones do, ie hold onto the id the object and load it on demand, but it also has to maintain the state of the proxy. Am i correct?

And that is more the edit case, I guess the new case makes things more complicated because you are not dealing with a proxy, but the object itself?

Right, that's why I did not go down this path.

Ok... I guess it seems you resolved your issues. Will update and check out how things work.

Cheers
Andrea

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.