[jira] Commented: (MYFACES-2594) Facelets state saving doesn't handle well programmatic component manipulation
[
https://issues.apache.org/jira/browse/MYFACES-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843459#action_12843459
]
Werner Punz commented on MYFACES-2594:
--
Dont get me wrong here since I am more an outsider on this one, but shouldn´t
this be fixable by dragging some kind of child meta information into the delta
state, if the user changes something.
> Facelets state saving doesn't handle well programmatic component manipulation
> -
>
> Key: MYFACES-2594
> URL: https://issues.apache.org/jira/browse/MYFACES-2594
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.0-beta-3
> Environment: myfaces trunk
>Reporter: Martin Koci
>Priority: Minor
>
> Simple tests (code pasted below) outputs following results:
> 1) JSP: switchs colums at every click with no problem
> 2) Facelets with javax.faces.PARTIAL_STATE_SAVING=false - no visual switch
> 3) Facelets with javax.faces.PARTIAL_STATE_SAVING=true switchs colums at
> every click with no problem
> Common code from test.jspx and test.xhtml
> ... jsp: or facelets stuff here ...
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> @ManagedBean
> @RequestScoped
> public class TestBean implements ActionListener {
> public void processAction(ActionEvent event) throws
> AbortProcessingException {
> FacesContext context = FacesContext.getCurrentInstance();
> UIComponent table =
> context.getViewRoot().findComponent("form:table");
> UIComponent column1 = table.getChildren().get(0);
> UIComponent column2 = table.getChildren().get(1);
> table.getChildren().clear();
> table.getChildren().add(column2);
> table.getChildren().add(column1);
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1750) Update NameResolver's getProvider doc to say it should return null instead of returning IOException since IOExceptions are expensive
Update NameResolver's getProvider doc to say it should return null instead of returning IOException since IOExceptions are expensive Key: TRINIDAD-1750 URL: https://issues.apache.org/jira/browse/TRINIDAD-1750 Project: MyFaces Trinidad Issue Type: Improvement Components: Skinning Reporter: Jeanne Waldman Assignee: Jeanne Waldman We might call NameResolver getProvider in a loop for each custom NameResolver - if there are custom NameResolvers. And if so, then we do not want the method to return IOException if the file cannot be resolved. Therefore, change the javadoc to say it should return null if the file name cannot be resolved. Also, update the implementations that we have now so that we do not get NullPointerExceptions if getProvider returns null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1727) Tag Doc to list JS Component Class
[ https://issues.apache.org/jira/browse/TRINIDAD-1727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeanne Waldman updated TRINIDAD-1727: - Resolution: Fixed Fix Version/s: 1.2.13-plugins Status: Resolved (was: Patch Available) > Tag Doc to list JS Component Class > -- > > Key: TRINIDAD-1727 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1727 > Project: MyFaces Trinidad > Issue Type: Improvement > Components: Documentation >Affects Versions: 1.2.11-plugins >Reporter: Maria Kaval >Assignee: Jeanne Waldman >Priority: Minor > Fix For: 1.2.13-plugins > > Attachments: JIRA1727.patch > > > In the component summary section of the component tag doc today, there is a > line for "UIComponent Class". The UI component class then links to the Java > Doc for the corresponding Java Class. This JIRA will track two things: > 1) Rename "UIComponent Class" to "Java Class" > 2) Add a "JavaScript Class" line to the component summary section at the top > of the tag doc which will link to the corresponding JS doc in the js_docs_out > directory -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-1746) move InputStreamProvider to be a public API
[ https://issues.apache.org/jira/browse/TRINIDAD-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeanne Waldman resolved TRINIDAD-1746. -- Resolution: Fixed Fix Version/s: 1.2.13-core > move InputStreamProvider to be a public API > --- > > Key: TRINIDAD-1746 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1746 > Project: MyFaces Trinidad > Issue Type: Improvement > Components: Skinning >Affects Versions: 1.2.13-core >Reporter: Jeanne Waldman >Assignee: Jeanne Waldman > Fix For: 1.2.13-core > > Attachments: MoveInputStreamProviderToAPI1.2.12.patch, > MoveISPAndNameResolverToAPI1.2.12.patch > > > Make InputStreamProvider a public API. > This means move > org.apache.myfaces.trinidadinternal.share.io.InputStreamProvider > to > org.apache.myfaces.trinidad.share.io.InputStreamProvider > This is needed to implement TRINIDAD-1729 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2594) Facelets state saving doesn't handle well programmatic component manipulation
[
https://issues.apache.org/jira/browse/MYFACES-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843322#action_12843322
]
Martin Koci commented on MYFACES-2594:
--
PARTIAL_STATE_SAVING=false: the problem is that switched order of components is
never saved. VDL.buildView during Render Response reverts it back. The most
suspicious are if -conditons in ComponentTagHandlerDelegate:
if (facetName == null)
{
parent.getChildren().remove(c);
}
and
if (facetName == null)
{
parent.getChildren().add(c);
}
Result of Render Response is UIData with children=[column1,column2] although
after Invoke Application it was children=[column2,column1]
> Facelets state saving doesn't handle well programmatic component manipulation
> -
>
> Key: MYFACES-2594
> URL: https://issues.apache.org/jira/browse/MYFACES-2594
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.0-beta-3
> Environment: myfaces trunk
>Reporter: Martin Koci
>Priority: Minor
>
> Simple tests (code pasted below) outputs following results:
> 1) JSP: switchs colums at every click with no problem
> 2) Facelets with javax.faces.PARTIAL_STATE_SAVING=false - no visual switch
> 3) Facelets with javax.faces.PARTIAL_STATE_SAVING=true switchs colums at
> every click with no problem
> Common code from test.jspx and test.xhtml
> ... jsp: or facelets stuff here ...
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> @ManagedBean
> @RequestScoped
> public class TestBean implements ActionListener {
> public void processAction(ActionEvent event) throws
> AbortProcessingException {
> FacesContext context = FacesContext.getCurrentInstance();
> UIComponent table =
> context.getViewRoot().findComponent("form:table");
> UIComponent column1 = table.getChildren().get(0);
> UIComponent column2 = table.getChildren().get(1);
> table.getChildren().clear();
> table.getChildren().add(column2);
> table.getChildren().add(column1);
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2594) Facelets state saving doesn't handle well programmatic component manipulation
[
https://issues.apache.org/jira/browse/MYFACES-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843297#action_12843297
]
Leonardo Uribe commented on MYFACES-2594:
-
At first view, I think the case with PARTIAL_STATE_SAVING=false should work
(because the whole tree is saved and restored) and the case with
PARTIAL_STATE_SAVING=true should not. We should verify these conditions first.
> Facelets state saving doesn't handle well programmatic component manipulation
> -
>
> Key: MYFACES-2594
> URL: https://issues.apache.org/jira/browse/MYFACES-2594
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.0-beta-3
> Environment: myfaces trunk
>Reporter: Martin Koci
>Priority: Minor
>
> Simple tests (code pasted below) outputs following results:
> 1) JSP: switchs colums at every click with no problem
> 2) Facelets with javax.faces.PARTIAL_STATE_SAVING=false - no visual switch
> 3) Facelets with javax.faces.PARTIAL_STATE_SAVING=true switchs colums at
> every click with no problem
> Common code from test.jspx and test.xhtml
> ... jsp: or facelets stuff here ...
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> @ManagedBean
> @RequestScoped
> public class TestBean implements ActionListener {
> public void processAction(ActionEvent event) throws
> AbortProcessingException {
> FacesContext context = FacesContext.getCurrentInstance();
> UIComponent table =
> context.getViewRoot().findComponent("form:table");
> UIComponent column1 = table.getChildren().get(0);
> UIComponent column2 = table.getChildren().get(1);
> table.getChildren().clear();
> table.getChildren().add(column2);
> table.getChildren().add(column1);
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2594) Facelets state saving doesn't handle well programmatic component manipulation
[
https://issues.apache.org/jira/browse/MYFACES-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843290#action_12843290
]
Jakob Korherr commented on MYFACES-2594:
Mhm. This is caused, because the current state saving mechanism relies on
rebuilding the view from the VDL page (.xhtml or .jsp). I also had a problem
with this once.
It seems that we somehow have to detect those dynamic tree alterations and also
store them in the state to be able to restore them in the next postback. The
best thing would be to check for the current lifecycle phase when the children
of a component are altered, I think.
Unfortunately I guess the spec does not say anything about this...
> Facelets state saving doesn't handle well programmatic component manipulation
> -
>
> Key: MYFACES-2594
> URL: https://issues.apache.org/jira/browse/MYFACES-2594
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.0-beta-3
> Environment: myfaces trunk
>Reporter: Martin Koci
>Priority: Minor
>
> Simple tests (code pasted below) outputs following results:
> 1) JSP: switchs colums at every click with no problem
> 2) Facelets with javax.faces.PARTIAL_STATE_SAVING=false - no visual switch
> 3) Facelets with javax.faces.PARTIAL_STATE_SAVING=true switchs colums at
> every click with no problem
> Common code from test.jspx and test.xhtml
> ... jsp: or facelets stuff here ...
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> @ManagedBean
> @RequestScoped
> public class TestBean implements ActionListener {
> public void processAction(ActionEvent event) throws
> AbortProcessingException {
> FacesContext context = FacesContext.getCurrentInstance();
> UIComponent table =
> context.getViewRoot().findComponent("form:table");
> UIComponent column1 = table.getChildren().get(0);
> UIComponent column2 = table.getChildren().get(1);
> table.getChildren().clear();
> table.getChildren().add(column2);
> table.getChildren().add(column1);
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2594) Facelets state saving doesn't handle well programmatic component manipulation
[
https://issues.apache.org/jira/browse/MYFACES-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843284#action_12843284
]
Martin Koci commented on MYFACES-2594:
--
This problem is the same issue I've reported against mojarra:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1414
Please note that myfaces have problem only in case of
PARTIAL_STATE_SAVING=false.
> Facelets state saving doesn't handle well programmatic component manipulation
> -
>
> Key: MYFACES-2594
> URL: https://issues.apache.org/jira/browse/MYFACES-2594
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.0-beta-3
> Environment: myfaces trunk
>Reporter: Martin Koci
>Priority: Minor
>
> Simple tests (code pasted below) outputs following results:
> 1) JSP: switchs colums at every click with no problem
> 2) Facelets with javax.faces.PARTIAL_STATE_SAVING=false - no visual switch
> 3) Facelets with javax.faces.PARTIAL_STATE_SAVING=true switchs colums at
> every click with no problem
> Common code from test.jspx and test.xhtml
> ... jsp: or facelets stuff here ...
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> @ManagedBean
> @RequestScoped
> public class TestBean implements ActionListener {
> public void processAction(ActionEvent event) throws
> AbortProcessingException {
> FacesContext context = FacesContext.getCurrentInstance();
> UIComponent table =
> context.getViewRoot().findComponent("form:table");
> UIComponent column1 = table.getChildren().get(0);
> UIComponent column2 = table.getChildren().get(1);
> table.getChildren().clear();
> table.getChildren().add(column2);
> table.getChildren().add(column1);
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2593) styles are escaped so that @import *.css doesn't work
[ https://issues.apache.org/jira/browse/MYFACES-2593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr resolved MYFACES-2593. Resolution: Fixed Fix Version/s: 2.0.0-beta-3 > styles are escaped so that @import *.css doesn't work > - > > Key: MYFACES-2593 > URL: https://issues.apache.org/jira/browse/MYFACES-2593 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.0-beta-2 > Environment: CSS >Reporter: Ganesh Jung >Assignee: Jakob Korherr > Fix For: 2.0.0-beta-3 > > > This one doesn't pull the script with MyFaces 2.0: > > @import "test.css" > > No problem with Mojarra here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2594) Facelets state saving doesn't handle well programmatic component manipulation
Facelets state saving doesn't handle well programmatic component manipulation
-
Key: MYFACES-2594
URL: https://issues.apache.org/jira/browse/MYFACES-2594
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.0.0-beta-3
Environment: myfaces trunk
Reporter: Martin Koci
Priority: Minor
Simple tests (code pasted below) outputs following results:
1) JSP: switchs colums at every click with no problem
2) Facelets with javax.faces.PARTIAL_STATE_SAVING=false - no visual switch
3) Facelets with javax.faces.PARTIAL_STATE_SAVING=true switchs colums at every
click with no problem
Common code from test.jspx and test.xhtml
... jsp: or facelets stuff here ...
@ManagedBean
@RequestScoped
public class TestBean implements ActionListener {
public void processAction(ActionEvent event) throws
AbortProcessingException {
FacesContext context = FacesContext.getCurrentInstance();
UIComponent table =
context.getViewRoot().findComponent("form:table");
UIComponent column1 = table.getChildren().get(0);
UIComponent column2 = table.getChildren().get(1);
table.getChildren().clear();
table.getChildren().add(column2);
table.getChildren().add(column1);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Google SoC
This is in regard with how Trinidad handle JavaScript free fallback during mobile rendering. Basically, we assign the JavaScript capability for a few mobile user-agents to 'none' in their capability files (Trinidad maintains a capability file for each user-agent). The method supportsScripting determines whether to fallback based on a user-agent's JavaScript capability, and this method is available in org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.XhtmlRenderer. I guess we can tweak this method based on some configuration parameter to return false to accomplish JavaScript free fallback. Mechanism behind JavaScript free fallback: The primary purpose of the JavaScript in the client-side is to assign values to parameters like source, event, etc. 1) During fallback rendering, we encode all these parameters and their values to the name attribute of a component. Example, for commandButton, we render: All components that are intended to submit a page are rendered as input element of type 'submit' and their name attributes are encoded with parameters and their values. Also, we render a hidden parameter '_noJavaScript' during form rendering to indicate that parameters are encoded. 2) During page submission, the submitting component's name attribute which contains the encoded parameters will be returned to the server. In the Trinidad filter, we check for the hidden parameter '_noJavaScript', if true, we wrap the incoming httpRequest with a wrapper that decoded these parameters from the name attribute. The wrapper adds these decoded parameters (source, event) to the parameterMap. Wrapper Class: org.apache.myfaces.trinidadinternal.webapp.wrappers.BasicHTMLBrowserRequestWrapper Example, a page has two commandButtons, whose source parameters are 'commandButton1' and 'commandButton2' respectively. These commandButtons will be rendered as below: if the page is submitted by commandButton2, the payload will contain 'source_parameterkeycommandButton2'. Hence, the wrapper can decoded the source parameter value to be 'commandButton2' Hope it helps. Thanks Mamallan On 3/9/2010 9:51 AM, Matthias Wessendorf wrote: On Tue, Mar 9, 2010 at 8:19 AM, Martin Marinschek wrote: Ok - if you are alright with that, I would have some more proposals. Some starters in the following: - Partial State Saving performance improvements in MyFaces 2.0 - Implement a JavaScript-Free Fallback in Tomahawk, Trinidad and/or Tobago Trinidad has some fallback already, however it is only applied when mobile rendering is involved (by user-agent detection of the components). So, we could port that... Basically, we assign the JavaScript capability for a few mobile user-agents to 'none' in their capability files (Trinidad maintains a capability file for each user-agent). The method supportsScripting which determines whether to fallback based on a user-agent's JavaScript capability is available in org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.XhtmlRenderer. I guess we can tweak this method based on some configuration parameter to return false to accomplish JavaScript free fallback. Mechanism behind JavaScript free fallback: The primary purpose of the JavaScript in the client-side is to assign values to parameters like source, event, etc. 1) During fallback rendering, we encode all these parameters and their values to the name attribute of a component. Example, for commandButton, we render: All components that are intended to submit a page are rendered as input element of type 'submit' and their name attributes are encoded with parameters and their values. Also, we render a hidden parameter '_noJavaScript' during form rendering to indicate that parameters are encoded. 2) During page submission, the submitting component's name attribute which contains the encoded parameters will be returned to the server. In the Trinidad filter, we check for the hidden parameter '_noJavaScript', if true, we wrap the incoming httpRequest with a wrapper that decoded these parameters from the name attribute. The wrapper adds these decoded parameters (source, event) to the parameterMap. Wrapper Class: org.apache.myfaces.trinidadinternal.webapp.wrappers.BasicHTMLBrowserRequestWrapper Example, a page has two commandButtons, whose source parameters are 'commandButton1' and 'commandButton2' respectively. These commandButtons will be rendered as below: if the page is submitted by commandButton2, the payload will contain 'source_parameterkeycommandButton2'. Hence, the wrapper can decoded the source parameter value to be 'commandButton2' Hope it helps. Thanks Mamallan Thanks Mamallan - Write (more) new skins for Trinidad yeah! :-) - Implement Double-Submit-Handling/Back-Button Handling in one of the MyFaces subprojects - Extend Orchestra use Conversations based on the JSF 2.0 custom scope API, Extend Orchestra to work with Spring Conver
[jira] Commented: (MYFACES-2593) styles are escaped so that @import *.css doesn't work
[ https://issues.apache.org/jira/browse/MYFACES-2593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843277#action_12843277 ] Jakob Korherr commented on MYFACES-2593: After some debugging I found out that gets escaped in the HtmlResponseWriterImpl. Unfortunately I can't imagine why this was done. I've never heard before that the content of