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