hi,
> One problem I see with this approach is when you need null-checking
> for nested properties:
> eg: new TextField<String>("city", customer.address.getObject().city );
exactly, that is *the* problem
otherwise we could have
new AlternativeCompoundPropertyModel(customer.getAddress().getCity());
with this class decomposing the object chain into an el-style
expression: customer.address.city which will be the wicket:id ...
*but*, this can easily lose synchronization with the markup.
another web framework called warp-widgets uses compile-time checking
of expressions in html files with mvel. perhaps this points us in the
right direction...
we were also thinking of something like a "compile time annotation"
(with logic) such as java's @SuppressWarnings , but not sure if it'll
work though.
any thoughts on this?
francisco
>
> Let me know what you think about it.
>
> Maarten
>
>
>> Thanks for any update if anyone knows anything!
>> Wayne
>>
>>
>>
>>
>>
>> Johan Compagner wrote:
>>>
>>> no i really dont like that
>>> then everywhere there code they need to do that, that is not an option.
>>> and they have to program themselfs agains the proxy api. I dont want that
>>> developers also have the learn/do that
>>> This is something commons-proxy needs to do
>>>
>>> On Sat, Mar 8, 2008 at 3:29 PM, James Carman <[EMAIL PROTECTED]>
>>> wrote:
>>>
>>>> Couldn't you also do:
>>>>
>>>> ProxyFactory pf = ...;
>>>> new SharedPropertyModel<Customer>(pf, customer);
>>>>
>>>> So, the client tells you what proxy factory implementation to use.
>>>>
>>>> On 3/8/08, James Carman <[EMAIL PROTECTED]> wrote:
>>>> > I see the JIRA, I'll go ahead and start the discussion on the dev list.
>>>> >
>>>> >
>>>> > On 3/8/08, James Carman <[EMAIL PROTECTED]> wrote:
>>>> > > On 3/8/08, Johan Compagner <[EMAIL PROTECTED]> wrote:
>>>> > >
>>>> > > > for wicket this is a feature it really should have
>>>> > > > now it defeats the purpose i have to make a decission in wicket
>>>> which
>>>> > > > factory i use
>>>> > > > Then i can just as well directly compile against cglib.
>>>> > > > I cant make the api that way that the developer has to give that
>>>> factory to
>>>> > > > use. That would be completely horrible,
>>>> > > >
>>>> > >
>>>> > >
>>>> > > You could always implement your own brand of discovery for your
>>>> > > project (perhaps by using the service discovery feature built into
>>>> the
>>>> > > jdk).
>>>> > >
>>>> > > I like the idea of splitting it (and doing it the slf4j way rather
>>>> > > than the JCL way). I have actually suggested that we start an
>>>> > > exploratory branch of JCL to make it work more like slf4j (we've
>>>> been
>>>> > > talking about this since 2005). Anyway, if you file a JIRA issue,
>>>> > > I'll make sure we have a discussion with the other devs. For your
>>>> > > immediate purposes, commons-discovery is available also.
>>>> > >
>>>> >
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/CompoundModel-based-on-proxies-tp15317807p20222077.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
