[JBoss JIRA] (RF-13505) Refactor custom tree traversal logic in EPVCI in order to leverage VisitContextFactory (blocked by Mojarra issue)
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13505?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč edited comment on RF-13505 at 5/22/14 6:33 AM:
----------------------------------------------------------
*First one:*
Seems that in the response, the correct render value is propagated: {{extension[id=org.richfaces.extension]/render=@all}} but the response doesn't contain an update for whole page.
----
The thing is that {{render=@all}} does not work at all, since we delegate to {{PartialViewContextImpl#processPartial(PhaseId)}} that asks for {{#isRenderAll()}} but it does not delegate to PVC chain (incl. EPVC). This means the JSF impl itself does not consider the request as {{render=@all}} and tries to render just implicitly rendered areas (as instructed by EPVC).
The fix consists of call of {{PartialViewContextImpl#setRenderAll(true)}} when needed.
was (Author: lfryc):
*First one:*
Seems that in the response, the correct render value is propagated: {{extension[id=org.richfaces.extension]/render=@all}} but the response doesn't contain an update for whole page.
> Refactor custom tree traversal logic in EPVCI in order to leverage VisitContextFactory (blocked by Mojarra issue)
> -----------------------------------------------------------------------------------------------------------------
>
> Key: RF-13505
> URL: https://issues.jboss.org/browse/RF-13505
> Project: RichFaces
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Affects Versions: 5.0.0.Alpha3
> Reporter: Lukáš Fryč
> Assignee: Lukáš Fryč
> Priority: Critical
> Fix For: 4.5.0.Alpha3
>
> Attachments: fu-request.png
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> Mojarra issue: https://java.net/jira/browse/JAVASERVERFACES-3151
> We will still need to use some:
> * resolve values in runtime
> * add IDs for execution of AjaxOutput's
> * collect list of meta-components to render
> * wrap PartialResponseWriter#endDocument() for RichFaces extensions and JavascriptService
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 6 months
[JBoss JIRA] (RF-13505) Refactor custom tree traversal logic in EPVCI in order to leverage VisitContextFactory (blocked by Mojarra issue)
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13505?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč edited comment on RF-13505 at 5/22/14 6:34 AM:
----------------------------------------------------------
*Second one:*
The problem is based in an approach how file upload sends request parameters to the server.
fileupload.js sets up parameters in a) query string b) request body (as form params).
This is odd, because undertow(?) detects just query string {{rf_fu_uid}} as a parameter and leaves form params unnoticed.
Because one of the form params is also {{org.richfaces.ajax.component}} parameter, EPVC assumes the request does not come from RichFaces component and delegates partial request processing to JSF impl. In JSF impl, implicitly rendered areas are not considered.
See attached image [{{fu-request.png}}|https://issues.jboss.org/secure/attachment/12382531/fu-request.png] for illustration of the problem.
----
I believe this couldn't work even without EPVC refactoring.
was (Author: lfryc):
*Second one:*
The problem is based in an approach how file upload sends request parameters to the server.
fileupload.js sets up parameters in a) query string b) request body (as form params).
This is odd, because undertow(?) detects just query string {{rf_fu_uid}} as a parameter and leaves form params unnoticed.
Because one of the form params is also {{org.richfaces.ajax.component}} parameter, EPVC assumes the request does not come from RichFaces component and delegates partial request processing to JSF impl. In JSF impl, implicitly rendered areas are not considered.
See attached image [{{fu-request.png}}|https://issues.jboss.org/secure/attachment/12382531/fu-request.png] for illustration of the problem.
> Refactor custom tree traversal logic in EPVCI in order to leverage VisitContextFactory (blocked by Mojarra issue)
> -----------------------------------------------------------------------------------------------------------------
>
> Key: RF-13505
> URL: https://issues.jboss.org/browse/RF-13505
> Project: RichFaces
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Affects Versions: 5.0.0.Alpha3
> Reporter: Lukáš Fryč
> Assignee: Lukáš Fryč
> Priority: Critical
> Fix For: 4.5.0.Alpha3
>
> Attachments: fu-request.png
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> Mojarra issue: https://java.net/jira/browse/JAVASERVERFACES-3151
> We will still need to use some:
> * resolve values in runtime
> * add IDs for execution of AjaxOutput's
> * collect list of meta-components to render
> * wrap PartialResponseWriter#endDocument() for RichFaces extensions and JavascriptService
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 6 months
[JBoss JIRA] (RF-13505) Refactor custom tree traversal logic in EPVCI in order to leverage VisitContextFactory (blocked by Mojarra issue)
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13505?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on RF-13505:
---------------------------------
*Second one:*
The problem is based in an approach how file upload sends request parameters to the server.
fileupload.js sets up parameters in a) query string b) request body (as form params).
This is odd, because undertow(?) detects just query string {{rf_fu_uid}} as a parameter and leaves form params unnoticed.
Because one of the form params is also {{org.richfaces.ajax.component}} parameter, EPVC assumes the request does not come from RichFaces component and delegates partial request processing to JSF impl. In JSF impl, implicitly rendered areas are not considered.
See attached image {{fu-request.png} for illustration of the problem.
> Refactor custom tree traversal logic in EPVCI in order to leverage VisitContextFactory (blocked by Mojarra issue)
> -----------------------------------------------------------------------------------------------------------------
>
> Key: RF-13505
> URL: https://issues.jboss.org/browse/RF-13505
> Project: RichFaces
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Affects Versions: 5.0.0.Alpha3
> Reporter: Lukáš Fryč
> Assignee: Lukáš Fryč
> Priority: Critical
> Fix For: 4.5.0.Alpha3
>
> Attachments: fu-request.png
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> Mojarra issue: https://java.net/jira/browse/JAVASERVERFACES-3151
> We will still need to use some:
> * resolve values in runtime
> * add IDs for execution of AjaxOutput's
> * collect list of meta-components to render
> * wrap PartialResponseWriter#endDocument() for RichFaces extensions and JavascriptService
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 6 months
[JBoss JIRA] (RF-13505) Refactor custom tree traversal logic in EPVCI in order to leverage VisitContextFactory (blocked by Mojarra issue)
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13505?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč edited comment on RF-13505 at 5/22/14 6:30 AM:
----------------------------------------------------------
*Second one:*
The problem is based in an approach how file upload sends request parameters to the server.
fileupload.js sets up parameters in a) query string b) request body (as form params).
This is odd, because undertow(?) detects just query string {{rf_fu_uid}} as a parameter and leaves form params unnoticed.
Because one of the form params is also {{org.richfaces.ajax.component}} parameter, EPVC assumes the request does not come from RichFaces component and delegates partial request processing to JSF impl. In JSF impl, implicitly rendered areas are not considered.
See attached image [{{fu-request.png}}|https://issues.jboss.org/secure/attachment/12382531/fu-request.png] for illustration of the problem.
was (Author: lfryc):
*Second one:*
The problem is based in an approach how file upload sends request parameters to the server.
fileupload.js sets up parameters in a) query string b) request body (as form params).
This is odd, because undertow(?) detects just query string {{rf_fu_uid}} as a parameter and leaves form params unnoticed.
Because one of the form params is also {{org.richfaces.ajax.component}} parameter, EPVC assumes the request does not come from RichFaces component and delegates partial request processing to JSF impl. In JSF impl, implicitly rendered areas are not considered.
See attached image {{fu-request.png} for illustration of the problem.
> Refactor custom tree traversal logic in EPVCI in order to leverage VisitContextFactory (blocked by Mojarra issue)
> -----------------------------------------------------------------------------------------------------------------
>
> Key: RF-13505
> URL: https://issues.jboss.org/browse/RF-13505
> Project: RichFaces
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Affects Versions: 5.0.0.Alpha3
> Reporter: Lukáš Fryč
> Assignee: Lukáš Fryč
> Priority: Critical
> Fix For: 4.5.0.Alpha3
>
> Attachments: fu-request.png
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> Mojarra issue: https://java.net/jira/browse/JAVASERVERFACES-3151
> We will still need to use some:
> * resolve values in runtime
> * add IDs for execution of AjaxOutput's
> * collect list of meta-components to render
> * wrap PartialResponseWriter#endDocument() for RichFaces extensions and JavascriptService
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 6 months
[JBoss JIRA] (RF-11301) Sub table: not possible to use data scroller on several subtables
by Jiří Štefek (JIRA)
[ https://issues.jboss.org/browse/RF-11301?page=com.atlassian.jira.plugin.s... ]
Jiří Štefek closed RF-11301.
----------------------------
Resolution: Out of Date
Works with latest 4.3.x, 4.5.x and 5.0.x RichFaces
> Sub table: not possible to use data scroller on several subtables
> -----------------------------------------------------------------
>
> Key: RF-11301
> URL: https://issues.jboss.org/browse/RF-11301
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 4.1.0.Milestone1, 4.2.2.Final
> Environment: RichFaces 4.1.0-SNAPSHOT r.d0f9c11eb0dacc1444c0a3182b12567e28aef6bc
> Metamer 4.1.0-SNAPSHOT r.22616
> Mojarra 2.1.2-FCS
> Apache Tomcat 7.0.19
> OpenJDK Runtime Environment 1.6.0_22-b22 @ Linux
> Chrome 13.0.782.112 @ Linux i686
> Reporter: Pavol Pitonak
> Fix For: 4.3.7
>
>
> 1. deploy Metamer and open http://localhost:8080/metamer/faces/components/richCollapsibleSubTable/sc...
> 2. scroll "Men" subtable to page 2 using "Next" button
> 3. scroll "Men" subtable to page 3 using "Next" button
> result:
> subtable is scrolled on page 2 but scrolling to page 3 doesn't work
> 4. scroll "Women" subtable to page 2 using "Next" button
> result:
> subtable "Men" is back on page 1
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 6 months
[JBoss JIRA] (RF-11301) Sub table: not possible to use data scroller on several subtables
by Jiří Štefek (JIRA)
[ https://issues.jboss.org/browse/RF-11301?page=com.atlassian.jira.plugin.s... ]
Jiří Štefek updated RF-11301:
-----------------------------
Fix Version/s: 4.3.7
(was: 5-Future)
> Sub table: not possible to use data scroller on several subtables
> -----------------------------------------------------------------
>
> Key: RF-11301
> URL: https://issues.jboss.org/browse/RF-11301
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 4.1.0.Milestone1, 4.2.2.Final
> Environment: RichFaces 4.1.0-SNAPSHOT r.d0f9c11eb0dacc1444c0a3182b12567e28aef6bc
> Metamer 4.1.0-SNAPSHOT r.22616
> Mojarra 2.1.2-FCS
> Apache Tomcat 7.0.19
> OpenJDK Runtime Environment 1.6.0_22-b22 @ Linux
> Chrome 13.0.782.112 @ Linux i686
> Reporter: Pavol Pitonak
> Fix For: 4.3.7
>
>
> 1. deploy Metamer and open http://localhost:8080/metamer/faces/components/richCollapsibleSubTable/sc...
> 2. scroll "Men" subtable to page 2 using "Next" button
> 3. scroll "Men" subtable to page 3 using "Next" button
> result:
> subtable is scrolled on page 2 but scrolling to page 3 doesn't work
> 4. scroll "Women" subtable to page 2 using "Next" button
> result:
> subtable "Men" is back on page 1
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 6 months