Re: method varargs and property expression

[Thiago H. de Paula Figueiredo]

On Mon, Jun 7, 2021 at 5:38 AM Numa Schmeder  wrote:

> Hi Thiago,
>

Hello!


> Thank you for your feedback, yes indeed, I have checked the code of the
> property binding and the antler syntax.
> Indeed it compiles byte code based on real method signature, so you can’t
> be to generic or it won’t find the method you have written.


And that's exactly how Tapestry voids runtime reflection so property access
is as fast as handwritten code. :)


> I was actually thinking of implementing Spring Expression Language (SpEL),
> OGNL is getting a bit outdated and is now longer evolving.


Interesting! Planning to opensource it when it's done? It would be nice.


> Although I figured out my language issue, if you don’t call
> PersistentLocale on first render, URL won’t contain the locale virtual
> folder in the path.
> I think this is a bug, the natural behavior seems to be if you define
> multiple locales, on first render without local (index page for example) it
> should select the appropriate locale from request, browser etc.. (this
> works) and set it with persistentLocale, so links should be written
> correctly with the locale virtual folder. What do you think ?
>

Hmm, I have to think about this one. No ready-made answers like the other
ones in this thread. :)


> Lastly I wanted to override a value encoder for specific hibernate objects
> to create SEO friendly urls , but it was discarded because there is already
> an hibernate value encoder registered with tapestry hibernate, how can I
> override it for specific objects ?
>

ValueEncoderSource is a service with a mapped configuration: key is the
class of the object being encoded/decoded, ValueEncoderFactory (which is
usually implemented together with ValueEncoder in most but not all cases),
so this should be a very straightforward Tapestry-IoC service contribution
override. I'm not sure how you tried to do your override.


> Your help is very much appreciated.


It's always nice to help people, doubly if it's about Tapestry. :D


>
>
> Thank you.
>
> Best regards,
>
> Numa
>
> > Le 6 juin 2021 à 21:09, Thiago H. de Paula Figueiredo <
> thiag...@gmail.com> a écrit :
> >
> > On Wed, May 26, 2021 at 7:00 AM Numa Schmeder  n...@dfacto.ch>> wrote:
> >
> >> Hello,
> >>
> >
> > Hello!
> >
> >
> >> It seems method with varargs doesn’t work with property expression.
> >> If I put the following property expression, I get an error: Message
> >> doesn’t have a public “format" method.
> >> ${messages.format('priceFromPerGuest', travelMinPricePerGuest,
> >> displayedCurrency)}
> >> But If I write it as follow is works:
> >> messages.format('priceFromPerGuest', [travelMinPricePerGuest,
> >> displayedCurrency])
> >>
> >> Is this a bug ?
> >>
> >
> > I don't think so. Varargs, as far as I know, are implemented in Java
> purely
> > as a compiler feature, and Tapestry prop binding expressions work at
> > runtime, so it only sees method(arg, Object[] varargs) for something
> > declared as method(arg1, Object... varargs).
> >
> >
> >> Tapestry property expression is a bit limiting, particularly in
> conditions
> >> where you can’t have logical expression as:  test=“size > 10”
> >>
> >
> > Let me be pedantic here. :) Yes, it's the prop binding, short for
> property.
> > Being based on properties, it can be very fast, since Tapestry-IoC and
> > Tapestry can create code that calls properties without using reflection.
> > This binding was never supposed to have logical expressions.
> >
> >
> >> I know the rational is to keep property expression as simple as
> possible,
> >> but having some logic expressed in the template is not that bad,
> >
> >
> > Having logic expressed in the template is completely against the way the
> > prop binding was created and implemented, so I suggest you to not try or
> > want to do something one given tool doesn't want.
> >
> >
> >> because it’s in context ans sometimes makes more sense than having
> >> everything in java code.
> >
> >
> > Here comes one of the beauties of Tapestry: it's incredibly flexible and
> > customizable. You can create your own bindings with any logic you want!
> If
> > you don't know how, please let us know and we'll show you how.
> >
> > By the way, ChenilleKit, a third-party Tapestry add-on library, provides
> an
> > OGNL binding that provides a lot of expression power (but uses reflection
> > at runtime).
> >
> >
> >> Also if you work a lot with collection of objects, you have to create a
> >> property for each type of element in the collections, the “var” keyword
> is
> >> not powerful to be used in complex property expressions.
> >> Exemple, this won’t work, but it would be very practical:
> >> 
> >>${var:country.getName(locale)} - ${getPopulation(var:country)}
> >> 
> >>
> >> And if you use a generic property tempValue that you could reuse in
> >> different places, it won’t work because all conduits will be based on
> the
> >> Object Type and not Country type.
> >>
> >> @Property
> >> Object tempValue
> >>
> >> 

Re: method varargs and property expression

[Numa Schmeder]

Hi Thiago,

Thank you for your feedback, yes indeed, I have checked the code of the 
property binding and the antler syntax. 
Indeed it compiles byte code based on real method signature, so you can’t be to 
generic or it won’t find the method you have written. 
I will look into chenille kit for the OGNL binding, it’s interesting. I agree 
prop binding is cleaner in many way as it avoid logic inside template. But a 
bit of logic in the template avoids writing boiler plate code and declaring 
tons of variables in your class juste to create loop indexes or loop values. 
I was actually thinking of implementing Spring Expression Language (SpEL), OGNL 
is getting a bit outdated and is now longer evolving. 

Although I figured out my language issue, if you don’t call PersistentLocale on 
first render, URL won’t contain the locale virtual folder in the path. 
I think this is a bug, the natural behavior seems to be if you define multiple 
locales, on first render without local (index page for example) it should 
select the appropriate locale from request, browser etc.. (this works) and set 
it with persistentLocale, so links should be written correctly with the locale 
virtual folder. What do you think ?

Lastly I wanted to override a value encoder for specific hibernate objects to 
create SEO friendly urls , but it was discarded because there is already an 
hibernate value encoder registered with tapestry hibernate, how can I override 
it for specific objects ?

Your help is very much appreciated. 

Thank you. 

Best regards, 

Numa 

> Le 6 juin 2021 à 21:09, Thiago H. de Paula Figueiredo  a 
> écrit :
> 
> On Wed, May 26, 2021 at 7:00 AM Numa Schmeder  > wrote:
> 
>> Hello,
>> 
> 
> Hello!
> 
> 
>> It seems method with varargs doesn’t work with property expression.
>> If I put the following property expression, I get an error: Message
>> doesn’t have a public “format" method.
>> ${messages.format('priceFromPerGuest', travelMinPricePerGuest,
>> displayedCurrency)}
>> But If I write it as follow is works:
>> messages.format('priceFromPerGuest', [travelMinPricePerGuest,
>> displayedCurrency])
>> 
>> Is this a bug ?
>> 
> 
> I don't think so. Varargs, as far as I know, are implemented in Java purely
> as a compiler feature, and Tapestry prop binding expressions work at
> runtime, so it only sees method(arg, Object[] varargs) for something
> declared as method(arg1, Object... varargs).
> 
> 
>> Tapestry property expression is a bit limiting, particularly in conditions
>> where you can’t have logical expression as:  test=“size > 10”
>> 
> 
> Let me be pedantic here. :) Yes, it's the prop binding, short for property.
> Being based on properties, it can be very fast, since Tapestry-IoC and
> Tapestry can create code that calls properties without using reflection.
> This binding was never supposed to have logical expressions.
> 
> 
>> I know the rational is to keep property expression as simple as possible,
>> but having some logic expressed in the template is not that bad,
> 
> 
> Having logic expressed in the template is completely against the way the
> prop binding was created and implemented, so I suggest you to not try or
> want to do something one given tool doesn't want.
> 
> 
>> because it’s in context ans sometimes makes more sense than having
>> everything in java code.
> 
> 
> Here comes one of the beauties of Tapestry: it's incredibly flexible and
> customizable. You can create your own bindings with any logic you want! If
> you don't know how, please let us know and we'll show you how.
> 
> By the way, ChenilleKit, a third-party Tapestry add-on library, provides an
> OGNL binding that provides a lot of expression power (but uses reflection
> at runtime).
> 
> 
>> Also if you work a lot with collection of objects, you have to create a
>> property for each type of element in the collections, the “var” keyword is
>> not powerful to be used in complex property expressions.
>> Exemple, this won’t work, but it would be very practical:
>> 
>>${var:country.getName(locale)} - ${getPopulation(var:country)}
>> 
>> 
>> And if you use a generic property tempValue that you could reuse in
>> different places, it won’t work because all conduits will be based on the
>> Object Type and not Country type.
>> 
>> @Property
>> Object tempValue
>> 
>> 
>>${tempValue.getName(locale)} - ${getPopulation(tempValue)}
>> 
>> 
>> Could we find a solution to avoir creating a lot of fields for all loops ?
>> 
> 
> The var binding only really accepts strings well because it doesn't use
> reflection and being able to support arbitrary types would need reflection.
> 
> 
>> 
>> Thank you for your help,
>> 
>> Best!
>> 
>> 
>>  >   Numa Schmeder
>> www.dfacto.ch   <
>> http://www.dfacto.ch/ >
>> n...@dfacto.ch  > >   |   M +41 79 538 30 0