You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Robert Zeigler (JIRA)" <ji...@apache.org> on 2011/06/26 01:31:47 UTC
[jira] [Created] (TAP5-1558) FormFragment should allow more fine
grained control over when to be considered "invisible"
FormFragment should allow more fine grained control over when to be considered "invisible"
------------------------------------------------------------------------------------------
Key: TAP5-1558
URL: https://issues.apache.org/jira/browse/TAP5-1558
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-core
Affects Versions: 5.3.0
Reporter: Robert Zeigler
Priority: Minor
The 5.2 line of Tapestry introduced the "alwaysSubmit" parameter to form fragment. This is nice because it allows the fragment to be submitted even if hidden. However, it doesn't cover all use cases. Consider a situation like:
<form>
<div id="tab1">...<t:formfragment ...><t:textfield validate="required".../></t:formfragment></div>
<div id="tab2">...<t:formfragment ...><t:textfield validate="required".../></t:formfragment></div>
<t:submit/>
</form>
User reveals tab 1, then reveals the form fragment on tab1 and makes changes. Now user reveals tab2. Note that the fragment on tab1 is still revealed in the context of tab1, but the entire tab1 is hidden. There is currently no way to make it so that "submit" will submit the information from the formfragment in both tabs and behave correctly in all situations. I will enumerate. Some definitions for clarity:
fragmentX is the fragment on tabX.
fragmentX visibility refers to the state of the actual fragment, rather than the state of the containing tab. So if fragment1 is visible, it means it's visible when tab1 is active... and I am considering it visible when tab2 is active, even though the entire tab1 is invisible.
1) If "alwaysSubmit" is false and fragment1 is invisible, you will get the correct behavior regardless of tab1/tab2 visibility
2) If "alwaysSubmit" is false and fragment1 is visible, you will get the correct behavior iff tab1 is active. If tab2 is active, fragment1's fields will not be submitted.
3) If "alwaysSubmit" is true and fragment1 is invisible, you will get incorrect behavior (well, technically, it's "correct": the information will be submitted, as per alwaysSubmit, but this is a case where you don't actually /want/ the information submitted if the fragment isn't visible)
4) If "alwaysSubmit" is true and fragment is visible, you will get correct behavior.
You can conditionally "alwaysSubmit": alwaysSubmit on the same condition for visibility as the "visible" trigger. The problem here comes in the following scenario:
User opens a page with fragment1 initially visible, but no data yet in the required field. User marks fragment1 as invisible. User submits the form. The submission will fail because "alwaysSubmit" was true at the time the form rendered.
The culprit behind this is Tapestry's "isDeepVisible" method. It searches for visibility up to the point where it finds a form element. But in the case above, the form element contains the tab divs, so the fragment is determined to be invisible and the data not submitted for the inactive tab, even if the user clicked on the trigger to make the fragment visible while the tab was active.
This is something of an edge case, but I think it can be handled cleanly by introducing a new parameter to formfragment, such as "visiblebound" (but better named!). The idea is to allow developers to specify an element or selector expression that bounds the search for visibility. The default would be the containing form element which would preserve the current behavior.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1558) FormFragment should allow more fine
grained control over when to be considered "invisible"
Posted by "Robert Zeigler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086340#comment-13086340 ]
Robert Zeigler commented on TAP5-1558:
--------------------------------------
Current behavior in 5.3, using the same "tab" scenario as above:
If both fragments are invisible at the first render, then you reveal fragment one on tab 1, then reveal tab 2 and reveal fragment 2 on tab 2, then the first submit, you will get correct behavior: both fragments will submit. But any subsequent render will not work; whichever tab is invisible when the page first renders will not submit it's form fragment (unless you re-hide & re-reveal it). Still happens because of the "isDeepVisible" search.
I'm wondering if instead of bounding the search, it would be enough to add a parameter for explicitly ignoring the parent visibility: "ignoreParentVisibility"; defaults to false to preserve the current behavior. It's a simpler solution that solves my use-case. But bounding the search is a more flexible solution. For instance, you could imagine a nested form fragment scenario. If the outer fragment is visible, and the inner fragment are visible, then submit, even if the tab containing them is invisible. But if the outer fragment is hidden, the inner fragment should be disabled, as well.
> FormFragment should allow more fine grained control over when to be considered "invisible"
> ------------------------------------------------------------------------------------------
>
> Key: TAP5-1558
> URL: https://issues.apache.org/jira/browse/TAP5-1558
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Robert Zeigler
> Assignee: Robert Zeigler
> Priority: Minor
>
> The 5.2 line of Tapestry introduced the "alwaysSubmit" parameter to form fragment. This is nice because it allows the fragment to be submitted even if hidden. However, it doesn't cover all use cases. Consider a situation like:
> <form>
> <div id="tab1">...<t:formfragment ...><t:textfield validate="required".../></t:formfragment></div>
> <div id="tab2">...<t:formfragment ...><t:textfield validate="required".../></t:formfragment></div>
> <t:submit/>
> </form>
> User reveals tab 1, then reveals the form fragment on tab1 and makes changes. Now user reveals tab2. Note that the fragment on tab1 is still revealed in the context of tab1, but the entire tab1 is hidden. There is currently no way to make it so that "submit" will submit the information from the formfragment in both tabs and behave correctly in all situations. I will enumerate. Some definitions for clarity:
> fragmentX is the fragment on tabX.
> fragmentX visibility refers to the state of the actual fragment, rather than the state of the containing tab. So if fragment1 is visible, it means it's visible when tab1 is active... and I am considering it visible when tab2 is active, even though the entire tab1 is invisible.
> 1) If "alwaysSubmit" is false and fragment1 is invisible, you will get the correct behavior regardless of tab1/tab2 visibility
> 2) If "alwaysSubmit" is false and fragment1 is visible, you will get the correct behavior iff tab1 is active. If tab2 is active, fragment1's fields will not be submitted.
> 3) If "alwaysSubmit" is true and fragment1 is invisible, you will get incorrect behavior (well, technically, it's "correct": the information will be submitted, as per alwaysSubmit, but this is a case where you don't actually /want/ the information submitted if the fragment isn't visible)
> 4) If "alwaysSubmit" is true and fragment is visible, you will get correct behavior.
> You can conditionally "alwaysSubmit": alwaysSubmit on the same condition for visibility as the "visible" trigger. The problem here comes in the following scenario:
> User opens a page with fragment1 initially visible, but no data yet in the required field. User marks fragment1 as invisible. User submits the form. The submission will fail because "alwaysSubmit" was true at the time the form rendered.
> The culprit behind this is Tapestry's "isDeepVisible" method. It searches for visibility up to the point where it finds a form element. But in the case above, the form element contains the tab divs, so the fragment is determined to be invisible and the data not submitted for the inactive tab, even if the user clicked on the trigger to make the fragment visible while the tab was active.
> This is something of an edge case, but I think it can be handled cleanly by introducing a new parameter to formfragment, such as "visiblebound" (but better named!). The idea is to allow developers to specify an element or selector expression that bounds the search for visibility. The default would be the containing form element which would preserve the current behavior.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1558) FormFragment should allow more fine
grained control over when to be considered "invisible"
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086865#comment-13086865 ]
Hudson commented on TAP5-1558:
------------------------------
Integrated in tapestry-trunk-freestyle #488 (See [https://builds.apache.org/job/tapestry-trunk-freestyle/488/])
TAP5-1558: FormFragment should allow more fine grained control over when to be considered "invisible"
robertdzeigler : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1159019
Files :
* /tapestry/tapestry5/trunk/tapestry-core/src/test/java/org/apache/tapestry5/integration/app1/pages/FormFragmentExplicitVisibleBoundsDemo.java
* /tapestry/tapestry5/trunk/tapestry-core/src/test/java/org/apache/tapestry5/integration/app1/pages/Index.java
* /tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/corelib/components/FormFragment.java
* /tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ClientBehaviorSupportImpl.java
* /tapestry/tapestry5/trunk/tapestry-core/src/main/resources/org/apache/tapestry5/tapestry.js
* /tapestry/tapestry5/trunk/tapestry-core/src/test/java/org/apache/tapestry5/integration/app1/AjaxTests.java
* /tapestry/tapestry5/trunk/tapestry-core/src/test/app1/FormFragmentExplicitVisibleBoundsDemo.tml
* /tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/services/ClientBehaviorSupport.java
* /tapestry/tapestry5/trunk/tapestry-core/src/test/java/org/apache/tapestry5/integration/app1/FormTests.java
* /tapestry/tapestry5/trunk/tapestry-test/src/main/java/org/apache/tapestry5/test/SeleniumTestCase.java
* /tapestry/tapestry5/trunk/tapestry-core/src/main/resources/org/apache/tapestry5/t5-formfragment.js
> FormFragment should allow more fine grained control over when to be considered "invisible"
> ------------------------------------------------------------------------------------------
>
> Key: TAP5-1558
> URL: https://issues.apache.org/jira/browse/TAP5-1558
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Robert Zeigler
> Assignee: Robert Zeigler
> Priority: Minor
> Fix For: 5.3
>
>
> The 5.2 line of Tapestry introduced the "alwaysSubmit" parameter to form fragment. This is nice because it allows the fragment to be submitted even if hidden. However, it doesn't cover all use cases. Consider a situation like:
> <form>
> <div id="tab1">...<t:formfragment ...><t:textfield validate="required".../></t:formfragment></div>
> <div id="tab2">...<t:formfragment ...><t:textfield validate="required".../></t:formfragment></div>
> <t:submit/>
> </form>
> User reveals tab 1, then reveals the form fragment on tab1 and makes changes. Now user reveals tab2. Note that the fragment on tab1 is still revealed in the context of tab1, but the entire tab1 is hidden. There is currently no way to make it so that "submit" will submit the information from the formfragment in both tabs and behave correctly in all situations. I will enumerate. Some definitions for clarity:
> fragmentX is the fragment on tabX.
> fragmentX visibility refers to the state of the actual fragment, rather than the state of the containing tab. So if fragment1 is visible, it means it's visible when tab1 is active... and I am considering it visible when tab2 is active, even though the entire tab1 is invisible.
> 1) If "alwaysSubmit" is false and fragment1 is invisible, you will get the correct behavior regardless of tab1/tab2 visibility
> 2) If "alwaysSubmit" is false and fragment1 is visible, you will get the correct behavior iff tab1 is active. If tab2 is active, fragment1's fields will not be submitted.
> 3) If "alwaysSubmit" is true and fragment1 is invisible, you will get incorrect behavior (well, technically, it's "correct": the information will be submitted, as per alwaysSubmit, but this is a case where you don't actually /want/ the information submitted if the fragment isn't visible)
> 4) If "alwaysSubmit" is true and fragment is visible, you will get correct behavior.
> You can conditionally "alwaysSubmit": alwaysSubmit on the same condition for visibility as the "visible" trigger. The problem here comes in the following scenario:
> User opens a page with fragment1 initially visible, but no data yet in the required field. User marks fragment1 as invisible. User submits the form. The submission will fail because "alwaysSubmit" was true at the time the form rendered.
> The culprit behind this is Tapestry's "isDeepVisible" method. It searches for visibility up to the point where it finds a form element. But in the case above, the form element contains the tab divs, so the fragment is determined to be invisible and the data not submitted for the inactive tab, even if the user clicked on the trigger to make the fragment visible while the tab was active.
> This is something of an edge case, but I think it can be handled cleanly by introducing a new parameter to formfragment, such as "visiblebound" (but better named!). The idea is to allow developers to specify an element or selector expression that bounds the search for visibility. The default would be the containing form element which would preserve the current behavior.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TAP5-1558) FormFragment should allow more fine
grained control over when to be considered "invisible"
Posted by "Robert Zeigler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Zeigler reassigned TAP5-1558:
------------------------------------
Assignee: Robert Zeigler
> FormFragment should allow more fine grained control over when to be considered "invisible"
> ------------------------------------------------------------------------------------------
>
> Key: TAP5-1558
> URL: https://issues.apache.org/jira/browse/TAP5-1558
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.3.0
> Reporter: Robert Zeigler
> Assignee: Robert Zeigler
> Priority: Minor
>
> The 5.2 line of Tapestry introduced the "alwaysSubmit" parameter to form fragment. This is nice because it allows the fragment to be submitted even if hidden. However, it doesn't cover all use cases. Consider a situation like:
> <form>
> <div id="tab1">...<t:formfragment ...><t:textfield validate="required".../></t:formfragment></div>
> <div id="tab2">...<t:formfragment ...><t:textfield validate="required".../></t:formfragment></div>
> <t:submit/>
> </form>
> User reveals tab 1, then reveals the form fragment on tab1 and makes changes. Now user reveals tab2. Note that the fragment on tab1 is still revealed in the context of tab1, but the entire tab1 is hidden. There is currently no way to make it so that "submit" will submit the information from the formfragment in both tabs and behave correctly in all situations. I will enumerate. Some definitions for clarity:
> fragmentX is the fragment on tabX.
> fragmentX visibility refers to the state of the actual fragment, rather than the state of the containing tab. So if fragment1 is visible, it means it's visible when tab1 is active... and I am considering it visible when tab2 is active, even though the entire tab1 is invisible.
> 1) If "alwaysSubmit" is false and fragment1 is invisible, you will get the correct behavior regardless of tab1/tab2 visibility
> 2) If "alwaysSubmit" is false and fragment1 is visible, you will get the correct behavior iff tab1 is active. If tab2 is active, fragment1's fields will not be submitted.
> 3) If "alwaysSubmit" is true and fragment1 is invisible, you will get incorrect behavior (well, technically, it's "correct": the information will be submitted, as per alwaysSubmit, but this is a case where you don't actually /want/ the information submitted if the fragment isn't visible)
> 4) If "alwaysSubmit" is true and fragment is visible, you will get correct behavior.
> You can conditionally "alwaysSubmit": alwaysSubmit on the same condition for visibility as the "visible" trigger. The problem here comes in the following scenario:
> User opens a page with fragment1 initially visible, but no data yet in the required field. User marks fragment1 as invisible. User submits the form. The submission will fail because "alwaysSubmit" was true at the time the form rendered.
> The culprit behind this is Tapestry's "isDeepVisible" method. It searches for visibility up to the point where it finds a form element. But in the case above, the form element contains the tab divs, so the fragment is determined to be invisible and the data not submitted for the inactive tab, even if the user clicked on the trigger to make the fragment visible while the tab was active.
> This is something of an edge case, but I think it can be handled cleanly by introducing a new parameter to formfragment, such as "visiblebound" (but better named!). The idea is to allow developers to specify an element or selector expression that bounds the search for visibility. The default would be the containing form element which would preserve the current behavior.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1558) FormFragment should allow more fine
grained control over when to be considered "invisible"
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086865#comment-13086865 ]
Hudson commented on TAP5-1558:
------------------------------
Integrated in tapestry-trunk-freestyle #488 (See [https://builds.apache.org/job/tapestry-trunk-freestyle/488/])
TAP5-1558: FormFragment should allow more fine grained control over when to be considered "invisible"
robertdzeigler : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1159019
Files :
* /tapestry/tapestry5/trunk/tapestry-core/src/test/java/org/apache/tapestry5/integration/app1/pages/FormFragmentExplicitVisibleBoundsDemo.java
* /tapestry/tapestry5/trunk/tapestry-core/src/test/java/org/apache/tapestry5/integration/app1/pages/Index.java
* /tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/corelib/components/FormFragment.java
* /tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ClientBehaviorSupportImpl.java
* /tapestry/tapestry5/trunk/tapestry-core/src/main/resources/org/apache/tapestry5/tapestry.js
* /tapestry/tapestry5/trunk/tapestry-core/src/test/java/org/apache/tapestry5/integration/app1/AjaxTests.java
* /tapestry/tapestry5/trunk/tapestry-core/src/test/app1/FormFragmentExplicitVisibleBoundsDemo.tml
* /tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/services/ClientBehaviorSupport.java
* /tapestry/tapestry5/trunk/tapestry-core/src/test/java/org/apache/tapestry5/integration/app1/FormTests.java
* /tapestry/tapestry5/trunk/tapestry-test/src/main/java/org/apache/tapestry5/test/SeleniumTestCase.java
* /tapestry/tapestry5/trunk/tapestry-core/src/main/resources/org/apache/tapestry5/t5-formfragment.js
> FormFragment should allow more fine grained control over when to be considered "invisible"
> ------------------------------------------------------------------------------------------
>
> Key: TAP5-1558
> URL: https://issues.apache.org/jira/browse/TAP5-1558
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Robert Zeigler
> Assignee: Robert Zeigler
> Priority: Minor
> Fix For: 5.3
>
>
> The 5.2 line of Tapestry introduced the "alwaysSubmit" parameter to form fragment. This is nice because it allows the fragment to be submitted even if hidden. However, it doesn't cover all use cases. Consider a situation like:
> <form>
> <div id="tab1">...<t:formfragment ...><t:textfield validate="required".../></t:formfragment></div>
> <div id="tab2">...<t:formfragment ...><t:textfield validate="required".../></t:formfragment></div>
> <t:submit/>
> </form>
> User reveals tab 1, then reveals the form fragment on tab1 and makes changes. Now user reveals tab2. Note that the fragment on tab1 is still revealed in the context of tab1, but the entire tab1 is hidden. There is currently no way to make it so that "submit" will submit the information from the formfragment in both tabs and behave correctly in all situations. I will enumerate. Some definitions for clarity:
> fragmentX is the fragment on tabX.
> fragmentX visibility refers to the state of the actual fragment, rather than the state of the containing tab. So if fragment1 is visible, it means it's visible when tab1 is active... and I am considering it visible when tab2 is active, even though the entire tab1 is invisible.
> 1) If "alwaysSubmit" is false and fragment1 is invisible, you will get the correct behavior regardless of tab1/tab2 visibility
> 2) If "alwaysSubmit" is false and fragment1 is visible, you will get the correct behavior iff tab1 is active. If tab2 is active, fragment1's fields will not be submitted.
> 3) If "alwaysSubmit" is true and fragment1 is invisible, you will get incorrect behavior (well, technically, it's "correct": the information will be submitted, as per alwaysSubmit, but this is a case where you don't actually /want/ the information submitted if the fragment isn't visible)
> 4) If "alwaysSubmit" is true and fragment is visible, you will get correct behavior.
> You can conditionally "alwaysSubmit": alwaysSubmit on the same condition for visibility as the "visible" trigger. The problem here comes in the following scenario:
> User opens a page with fragment1 initially visible, but no data yet in the required field. User marks fragment1 as invisible. User submits the form. The submission will fail because "alwaysSubmit" was true at the time the form rendered.
> The culprit behind this is Tapestry's "isDeepVisible" method. It searches for visibility up to the point where it finds a form element. But in the case above, the form element contains the tab divs, so the fragment is determined to be invisible and the data not submitted for the inactive tab, even if the user clicked on the trigger to make the fragment visible while the tab was active.
> This is something of an edge case, but I think it can be handled cleanly by introducing a new parameter to formfragment, such as "visiblebound" (but better named!). The idea is to allow developers to specify an element or selector expression that bounds the search for visibility. The default would be the containing form element which would preserve the current behavior.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TAP5-1558) FormFragment should allow more fine
grained control over when to be considered "invisible"
Posted by "Robert Zeigler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Zeigler reassigned TAP5-1558:
------------------------------------
Assignee: Robert Zeigler
> FormFragment should allow more fine grained control over when to be considered "invisible"
> ------------------------------------------------------------------------------------------
>
> Key: TAP5-1558
> URL: https://issues.apache.org/jira/browse/TAP5-1558
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.3.0
> Reporter: Robert Zeigler
> Assignee: Robert Zeigler
> Priority: Minor
>
> The 5.2 line of Tapestry introduced the "alwaysSubmit" parameter to form fragment. This is nice because it allows the fragment to be submitted even if hidden. However, it doesn't cover all use cases. Consider a situation like:
> <form>
> <div id="tab1">...<t:formfragment ...><t:textfield validate="required".../></t:formfragment></div>
> <div id="tab2">...<t:formfragment ...><t:textfield validate="required".../></t:formfragment></div>
> <t:submit/>
> </form>
> User reveals tab 1, then reveals the form fragment on tab1 and makes changes. Now user reveals tab2. Note that the fragment on tab1 is still revealed in the context of tab1, but the entire tab1 is hidden. There is currently no way to make it so that "submit" will submit the information from the formfragment in both tabs and behave correctly in all situations. I will enumerate. Some definitions for clarity:
> fragmentX is the fragment on tabX.
> fragmentX visibility refers to the state of the actual fragment, rather than the state of the containing tab. So if fragment1 is visible, it means it's visible when tab1 is active... and I am considering it visible when tab2 is active, even though the entire tab1 is invisible.
> 1) If "alwaysSubmit" is false and fragment1 is invisible, you will get the correct behavior regardless of tab1/tab2 visibility
> 2) If "alwaysSubmit" is false and fragment1 is visible, you will get the correct behavior iff tab1 is active. If tab2 is active, fragment1's fields will not be submitted.
> 3) If "alwaysSubmit" is true and fragment1 is invisible, you will get incorrect behavior (well, technically, it's "correct": the information will be submitted, as per alwaysSubmit, but this is a case where you don't actually /want/ the information submitted if the fragment isn't visible)
> 4) If "alwaysSubmit" is true and fragment is visible, you will get correct behavior.
> You can conditionally "alwaysSubmit": alwaysSubmit on the same condition for visibility as the "visible" trigger. The problem here comes in the following scenario:
> User opens a page with fragment1 initially visible, but no data yet in the required field. User marks fragment1 as invisible. User submits the form. The submission will fail because "alwaysSubmit" was true at the time the form rendered.
> The culprit behind this is Tapestry's "isDeepVisible" method. It searches for visibility up to the point where it finds a form element. But in the case above, the form element contains the tab divs, so the fragment is determined to be invisible and the data not submitted for the inactive tab, even if the user clicked on the trigger to make the fragment visible while the tab was active.
> This is something of an edge case, but I think it can be handled cleanly by introducing a new parameter to formfragment, such as "visiblebound" (but better named!). The idea is to allow developers to specify an element or selector expression that bounds the search for visibility. The default would be the containing form element which would preserve the current behavior.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TAP5-1558) FormFragment should allow more fine
grained control over when to be considered "invisible"
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship reassigned TAP5-1558:
------------------------------------------
Assignee: Howard M. Lewis Ship (was: Robert Zeigler)
> FormFragment should allow more fine grained control over when to be considered "invisible"
> ------------------------------------------------------------------------------------------
>
> Key: TAP5-1558
> URL: https://issues.apache.org/jira/browse/TAP5-1558
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Robert Zeigler
> Assignee: Howard M. Lewis Ship
> Priority: Minor
>
> The 5.2 line of Tapestry introduced the "alwaysSubmit" parameter to form fragment. This is nice because it allows the fragment to be submitted even if hidden. However, it doesn't cover all use cases. Consider a situation like:
> <form>
> <div id="tab1">...<t:formfragment ...><t:textfield validate="required".../></t:formfragment></div>
> <div id="tab2">...<t:formfragment ...><t:textfield validate="required".../></t:formfragment></div>
> <t:submit/>
> </form>
> User reveals tab 1, then reveals the form fragment on tab1 and makes changes. Now user reveals tab2. Note that the fragment on tab1 is still revealed in the context of tab1, but the entire tab1 is hidden. There is currently no way to make it so that "submit" will submit the information from the formfragment in both tabs and behave correctly in all situations. I will enumerate. Some definitions for clarity:
> fragmentX is the fragment on tabX.
> fragmentX visibility refers to the state of the actual fragment, rather than the state of the containing tab. So if fragment1 is visible, it means it's visible when tab1 is active... and I am considering it visible when tab2 is active, even though the entire tab1 is invisible.
> 1) If "alwaysSubmit" is false and fragment1 is invisible, you will get the correct behavior regardless of tab1/tab2 visibility
> 2) If "alwaysSubmit" is false and fragment1 is visible, you will get the correct behavior iff tab1 is active. If tab2 is active, fragment1's fields will not be submitted.
> 3) If "alwaysSubmit" is true and fragment1 is invisible, you will get incorrect behavior (well, technically, it's "correct": the information will be submitted, as per alwaysSubmit, but this is a case where you don't actually /want/ the information submitted if the fragment isn't visible)
> 4) If "alwaysSubmit" is true and fragment is visible, you will get correct behavior.
> You can conditionally "alwaysSubmit": alwaysSubmit on the same condition for visibility as the "visible" trigger. The problem here comes in the following scenario:
> User opens a page with fragment1 initially visible, but no data yet in the required field. User marks fragment1 as invisible. User submits the form. The submission will fail because "alwaysSubmit" was true at the time the form rendered.
> The culprit behind this is Tapestry's "isDeepVisible" method. It searches for visibility up to the point where it finds a form element. But in the case above, the form element contains the tab divs, so the fragment is determined to be invisible and the data not submitted for the inactive tab, even if the user clicked on the trigger to make the fragment visible while the tab was active.
> This is something of an edge case, but I think it can be handled cleanly by introducing a new parameter to formfragment, such as "visiblebound" (but better named!). The idea is to allow developers to specify an element or selector expression that bounds the search for visibility. The default would be the containing form element which would preserve the current behavior.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TAP5-1558) FormFragment should allow more fine
grained control over when to be considered "invisible"
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship reassigned TAP5-1558:
------------------------------------------
Assignee: (was: Howard M. Lewis Ship)
> FormFragment should allow more fine grained control over when to be considered "invisible"
> ------------------------------------------------------------------------------------------
>
> Key: TAP5-1558
> URL: https://issues.apache.org/jira/browse/TAP5-1558
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Robert Zeigler
> Priority: Minor
>
> The 5.2 line of Tapestry introduced the "alwaysSubmit" parameter to form fragment. This is nice because it allows the fragment to be submitted even if hidden. However, it doesn't cover all use cases. Consider a situation like:
> <form>
> <div id="tab1">...<t:formfragment ...><t:textfield validate="required".../></t:formfragment></div>
> <div id="tab2">...<t:formfragment ...><t:textfield validate="required".../></t:formfragment></div>
> <t:submit/>
> </form>
> User reveals tab 1, then reveals the form fragment on tab1 and makes changes. Now user reveals tab2. Note that the fragment on tab1 is still revealed in the context of tab1, but the entire tab1 is hidden. There is currently no way to make it so that "submit" will submit the information from the formfragment in both tabs and behave correctly in all situations. I will enumerate. Some definitions for clarity:
> fragmentX is the fragment on tabX.
> fragmentX visibility refers to the state of the actual fragment, rather than the state of the containing tab. So if fragment1 is visible, it means it's visible when tab1 is active... and I am considering it visible when tab2 is active, even though the entire tab1 is invisible.
> 1) If "alwaysSubmit" is false and fragment1 is invisible, you will get the correct behavior regardless of tab1/tab2 visibility
> 2) If "alwaysSubmit" is false and fragment1 is visible, you will get the correct behavior iff tab1 is active. If tab2 is active, fragment1's fields will not be submitted.
> 3) If "alwaysSubmit" is true and fragment1 is invisible, you will get incorrect behavior (well, technically, it's "correct": the information will be submitted, as per alwaysSubmit, but this is a case where you don't actually /want/ the information submitted if the fragment isn't visible)
> 4) If "alwaysSubmit" is true and fragment is visible, you will get correct behavior.
> You can conditionally "alwaysSubmit": alwaysSubmit on the same condition for visibility as the "visible" trigger. The problem here comes in the following scenario:
> User opens a page with fragment1 initially visible, but no data yet in the required field. User marks fragment1 as invisible. User submits the form. The submission will fail because "alwaysSubmit" was true at the time the form rendered.
> The culprit behind this is Tapestry's "isDeepVisible" method. It searches for visibility up to the point where it finds a form element. But in the case above, the form element contains the tab divs, so the fragment is determined to be invisible and the data not submitted for the inactive tab, even if the user clicked on the trigger to make the fragment visible while the tab was active.
> This is something of an edge case, but I think it can be handled cleanly by introducing a new parameter to formfragment, such as "visiblebound" (but better named!). The idea is to allow developers to specify an element or selector expression that bounds the search for visibility. The default would be the containing form element which would preserve the current behavior.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1558) FormFragment should allow more fine
grained control over when to be considered "invisible"
Posted by "Robert Zeigler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086340#comment-13086340 ]
Robert Zeigler commented on TAP5-1558:
--------------------------------------
Current behavior in 5.3, using the same "tab" scenario as above:
If both fragments are invisible at the first render, then you reveal fragment one on tab 1, then reveal tab 2 and reveal fragment 2 on tab 2, then the first submit, you will get correct behavior: both fragments will submit. But any subsequent render will not work; whichever tab is invisible when the page first renders will not submit it's form fragment (unless you re-hide & re-reveal it). Still happens because of the "isDeepVisible" search.
I'm wondering if instead of bounding the search, it would be enough to add a parameter for explicitly ignoring the parent visibility: "ignoreParentVisibility"; defaults to false to preserve the current behavior. It's a simpler solution that solves my use-case. But bounding the search is a more flexible solution. For instance, you could imagine a nested form fragment scenario. If the outer fragment is visible, and the inner fragment are visible, then submit, even if the tab containing them is invisible. But if the outer fragment is hidden, the inner fragment should be disabled, as well.
> FormFragment should allow more fine grained control over when to be considered "invisible"
> ------------------------------------------------------------------------------------------
>
> Key: TAP5-1558
> URL: https://issues.apache.org/jira/browse/TAP5-1558
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Robert Zeigler
> Assignee: Robert Zeigler
> Priority: Minor
>
> The 5.2 line of Tapestry introduced the "alwaysSubmit" parameter to form fragment. This is nice because it allows the fragment to be submitted even if hidden. However, it doesn't cover all use cases. Consider a situation like:
> <form>
> <div id="tab1">...<t:formfragment ...><t:textfield validate="required".../></t:formfragment></div>
> <div id="tab2">...<t:formfragment ...><t:textfield validate="required".../></t:formfragment></div>
> <t:submit/>
> </form>
> User reveals tab 1, then reveals the form fragment on tab1 and makes changes. Now user reveals tab2. Note that the fragment on tab1 is still revealed in the context of tab1, but the entire tab1 is hidden. There is currently no way to make it so that "submit" will submit the information from the formfragment in both tabs and behave correctly in all situations. I will enumerate. Some definitions for clarity:
> fragmentX is the fragment on tabX.
> fragmentX visibility refers to the state of the actual fragment, rather than the state of the containing tab. So if fragment1 is visible, it means it's visible when tab1 is active... and I am considering it visible when tab2 is active, even though the entire tab1 is invisible.
> 1) If "alwaysSubmit" is false and fragment1 is invisible, you will get the correct behavior regardless of tab1/tab2 visibility
> 2) If "alwaysSubmit" is false and fragment1 is visible, you will get the correct behavior iff tab1 is active. If tab2 is active, fragment1's fields will not be submitted.
> 3) If "alwaysSubmit" is true and fragment1 is invisible, you will get incorrect behavior (well, technically, it's "correct": the information will be submitted, as per alwaysSubmit, but this is a case where you don't actually /want/ the information submitted if the fragment isn't visible)
> 4) If "alwaysSubmit" is true and fragment is visible, you will get correct behavior.
> You can conditionally "alwaysSubmit": alwaysSubmit on the same condition for visibility as the "visible" trigger. The problem here comes in the following scenario:
> User opens a page with fragment1 initially visible, but no data yet in the required field. User marks fragment1 as invisible. User submits the form. The submission will fail because "alwaysSubmit" was true at the time the form rendered.
> The culprit behind this is Tapestry's "isDeepVisible" method. It searches for visibility up to the point where it finds a form element. But in the case above, the form element contains the tab divs, so the fragment is determined to be invisible and the data not submitted for the inactive tab, even if the user clicked on the trigger to make the fragment visible while the tab was active.
> This is something of an edge case, but I think it can be handled cleanly by introducing a new parameter to formfragment, such as "visiblebound" (but better named!). The idea is to allow developers to specify an element or selector expression that bounds the search for visibility. The default would be the containing form element which would preserve the current behavior.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TAP5-1558) FormFragment should allow more fine
grained control over when to be considered "invisible"
Posted by "Robert Zeigler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Zeigler reassigned TAP5-1558:
------------------------------------
Assignee: Robert Zeigler
> FormFragment should allow more fine grained control over when to be considered "invisible"
> ------------------------------------------------------------------------------------------
>
> Key: TAP5-1558
> URL: https://issues.apache.org/jira/browse/TAP5-1558
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Robert Zeigler
> Assignee: Robert Zeigler
> Priority: Minor
>
> The 5.2 line of Tapestry introduced the "alwaysSubmit" parameter to form fragment. This is nice because it allows the fragment to be submitted even if hidden. However, it doesn't cover all use cases. Consider a situation like:
> <form>
> <div id="tab1">...<t:formfragment ...><t:textfield validate="required".../></t:formfragment></div>
> <div id="tab2">...<t:formfragment ...><t:textfield validate="required".../></t:formfragment></div>
> <t:submit/>
> </form>
> User reveals tab 1, then reveals the form fragment on tab1 and makes changes. Now user reveals tab2. Note that the fragment on tab1 is still revealed in the context of tab1, but the entire tab1 is hidden. There is currently no way to make it so that "submit" will submit the information from the formfragment in both tabs and behave correctly in all situations. I will enumerate. Some definitions for clarity:
> fragmentX is the fragment on tabX.
> fragmentX visibility refers to the state of the actual fragment, rather than the state of the containing tab. So if fragment1 is visible, it means it's visible when tab1 is active... and I am considering it visible when tab2 is active, even though the entire tab1 is invisible.
> 1) If "alwaysSubmit" is false and fragment1 is invisible, you will get the correct behavior regardless of tab1/tab2 visibility
> 2) If "alwaysSubmit" is false and fragment1 is visible, you will get the correct behavior iff tab1 is active. If tab2 is active, fragment1's fields will not be submitted.
> 3) If "alwaysSubmit" is true and fragment1 is invisible, you will get incorrect behavior (well, technically, it's "correct": the information will be submitted, as per alwaysSubmit, but this is a case where you don't actually /want/ the information submitted if the fragment isn't visible)
> 4) If "alwaysSubmit" is true and fragment is visible, you will get correct behavior.
> You can conditionally "alwaysSubmit": alwaysSubmit on the same condition for visibility as the "visible" trigger. The problem here comes in the following scenario:
> User opens a page with fragment1 initially visible, but no data yet in the required field. User marks fragment1 as invisible. User submits the form. The submission will fail because "alwaysSubmit" was true at the time the form rendered.
> The culprit behind this is Tapestry's "isDeepVisible" method. It searches for visibility up to the point where it finds a form element. But in the case above, the form element contains the tab divs, so the fragment is determined to be invisible and the data not submitted for the inactive tab, even if the user clicked on the trigger to make the fragment visible while the tab was active.
> This is something of an edge case, but I think it can be handled cleanly by introducing a new parameter to formfragment, such as "visiblebound" (but better named!). The idea is to allow developers to specify an element or selector expression that bounds the search for visibility. The default would be the containing form element which would preserve the current behavior.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TAP5-1558) FormFragment should allow more fine
grained control over when to be considered "invisible"
Posted by "Robert Zeigler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Zeigler reassigned TAP5-1558:
------------------------------------
Assignee: Robert Zeigler
> FormFragment should allow more fine grained control over when to be considered "invisible"
> ------------------------------------------------------------------------------------------
>
> Key: TAP5-1558
> URL: https://issues.apache.org/jira/browse/TAP5-1558
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Robert Zeigler
> Assignee: Robert Zeigler
> Priority: Minor
>
> The 5.2 line of Tapestry introduced the "alwaysSubmit" parameter to form fragment. This is nice because it allows the fragment to be submitted even if hidden. However, it doesn't cover all use cases. Consider a situation like:
> <form>
> <div id="tab1">...<t:formfragment ...><t:textfield validate="required".../></t:formfragment></div>
> <div id="tab2">...<t:formfragment ...><t:textfield validate="required".../></t:formfragment></div>
> <t:submit/>
> </form>
> User reveals tab 1, then reveals the form fragment on tab1 and makes changes. Now user reveals tab2. Note that the fragment on tab1 is still revealed in the context of tab1, but the entire tab1 is hidden. There is currently no way to make it so that "submit" will submit the information from the formfragment in both tabs and behave correctly in all situations. I will enumerate. Some definitions for clarity:
> fragmentX is the fragment on tabX.
> fragmentX visibility refers to the state of the actual fragment, rather than the state of the containing tab. So if fragment1 is visible, it means it's visible when tab1 is active... and I am considering it visible when tab2 is active, even though the entire tab1 is invisible.
> 1) If "alwaysSubmit" is false and fragment1 is invisible, you will get the correct behavior regardless of tab1/tab2 visibility
> 2) If "alwaysSubmit" is false and fragment1 is visible, you will get the correct behavior iff tab1 is active. If tab2 is active, fragment1's fields will not be submitted.
> 3) If "alwaysSubmit" is true and fragment1 is invisible, you will get incorrect behavior (well, technically, it's "correct": the information will be submitted, as per alwaysSubmit, but this is a case where you don't actually /want/ the information submitted if the fragment isn't visible)
> 4) If "alwaysSubmit" is true and fragment is visible, you will get correct behavior.
> You can conditionally "alwaysSubmit": alwaysSubmit on the same condition for visibility as the "visible" trigger. The problem here comes in the following scenario:
> User opens a page with fragment1 initially visible, but no data yet in the required field. User marks fragment1 as invisible. User submits the form. The submission will fail because "alwaysSubmit" was true at the time the form rendered.
> The culprit behind this is Tapestry's "isDeepVisible" method. It searches for visibility up to the point where it finds a form element. But in the case above, the form element contains the tab divs, so the fragment is determined to be invisible and the data not submitted for the inactive tab, even if the user clicked on the trigger to make the fragment visible while the tab was active.
> This is something of an edge case, but I think it can be handled cleanly by introducing a new parameter to formfragment, such as "visiblebound" (but better named!). The idea is to allow developers to specify an element or selector expression that bounds the search for visibility. The default would be the containing form element which would preserve the current behavior.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TAP5-1558) FormFragment should allow more fine
grained control over when to be considered "invisible"
Posted by "Robert Zeigler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Zeigler closed TAP5-1558.
--------------------------------
Resolution: Fixed
Fix Version/s: 5.3
Users can override the default behavior by supplying a js function that is called to determine whether the boundary condition has been met. Default is a function that examines tagName for "FORM", preserving original behavior.
> FormFragment should allow more fine grained control over when to be considered "invisible"
> ------------------------------------------------------------------------------------------
>
> Key: TAP5-1558
> URL: https://issues.apache.org/jira/browse/TAP5-1558
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Robert Zeigler
> Assignee: Robert Zeigler
> Priority: Minor
> Fix For: 5.3
>
>
> The 5.2 line of Tapestry introduced the "alwaysSubmit" parameter to form fragment. This is nice because it allows the fragment to be submitted even if hidden. However, it doesn't cover all use cases. Consider a situation like:
> <form>
> <div id="tab1">...<t:formfragment ...><t:textfield validate="required".../></t:formfragment></div>
> <div id="tab2">...<t:formfragment ...><t:textfield validate="required".../></t:formfragment></div>
> <t:submit/>
> </form>
> User reveals tab 1, then reveals the form fragment on tab1 and makes changes. Now user reveals tab2. Note that the fragment on tab1 is still revealed in the context of tab1, but the entire tab1 is hidden. There is currently no way to make it so that "submit" will submit the information from the formfragment in both tabs and behave correctly in all situations. I will enumerate. Some definitions for clarity:
> fragmentX is the fragment on tabX.
> fragmentX visibility refers to the state of the actual fragment, rather than the state of the containing tab. So if fragment1 is visible, it means it's visible when tab1 is active... and I am considering it visible when tab2 is active, even though the entire tab1 is invisible.
> 1) If "alwaysSubmit" is false and fragment1 is invisible, you will get the correct behavior regardless of tab1/tab2 visibility
> 2) If "alwaysSubmit" is false and fragment1 is visible, you will get the correct behavior iff tab1 is active. If tab2 is active, fragment1's fields will not be submitted.
> 3) If "alwaysSubmit" is true and fragment1 is invisible, you will get incorrect behavior (well, technically, it's "correct": the information will be submitted, as per alwaysSubmit, but this is a case where you don't actually /want/ the information submitted if the fragment isn't visible)
> 4) If "alwaysSubmit" is true and fragment is visible, you will get correct behavior.
> You can conditionally "alwaysSubmit": alwaysSubmit on the same condition for visibility as the "visible" trigger. The problem here comes in the following scenario:
> User opens a page with fragment1 initially visible, but no data yet in the required field. User marks fragment1 as invisible. User submits the form. The submission will fail because "alwaysSubmit" was true at the time the form rendered.
> The culprit behind this is Tapestry's "isDeepVisible" method. It searches for visibility up to the point where it finds a form element. But in the case above, the form element contains the tab divs, so the fragment is determined to be invisible and the data not submitted for the inactive tab, even if the user clicked on the trigger to make the fragment visible while the tab was active.
> This is something of an edge case, but I think it can be handled cleanly by introducing a new parameter to formfragment, such as "visiblebound" (but better named!). The idea is to allow developers to specify an element or selector expression that bounds the search for visibility. The default would be the containing form element which would preserve the current behavior.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TAP5-1558) FormFragment should allow more fine
grained control over when to be considered "invisible"
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship reassigned TAP5-1558:
------------------------------------------
Assignee: (was: Howard M. Lewis Ship)
> FormFragment should allow more fine grained control over when to be considered "invisible"
> ------------------------------------------------------------------------------------------
>
> Key: TAP5-1558
> URL: https://issues.apache.org/jira/browse/TAP5-1558
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Robert Zeigler
> Priority: Minor
>
> The 5.2 line of Tapestry introduced the "alwaysSubmit" parameter to form fragment. This is nice because it allows the fragment to be submitted even if hidden. However, it doesn't cover all use cases. Consider a situation like:
> <form>
> <div id="tab1">...<t:formfragment ...><t:textfield validate="required".../></t:formfragment></div>
> <div id="tab2">...<t:formfragment ...><t:textfield validate="required".../></t:formfragment></div>
> <t:submit/>
> </form>
> User reveals tab 1, then reveals the form fragment on tab1 and makes changes. Now user reveals tab2. Note that the fragment on tab1 is still revealed in the context of tab1, but the entire tab1 is hidden. There is currently no way to make it so that "submit" will submit the information from the formfragment in both tabs and behave correctly in all situations. I will enumerate. Some definitions for clarity:
> fragmentX is the fragment on tabX.
> fragmentX visibility refers to the state of the actual fragment, rather than the state of the containing tab. So if fragment1 is visible, it means it's visible when tab1 is active... and I am considering it visible when tab2 is active, even though the entire tab1 is invisible.
> 1) If "alwaysSubmit" is false and fragment1 is invisible, you will get the correct behavior regardless of tab1/tab2 visibility
> 2) If "alwaysSubmit" is false and fragment1 is visible, you will get the correct behavior iff tab1 is active. If tab2 is active, fragment1's fields will not be submitted.
> 3) If "alwaysSubmit" is true and fragment1 is invisible, you will get incorrect behavior (well, technically, it's "correct": the information will be submitted, as per alwaysSubmit, but this is a case where you don't actually /want/ the information submitted if the fragment isn't visible)
> 4) If "alwaysSubmit" is true and fragment is visible, you will get correct behavior.
> You can conditionally "alwaysSubmit": alwaysSubmit on the same condition for visibility as the "visible" trigger. The problem here comes in the following scenario:
> User opens a page with fragment1 initially visible, but no data yet in the required field. User marks fragment1 as invisible. User submits the form. The submission will fail because "alwaysSubmit" was true at the time the form rendered.
> The culprit behind this is Tapestry's "isDeepVisible" method. It searches for visibility up to the point where it finds a form element. But in the case above, the form element contains the tab divs, so the fragment is determined to be invisible and the data not submitted for the inactive tab, even if the user clicked on the trigger to make the fragment visible while the tab was active.
> This is something of an edge case, but I think it can be handled cleanly by introducing a new parameter to formfragment, such as "visiblebound" (but better named!). The idea is to allow developers to specify an element or selector expression that bounds the search for visibility. The default would be the containing form element which would preserve the current behavior.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TAP5-1558) FormFragment should allow more fine
grained control over when to be considered "invisible"
Posted by "Robert Zeigler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Zeigler closed TAP5-1558.
--------------------------------
Resolution: Fixed
Fix Version/s: 5.3
Users can override the default behavior by supplying a js function that is called to determine whether the boundary condition has been met. Default is a function that examines tagName for "FORM", preserving original behavior.
> FormFragment should allow more fine grained control over when to be considered "invisible"
> ------------------------------------------------------------------------------------------
>
> Key: TAP5-1558
> URL: https://issues.apache.org/jira/browse/TAP5-1558
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Robert Zeigler
> Assignee: Robert Zeigler
> Priority: Minor
> Fix For: 5.3
>
>
> The 5.2 line of Tapestry introduced the "alwaysSubmit" parameter to form fragment. This is nice because it allows the fragment to be submitted even if hidden. However, it doesn't cover all use cases. Consider a situation like:
> <form>
> <div id="tab1">...<t:formfragment ...><t:textfield validate="required".../></t:formfragment></div>
> <div id="tab2">...<t:formfragment ...><t:textfield validate="required".../></t:formfragment></div>
> <t:submit/>
> </form>
> User reveals tab 1, then reveals the form fragment on tab1 and makes changes. Now user reveals tab2. Note that the fragment on tab1 is still revealed in the context of tab1, but the entire tab1 is hidden. There is currently no way to make it so that "submit" will submit the information from the formfragment in both tabs and behave correctly in all situations. I will enumerate. Some definitions for clarity:
> fragmentX is the fragment on tabX.
> fragmentX visibility refers to the state of the actual fragment, rather than the state of the containing tab. So if fragment1 is visible, it means it's visible when tab1 is active... and I am considering it visible when tab2 is active, even though the entire tab1 is invisible.
> 1) If "alwaysSubmit" is false and fragment1 is invisible, you will get the correct behavior regardless of tab1/tab2 visibility
> 2) If "alwaysSubmit" is false and fragment1 is visible, you will get the correct behavior iff tab1 is active. If tab2 is active, fragment1's fields will not be submitted.
> 3) If "alwaysSubmit" is true and fragment1 is invisible, you will get incorrect behavior (well, technically, it's "correct": the information will be submitted, as per alwaysSubmit, but this is a case where you don't actually /want/ the information submitted if the fragment isn't visible)
> 4) If "alwaysSubmit" is true and fragment is visible, you will get correct behavior.
> You can conditionally "alwaysSubmit": alwaysSubmit on the same condition for visibility as the "visible" trigger. The problem here comes in the following scenario:
> User opens a page with fragment1 initially visible, but no data yet in the required field. User marks fragment1 as invisible. User submits the form. The submission will fail because "alwaysSubmit" was true at the time the form rendered.
> The culprit behind this is Tapestry's "isDeepVisible" method. It searches for visibility up to the point where it finds a form element. But in the case above, the form element contains the tab divs, so the fragment is determined to be invisible and the data not submitted for the inactive tab, even if the user clicked on the trigger to make the fragment visible while the tab was active.
> This is something of an edge case, but I think it can be handled cleanly by introducing a new parameter to formfragment, such as "visiblebound" (but better named!). The idea is to allow developers to specify an element or selector expression that bounds the search for visibility. The default would be the containing form element which would preserve the current behavior.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TAP5-1558) FormFragment should allow more fine
grained control over when to be considered "invisible"
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship reassigned TAP5-1558:
------------------------------------------
Assignee: Howard M. Lewis Ship (was: Robert Zeigler)
> FormFragment should allow more fine grained control over when to be considered "invisible"
> ------------------------------------------------------------------------------------------
>
> Key: TAP5-1558
> URL: https://issues.apache.org/jira/browse/TAP5-1558
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Robert Zeigler
> Assignee: Howard M. Lewis Ship
> Priority: Minor
>
> The 5.2 line of Tapestry introduced the "alwaysSubmit" parameter to form fragment. This is nice because it allows the fragment to be submitted even if hidden. However, it doesn't cover all use cases. Consider a situation like:
> <form>
> <div id="tab1">...<t:formfragment ...><t:textfield validate="required".../></t:formfragment></div>
> <div id="tab2">...<t:formfragment ...><t:textfield validate="required".../></t:formfragment></div>
> <t:submit/>
> </form>
> User reveals tab 1, then reveals the form fragment on tab1 and makes changes. Now user reveals tab2. Note that the fragment on tab1 is still revealed in the context of tab1, but the entire tab1 is hidden. There is currently no way to make it so that "submit" will submit the information from the formfragment in both tabs and behave correctly in all situations. I will enumerate. Some definitions for clarity:
> fragmentX is the fragment on tabX.
> fragmentX visibility refers to the state of the actual fragment, rather than the state of the containing tab. So if fragment1 is visible, it means it's visible when tab1 is active... and I am considering it visible when tab2 is active, even though the entire tab1 is invisible.
> 1) If "alwaysSubmit" is false and fragment1 is invisible, you will get the correct behavior regardless of tab1/tab2 visibility
> 2) If "alwaysSubmit" is false and fragment1 is visible, you will get the correct behavior iff tab1 is active. If tab2 is active, fragment1's fields will not be submitted.
> 3) If "alwaysSubmit" is true and fragment1 is invisible, you will get incorrect behavior (well, technically, it's "correct": the information will be submitted, as per alwaysSubmit, but this is a case where you don't actually /want/ the information submitted if the fragment isn't visible)
> 4) If "alwaysSubmit" is true and fragment is visible, you will get correct behavior.
> You can conditionally "alwaysSubmit": alwaysSubmit on the same condition for visibility as the "visible" trigger. The problem here comes in the following scenario:
> User opens a page with fragment1 initially visible, but no data yet in the required field. User marks fragment1 as invisible. User submits the form. The submission will fail because "alwaysSubmit" was true at the time the form rendered.
> The culprit behind this is Tapestry's "isDeepVisible" method. It searches for visibility up to the point where it finds a form element. But in the case above, the form element contains the tab divs, so the fragment is determined to be invisible and the data not submitted for the inactive tab, even if the user clicked on the trigger to make the fragment visible while the tab was active.
> This is something of an edge case, but I think it can be handled cleanly by introducing a new parameter to formfragment, such as "visiblebound" (but better named!). The idea is to allow developers to specify an element or selector expression that bounds the search for visibility. The default would be the containing form element which would preserve the current behavior.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira