[
https://issues.apache.org/jira/browse/LABS-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711229#action_12711229
]
Simone Gianni commented on LABS-352:
------------------------------------
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 ).
> [refactoring][beanview] Carve single mode creation pieces out of producers
> --------------------------------------------------------------------------
>
> Key: LABS-352
> URL: https://issues.apache.org/jira/browse/LABS-352
> Project: Labs
> Issue Type: Improvement
> Components: Magma
> Affects Versions: Current
> Reporter: Simone Gianni
> Assignee: Simone Gianni
> Fix For: Current
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
