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
