I haven't touched our FM code in over a decade... but IIRC, what I had done
was to implement a custom Properties class.
Then our vars are stored in an instance of this (instead of
java.util.Properties).

The reason we needed it was that in our code, our end users are defining
variables, values and templates.
These are non-tech users, so we needed to check multiple places for
variables in our backend.
The custom properties `get` methods would do that.

Try this out -- if it doesn't work, I can go locate the codebase.

On Tue, Sep 19, 2023 at 2:55 AM Christoph Rüger <c.rue...@synesty.com>
wrote:

> Am Di., 19. Sept. 2023 um 08:51 Uhr schrieb Renny Koshy <rko...@gmail.com
> >:
>
> > You could also add your own variable resolution code.
>
>
> Thanks. Interesting. Any hint or link to github source code where to add
> this?
>
>
> > If it can't find the
> > variable, then resolve that as the template string for that variable. So
> > "myvar" resolves to "${myvar}" if it can't be found
> >
> > On Mon, Sep 18, 2023, 7:24 PM Christoph Rüger <c.rue...@synesty.com>
> > wrote:
> >
> > > Am Mo., 18. Sept. 2023 um 19:55 Uhr schrieb Alon Ziv
> > > <nola...@google.com.invalid>:
> > >
> > > > I'm not sure such automatic behavior is feasible.
> > > >
> > > > Consider e.g. a template like
> > > ${conditionVariable?then(dateVariable?iso_local("Europe/Rome"),
> > > > "UNKNOWN")}
> > > > What would the automatic logic do if conditionVariable is null, but
> > > > dateVariable is set? Or the opposite? (Sure, we may construct
> > equivalent
> > > > expressions for such cases - but it's really complex, and I don't
> > believe
> > > > it's feasible in the *general* case).
> > > >
> > >
> > > I guess you are right. Just wanted to put that up for brainstorming.
> > > It just came up during discussion today, and there were ideas like
> > "could
> > > we just use reg-ex to extract the parts we can render in phase 1" and
> the
> > > rest in phase2. etc. So I thought I might ask here for alternatives :)
> > >
> > > In our case we have much control over the variables which are allowed
> to
> > > be inserted in the templates string. So we could at least validate that
> > > people do enter complex expressions, but just use simple pre-defined
> > > variables.
> > >
> > > I think ${variableB!r"${variableB}"} is a good approach so far. We may
> > > construct that under the hood somehow and let people automatically
> insert
> > > this variable-text on click.
> > >
> > > Anyway, thanks for the ideas :)
> > >
> > >
> > > >
> > > > On Mon, Sep 18, 2023 at 8:32 PM Christoph Rüger <
> c.rue...@synesty.com>
> > > > wrote:
> > > >
> > > >> Am Mo., 18. Sept. 2023 um 18:12 Uhr schrieb Alon Ziv
> > > >> <nola...@google.com.invalid>:
> > > >>
> > > >> > You can achieve this via template magic already:
> > > >> >
> > > >> > ${variableB!r"${variableB}"}
> > > >> >
> > > >>
> > > >> Thanks, good to know.
> > > >> But I am looking for something where the template does not need to
> be
> > > >> changed.
> > > >> Basically this behavior but automatically done.
> > > >>
> > > >>
> > > >> >
> > > >> > On Mon, Sep 18, 2023 at 7:03 PM Christoph Rüger <
> > c.rue...@synesty.com
> > > >
> > > >> > wrote:
> > > >> >
> > > >> >> Hi,
> > > >> >> we may have a rather special case and are looking for ideas.
> > > >> >> We would like to to keep the placeholders as they are in case of
> > null
> > > >> >> values.
> > > >> >>
> > > >> >> Assume the following template:
> > > >> >>
> > > >> >> ${metaHeaderDataA}
> > > >> >> ${variableB}
> > > >> >>
> > > >> >> We would like the following behavior:
> > > >> >>
> > > >> >> *1st render phase:*
> > > >> >> data.put("metaHeaderDataA", "foo")
> > > >> >> environment.process(template);
> > > >> >>
> > > >> >> Expected Output:
> > > >> >> foo
> > > >> >> ${variableB}
> > > >> >>
> > > >> >> The we want to render this output again with:
> > > >> >>
> > > >> >> *2nd render phase:*
> > > >> >> data.put("variableB", "bar")
> > > >> >> environment.process(template);
> > > >> >>
> > > >> >> Expected final Output:
> > > >> >> foo
> > > >> >> bar
> > > >> >>
> > > >> >> As you see there 2 two rendering phases involved. In phase 1 only
> > > some
> > > >> >> variables are known (metaHeaderDataA).
> > > >> >> The other variables come later.
> > > >> >> We would like keep the placeholders in the 1st rendering phase,
> if
> > > >> there
> > > >> >> is
> > > >> >> no value or null value in the data model, so that they can be
> > > rendered
> > > >> >> later.
> > > >> >>
> > > >> >> I think this is very special.
> > > >> >> So I am just  thinking, is this something which could
> > (theoretically)
> > > >> be a
> > > >> >> configurable option maybe on a per-Template-object level (Java
> > Code)?
> > > >> Or
> > > >> >> is
> > > >> >> this something impossible to do?
> > > >> >>
> > > >> >> Or any other workaround ideas?
> > > >> >>
> > > >> >>
> > > >> >> Thanks
> > > >> >> Christoph
> > > >> >>
> > > >>
> > > >>
> > >
> > > --
> > > Synesty GmbH
> > > Berggasse 1
> > > 07745 Jena
> > > Tel.: +49 3641 5596493Internet:
> > > https://synesty.com <https://synesty.com>
> > > Informationen zum Datenschutz:
> > > https://synesty.com/datenschutz <https://synesty.com/datenschutz>
> > >
> > > Geschäftsführer: Christoph Rüger
> > > Unternehmenssitz: Jena
> > > Handelsregister B
> > > beim Amtsgericht: Jena
> > > Handelsregister-Nummer: HRB 508766
> > > Ust-IdNr.:
> > > DE287564982
> > >
> >
>
>
> --
> Christoph Rüger, Geschäftsführer
> Synesty <https://synesty.com/> - Anbinden und Automatisieren ohne
> Programmieren
>
> --
> Synesty GmbH
> Berggasse 1
> 07745 Jena
> Tel.: +49 3641 5596493Internet:
> https://synesty.com <https://synesty.com>
> Informationen zum Datenschutz:
> https://synesty.com/datenschutz <https://synesty.com/datenschutz>
>
> Geschäftsführer: Christoph Rüger
> Unternehmenssitz: Jena
> Handelsregister B
> beim Amtsgericht: Jena
> Handelsregister-Nummer: HRB 508766
> Ust-IdNr.:
> DE287564982
>

Reply via email to