Tapestry 5
  1. Tapestry 5
  2. TAP5-619

Add parameter to PropertyEditor to allow custom BeanBlockSource to be used in place of the default one

    Details

    • Type: Wish Wish
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 5.1.0.1
    • Fix Version/s: 5.1.0.3
    • Component/s: tapestry-core
    • Labels:
      None

      Description

      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.

        Activity

        Hide
        Howard M. Lewis Ship added a comment -

        Changing the @Inject to a @Parameter with a default will solve this problem.

        I'm nervous about making the framework any more baroque than it has to be ... it's a slippery slope.

        Show
        Howard M. Lewis Ship added a comment - Changing the @Inject to a @Parameter with a default will solve this problem. I'm nervous about making the framework any more baroque than it has to be ... it's a slippery slope.
        Hide
        Alfie Kirkpatrick added a comment -

        Thanks. Am already aware of overrides. In this case I do not know the specific field names. I want to map property types to custom edit blocks. And I am already past beaneditform and beaneditor. I want to create a component around propertyeditor directly...

        I perhaps could do something cludgy with overrides (will check) but already have customisations around beanblocksource, hence the request.

        I can probably hack around this by appending my property types with some custom string like *SEARCHMODE* and then checking for this in my beanblockoverridesource, but setting a specific beanblocksource on propertyeditor would be much more elegant

        Perhaps I should have raised this on the mailing list first. If I have followed the wrong protocol please let me know, but I saw this as a relatively simple and clear cut wishlist request. Regards.

        Show
        Alfie Kirkpatrick added a comment - Thanks. Am already aware of overrides. In this case I do not know the specific field names. I want to map property types to custom edit blocks. And I am already past beaneditform and beaneditor. I want to create a component around propertyeditor directly... I perhaps could do something cludgy with overrides (will check) but already have customisations around beanblocksource, hence the request. I can probably hack around this by appending my property types with some custom string like * SEARCHMODE * and then checking for this in my beanblockoverridesource, but setting a specific beanblocksource on propertyeditor would be much more elegant Perhaps I should have raised this on the mailing list first. If I have followed the wrong protocol please let me know, but I saw this as a relatively simple and clear cut wishlist request. Regards.
        Hide
        Thiago H. de Paula Figueiredo added a comment -

        Hi!

        You can use property error overrides:

        <t:beaneditform object="loginCredentials">
        <t:parameter name="password">
        <t:label for="password"/>
        <t:passwordfield t:id="password" value="loginCredentials.password"/>
        </t:parameter>
        </t:beaneditform>

        http://tapestry.formos.com/nightly/tapestry5/guide/beaneditform.html

        Another solution is to use BeanEditor instead of BeanEditForm (easy transition) and its overrides parameter.

        Show
        Thiago H. de Paula Figueiredo added a comment - Hi! You can use property error overrides: <t:beaneditform object="loginCredentials"> <t:parameter name="password"> <t:label for="password"/> <t:passwordfield t:id="password" value="loginCredentials.password"/> </t:parameter> </t:beaneditform> http://tapestry.formos.com/nightly/tapestry5/guide/beaneditform.html Another solution is to use BeanEditor instead of BeanEditForm (easy transition) and its overrides parameter.
        Hide
        Alfie Kirkpatrick added a comment -

        Hi Thiago, I take your points but just for the record, while BeanBlockSource can be overridden, currently the same service is injected in all cases. I want to specify a particular BeanBlockSource instance for a particular PropertyEditor in my page. PropertyEditor is not classed as 'internal' so I don't see a problem in principle with this as a wishlist item...

        Show
        Alfie Kirkpatrick added a comment - Hi Thiago, I take your points but just for the record, while BeanBlockSource can be overridden, currently the same service is injected in all cases. I want to specify a particular BeanBlockSource instance for a particular PropertyEditor in my page. PropertyEditor is not classed as 'internal' so I don't see a problem in principle with this as a wishlist item...
        Hide
        Thiago H. de Paula Figueiredo added a comment -

        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

        Show
        Thiago H. de Paula Figueiredo added a comment - 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

          People

          • Assignee:
            Howard M. Lewis Ship
            Reporter:
            Alfie Kirkpatrick
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development