Okay, that makes sense except for this bit:

> Especially strange would be if I had an expression like "${foo.bar?}baz" and the default value for the property gets put in;

For one this wouldn't work and I don't think we want it to work, the default value will be put in only if the attribute resolution is empty (or if it's the reserved string if we're going with that), so "${foo.bar?}baz" would resolve to "baz". We're not looking for a way to "inject" the default value, we want the attribute definition to use its default value because the user didn't provide anything (as far as the definition is concerned). As such the optional expression doesn't make sense in any kind of nested context.

At least that's my impression,
@jdenise, do you want to weigh in? I don't want to misinterpret the intended usage.


On Fri, Sep 10, 2021 at 6:13 PM David Lloyd <david.lloyd@redhat.com> wrote:
I get that and I agree that the syntax is more concise. However I don't like that it doesn't integrate with the syntax parsing of expressions themselves (this can lead to unexpected interactions), and I also don't like that it is different from the way that expressions normally function with respect to the fact that property expressions generally resolve based on locally-available information. The syntax really makes one think that it's something happening at the property expression parsing level. I'd expect something like `${foo.bar?}` to have a behavior based only on aspects of the `foo.bar` expression itself; to have it default to some non-local value based on the *context* of the expression is really pretty unexpected in my opinion.  Especially strange would be if I had an expression like "${foo.bar?}baz" and the default value for the property gets put in; at least if I have "${foo.bar:${default}}baz" or even "${default}baz", I can understand what's happening a little more clearly (i.e. that it's a concatenation and nothing more, not some kind of operator or something).

Having a reserved property name for the default value not only integrates cleanly with the expression parser, but it's also something that we could potentially carry over to Quarkus, SmallRye Config, or other tools which use expressions for configuration.

On Fri, Sep 10, 2021 at 11:00 AM Michal Petrov <mpetrov@redhat.com> wrote:
Well I guess we can either have a custom syntax for the optional expression or a custom syntax (reserved string) for the default value, I went with an option that is more concise.

On Thu, Sep 9, 2021 at 2:50 PM David Lloyd <david.lloyd@redhat.com> wrote:
Yes that would be a problem.  Mainly I'm trying to think of an alternative solution that doesn't involve a custom syntax though. Maybe a special variable called "default" could be used e.g. `${foo.bar:${default}}`? Is that too convoluted?

On Thu, Sep 9, 2021 at 6:23 AM Michal Petrov <mpetrov@redhat.com> wrote:
It's not, the attribute definition method would still have to be changed. But it would no longer be possible to set the attribute value to an empty string using this expression, isn't that a problem?

On Tue, Sep 7, 2021 at 6:55 PM David Lloyd <david.lloyd@redhat.com> wrote:
I think the proposed functionality should already mostly be present, as you can supply an empty default value. For example "${foo.bar:}" will not throw an exception if `foo.bar` is missing but rather return an empty string. Is an empty string sufficient to yield the default value of an attribute?

On Tue, Sep 7, 2021 at 11:32 AM Michal Petrov <mpetrov@redhat.com> wrote:
Hi,

I'm looking for feedback on my issue - https://issues.redhat.com/browse/WFCORE-5339, analysis document at https://github.com/wildfly/wildfly-proposals/pull/423

Thanks,
Michal
_______________________________________________
wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s


--
- DML • he/him


--
- DML • he/him


--
- DML • he/him