AutoCompleteTextField and CompoundPropertyModel

[Patrick1701]

Hello, I'm not able to get the value for an AutoCompleteTextField combined with a CompoundPropertyModel.

The value is always empty, caused by the inner converter of AutoCompleteTextField (see below, getting null)

if (value != null && value.equals(AutoCompleteTextField.this.getModelValue()))
                {
                    return AutoCompleteTextField.this.getModelObject();
                }

                return null; //if the TextField value (string) does not corresponds to the current object model (ie: user specific value), returns null.

I also tried the constructor with Class type, but I always run into null return.

Here my code...

public class AddressFormComponent<Address> extends Panel {
    public AddressFormComponent(String id, Address a) {
        super(id, new CompoundPropertyModel<Address>(a));
        add(new TextField<String>("street"));
        add(new TextField<String>("houseNumber"));
        add(new TextField<String>("zip"));
        add(new AutoCompleteTextField<String>("city") {
                private static final long serialVersionUID = 1L;

                @Override
                protected List<String> getChoices(String input) {
                    return AutoCompleteUtils.startsWith(input, CITYS);
                }

            }
        );
    }
}

used by PersoneForm:

class PersonForm extends Form<Person> {
        private static final long serialVersionUID = 1L;

        public PersonForm(String id, Person p) {
            super(id, new CompoundPropertyModel<Person>(p));
            add(new TextField<String>("name"));
            add(new AddressFormComponent<Address>("address", getModelObject().getAddress()));

            add(new Button("profilesubmitbutton"));
        }

(Person has an Address, getAddress())

Thanx for help :-) Patrick

[sebfz1]

Hi Patrick,

To be honest... I came into a quite similar issue last week but I was not able to reproduce it while back at home... So, I will try to re-investigate...

I will propose you a workaround, but just make sure to test without supplying getModelObject().getAddress(), ie:

add(new AddressFormComponent<Address>("address");

The only workaround I can propose you for now is to differentiate the models so the ACTF has its own model, then you reflect the change to the "parent" model in onSelected:

new AutoCompleteTextField<String>("city", new Model<String>(theCity))
{
            @Override
            protected void onSelected(AjaxRequestTarget target) {

                super.onSelected(target);

                //FIXME: hack, to be removed when new version of wicket-jquery-ui available (> 1.4.1 / 6.2.1)
                AddressFormComponent.this.getModelObject().setCity(this.getModelObject());
                AddressFormComponent.this.modelChanged();
            }
}

I will try to solve this asap...

Thanks & best regards, Sebastien.

[Patrick1701]

Hmm... I do not have a AddressFormComponent.this.getModelObject(). Its a Panel...

And, I must supply the Address to the AddressFormComponent, because the city String is a member of Address (using the same form for edit and new).

[Patrick1701]

Ok, got it work...

making Address final in constructor of AddressFormComponent and can use setCity(this.getModelObject()) direct.

But... unfortunately... a value (not chosen from AutoCompleteText) just typed in, does not modify the Address.setCity(), cause it doesn't runs through the onSelected(...).

[sebfz1]

Richard,

I understand the concern. Basically, the ACTF is designed to return an object reference chosen from a list of objects, it could be either beans or String(s). But, it is not designed to "interpret" the user entry (that's why the internal converter "fails" here)

I think I now how to solve this but it can lead to a significant change in the ACTF design, so I need to think about it... I will try within the next 48h.

Sorry for the inconvenience, Sebastien.

[sebfz1]

Oops, named you Richard...Sorry Patrick! (I am running a temperature since several days, I guess my brain is not absolutely well connected... :s)

[Patrick1701]

No Problem... :-)

What was the main intention of the internal converter? I do not really understand, why a converter is there.... especially when you say the ACTF should not take care about value interpretation. What it does, (it seems to me) taking too much care, by checking the values and returning null, in case they do not match.

As far as I remember while debugging, I already had the correct value, so I assumed, the ACTF than will just put it into the CompoundProperty Wrapped Address (setCity(...)) and thats it... but the converter nulled it just a second before. :-/

Gute Besserung! / Get well soon!

[sebfz1]

Hi Patrick,

That's is a good question... And the answer is that the converter is needed in the dual case:

• you use a bean
• you post the form

Even the model object has been previously set, the form processing will process the input in any case (if you submit the form I mean). If you are using a bean, without a converter, you get null. So you need a converter, but to prevent you (the user) to write your own converter, I did this internal converter because I already had the value (from the selection). So that made (in the past ;)) sense.

This update followed a (long) discussion you can read here: https://groups.google.com/forum/?fromgroups=#!topic/wicket-jquery-ui/ZvzwpUZ6SvA

But still... I do not understand why it is not working with String(s). The converter should not be called and I expect the ACTF behave like a standard TextField... This is this part I need to investigate.

I will let you know,

Gute Nacht :) Sebastien.

PS: Just out of curiosity, does the city you are working in begins with the letter R ? And the company with the letter O ?

[Patrick1701]

Hmm, No?! :-)

Its H and N ;-)

[Patrick1701]

I debugged a bit more... I think I have something.

The internal method getModelValue() of ACTF delegates to FormComponent getModelObject() to retrieve the value. In case of an existing value in Address Object, for instance "Paris", AND I didnt use the ACFT proposal feature, the getModelObject() of FormComponent retrieves the old value "Paris", the ACFT has the new value "Munich", and than it is not equal and falls back returning null.

I just typed the new value Munich without clicking the proposed Munich, than I have this behavior. If I use the proposed Munich from the list, then the Address.setCity() becomes correctly set to Munich.

I think, there is a modelChanged Event or something missing, when the InputField gets modified manually. The extended textfield does not recognize the change, and retrieves the old value. Old and new of ACTF are not equal and the return-null-behavior of the converter does the rest.

Perhaps ACTF getModelValue() should ask getInput() instead of this.getModelObject() ?!

Patrick

[sebfz1]

Hi Patrick,

Thanks for your investigation, all is true. I also investigated and finally found the reason of the problem. Since the beginning, I am surprised with one thing: that the converter is called when using String, given the fact that no Type is provided to the constructor.

In fact, if the model is a PropertyModel (or a CompoundPropertyModel), then these are IObjectClassAwareModel objects, and then the type is guessed by the AbstractTextComponent, supplying the Type. So, the type is not null and then the converter is called, causing the issue.

I do not know yet how to solve it the best way... Still thinking on it...

Best regards, Sebastien.

PS: about the city and company, that was because the first german city in term of visits of the demo site is Russelsheim, well known for a company starting with a O! :)

[sebfz1]

Hi Patrick,

I did a quick fix for that issue. I am almost sure it will work in all cases now, but I am still thinking there might be a better way to manage how the ACTF should behave... I am letting this issue open for now.

I have deployed a snapshot release: 6.2.2-SNAPSHOT Caution, the jQuery UI has been upgraded to 1.10.0 since version 6.2.1. You may have to upgrade your CSS theme.

Thanks to let me know how it goes.

Best regards, Sebastien.

[Patrick1701]

Hi Sebastian, first test... works for me. :-)

Pay attention... only for my issue. I did not test several ways of usage/implementations of ACTF.

kind regards Patrick

[sebfz1]

Hi Patrick, thanks for the feedback!