The way I see it, Java developers usually don't know much about FreeMarker
details like how certain methods can be accessed in the template language
(i.e., as a method, as a sub-variable, etc,). But they know which plain
Java methods they want to make accessible ("expose") for templates from
security/maintainability reasons. That's why it's better that that's the
first step. After that, if someone actually writes templates, and is
annoyed by how some members are accessed in the template language by
default, then there's a context and motivation to look into FreeMarker
details, and hopefully find the desired settings.On Sun, Apr 21, 2024 at 4:51 AM Simon Hartley <scrhart...@yahoo.co.uk.invalid> wrote: > I don't know if it makes sense given the method fine tuning stuff, but > here are two approaches: > 1. First choose which methods are exposed and then choose how they can be > accessed in the template, > i.e. which ones are "properties" (i.e. hash items) > 2. First determine what methods we are going to treat as properties and > then do exposure afterwards (methods and/or properties) > > Would it be clearer to rename in ZeroArgumentNonVoidMethodPolicy > so BOTH_PROPERTY_AND_METHOD becomes BOTH_HASH_ITEM_AND_METHOD ? > > For exposureLevel, we could choose to split it by adding > recordExposureLevel (defaulting to USE_DEFAULT or UNSET, with a value of > e.g. -1), > rather than adding a million variations to the existing exposureLevel > flags. > > Cheers, > Simon > > > > > On Sunday, 14 April 2024 at 12:43:50 BST, Daniel Dekany < > daniel.dek...@gmail.com> wrote: > > > > > > There's no "EXPOSE" variant for that, at the moment. We had to add > something like EXPOSE_PROPERTIES_ONLY_EXCEPT_FOR_RECORDS_AND_VALUE_TYPES, > though with a less comical and more future-proof name. > > On Sun, Apr 14, 2024 at 12:29 PM Simon Hartley > <scrhart...@yahoo.co.uk.invalid> wrote: > > > > I experimented with setting: > > exposureLevel=freemarker.ext.beans.BeansWrapper.EXPOSE_PROPERTIES_ONLY > > > > This seems to prevent records from using anything but the bean > properties, > > so the components in the record don't get exposed as hash items. > > Is there some equivalent so that I could have beans act just as beans > > and records act just (more or less) as records (at least as a plan for > the future)? > > Or to filter out methods which don't conform to > ZeroArgumentNonVoidMethodPolicy (plus indexed methods)? > > > > Cheers, > > Simon > > > > > > > > > > On Thursday, 11 April 2024 at 09:42:02 BST, Daniel Dekany < > daniel.dek...@gmail.com> wrote: > > > > > > > > > > > > > So what I plant to do is renaming things to something like these > > > (suggestion for better names are welcome): > > > > > > ZeroArgumentNonVoidMethodPolicy.BEAN_AWARE_THEN_EXPOSE_AS_METHOD > > > ZeroArgumentNonVoidMethodPolicy.BEAN_AWARE_THEN_EXPOSE_AS_PROPERTY > > > > ZeroArgumentNonVoidMethodPolicy.BEAN_AWARE_THEN_EXPOSE_AS_PROPERTY_AND_METHOD > > > > > > And then maybe I would also add policies where we don't care about > > > bean stuff, as it should be in theory with records. I don't think many > > > user will want such a purist approach, but it can be useful in > > > ensuring that our implementation is sound (because then it should be > > > possible to implement such a policy). > > > > -- > Best regards, > > Daniel Dekany > -- Best regards, Daniel Dekany
