[
https://issues.apache.org/jira/browse/LABS-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708294#action_12708294
]
Simone Gianni commented on LABS-352:
------------------------------------
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.
> [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]
