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

Thiago H. de Paula Figueiredo closed TAP5-619.
----------------------------------------------

    Resolution: Won't Fix

BeanBlockSource, is any other Tapestry service, is already overridable. 

To reorder or remove properties from a BeanEditForm, you can use the reorder 
and exclude parameters.

By the way, Howard already stated in the mailing list that:

"(...) Grid and BeanEditForm are intended as 
scaffolding to get you up and running quick.  As your application gets 
refined, you may start to pull apart the scaffolding components to 
build something more precisely tuned to your specific requirements. It 
is not my intention that we should keep layering on more parameters 
and models and such to make BeanEditForm and Grid the be-all and 
end-all of editting and display components; they're really about 
keeping momentum going, especially during the early, frustrating parts 
of writing an application: those first few steps."

http://www.nabble.com/Tabindex-and-accesskey-in-BeanEditForm--td22380749s302.html#a22420266


> Provide way to override PropertyEditor.beanBlockSource
> ------------------------------------------------------
>
>                 Key: TAP5-619
>                 URL: https://issues.apache.org/jira/browse/TAP5-619
>             Project: Tapestry 5
>          Issue Type: Wish
>          Components: tapestry-core
>    Affects Versions: 5.1.0.1
>            Reporter: Alfie Kirkpatrick
>            Priority: Minor
>
> I am building a search form and would like to override the default edit 
> blocks with search-style ones. This is conjunction with a HashMap<String, 
> Object> backed bean model. As an example, for dates I want to have a date 
> range block which sends back a start/end range for a date, possibly as a 
> DateRangeSearchTerm against the property name in the hashmap. The search 
> implementation will then know how to convert this into a query to the backend.
> I might be pushing the whole BeanEditModel/Conduit framework further than 
> intended? However, doing it this way provides some nice ways to override an 
> auto-built form, eg. by restricting/reordering the properties or by 
> overriding specific blocks even further.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to