Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 1.1.0.M3
    • Fix Version/s: 1.1.0.RC1
    • Component/s: WEB MVC
    • Labels:
      None

      Description

      The current M3 Converter scaffolding is suboptimal.
      Converters are created in every controller for the same classes.
      If you need to rework a converter for an entity, you need to push-in all converters for this entity in all affected controllers.

      From our point of view, a better approach (dry) is:

      • a default converter should be provided by the entity.
      • on application startup, the GenericConversionService should register all converters in the entities.
      • additionally, it should be possible to add/replace converters in specific controllers to be as flexible as possible.

      Another approach would be, to introduce a conversion object for each entity in the web layer if you do not want to mix presentation with persistence layer.

      Description described above would possibly also fix ROO-1387

        Issue Links

          Activity

          Hide
          Stefan Schmidt added a comment -

          Robert,

          The converters are part of the controller because their only purpose is to improve the display labels of drop down select boxes in MVC scaffolded views. We have done this to keep separation between the toString() method on domain objects (which as previously used for drop down labels) and UI concerns. As such I don't think it is a good idea to move these UI specific converters into the domain layer. In normal circumstances I would expect that there is one (or maximum two) controllers for each domain object so the amount of 'extra' work is manageable IMO.

          ROO-1387 seems to be related to a bug in Spring Framework.

          -Stefan

          Show
          Stefan Schmidt added a comment - Robert, The converters are part of the controller because their only purpose is to improve the display labels of drop down select boxes in MVC scaffolded views. We have done this to keep separation between the toString() method on domain objects (which as previously used for drop down labels) and UI concerns. As such I don't think it is a good idea to move these UI specific converters into the domain layer. In normal circumstances I would expect that there is one (or maximum two) controllers for each domain object so the amount of 'extra' work is manageable IMO. ROO-1387 seems to be related to a bug in Spring Framework. -Stefan
          Hide
          Stefan Schmidt added a comment -

          I'll go ahead and close this issue given the explanations above.

          Show
          Stefan Schmidt added a comment - I'll go ahead and close this issue given the explanations above.
          Hide
          Harald Walker added a comment -

          Isn't it so that converters are unique in the web-application for given sourceType/targetType pairs?

          So if controller A and B both register a converter for the same entity only one is going to be used.

          I've seen this happen after I had pushed in a converter to customize it in controller A and when controller B was being used (with default ROO generated converter for the same entity) the customized converter of controller A was actually being called. Understandable but unexpected behavior.

          Show
          Harald Walker added a comment - Isn't it so that converters are unique in the web-application for given sourceType/targetType pairs? So if controller A and B both register a converter for the same entity only one is going to be used. I've seen this happen after I had pushed in a converter to customize it in controller A and when controller B was being used (with default ROO generated converter for the same entity) the customized converter of controller A was actually being called. Understandable but unexpected behavior.
          Hide
          Adam Chesney added a comment -

          I am experiencing the same issue. I had set @RooWebScaffold(registerConverters=false) on all of my controllers so that toString() is used instead of the custom converters for drop downs. However, then someone else added a new Controller to the project (without setting the registerConverters=false) and all of my pages that happen to use drop downs with the same Entities in as this new Controller suddenly revert to using the Converters registered by that new controller. This is definitely an issue. A converter added to a Controller aspect is used globally rather than just for that controller. Can we get it re-opened?

          As a workaround, I would be happy to register my own converters at start up, outside the scope of individual controllers. But, I'm not sure how to do that or even if it is possible?

          Show
          Adam Chesney added a comment - I am experiencing the same issue. I had set @RooWebScaffold(registerConverters=false) on all of my controllers so that toString() is used instead of the custom converters for drop downs. However, then someone else added a new Controller to the project (without setting the registerConverters=false) and all of my pages that happen to use drop downs with the same Entities in as this new Controller suddenly revert to using the Converters registered by that new controller. This is definitely an issue. A converter added to a Controller aspect is used globally rather than just for that controller. Can we get it re-opened? As a workaround, I would be happy to register my own converters at start up, outside the scope of individual controllers. But, I'm not sure how to do that or even if it is possible?
          Hide
          Stefan Schmidt added a comment -

          This issue is being addressed in ROO-1655 so I'll leave this as closed but you can rest assured that we are aware of this issue and will address it soon.

          Show
          Stefan Schmidt added a comment - This issue is being addressed in ROO-1655 so I'll leave this as closed but you can rest assured that we are aware of this issue and will address it soon.

            People

            • Assignee:
              Stefan Schmidt
              Reporter:
              Robert Oschwald
            • Votes:
              2 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: