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

        Mark Struberg created issue -
        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
        Gerhard Petracek made changes -
        Field Original Value New Value
        Assignee Mark Struberg [ struberg ] Gerhard Petracek [ gpetracek ]
        Gerhard Petracek made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        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 -

        @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
        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"
        Gerhard Petracek made changes -
        Status In Progress [ 3 ] Resolved [ 5 ]
        Fix Version/s 1.0.0 [ 12316424 ]
        Resolution Fixed [ 1 ]
        Gerhard Petracek made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open In Progress In Progress
        4d 23h 37m 1 Gerhard Petracek 13/May/11 11:25
        In Progress In Progress Resolved Resolved
        4d 11h 43m 1 Gerhard Petracek 17/May/11 23:09
        Resolved Resolved Closed Closed
        49d 13h 31m 1 Gerhard Petracek 06/Jul/11 12:40

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development