You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tapestry.apache.org by "Jochen Kemnade (JIRA)" <ji...@apache.org> on 2015/01/12 09:11:07 UTC

[jira] [Closed] (TAP5-886) BeanEditor/PropertyEditor refactor for easy customization/extension

     [ https://issues.apache.org/jira/browse/TAP5-886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jochen Kemnade closed TAP5-886.
-------------------------------
    Resolution: Invalid

We assume this is no longer relevant and therefore close it.
If you still have this issue in a recent Tapestry version (such as 5.3.8 or the latest 5.4 preview release), feel free to provide the necessary information and reopen.

> BeanEditor/PropertyEditor refactor for easy customization/extension
> -------------------------------------------------------------------
>
>                 Key: TAP5-886
>                 URL: https://issues.apache.org/jira/browse/TAP5-886
>             Project: Tapestry 5
>          Issue Type: Improvement
>          Components: tapestry-core
>            Reporter: Giulio Micali
>            Priority: Minor
>
> Problem Description:
> This post is derived from my wish to write a custom improved BeanEditor component, extending its behaviour to manage read-only properties, excluding all attributes of one or more parent classes of my bean, ecc...
> I tried to write that component, but I found that I should override(alias duplicating) too many components/services involved in the process:
> A) the BeanModelSource service: 
> I had overridden the createEditModel() in order to call create(beanClass, false, messages); to view the read-only properties.
> B) the BeanBlockSource service: 
> the "edit blocks" contains the editor, but also the label: the worst problem stays here, forcing the layout of the container(BeanEditor or MyBeanEditor) in a too much restricted way.
> C) the propertyEditor:
> this component gets the model from BeanModelSource and the (default)block to render from BeanBlockSource:
> - it doesn't know if a property is "read only", so if I override the BeanModelSource to get read only properties, it cannot discriminate them and render always a form control.
> - the Block interface does not expose it's children list, so I cannot use a dirty-workaround to remove the "label" component at rendering time
> D) MyBeanEditor (obviously): 
> here I will rewrite the template, extend the original POJO with custom modifications, ecc...
> but to do so, I have to do the overrides described above.
> Too many things to override.
> Suggested Solution:
> 1) the BeanModelSource service
> - the returned PropertyModel must have a boolean "writable" property, taken from PropertyAdapter.isUpdate().
> - the createEditModel() method is no longer useful, beanEditor must call directly BeanModelSource.create(model, !BeanEditor.displayReadOnly, messages).
> 2) the BeanBlockSource service
> - the "label" component must be detached from the "editor" block and should have it's own block "<myProperty>Label" (like the grid component header) with default value <t:label for="myEditor"/>
> With that change, we can use propertyEditor inside other components(like grid or custom components)
> 3) the propertyEditor:
> - if a property is read-only, the editor (default)block will be taken from the BeanDisplay-related blocks.
> - (optional) can have a parameter "disabled" (tipically the BeanEditor can pass it's own value): the value will "mark" at runtime the property as read-only, overriding the value from BeanModel.
> 4) BeanEditor
> the BeanEditor must:
> - add a boolean parameter "displayReadOnly", which affects the call to BeanModelSource.create(model, !displayReadOnly, messages);
> - provide by itself the "label block" just like the BeanDisplay component(a base class for that will be the best) getting it from the BeanBlockSource service. 
> - if a property is read-only, the label block will be taken from the BeanDisplay-related block.
> - both label and editor block will be overridable just with the "overrides" behaviour.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)