You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@click.apache.org by Ricardo Lecheta <rl...@gmail.com> on 2008/11/17 21:40:58 UTC
OgnlService?
Hi all,
I was thinking about test some other reflection libraries, but the code is
too tied to Ognl, or just normal reflection...
So I remember that know Click has been refactored to use Services...
What about create a Service to encapsulate all the reflection stuff ?
So it would be easier to change from some OgnlService to other
implementation.
I´m not sure if this would be easier to do but... what do you all think
about this?
regards
--
Ricardo
Re: OgnlService?
Posted by Ricardo Lecheta <rl...@gmail.com>.
Hi all,
thanks for the answers..
>>Is there a particular expression language you are interested in?
No. To be honest, I don´t care what implementation it is...
The current implementation performs really well for me.
But sometimes I need to use reflection inside my own code.
This is why I´m thinking about the ognl service..
Click already expose some services -> ClickUtils.getLogService()
regards,
On Tue, Nov 18, 2008 at 3:38 AM, Bob Schellink <sa...@gmail.com> wrote:
> Hi Ricardo,
>
> A related issue is this one: http://www.avoka.com/jira/browse/CLK-306
>
> I agree with you that if we go through the effort of introducing a
> different expression language it should
> be through a service, but Click should only ship with one implementation.
>
> Is there a particular expression language you are interested in?
>
> kind regards
>
> bob
>
>
> Malcolm Edgar wrote:
>
>> On this issue we did a bunch of testing around performance.
>>
>> Click uses Reflection with cached method caching for rendering/read
>> operations, and this is very fast. There was not appreciable
>> difference between Click's use of reflection and MVEL. You see a lot
>> of reflection used in Table row data rendering.
>>
>> Where Click uses OGNL is for writing/set operations. These are much
>> less infrequent than read operations, and are used in Form setting and
>> autobinding operations.
>>
>> My take on this is that we should probably use either OGNL or MVEL,
>> but not both. In think swapping OGNL for MVEL could be on the roadmap
>> for 1.6, but we really need a compelling reason to do this. Otherwise
>> we will get the opportunity to find a new bunch of bugs :)
>>
>> regards Malcolm Edgar
>>
>> On Tue, Nov 18, 2008 at 1:33 PM, florin.g <fl...@bytenotes.com> wrote:
>>
>>
>>> If Click does not expose the ognl features to the framework user yet
>>> simply
>>> uses it internally I would not see how this it benefits the user. I
>>> appreciate the ability to swap the templating module (velocity,
>>> freemarker,
>>> jsp) as using one over the other could be a religious thing.
>>>
>>> Unless mvel is faster? There was a discussion here before regarding this
>>> issue.
>>>
>>>
>>>
>>>
>>>
>>> Ricardo Lecheta-2 wrote:
>>>
>>>
>>>> Hi all,
>>>>
>>>> I was thinking about test some other reflection libraries, but the code
>>>> is
>>>> too tied to Ognl, or just normal reflection...
>>>>
>>>> So I remember that know Click has been refactored to use Services...
>>>>
>>>> What about create a Service to encapsulate all the reflection stuff ?
>>>>
>>>> So it would be easier to change from some OgnlService to other
>>>> implementation.
>>>>
>>>> I´m not sure if this would be easier to do but... what do you all think
>>>> about this?
>>>>
>>>> regards
>>>>
>>>> --
>>>> Ricardo
>>>>
>>>>
>>>>
>>>>
>>> --
>>> View this message in context:
>>> http://n2.nabble.com/OgnlService--tp1511200p1512471.html
>>> Sent from the click-development mailing list archive at Nabble.com.
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
--
Ricardo Lecheta
Re: OgnlService?
Posted by Bob Schellink <sa...@gmail.com>.
Hi Ricardo,
A related issue is this one: http://www.avoka.com/jira/browse/CLK-306
I agree with you that if we go through the effort of introducing a
different expression language it should
be through a service, but Click should only ship with one implementation.
Is there a particular expression language you are interested in?
kind regards
bob
Malcolm Edgar wrote:
> On this issue we did a bunch of testing around performance.
>
> Click uses Reflection with cached method caching for rendering/read
> operations, and this is very fast. There was not appreciable
> difference between Click's use of reflection and MVEL. You see a lot
> of reflection used in Table row data rendering.
>
> Where Click uses OGNL is for writing/set operations. These are much
> less infrequent than read operations, and are used in Form setting and
> autobinding operations.
>
> My take on this is that we should probably use either OGNL or MVEL,
> but not both. In think swapping OGNL for MVEL could be on the roadmap
> for 1.6, but we really need a compelling reason to do this. Otherwise
> we will get the opportunity to find a new bunch of bugs :)
>
> regards Malcolm Edgar
>
> On Tue, Nov 18, 2008 at 1:33 PM, florin.g <fl...@bytenotes.com> wrote:
>
>> If Click does not expose the ognl features to the framework user yet simply
>> uses it internally I would not see how this it benefits the user. I
>> appreciate the ability to swap the templating module (velocity, freemarker,
>> jsp) as using one over the other could be a religious thing.
>>
>> Unless mvel is faster? There was a discussion here before regarding this
>> issue.
>>
>>
>>
>>
>>
>> Ricardo Lecheta-2 wrote:
>>
>>> Hi all,
>>>
>>> I was thinking about test some other reflection libraries, but the code is
>>> too tied to Ognl, or just normal reflection...
>>>
>>> So I remember that know Click has been refactored to use Services...
>>>
>>> What about create a Service to encapsulate all the reflection stuff ?
>>>
>>> So it would be easier to change from some OgnlService to other
>>> implementation.
>>>
>>> I´m not sure if this would be easier to do but... what do you all think
>>> about this?
>>>
>>> regards
>>>
>>> --
>>> Ricardo
>>>
>>>
>>>
>> --
>> View this message in context: http://n2.nabble.com/OgnlService--tp1511200p1512471.html
>> Sent from the click-development mailing list archive at Nabble.com.
>>
>>
>>
>
>
Re: OgnlService?
Posted by Malcolm Edgar <ma...@gmail.com>.
On this issue we did a bunch of testing around performance.
Click uses Reflection with cached method caching for rendering/read
operations, and this is very fast. There was not appreciable
difference between Click's use of reflection and MVEL. You see a lot
of reflection used in Table row data rendering.
Where Click uses OGNL is for writing/set operations. These are much
less infrequent than read operations, and are used in Form setting and
autobinding operations.
My take on this is that we should probably use either OGNL or MVEL,
but not both. In think swapping OGNL for MVEL could be on the roadmap
for 1.6, but we really need a compelling reason to do this. Otherwise
we will get the opportunity to find a new bunch of bugs :)
regards Malcolm Edgar
On Tue, Nov 18, 2008 at 1:33 PM, florin.g <fl...@bytenotes.com> wrote:
>
> If Click does not expose the ognl features to the framework user yet simply
> uses it internally I would not see how this it benefits the user. I
> appreciate the ability to swap the templating module (velocity, freemarker,
> jsp) as using one over the other could be a religious thing.
>
> Unless mvel is faster? There was a discussion here before regarding this
> issue.
>
>
>
>
>
> Ricardo Lecheta-2 wrote:
>>
>> Hi all,
>>
>> I was thinking about test some other reflection libraries, but the code is
>> too tied to Ognl, or just normal reflection...
>>
>> So I remember that know Click has been refactored to use Services...
>>
>> What about create a Service to encapsulate all the reflection stuff ?
>>
>> So it would be easier to change from some OgnlService to other
>> implementation.
>>
>> I´m not sure if this would be easier to do but... what do you all think
>> about this?
>>
>> regards
>>
>> --
>> Ricardo
>>
>>
>
> --
> View this message in context: http://n2.nabble.com/OgnlService--tp1511200p1512471.html
> Sent from the click-development mailing list archive at Nabble.com.
>
>
Re: OgnlService?
Posted by "florin.g" <fl...@bytenotes.com>.
If Click does not expose the ognl features to the framework user yet simply
uses it internally I would not see how this it benefits the user. I
appreciate the ability to swap the templating module (velocity, freemarker,
jsp) as using one over the other could be a religious thing.
Unless mvel is faster? There was a discussion here before regarding this
issue.
Ricardo Lecheta-2 wrote:
>
> Hi all,
>
> I was thinking about test some other reflection libraries, but the code is
> too tied to Ognl, or just normal reflection...
>
> So I remember that know Click has been refactored to use Services...
>
> What about create a Service to encapsulate all the reflection stuff ?
>
> So it would be easier to change from some OgnlService to other
> implementation.
>
> I´m not sure if this would be easier to do but... what do you all think
> about this?
>
> regards
>
> --
> Ricardo
>
>
--
View this message in context: http://n2.nabble.com/OgnlService--tp1511200p1512471.html
Sent from the click-development mailing list archive at Nabble.com.