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(a)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(a)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(a)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(a)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(a)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(a)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(a)lists.jboss.org
>>>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
>>>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>>>
>>>>
>>>>
>>>> --
>>>> - DML • he/him
>>>>
>>>
>>
>> --
>> - DML • he/him
>>
>
--
- DML • he/him