MyFaces CODI
  1. MyFaces CODI
  2. EXTCDI-174

Introduce @PropertyActivated or @ConfigActivated

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.0.0
    • Component/s: Core
    • Labels:
      None

      Description

      While at JAX, I got pretty often asked if there is a way to configure <alternatives> automatically via configuration. I pointed them to @ProjectStageActivated and this solved 60% of the problems.
      But there are pretty often more complex scenarios where users like to switch between e.g. database vendors based on an external configuration.

      This could e.g. be a normal java properties file and something like

      @PropertyActivated("user.databyse", "mysql")
      

      where the first parameter is the name and the 2nd is the value which must be set.

      Please add further ideas for ways to change those configurations.

      The actual implementation should be trivial as we have most of the work done already in ProjectStageActivationExtension.

        Activity

        Hide
        Gerhard Petracek added a comment -

        name of the annotation: @ExpressionActivated

        supported expressions:

        "key1==value1;key2!=value2"

        and it's possible to mark required keys - e.g.:
        "key2==*;key2!=value2"

        Show
        Gerhard Petracek added a comment - name of the annotation: @ExpressionActivated supported expressions: "key1==value1;key2!=value2" and it's possible to mark required keys - e.g.: "key2==*;key2!=value2"
        Hide
        Gerhard Petracek added a comment -

        @PropertyActivated("user.database", "mysql") is imo too error prone

        "any expression" is a placeholder. by default i would suggest to support
        @ActivatedOn("user.database==mysql;property2==value2")
        later on we can extend the syntax e.g. to
        @ActivatedOn("user.database==mysql || property2==value2")
        that isn't possible with your @PropertyActivated suggestion.
        by default it is as easy as your suggestion! and if an >advanced< user would like to extend the syntax s/he can simply do it by providing a custom interpreter implementation.
        so we don't have to support all edge cases.

        Show
        Gerhard Petracek added a comment - @PropertyActivated("user.database", "mysql") is imo too error prone "any expression" is a placeholder. by default i would suggest to support @ActivatedOn("user.database==mysql;property2==value2") later on we can extend the syntax e.g. to @ActivatedOn("user.database==mysql || property2==value2") that isn't possible with your @PropertyActivated suggestion. by default it is as easy as your suggestion! and if an >advanced< user would like to extend the syntax s/he can simply do it by providing a custom interpreter implementation. so we don't have to support all edge cases.
        Hide
        Mark Struberg added a comment -

        Interpreter is a neat idea, but most probably way to complicated for casual users. Also the name should really match with the already existing @ProjectStageActivated.

        Btw, what do you mean with 'any expression' ?

        Show
        Mark Struberg added a comment - Interpreter is a neat idea, but most probably way to complicated for casual users. Also the name should really match with the already existing @ProjectStageActivated. Btw, what do you mean with 'any expression' ?
        Hide
        Gerhard Petracek added a comment -

        suggestion:

        @ActivatedOn("any expression")

        ... by default it would be interpreted by ConfiguredValueInterpreter which delegates to the existing ConfiguredValueResolver (which also allows to add custom resolvers to the lookup chain).

        as an alternative it would be possible to overrule the default interpreter via:

        @ActivatedOn(value = "any expression", interpreter = CustomInterpreter.class)

        -> per default it's simple but still very extensible

        Show
        Gerhard Petracek added a comment - suggestion: @ActivatedOn("any expression") ... by default it would be interpreted by ConfiguredValueInterpreter which delegates to the existing ConfiguredValueResolver (which also allows to add custom resolvers to the lookup chain). as an alternative it would be possible to overrule the default interpreter via: @ActivatedOn(value = "any expression", interpreter = CustomInterpreter.class) -> per default it's simple but still very extensible

          People

          • Assignee:
            Gerhard Petracek
            Reporter:
            Mark Struberg
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development