Mailing-List: contact isis-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: isis-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of dkhaywood@gmail.com designates
 74.125.82.43 as permitted sender)
Sender: Dan Haywood <dkhaywood@gmail.com>
References: <4E1206B4.30797.F6566E@kevin.kmz.co.za>
 <4E175B76.10955.4239CC@kevin.kmz.co.za>
 <4E1869F9.13805.77D916@kevin.kmz.co.za>
 <4E1B201D.9342.3A02D9@kevin.kmz.co.za>
In-Reply-To: <4E1B201D.9342.3A02D9@kevin.kmz.co.za>
Mime-Version: 1.0 (iPhone Mail 8C148)
Content-Type: text/plain;
	charset=us-ascii
Message-Id: <F453388A-C96C-4FBE-9131-6DFD0D3231E3@googlemail.com>
Content-Transfer-Encoding: quoted-printable
From: Dan Haywood <dan@haywood-associates.co.uk>
Subject: Re: Wicket Viewer - fetching choices for value types
Date: Mon, 11 Jul 2011 20:40:55 +0100
To: "isis-dev@incubator.apache.org" <isis-dev@incubator.apache.org>

I'll try to look at tomorrow eve.=20
Cheers,
Dan

Sent from my iPhone

On 11 Jul 2011, at 17:09, "Kevin Meyer - KMZ" <kevin@kmz.co.za> wrote:

> Phew!
>=20
> A bit of a slog, trying to understand Wicket and the Wicket Viewer, but=20=

> I finally seem to have something that works.
>=20
> I had to change ConverterForObjectAdapterMemento#convertToString=20
> to work with value-type objects.
>=20
> Otherwise, the Wicket viewer now seems to support choicesXXX for=20
> properties for value types.=20
>=20
> I have not tested this for parameters.
>=20
> One annoying thing I have not completed is getting the layout sorted=20
> out. The choices dropdown list appears outside the property "label"=20
> range, and renders a bit vertically displaced.
>=20
> Dan, if you get a chance, could you look at ValueCollections.java/html=20
> and see what is missing?
>=20
> I've tested this for Date and String, and it works.
>=20
> Ah - nearly forgot - I also don't (yet) know how to correctly initialise t=
he=20
> drop-down list with the existing property value. It always starts off with=
=20
> "Choose One", instead of the existing value.
>=20
> Regards,
> Kevin
>=20
>=20
> On 9 Jul 2011 at 16:47, Kevin Meyer - KMZ wrote:
>=20
>> Hi Dan,
>>=20
>> I got quite far, to the extend that I was able to render the choices in a=
=20
>> drop-down list, but I *still* had the original input field as a free-form=
=20
>> entry box.
>>=20
>> While trying to address this, I got stuck again.
>>=20
>> Anyway!
>>=20
>> If ComponentFactoryScalarAbstract#createComponent, I have some=20
>> code (currently commented out) that looks like this:
>>=20
>>    public final Component createComponent(final String id, final IModel<?=
> model) {
>>        final ScalarModel scalarModel =3D (ScalarModel) model;
>>=20
>>        // TODO: This is where the ValueCollection panel gets created.
>>        final List<ObjectAdapter> choices =3D scalarModel.getChoices();
>>        if (choices.size() > 0) {
>>    return new ValueCollection(id, scalarModel);
>>        } else {
>>            return createComponent(id, scalarModel);
>>        }
>>    }
>>=20
>> The point is that if a property of any of the regular scalarModel types i=
s=20
>> found to have some choices, then instead of creating the normal=20
>> component (e.g. StringPanel), the factory creates a ValueCollection=20
>> (ok, the name can be changed).
>>=20
>> As I see it, this value collection simply needs to render a the value typ=
e=20
>> as a dropdown list...
>>=20
>> But I'm getting stuck trying to synchronise the HTML and the wicket=20
>> viewer code in ValueCollection.
>>=20
>> I'm going to stop here for a while, but would appreciate it if you could=20=

>> uncomment the block in ComponentFactoryScalarAbstract, above,=20
>> and have a look at my ValueCollection.java & html.
>>=20
>> I deleted what turned out to be unneeded changes to the=20
>> ComponentFactoryListDefault.java, ComponentType.java, etc, and=20
>> deleted the unneeded ValueCollectionFactory.java.
>>=20
>> Regards,
>> Kevin
>>=20
>=20