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

["Jochen Kemnade (JIRA)" <ji...@apache.org>]

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

Jochen Kemnade updated TAP5-886:
--------------------------------


This issue has been last updated about 1.5 years ago and has no information about the versions that are affected. That makes it hard to determine whether it is still relevant.
If the issue still persists with the current stable version (5.3.7) or the most recent development preview of Tapestry (5.4-beta-6), both of which are available from Maven Central, please update it as soon as possible, adding the respective version(s) to the issue's "Affects Version/s".

> 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.2#6252)