the mechanism for looking up expressions is not extensible, because it
isnt meant to be extended. so you have to write your own model from
scratch using something like mvel/ognl to access the property. both of
those support method calls afaik.

-igor

On Wed, Nov 5, 2008 at 1:56 AM, Jan Stette <[EMAIL PROTECTED]> wrote:
> 2008/11/5 Igor Vaynberg <[EMAIL PROTECTED]>
>
>> On Tue, Nov 4, 2008 at 5:54 PM, Jan Stette <[EMAIL PROTECTED]> wrote:
>> > Sure.  To explain a bit more why I'm asking: I have a table component
>> that's
>> > configured using property expressions as to what's shown in each column.
>> > The types of objects to be shown in the table are not known in advance,
>> > hence having a hard coded model for a specific type of class isn't really
>> > desirable.  Given this, do you think it would make sense to provide an
>> > extended property model, so that it could cope with the type of example
>> of
>> > objects I showed below?
>>
>> no i do not. we keep our property expression language simple on
>> purpose - we prefer java over strings. what you should do is have
>> these objects implement an itnerface that has String getValue(String
>> key) defined - that is how java works. if you cant do that then you
>> can always yourself write something that uses reflection.
>>
>> -igor
>>
>>
> Sorry, I don't think I'm making myself clear.  I was asking if I could
> provide an extended property model, not for it to be provided in Wicket!
> :-)  As I asked in my original question, what is the right place to hook
> this in, is it by overriding AbstractPropertyModel.getObject()?  I had a
> look at http://cwiki.apache.org/WICKET/property-expression-language.html,
> but that page seems out of date.
>
> Regards,
> Jan
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to