Have you tried AjaxFormComponentUpdatingBehavior?

--
Jeremy Thomerson
http://www.wickettraining.com



On Thu, Mar 11, 2010 at 8:47 PM, Matthew Welch <[email protected]> wrote:

> I'm experimenting with a domain model that extremely interconnected. It's
> being persisted using a graph database which handles this high degree of
> interconnectivity with aplomb, however because my each of my domain objects
> is so tighly tied to the others, I have to be very careful to always use
> LoadableDetachableModels or I can easily end up serializing quite a bit of
> unintended data with the page.
>
> So far, this hasn't been too bad. In the past, I never used LDMs for forms,
> and I ran into a few initial issues at first, but they were mostly just me
> relearning some of my former habits. However, I have no run into an a
> corner
> case that I'm hoping someone with more knowledge of Wicket or a good
> creative stream might be able to help me figure out.
>
> I have a form backed by a LDM. Three of the fields (select fields) are
> cascading in the sense that I need to fill out one before the second is
> enabled and the options for the second are determined by the first. The
> cascade continues from the second to the third. I attached a
> AjaxFormComponentUpdatingBehavior tied to the "onblur" event for the first
> and second fields. I used this update the second and third fields when
> appropriate. This seemed to work fine, but then suddenly I ran into
> problems
> with the fields reverting back to the values they held before I modified
> them. I'm embarrassed to admin that I was stumped by this for a good thirty
> minutes until I remembered that this was all backed by a LDM. Obviously,
> when the ajax request would hit the server, the model would be reloaded
> from
> the back end with it's original values.
>
> I'm a bit stuck. I can make the form a little less fancy and not limit the
> items in the second and third fields from the value in the first and second
> respectively, but I'd prefer not to have to do that. Any ideas?
>
> Matt
>

Reply via email to