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 <thiag...@gmail.com> a > écrit : > > On Wed, May 26, 2021 at 7:00 AM Numa Schmeder <n...@dfacto.ch > <mailto: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: >> <t:loop source=“countries” value=“var:country”> >> ${var:country.getName(locale)} - ${getPopulation(var:country)} >> </t:loop> >> >> 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 >> >> <t:loop source=“countries” value=“var: tempValue”> >> ${tempValue.getName(locale)} - ${getPopulation(tempValue)} >> </t:loop> >> >> 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! >> >> >> <http://www.dfacto.ch/ <http://www.dfacto.ch/>> Numa Schmeder >> www.dfacto.ch <http://www.dfacto.ch/> < >> http://www.dfacto.ch/ <http://www.dfacto.ch/>> >> n...@dfacto.ch <mailto:n...@dfacto.ch> <mailto:n...@dfacto.ch >> <mailto:n...@dfacto.ch>> | M +41 79 538 30 01 >> >> DIGITAL STRATEGY | DESIGN | DEVELOPMENT >> >> >> >> >> > > -- > Thiago
