You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Eric Norman (Jira)" <ji...@apache.org> on 2021/07/16 17:45:00 UTC

[jira] [Resolved] (SLING-10610) Support the @ValueFrom suffix for the :name and :nameHint parameters

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

Eric Norman resolved SLING-10610.
---------------------------------
    Resolution: Fixed

No objections were raised, so merged the PR at:  [{{cd158e8}}|https://github.com/apache/sling-org-apache-sling-servlets-post/commit/cd158e8c812e5aeb3edfec57f7a88547b594d734] 

> Support the @ValueFrom suffix for the :name and :nameHint parameters
> --------------------------------------------------------------------
>
>                 Key: SLING-10610
>                 URL: https://issues.apache.org/jira/browse/SLING-10610
>             Project: Sling
>          Issue Type: New Feature
>            Reporter: Eric Norman
>            Assignee: Eric Norman
>            Priority: Major
>             Fix For: Servlets POST 2.4.6
>
>          Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Currently the :name and :nameHint properties are not considering or handling the @ValueFrom suffix. This makes reusing the same text for some property and the :name/:nameHint value require a form that uses the @ValueFrom suffix on the other field and looks something like this:
>  
> {code:java}
> <form method="POST" action="/content/page" enctype="multipart/form-data">
>     <input type="hidden" name="message@ValueFrom" value=":nameHint" />
>     <input type="text" name=":nameHint" />
>     <input type="Submit" />
> </form>
> {code}
> Notice that the :nameHint field is the one the user is typing the text into and the "message" field gets the same value.
>  
> This form structure seems counter intuitive as the "message" field is the one that would ultimately contain the text the user typed but the user is sending the text as the :nameHint parameter.
> Plus, consider the use case where you have a create and update script for a resource that are nearly identical except for how you are defining the name.  Having this field juggling in the create script makes it more difficult to reuse that form as the create and update forms would require different logic.
> If the :name and :nameHint handling supported and handled the @ValueFrom suffix, then the script could be more intuitive and easier to re-use the common parts for the create/update scenario.
> For example:
> {code:java}
> <form method="POST" action="/content/page" enctype="multipart/form-data">
>   <input type="hidden" name=":nameHint@ValueFrom" value="message" />
>   <input type="text" name="message" />
>   <input type="Submit" />
> </form>
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)