Labs
  1. Labs
  2. LABS-352

[refactoring][beanview] Carve single mode creation pieces out of producers

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: Current
    • Fix Version/s: Current
    • Component/s: Magma
    • Labels:
      None

      Description

      With LABS-351 we have intermediate types that can be inferred instead of more generic types like String, byte[] or streams.

      Now we need to implement a way to have beansview pieces to cope with them.

      This should be done in a pluggable way. Most importantly, pluggability is needed to extend both ShowBean and ShowList (and conseguently form and paginated list) customization.

      Right now, ShowBean delegates to a createMain method the creation of the inner content of a leaf in the ViewTree, the form producer then further delegates to specific methods to create drodowns, textareas etc..

      Similarly, ShowList delegates to createFieldNodeCell method, which is a bit less clean than createMain.

      Probably, we could refactor these methods a bit to give a clear path for extension using AspectJ around advices. For example, to handle file uploads, an around advice on createMain could intercept when the node contains a File intermediate type and output an upload field in the form or a link for downloading the file in a showbean.

      A similar approach should be taken for form binding, cause the two will most probably go in pairs.

      The final objective could be to declare an abstract aspect to customize appearance of certain intermediate types in lists, showbeans and forms, and parsing of incoming parameters for forms binding.

      Such aspects could then be implemented to support different form/display technologies, like JSF.

        Activity

        Hide
        Simone Gianni added a comment -

        The system is in place and works correctly.

        We still need an annotation to :

        • specify a specific class for input/output
        • specify a style property, similar to that of formatters, to permit different formats for output/form input
        Show
        Simone Gianni added a comment - The system is in place and works correctly. We still need an annotation to : specify a specific class for input/output specify a style property, similar to that of formatters, to permit different formats for output/form input
        Hide
        Simone Gianni added a comment -

        A lot of stuff has evolved in the mean time.

        Let's redefine the scope of this issue better.

        LABS-494 is evolving to use the dynamic configuration system ( LABS-365 ) to provide a simple way for the user to customize rendering. While this could eventually also provide a way to generate custom form fields or alter the default way a field is displayed (complete access to the bean and property value could be permitted), it is intended primarily for customizing the "external" part of the layout, like for example wrapping in an additional div, or similar stuff.

        This bug is related to "meta types", like a rich text or an uploaded file etc.. which need to be rendered with a custom HTML.

        There are already two layers regarding "rendering" the value of a field : converters for bidirectional machine read-write, formatters for bidirectional and localized human read-write. These layers both work on plain strings.

        When these "meta types" comes into play, however, a string is not sufficient, cause we need to create custom HTML for display in show bean and lists, custom HTML for editing in forms, and a custom binding for forms that goes in pair with the custom HTML.

        We don't expect users to customize these "internals". If they really need to, they can use the system that is evolving in LABS-494, or write a custom aspect.

        So, using service discovery, will make the whole system slower giving no real feature.

        Going back to aspects, problems outlined in the previous comments still exist, but there could be a way out.

        Currently each BeanData contains a number of PropertyInfo objects. These have toString that is used by converters, and toUser that is used by formatters. PropertyInfo objects are created once and then cached (except in the future when LABS-232 will be implemented), so they should be fast.

        We could add methods to PropertyInfo to return propert HTML (or an instance that produces proper HTML), ans use it for this new layer, as much as it is already done with toString and toUser.

        To have a simpler way to hook aspects on these PropertyInfo, we could subclass them, and have one for each type we need to support. This could also remove the need for service discovery for formatters and converters, replacing them with an aspect returning the correct subclass of PropertyInfo.

        Show
        Simone Gianni added a comment - A lot of stuff has evolved in the mean time. Let's redefine the scope of this issue better. LABS-494 is evolving to use the dynamic configuration system ( LABS-365 ) to provide a simple way for the user to customize rendering. While this could eventually also provide a way to generate custom form fields or alter the default way a field is displayed (complete access to the bean and property value could be permitted), it is intended primarily for customizing the "external" part of the layout, like for example wrapping in an additional div, or similar stuff. This bug is related to "meta types", like a rich text or an uploaded file etc.. which need to be rendered with a custom HTML. There are already two layers regarding "rendering" the value of a field : converters for bidirectional machine read-write, formatters for bidirectional and localized human read-write. These layers both work on plain strings. When these "meta types" comes into play, however, a string is not sufficient, cause we need to create custom HTML for display in show bean and lists, custom HTML for editing in forms, and a custom binding for forms that goes in pair with the custom HTML. We don't expect users to customize these "internals". If they really need to, they can use the system that is evolving in LABS-494 , or write a custom aspect. So, using service discovery, will make the whole system slower giving no real feature. Going back to aspects, problems outlined in the previous comments still exist, but there could be a way out. Currently each BeanData contains a number of PropertyInfo objects. These have toString that is used by converters, and toUser that is used by formatters. PropertyInfo objects are created once and then cached (except in the future when LABS-232 will be implemented), so they should be fast. We could add methods to PropertyInfo to return propert HTML (or an instance that produces proper HTML), ans use it for this new layer, as much as it is already done with toString and toUser. To have a simpler way to hook aspects on these PropertyInfo, we could subclass them, and have one for each type we need to support. This could also remove the need for service discovery for formatters and converters, replacing them with an aspect returning the correct subclass of PropertyInfo.
        Hide
        Simone Gianni added a comment -

        Doing this via Aspects is a mess, for a number of reasons :

        • There is no static determinable way of seing the type of the property the view node represents, so the check should be done dynamically, introducing a certain degree of overhead
        • As a conseguence, creating abstract aspects then instantiated per type is not feasbile, or at least not easy at all
        • Even if it was easy, if two or more packages provide methods to format the same type there would be no clear way to determine which one should work :
          ... There is no way to determine if more than one is advicing the same method FOR THE SAME data type, cause of the runtime checks
          ... Precedences are a problem, cause they suppose you know other elements, so are not practical for completely dynamic systems.

        So, the preferred way is to use a service-like approach as the one used for converters and formatters. With the addition of contextualization to properties and service discovery ( LABS-365 ) this would bring contextualized configuration in this area in a uniform way with other components dealing with data types, while the standard system will naturally avoid duplicates, even if based on classpath loading which is not optimal (see LABS-366 ).

        Show
        Simone Gianni added a comment - Doing this via Aspects is a mess, for a number of reasons : There is no static determinable way of seing the type of the property the view node represents, so the check should be done dynamically, introducing a certain degree of overhead As a conseguence, creating abstract aspects then instantiated per type is not feasbile, or at least not easy at all Even if it was easy, if two or more packages provide methods to format the same type there would be no clear way to determine which one should work : ... There is no way to determine if more than one is advicing the same method FOR THE SAME data type, cause of the runtime checks ... Precedences are a problem, cause they suppose you know other elements, so are not practical for completely dynamic systems. So, the preferred way is to use a service-like approach as the one used for converters and formatters. With the addition of contextualization to properties and service discovery ( LABS-365 ) this would bring contextualized configuration in this area in a uniform way with other components dealing with data types, while the standard system will naturally avoid duplicates, even if based on classpath loading which is not optimal (see LABS-366 ).
        Hide
        Simone Gianni added a comment -

        The showbean, showlist and form classes should be mostly "empty", providing only the outside structure but nearly no content (or a very basic default content), and also currently supported controls and outputs (dropdowns, buttons, radiobuttons, etc..) should be repackaged in separate aspects.

        It would be nice to have abstract aspects to do this, to avoid having many places where the same pointcut/aroud advice is written.

        Anyway basic tests bring to a number of considerations :

        • There is no way to specify an abstract pointcut to select the type of the property in the view tree node, this is because the check is runtime and cannot be made static, since a static method would not be extensible.
        • Having such a checkType method as a private method of the aspect is possible, but could impact performances.
        • Many of these "plugins" will need to work on internal data provided by the object they are working on. Expecially for forms, access to a number of fields is required. This means that methods should be ITDed to the original class, a reference to the original object passed, and the method called there. Nothing expecially bad with it, but care should be taken for performance.
        • Since these plugins are going to ITD methods, they will not be extensible, not a problem since an aspect is not extensible itself, but can be extended with other aspects.
        Show
        Simone Gianni added a comment - The showbean, showlist and form classes should be mostly "empty", providing only the outside structure but nearly no content (or a very basic default content), and also currently supported controls and outputs (dropdowns, buttons, radiobuttons, etc..) should be repackaged in separate aspects. It would be nice to have abstract aspects to do this, to avoid having many places where the same pointcut/aroud advice is written. Anyway basic tests bring to a number of considerations : There is no way to specify an abstract pointcut to select the type of the property in the view tree node, this is because the check is runtime and cannot be made static, since a static method would not be extensible. Having such a checkType method as a private method of the aspect is possible, but could impact performances. Many of these "plugins" will need to work on internal data provided by the object they are working on. Expecially for forms, access to a number of fields is required. This means that methods should be ITDed to the original class, a reference to the original object passed, and the method called there. Nothing expecially bad with it, but care should be taken for performance. Since these plugins are going to ITD methods, they will not be extensible, not a problem since an aspect is not extensible itself, but can be extended with other aspects.

          People

          • Assignee:
            Simone Gianni
            Reporter:
            Simone Gianni
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development