Re: javax.faces.ViewState hidden field
JSF 1.2 standardized on the identifier: javax.faces.ViewState, previous versions of JSF 1.1 (myfaces and RI) each had their own identifiers which caused difficulties for component developers lightbulb432 wrote: What is the purpose of the hidden field named javax.faces.ViewState, and how does it differ from the following hidden fields: - jsf_view_64 - jsf_tree_64 Also, I noticed some sample HTML outputs from JSF, and they had multiple javax.faces.ViewState hidden fields throughout the page. I also noticed each hidden field was on a separate table (i.e. no table had more than one javax.faces.ViewState), and that each occurrence of the hidden field had exactly the same value. Finally, I noticed that some tables on the page had this hidden field and others did not. Any component has the option of rendering the ViewState, traditionally this is done at the start or tail of an h:form's rendered output. Some developers still put in multiple/separate h:forms in a page, forcing the ViewState to be rendered within each form/scope. A common practice is to always put a single h:form around all of your content. This can be done easily if you use templating languages like Facelets where all of your pages use one parent template that has one h:form around everything. What determines whether a table has this hidden field or not? It's up to the components you use for the most part, except the the enforced case of h:form. I was just amazed by the huge inefficiency in having to transfer 3x the hidden form field data (when each hidden field value is so large as it is) when they all have the exact same value! Would this be a good case to use server-side state saving, because the bandwidth not doing so would eat up would be huge, right? I'd be surprised what component would be rendering the page state multiple times if not multiple h:forms in the page. Since javax.faces.ViewState is now a standard identifier, components with JavaScript logic for postback (ala AJAX) could easily pull out the ViewState from that one DOM source in the page instead of requiring a separate render. There are outlining issues with repeated javax.faces.ViewState nodes in the page and sharing the same identifier (DOM no-no), but we can get around this by rendering: id="javax.faces.ViewState" value=""/> id="javax.faces.ViewState0" value=""/> id="javax.faces.ViewState1" value=""/>
javax.faces.ViewState hidden field
What is the purpose of the hidden field named javax.faces.ViewState, and how does it differ from the following hidden fields: - jsf_view_64 - jsf_tree_64 Also, I noticed some sample HTML outputs from JSF, and they had multiple javax.faces.ViewState hidden fields throughout the page. I also noticed each hidden field was on a separate table (i.e. no table had more than one javax.faces.ViewState), and that each occurrence of the hidden field had exactly the same value. Finally, I noticed that some tables on the page had this hidden field and others did not. What determines whether a table has this hidden field or not? I was just amazed by the huge inefficiency in having to transfer 3x the hidden form field data (when each hidden field value is so large as it is) when they all have the exact same value! Would this be a good case to use server-side state saving, because the bandwidth not doing so would eat up would be huge, right? -- View this message in context: http://www.nabble.com/javax.faces.ViewState-hidden-field-tf2864080.html#a8003754 Sent from the My Faces - Dev mailing list archive at Nabble.com.
Re: Reason behind jsf_sequence?
When a postback occurs, the ViewState is restored from the previous request-- in the case of: Client: The ViewState is serialized and posted back to the server-- so you could render a page, come back 5 hours later and click a button, sending the state you have stored in the page back to the server for use. Server: The ViewState is stored on the server, so the page only has a sequence number to identify, on postback, which rendered state we should use. lightbulb432 wrote: That's a good point. Few follow ups below: 1) Could you please explain what, on a high level, the general algorithm used by the server would be to see whether the state is part of the same "sequence" of activities? e.g. if I open up two windows and am doing two different things at the same time, couldn't potentially the jsf_sequences in the first window be 1,3,5,7,9... and for the second window be 2,4,6,8,10...? There is no continuity with ViewState-- nor is there an expectation on the 'sequence' of identifiers, it could be any unique number. Theoretically, you could store ViewState globally in the application scope, handing out identifiers from one, shared sequence number. So I think there's some confusion with the term 'sequence' here, since it should just be 'unique id' or 'primary key' How would the server generally tell which came from which window using jsf_sequence? Because each window would postback the id rendered in that page, telling the server which ViewState to associate to process update/action logic. 2) A somewhat related question I have is what is the difference between the back button problem for client-side and server-side state saving? From what I've read in articles/posts/books, I get the impression that it's a bigger problem with server-side than client-side state saving (e.g. even your post singled out server-side). I know that the state is stored in the actual page as a hidden field with client-side, but I can't conceptualize how that solves the problem...after all, if you hit the back button, aren't you looking at an outdated component tree even with client-side, because that's what the hidden field has stored? When you use client-side state saving, you, the client, are always passing in the page state you are currently viewing, there's no opportunity to become disjoint from the server state because it's all on the client. Original implementations of server-side state did not have any uid/sequence associated, so as you hit the back and forward button, there was opportunity for disconnect on what version of 'main.faces' you were actually working with. Since server-side state now pases a uid/sequence on postback, there's no question as to which version of 'main.faces' you were currently viewing. 3) You mentioned that jsf_sequence is used with server-side state saving, but I've noticed it in client-side state-saving's generated HTML as well. Could you perhaps describe how it would be used with client-side? (Same reason as for server-side? I'm basically wondering why you singled out server-side...maybe it'll have something to do with the response to my question #2...) jsf_sequence may be used or rendered for other reasons, but i don't think it's necessary to supplement client-side statesaving since the rendered Base64 string *is* the viewstate and not just some identifier. -- Jacob Thanks a lot. Jacob Hookom wrote: If it's like the RI, the reasoning is to accommodate the back button issue with server-side state saving. It would be wrong to assume/associate a single state with a page given multiple windows and back button use. Using a sequence adds a level of uniqueness to state which is equal to 'page + sequence id'. I've been noticing in my output a jsf_sequence hidden form field that increments on what seems to be each request. What's the reason for such an incrementing hidden field? Does it have something to do with this "back button issue"? If so, how? I tried using a debugger but quickly got overwhelmed... :( -- View this message in context: http://www.nabble.com/Reason-behind-jsf_sequence--tf2860440.html#a7992103 Sent from the My Faces - Dev mailing list archive at Nabble.com.
RE: Reason behind jsf_sequence?
That's a good point. Few follow ups below: 1) Could you please explain what, on a high level, the general algorithm used by the server would be to see whether the state is part of the same "sequence" of activities? e.g. if I open up two windows and am doing two different things at the same time, couldn't potentially the jsf_sequences in the first window be 1,3,5,7,9... and for the second window be 2,4,6,8,10...? How would the server generally tell which came from which window using jsf_sequence? 2) A somewhat related question I have is what is the difference between the back button problem for client-side and server-side state saving? From what I've read in articles/posts/books, I get the impression that it's a bigger problem with server-side than client-side state saving (e.g. even your post singled out server-side). I know that the state is stored in the actual page as a hidden field with client-side, but I can't conceptualize how that solves the problem...after all, if you hit the back button, aren't you looking at an outdated component tree even with client-side, because that's what the hidden field has stored? 3) You mentioned that jsf_sequence is used with server-side state saving, but I've noticed it in client-side state-saving's generated HTML as well. Could you perhaps describe how it would be used with client-side? (Same reason as for server-side? I'm basically wondering why you singled out server-side...maybe it'll have something to do with the response to my question #2...) Thanks a lot. Jacob Hookom wrote: > > If it's like the RI, the reasoning is to accommodate the back button issue > with server-side state saving. It would be wrong to assume/associate a > single state with a page given multiple windows and back button use. > Using a sequence adds a level of uniqueness to state which is equal to > 'page + sequence id'. > > >> >>I've been noticing in my output a jsf_sequence hidden form field that >>increments on what seems to be each request. What's the reason for such an >>incrementing hidden field? >> >>Does it have something to do with this "back button issue"? If so, how? >> >>I tried using a debugger but quickly got overwhelmed... :( >>-- >>View this message in context: >>http://www.nabble.com/Reason-behind-jsf_sequence--tf2860440.html#a7992103 >>Sent from the My Faces - Dev mailing list archive at Nabble.com. >> > > -- View this message in context: http://www.nabble.com/Reason-behind-jsf_sequence--tf2860440.html#a8003568 Sent from the My Faces - Dev mailing list archive at Nabble.com.
Re: IDEA: client-side state manager that restores majority of saved state from initial tree state
Adam Winer (Oracle ADF), Ed Burns (JSF Co-Spec Lead), and myself talked about this in combination with Facelets at JavaOne last year, we actually have some numbers generated: http://weblogs.java.net/blog/edburns/archive/2006/05/javaone_video_a_1.html (video, excuse my Minnesota slang) Facelets currently does have an option to build a tree completely on post back as an alternative to StateSaving, some of this (theory) is described here: http://weblogs.java.net/blog/jhook/archive/2006/01/experiment_goin_1.html Some caveats occur with UIInputs default behavior for ValueChangeListeners instead of comparing the sent value to the bound variable, it instead compares to the last value rendered-- preventing a stateless postback from firing ValueChangeEvents. There are others-- but the moral is that any state stored should be an extreme rarity if we can assert a consistent component model (everything is a UIComponent). JSF's unique approach to View/Model separation only re-enforces the perspective of UIComponents as pure mediators for the request (render or postback). JSF's rules around Client Id generation and API methods such as findComponent and invokeOnComponent prove that we can do some pretty cool things with structual consistency. I would like to see this re-architected for JSF 2.0 such that only sparse usages of a @Stateful annotation on a UIComponent's member field is required and viewstate can then stay below a few hundred bytes instead of a few hundred kilobytes, stateless in most cases unless you have some 'counter' component. With frameworks such as JMaki, Dojo, YUI-Ext, etc-- we are seeing a strong push to componentize within the browser via JavaScript-- well, as we talked about in our JavaOne presentation-- there's usually some server-side facet to mediate the communication. Many of these frameworks require development of separate endpoints, but if we take something like JSF's specific rules for page/clientId negotiation-- then we can start to combine/relate these components in a richer fashion on the server. Many solutions such as JMake, Dojo, and GWT try to mediate multiple events on the client, resulting in 5 or 6 separate request/responses to complete a task on the client (even initial load)-- where the Avatar/Ajax4jsf solutions can deliver multiple changes from their UIComponent counterparts in a single request/response, while keeping within the full JEE stack on the server-- -- Jacob Thomas Spiegl wrote: Maybe you can take a look at the Trinidad approach. I think Trinidad solves state-saving more effective than tomahawk or myfaces does. On 12/20/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote: I'm a fan of client-side state saving. It solves a lot of issues for me. However, there's no doubt that it requires more bandwidth due to saving the entire component tree state in a hidden input field. I wonder how much of this is really necessary. I'm guessing 90% of the state saved is simply constant for a given page.The two examples I can think of where this wouldn't be true would be the localValue for a UIInput or java code that directly manipulates a component. It seems like the state manager could preserve (or recreate) the original state of the component from the page code, compare that state with the current state of the component, and then mark it with a boolean value (didStateChange). For most components, this would result in a save state size of one boolean (no more than a char, and could probably even been put into a bit array if one needed to. For components whose state did differ from the original state, it would require one additional boolean value. This should work for any JSF implementation. A clever implementation could go a step further and separate the state saved into "state that rarely differs" and "state that always differs (UIInput localValue, for instance)" so as to reduce even the 10% remaining. So we'd be trading off network (and html size) bandwidth for server-side processing (or perhaps memory if you were willing to cache original page states in the application). Anyone else have any thoughts on this idea?
Re: MyFaces 1.1.5 Release Status?
On 12/21/06, Jeff Bischoff <[EMAIL PROTECTED]> wrote: [...] The problem with this is that, despite lengthening your release cycle, you are still having trouble with release stability. In order to achieve this stability, you either need to be willing to branch for extensive testing before a release (even though it is meanwhile "getting out of date"). Or, you can take a look at ideas like Paul Spencer's idea for following a Tomcat style of release. If you're going to be releasing code that is only a few days or a week fresh from the trunk, then you're going to need to start releasing maintenance updates to gradually add to their stability. I'm just a humble user, but this is my 2 cents... I would second that. There is no way to apply bug-fix patches without upgrading to a newer, "not-stable-yet" snapshot nightly build. Regards, Aneesha Regards, Jeff Bischoff Kenneth L Kurz & Associates, Inc. Thomas Spiegl wrote: > tomahawk 1.1.4 branch is quite out of date by now. I'd like to skip > this one, and start releasing core and tomahawk 1.1.5 asap. > > > On 12/18/06, Paul Spencer <[EMAIL PROTECTED]> wrote: >> This is yet another release status request. >> >> Current open issue with a Fix Version = 1.1.5-SNAPSHOT >> > MYFACES-1372 not shown (-> not working) >> ** Per an 8-Dec-2006 Posting from Mike Kienenberger: >> MYFACES-1372 not shown (-> not working) is important, >> but it's been broken for 18 months. It's not a regression as far as >> I know. >> >> > MYFACES-1409incorrect behavior after RESTORE_VIEW responseComplete >> >> > MYFACES-1411Lifecycle phase executions repetitions >> ** Per an 8-Dec-2006 Posting from Mike Kienenberger: >> MYFACES-1411 has I.P. issues. >> >> >> > MYFACES-1506Translated messages in Messages.properties files >> ** Per an 8-Dec-2006 Posting from Mike Kienenberger: >> MYFACES-1506 is an improvement. It can be moved to 1.1.6. Actually, >> this is a Tomahawk issue, not a MyFaces one. Should be moved. Not >> sure how Messages.properties interacts with Tomahawk, though. >> >> >> None of the above issue are marked as blockers. Are any of the actually >> blockers to the 1.1.5 release? >> >> >> What is holding up this release? >> >> Paul Spencer >> >> > >
[jira] Created: (TOMAHAWK-829) Batch of Java codes and JavaScript files for creating Dynamic Tables [such as changing between different List, and etceteras]
Batch of Java codes and JavaScript files for creating Dynamic Tables [such as changing between different List, and etceteras] - Key: TOMAHAWK-829 URL: http://issues.apache.org/jira/browse/TOMAHAWK-829 Project: MyFaces Tomahawk Issue Type: New Feature Environment: In my development I have used mainly JDK 1.4 version and JSP 1.1 version. Also I have used the following dtd for facesconfig.xml => http://java.sun.com/dtd/web-facesconfig_1_0.dtd. Reporter: Ji Kim Hi, my name is Ji [a.k.a. G] and as I strongly desire in joining the Apache organization for developmental purpose I wish to contribute some code to the apache myfaces's sandbox. Hopefully I have done everything correctly that I was suppose to, but the likelihood is rather small as this is my first attempt in contributing code to the Apache organization [one thing that I know that will be somewhat faulty is the xdoc]. List of things I have included in this Jira => README.txt describes such thing as filesystem of where I hoped to place the code in myfaces_sandbox_changes.patch [tld patch] faces-config_changes.patch [faces-config patch] (2) javaDoc.zip (3) classes.zip which contains CLASS + JS Files (4) jsES.zip which contains solely JS Files (5) jsp.zip which contains one JSP Example (6)selfmanagetable.jpe for the Xdoc (7)selfmanagetable.xml xdoc containing description of components + tags [I think that this is wrong and will correct itlater] (8)javaSource.zip Java Files [includes JS under SelfManageTableComponet as I used AddResource] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TOMAHAWK-826) Improve outputLabel component to have a different CSS class in case of an error
[
http://issues.apache.org/jira/browse/TOMAHAWK-826?page=comments#action_12460073
]
Alex Savitsky commented on TOMAHAWK-826:
Is this a sandbox component? I only looked at the released components, so must
have missed that one.
Still, it's not so clear with the "if" component, either - what kind of
condition would I put there? It would be something on the lines of "#{empty
facesContext.messages[targetControlId] ? 'normalStyle' : 'errorStyle'}", but
where would I get the targetControlId (the Id of control being labeled, that
is) from, without resorting to "forceId"?
> Improve outputLabel component to have a different CSS class in case of an
> error
> ---
>
> Key: TOMAHAWK-826
> URL: http://issues.apache.org/jira/browse/TOMAHAWK-826
> Project: MyFaces Tomahawk
> Issue Type: Improvement
>Reporter: Alex Savitsky
>Priority: Minor
> Attachments: HtmlFlaggableLabelRenderer.java
>
>
> Currently, the only visual cue for validation errors is to display validation
> messages using . However, quite often there's a different
> requirement for error flagging, namely to identify the field labels (e.g.,
> make them red) if the field has an error. This behavior cannot be achieved
> using available controls, and therefore I propose to enhance an existing
> Label control with this functionality. All it would have to do is to set a
> specified CSS class (and/or CSS style) on a label component, if the field
> referenced with the "for" attribute has an error.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TOMAHAWK-828) Extension Filter incompatibility with the RI
Extension Filter incompatibility with the RI Key: TOMAHAWK-828 URL: http://issues.apache.org/jira/browse/TOMAHAWK-828 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.1 Environment: 1.1 RI + tomahawk and sandbox trunk Reporter: Werner Punz Assigned To: Mario Ivankovits While testing some components for promotion I ran into an issue with the extension filter I am not sure about the root of the problem but the symptoms are like following: The RI in combination with the sandbox runs into a severe resource loading problem at subsequent resource loads, the affected testable component is the fisheye component which relies mostly on javascript only. The error issued in the runtime system is: Error while serving resource: dojo.DojoResourceLoader/dojo.js, message : null ClientAbortException: java.net.SocketException: Connection reset by peer: socket write error at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:366) at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:403) at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:314) at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:278) at org.apache.catalina.connector.CoyoteOutputStream.close(CoyoteOutputStream.java:103) at org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader.writeResource(MyFacesResourceLoader.java:194) at org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader.serveResource(MyFacesResourceLoader.java:167) at org.apache.myfaces.renderkit.html.util.DefaultAddResource.serveResource(DefaultAddResource.java:606) at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:128) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:868) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:663) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) I assume some bug regarding the combination ri and tomahawk in this case because the error is not issued once the ri is replaced by myfaces. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TOMAHAWK-826) Improve outputLabel component to have a different CSS class in case of an error
[ http://issues.apache.org/jira/browse/TOMAHAWK-826?page=comments#action_12460068 ] Jeff Bischoff commented on TOMAHAWK-826: Not to say that I wouldn't support adding such a feature (I think it might be neat), but when you say "This behavior cannot be achieved using available controls...", are you sure you can not achieve this effect using the component added in TOMAHAWK-165? Of course this and similar approaches would require multiple outputLabels for each component, making your proposed solution still preferable. :) [1] http://issues.apache.org/jira/browse/TOMAHAWK-165 > Improve outputLabel component to have a different CSS class in case of an > error > --- > > Key: TOMAHAWK-826 > URL: http://issues.apache.org/jira/browse/TOMAHAWK-826 > Project: MyFaces Tomahawk > Issue Type: Improvement >Reporter: Alex Savitsky >Priority: Minor > Attachments: HtmlFlaggableLabelRenderer.java > > > Currently, the only visual cue for validation errors is to display validation > messages using . However, quite often there's a different > requirement for error flagging, namely to identify the field labels (e.g., > make them red) if the field has an error. This behavior cannot be achieved > using available controls, and therefore I propose to enhance an existing > Label control with this functionality. All it would have to do is to set a > specified CSS class (and/or CSS style) on a label component, if the field > referenced with the "for" attribute has an error. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TOMAHAWK-635) JspTilesViewHandlerImpl doesn't work with Portlets
[ http://issues.apache.org/jira/browse/TOMAHAWK-635?page=comments#action_12460061 ] David Paterson commented on TOMAHAWK-635: - Confirmed identical issue working with Liferay 4.2 and tomahawkbridge-0.9. > JspTilesViewHandlerImpl doesn't work with Portlets > -- > > Key: TOMAHAWK-635 > URL: http://issues.apache.org/jira/browse/TOMAHAWK-635 > Project: MyFaces Tomahawk > Issue Type: Bug > Components: Portlet_Support >Affects Versions: 1.1.1 > Environment: Windows XP, j2sdk1.4.2_06, JBoss Portal 2.0 + JBoss AS > 4.0.2, MyFaces 1.1.1RC3 >Reporter: Aimar Tellitu > Assigned To: Stan Silvert > > I have a web application that it works with MyFaces and Tiles (using the View > Handler org.apache.myfaces.application.jsp.JspTilesViewHandlerImpl. > I'm trying to make it works as a Portlet. But I have found some problems with > JspTilesViewHandlerImpl: >-getServletMapping can't work because with portlet implementation > externalContext.getRequestServletPath() and > externalContext.getRequestPathInfo() always return null (see > org.apache.myfaces.context.portlet.PortletExternalContextImpl). >-In many places of this class there are many references to ServletRequest, > ServletContext, HttpServletRequest and HttpServletResponse. This type-casting > isn't correct when we're working with portlets. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TOMAHAWK-827) inputHtml
inputHtml - Key: TOMAHAWK-827 URL: http://issues.apache.org/jira/browse/TOMAHAWK-827 Project: MyFaces Tomahawk Issue Type: Bug Components: Html Editor Affects Versions: 1.1.3 Environment: Using IE 6 Reporter: Gabriel Enriquez Fix For: 1.1.3 I am able to display using: And there is a JS error. According to this url: http://wiki.apache.org/myfaces/WYSIWYG_Editor?highlight=%28inputHtml%29 (supposedly last update: last edited 2006-02-17 22:28:26 by MikeKienenberger.) It has some bugs. I want to double check if there are still bugs on this component and should try another component like DOJO library. Thanks, Gabriel -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TOMAHAWK-826) Improve outputLabel component to have a different CSS class in case of an error
Improve outputLabel component to have a different CSS class in case of an error --- Key: TOMAHAWK-826 URL: http://issues.apache.org/jira/browse/TOMAHAWK-826 Project: MyFaces Tomahawk Issue Type: Improvement Reporter: Alex Savitsky Priority: Minor Currently, the only visual cue for validation errors is to display validation messages using . However, quite often there's a different requirement for error flagging, namely to identify the field labels (e.g., make them red) if the field has an error. This behavior cannot be achieved using available controls, and therefore I propose to enhance an existing Label control with this functionality. All it would have to do is to set a specified CSS class (and/or CSS style) on a label component, if the field referenced with the "for" attribute has an error. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: MyFaces 1.1.5 Release Status?
Thomas Spiegl wrote: > tomahawk 1.1.4 branch is quite out of date by now. Yes, if it were "current" (i.e. the trunk) it wouldn't be "stable". It was branched ~2 months ago. > I'd like to skip > this one, and start releasing core and tomahawk 1.1.5 asap. > This seems such a common tendency of the myfaces team, to be eager to get the new functionality out and released. The problem with this is that, despite lengthening your release cycle, you are still having trouble with release stability. In order to achieve this stability, you either need to be willing to branch for extensive testing before a release (even though it is meanwhile "getting out of date"). Or, you can take a look at ideas like Paul Spencer's idea for following a Tomcat style of release. If you're going to be releasing code that is only a few days or a week fresh from the trunk, then you're going to need to start releasing maintenance updates to gradually add to their stability. I'm just a humble user, but this is my 2 cents... Regards, Jeff Bischoff Kenneth L Kurz & Associates, Inc. Thomas Spiegl wrote: tomahawk 1.1.4 branch is quite out of date by now. I'd like to skip this one, and start releasing core and tomahawk 1.1.5 asap. On 12/18/06, Paul Spencer <[EMAIL PROTECTED]> wrote: This is yet another release status request. Current open issue with a Fix Version = 1.1.5-SNAPSHOT > MYFACES-1372 not shown (-> not working) ** Per an 8-Dec-2006 Posting from Mike Kienenberger: MYFACES-1372 not shown (-> not working) is important, but it's been broken for 18 months. It's not a regression as far as I know. > MYFACES-1409incorrect behavior after RESTORE_VIEW responseComplete > MYFACES-1411Lifecycle phase executions repetitions ** Per an 8-Dec-2006 Posting from Mike Kienenberger: MYFACES-1411 has I.P. issues. > MYFACES-1506Translated messages in Messages.properties files ** Per an 8-Dec-2006 Posting from Mike Kienenberger: MYFACES-1506 is an improvement. It can be moved to 1.1.6. Actually, this is a Tomahawk issue, not a MyFaces one. Should be moved. Not sure how Messages.properties interacts with Tomahawk, though. None of the above issue are marked as blockers. Are any of the actually blockers to the 1.1.5 release? What is holding up this release? Paul Spencer
Re: IDEA: client-side state manager that restores majority of saved state from initial tree state
Maybe you can take a look at the Trinidad approach. I think Trinidad solves state-saving more effective than tomahawk or myfaces does. On 12/20/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote: I'm a fan of client-side state saving. It solves a lot of issues for me. However, there's no doubt that it requires more bandwidth due to saving the entire component tree state in a hidden input field. I wonder how much of this is really necessary. I'm guessing 90% of the state saved is simply constant for a given page.The two examples I can think of where this wouldn't be true would be the localValue for a UIInput or java code that directly manipulates a component. It seems like the state manager could preserve (or recreate) the original state of the component from the page code, compare that state with the current state of the component, and then mark it with a boolean value (didStateChange). For most components, this would result in a save state size of one boolean (no more than a char, and could probably even been put into a bit array if one needed to. For components whose state did differ from the original state, it would require one additional boolean value. This should work for any JSF implementation. A clever implementation could go a step further and separate the state saved into "state that rarely differs" and "state that always differs (UIInput localValue, for instance)" so as to reduce even the 10% remaining. So we'd be trading off network (and html size) bandwidth for server-side processing (or perhaps memory if you were willing to cache original page states in the application). Anyone else have any thoughts on this idea? -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
IDEA: client-side state manager that restores majority of saved state from initial tree state
I'm a fan of client-side state saving. It solves a lot of issues for me. However, there's no doubt that it requires more bandwidth due to saving the entire component tree state in a hidden input field. I wonder how much of this is really necessary. I'm guessing 90% of the state saved is simply constant for a given page.The two examples I can think of where this wouldn't be true would be the localValue for a UIInput or java code that directly manipulates a component. It seems like the state manager could preserve (or recreate) the original state of the component from the page code, compare that state with the current state of the component, and then mark it with a boolean value (didStateChange). For most components, this would result in a save state size of one boolean (no more than a char, and could probably even been put into a bit array if one needed to. For components whose state did differ from the original state, it would require one additional boolean value. This should work for any JSF implementation. A clever implementation could go a step further and separate the state saved into "state that rarely differs" and "state that always differs (UIInput localValue, for instance)" so as to reduce even the 10% remaining. So we'd be trading off network (and html size) bandwidth for server-side processing (or perhaps memory if you were willing to cache original page states in the application). Anyone else have any thoughts on this idea?
[jira] Commented: (MYFACES-1396) Too much escaping
[ http://issues.apache.org/jira/browse/MYFACES-1396?page=comments#action_12460002 ] Paul Spencer commented on MYFACES-1396: --- Paul, I would like to be create the problem so it can be addressed. Their are many places where the charset can be set, including the browser and MyFaces tags. At this point I do not know where the charset is set to UTF8. Where/are you seeing UTF8 in any of the pages generated by MyFaces? Paul Spencer > Too much escaping > - > > Key: MYFACES-1396 > URL: http://issues.apache.org/jira/browse/MYFACES-1396 > Project: MyFaces Core > Issue Type: Bug > Components: General >Reporter: Tomas Fischer > Assigned To: Martin Marinschek >Priority: Blocker > Attachments: test.jsf > > > HTMLOutputText (which delegates to HTMLEncoder) escapes not only XML-invalid > charactres (like <, >, &), but also german umlauts. This is OK if generating > (X)HTML, but not OK if generating XML. However, according to the official > documentation to the outputText Tag the german umlauts should not be quoted: > If the "escape" attribute is not present, or it is present and its value is > "true" all angle brackets should be converted to the ampersand xx semicolon > syntax when rendering the value of the "value" attribute as the value of the > component. > There is an automatic XML detection, but this is broken, as only predefined > MIME-types are recognized (application/xhtml+xml, application/xml, text/xml). > This bug prevents using JSF for generating other content (e.g. SVG, MIME-type > image/svg+xml). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1424) Incorrect source repository commands
[ http://issues.apache.org/jira/browse/MYFACES-1424?page=comments#action_12459995 ] Paul Pogonyshev commented on MYFACES-1424: -- Well, OK, but I guess 99% of interested people are interested in the source code of MyFaces, not of its site... > Incorrect source repository commands > > > Key: MYFACES-1424 > URL: http://issues.apache.org/jira/browse/MYFACES-1424 > Project: MyFaces Core > Issue Type: Bug > Components: website >Reporter: Popcorn >Priority: Critical > > On the website on the page http://myfaces.apache.org/source-repository.html, > the source repository commands have the following URL: > http://svn.apache.org/repos/asf/myfaces/site/trunk > This doesn't point to the MyFaces source code. > It needs to be fixed. I cannot figure out which path I should get source from > for the current release. > For example it says: > "The source can be checked out anonymously from SVN with this command: > $ svn checkout http://svn.apache.org/repos/asf/myfaces/site/trunk myfaces" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1424) Incorrect source repository commands
[ http://issues.apache.org/jira/browse/MYFACES-1424?page=comments#action_12459992 ] Wendy Smoak commented on MYFACES-1424: -- The website is a separate module, so its scm url points to the source code for the website itself. We can add a src/site/apt/source-repository.apt to override the page generated by Maven, with links to the pages for the various modules and the instructions on how to build it (which I think are on the wiki.) > Incorrect source repository commands > > > Key: MYFACES-1424 > URL: http://issues.apache.org/jira/browse/MYFACES-1424 > Project: MyFaces Core > Issue Type: Bug > Components: website >Reporter: Popcorn >Priority: Critical > > On the website on the page http://myfaces.apache.org/source-repository.html, > the source repository commands have the following URL: > http://svn.apache.org/repos/asf/myfaces/site/trunk > This doesn't point to the MyFaces source code. > It needs to be fixed. I cannot figure out which path I should get source from > for the current release. > For example it says: > "The source can be checked out anonymously from SVN with this command: > $ svn checkout http://svn.apache.org/repos/asf/myfaces/site/trunk myfaces" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1424) Incorrect source repository commands
[ http://issues.apache.org/jira/browse/MYFACES-1424?page=comments#action_12459991 ] Paul Pogonyshev commented on MYFACES-1424: -- Uh, sorry. Seems working, just my SVN build doesn't support SSL. > Incorrect source repository commands > > > Key: MYFACES-1424 > URL: http://issues.apache.org/jira/browse/MYFACES-1424 > Project: MyFaces Core > Issue Type: Bug > Components: website >Reporter: Popcorn >Priority: Critical > > On the website on the page http://myfaces.apache.org/source-repository.html, > the source repository commands have the following URL: > http://svn.apache.org/repos/asf/myfaces/site/trunk > This doesn't point to the MyFaces source code. > It needs to be fixed. I cannot figure out which path I should get source from > for the current release. > For example it says: > "The source can be checked out anonymously from SVN with this command: > $ svn checkout http://svn.apache.org/repos/asf/myfaces/site/trunk myfaces" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: Reason behind jsf_sequence?
If it's like the RI, the reasoning is to accommodate the back button issue with server-side state saving. It would be wrong to assume/associate a single state with a page given multiple windows and back button use. Using a sequence adds a level of uniqueness to state which is equal to 'page + sequence id'. > >I've been noticing in my output a jsf_sequence hidden form field that >increments on what seems to be each request. What's the reason for such an >incrementing hidden field? > >Does it have something to do with this "back button issue"? If so, how? > >I tried using a debugger but quickly got overwhelmed... :( >-- >View this message in context: >http://www.nabble.com/Reason-behind-jsf_sequence--tf2860440.html#a7992103 >Sent from the My Faces - Dev mailing list archive at Nabble.com. >
[jira] Commented: (MYFACES-1424) Incorrect source repository commands
[ http://issues.apache.org/jira/browse/MYFACES-1424?page=comments#action_12459988 ] Popcorn commented on MYFACES-1424: -- Works for me. What doesn't work? > Incorrect source repository commands > > > Key: MYFACES-1424 > URL: http://issues.apache.org/jira/browse/MYFACES-1424 > Project: MyFaces Core > Issue Type: Bug > Components: website >Reporter: Popcorn >Priority: Critical > > On the website on the page http://myfaces.apache.org/source-repository.html, > the source repository commands have the following URL: > http://svn.apache.org/repos/asf/myfaces/site/trunk > This doesn't point to the MyFaces source code. > It needs to be fixed. I cannot figure out which path I should get source from > for the current release. > For example it says: > "The source can be checked out anonymously from SVN with this command: > $ svn checkout http://svn.apache.org/repos/asf/myfaces/site/trunk myfaces" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1396) Too much escaping
[ http://issues.apache.org/jira/browse/MYFACES-1396?page=comments#action_12459986 ] Paul Pogonyshev commented on MYFACES-1396: -- And let me clarify why I think browser should have absolutely no saying in the a resulting encoding. Nowadays all browser should be able to handle any encoding just fine, as long as it is state in HTML page header. If a browser fails to handle a particular encoding, you should upgrade it, else throw it away. _Nothing_ I know of can reencode pages on the fly, so MyFaces seems to invent a wheel that is absolutely unneeded. In fact you seem to encourage browser behaviour which will not work with other server-side solutions, especially if a server just contains a number of static HTMLs. I can also confirm that it works perfectly without reencoding in JSP parts of the site. > Too much escaping > - > > Key: MYFACES-1396 > URL: http://issues.apache.org/jira/browse/MYFACES-1396 > Project: MyFaces Core > Issue Type: Bug > Components: General >Reporter: Tomas Fischer > Assigned To: Martin Marinschek >Priority: Blocker > Attachments: test.jsf > > > HTMLOutputText (which delegates to HTMLEncoder) escapes not only XML-invalid > charactres (like <, >, &), but also german umlauts. This is OK if generating > (X)HTML, but not OK if generating XML. However, according to the official > documentation to the outputText Tag the german umlauts should not be quoted: > If the "escape" attribute is not present, or it is present and its value is > "true" all angle brackets should be converted to the ampersand xx semicolon > syntax when rendering the value of the "value" attribute as the value of the > component. > There is an automatic XML detection, but this is broken, as only predefined > MIME-types are recognized (application/xhtml+xml, application/xml, text/xml). > This bug prevents using JSF for generating other content (e.g. SVG, MIME-type > image/svg+xml). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1396) Too much escaping
[ http://issues.apache.org/jira/browse/MYFACES-1396?page=comments#action_12459985 ] Paul Spencer commented on MYFACES-1396: --- I have used the tcpmon from the Apache Axis project http://ws.apache.org/axis/java/user-guide.html#AppendixUsingTheAxisTCPMonitorTcpmon Paul Spencer > Too much escaping > - > > Key: MYFACES-1396 > URL: http://issues.apache.org/jira/browse/MYFACES-1396 > Project: MyFaces Core > Issue Type: Bug > Components: General >Reporter: Tomas Fischer > Assigned To: Martin Marinschek >Priority: Blocker > Attachments: test.jsf > > > HTMLOutputText (which delegates to HTMLEncoder) escapes not only XML-invalid > charactres (like <, >, &), but also german umlauts. This is OK if generating > (X)HTML, but not OK if generating XML. However, according to the official > documentation to the outputText Tag the german umlauts should not be quoted: > If the "escape" attribute is not present, or it is present and its value is > "true" all angle brackets should be converted to the ampersand xx semicolon > syntax when rendering the value of the "value" attribute as the value of the > component. > There is an automatic XML detection, but this is broken, as only predefined > MIME-types are recognized (application/xhtml+xml, application/xml, text/xml). > This bug prevents using JSF for generating other content (e.g. SVG, MIME-type > image/svg+xml). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1396) Too much escaping
[ http://issues.apache.org/jira/browse/MYFACES-1396?page=comments#action_12459981 ] Paul Pogonyshev commented on MYFACES-1396: -- 1) No. I'm too tired now to find how to do it. 2) Firefox 2.0. 3) English (US). > Too much escaping > - > > Key: MYFACES-1396 > URL: http://issues.apache.org/jira/browse/MYFACES-1396 > Project: MyFaces Core > Issue Type: Bug > Components: General >Reporter: Tomas Fischer > Assigned To: Martin Marinschek >Priority: Blocker > Attachments: test.jsf > > > HTMLOutputText (which delegates to HTMLEncoder) escapes not only XML-invalid > charactres (like <, >, &), but also german umlauts. This is OK if generating > (X)HTML, but not OK if generating XML. However, according to the official > documentation to the outputText Tag the german umlauts should not be quoted: > If the "escape" attribute is not present, or it is present and its value is > "true" all angle brackets should be converted to the ampersand xx semicolon > syntax when rendering the value of the "value" attribute as the value of the > component. > There is an automatic XML detection, but this is broken, as only predefined > MIME-types are recognized (application/xhtml+xml, application/xml, text/xml). > This bug prevents using JSF for generating other content (e.g. SVG, MIME-type > image/svg+xml). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1396) Too much escaping
[ http://issues.apache.org/jira/browse/MYFACES-1396?page=comments#action_12459978 ] Paul Spencer commented on MYFACES-1396: --- Paul, Can you verify what you browser is sending, i.e. UTF8 or UTF-8? What is the borwser? What is the default language? Paul Spencer > Too much escaping > - > > Key: MYFACES-1396 > URL: http://issues.apache.org/jira/browse/MYFACES-1396 > Project: MyFaces Core > Issue Type: Bug > Components: General >Reporter: Tomas Fischer > Assigned To: Martin Marinschek >Priority: Blocker > Attachments: test.jsf > > > HTMLOutputText (which delegates to HTMLEncoder) escapes not only XML-invalid > charactres (like <, >, &), but also german umlauts. This is OK if generating > (X)HTML, but not OK if generating XML. However, according to the official > documentation to the outputText Tag the german umlauts should not be quoted: > If the "escape" attribute is not present, or it is present and its value is > "true" all angle brackets should be converted to the ampersand xx semicolon > syntax when rendering the value of the "value" attribute as the value of the > component. > There is an automatic XML detection, but this is broken, as only predefined > MIME-types are recognized (application/xhtml+xml, application/xml, text/xml). > This bug prevents using JSF for generating other content (e.g. SVG, MIME-type > image/svg+xml). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1396) Too much escaping
[ http://issues.apache.org/jira/browse/MYFACES-1396?page=comments#action_12459975 ] Paul Pogonyshev commented on MYFACES-1396: -- Note from the code, there's nothing like that (I actually grepped all source tree.) It may get it from the browser, I don't know. However, in this case it is very wrong: 1) at least MyFaces must handle "UTF8" just like "UTF-8"; 2) browser must not determine encoding of pages, since it is impossible to reencode pages robustly; in particular, inserting HTML entities into unsuspecting JavaScript (as in my case) will break things. > Too much escaping > - > > Key: MYFACES-1396 > URL: http://issues.apache.org/jira/browse/MYFACES-1396 > Project: MyFaces Core > Issue Type: Bug > Components: General >Reporter: Tomas Fischer > Assigned To: Martin Marinschek >Priority: Blocker > Attachments: test.jsf > > > HTMLOutputText (which delegates to HTMLEncoder) escapes not only XML-invalid > charactres (like <, >, &), but also german umlauts. This is OK if generating > (X)HTML, but not OK if generating XML. However, according to the official > documentation to the outputText Tag the german umlauts should not be quoted: > If the "escape" attribute is not present, or it is present and its value is > "true" all angle brackets should be converted to the ampersand xx semicolon > syntax when rendering the value of the "value" attribute as the value of the > component. > There is an automatic XML detection, but this is broken, as only predefined > MIME-types are recognized (application/xhtml+xml, application/xml, text/xml). > This bug prevents using JSF for generating other content (e.g. SVG, MIME-type > image/svg+xml). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1396) Too much escaping
[ http://issues.apache.org/jira/browse/MYFACES-1396?page=comments#action_12459974 ] Paul Spencer commented on MYFACES-1396: --- Paul, I have search the source code for "UTF8", but found nothing. Like you said, the charset is being passed into HtmlResponseWriterImpl, have you verifed that MyFaces is getting the charset "UTF8" from you browser or source code, including JSP? Paul Spencer > Too much escaping > - > > Key: MYFACES-1396 > URL: http://issues.apache.org/jira/browse/MYFACES-1396 > Project: MyFaces Core > Issue Type: Bug > Components: General >Reporter: Tomas Fischer > Assigned To: Martin Marinschek >Priority: Blocker > Attachments: test.jsf > > > HTMLOutputText (which delegates to HTMLEncoder) escapes not only XML-invalid > charactres (like <, >, &), but also german umlauts. This is OK if generating > (X)HTML, but not OK if generating XML. However, according to the official > documentation to the outputText Tag the german umlauts should not be quoted: > If the "escape" attribute is not present, or it is present and its value is > "true" all angle brackets should be converted to the ampersand xx semicolon > syntax when rendering the value of the "value" attribute as the value of the > component. > There is an automatic XML detection, but this is broken, as only predefined > MIME-types are recognized (application/xhtml+xml, application/xml, text/xml). > This bug prevents using JSF for generating other content (e.g. SVG, MIME-type > image/svg+xml). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TOBAGO-224) validation of tree works incorrect
[ http://issues.apache.org/jira/browse/TOBAGO-224?page=all ] Volker Weber resolved TOBAGO-224. - Fix Version/s: 1.0.9 (was: 1.0.10) Resolution: Fixed > validation of tree works incorrect > -- > > Key: TOBAGO-224 > URL: http://issues.apache.org/jira/browse/TOBAGO-224 > Project: MyFaces Tobago > Issue Type: Bug >Reporter: Volker Weber > Assigned To: Volker Weber > Fix For: 1.0.9 > > > in a tree with selection=leafOnly and a selected node is a message generated, > but updateModel and invokeApplication are not skipped -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TOBAGO-224) validation of tree works incorrect
validation of tree works incorrect -- Key: TOBAGO-224 URL: http://issues.apache.org/jira/browse/TOBAGO-224 Project: MyFaces Tobago Issue Type: Bug Reporter: Volker Weber Assigned To: Volker Weber Fix For: 1.0.10 in a tree with selection=leafOnly and a selected node is a message generated, but updateModel and invokeApplication are not skipped -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Reason behind jsf_sequence?
I've been noticing in my output a jsf_sequence hidden form field that increments on what seems to be each request. What's the reason for such an incrementing hidden field? Does it have something to do with this "back button issue"? If so, how? I tried using a debugger but quickly got overwhelmed... :( -- View this message in context: http://www.nabble.com/Reason-behind-jsf_sequence--tf2860440.html#a7992103 Sent from the My Faces - Dev mailing list archive at Nabble.com.
[jira] Commented: (MYFACES-1396) Too much escaping
[ http://issues.apache.org/jira/browse/MYFACES-1396?page=comments#action_12459948 ] Paul Pogonyshev commented on MYFACES-1396: -- Eh, I meant org.apache.myfaces.shared_impl.renderkit.html.HtmlResponseWriterImpl for the second list item. Anyway, that is mentioned in parenthesis. > Too much escaping > - > > Key: MYFACES-1396 > URL: http://issues.apache.org/jira/browse/MYFACES-1396 > Project: MyFaces Core > Issue Type: Bug > Components: General >Reporter: Tomas Fischer > Assigned To: Martin Marinschek >Priority: Blocker > Attachments: test.jsf > > > HTMLOutputText (which delegates to HTMLEncoder) escapes not only XML-invalid > charactres (like <, >, &), but also german umlauts. This is OK if generating > (X)HTML, but not OK if generating XML. However, according to the official > documentation to the outputText Tag the german umlauts should not be quoted: > If the "escape" attribute is not present, or it is present and its value is > "true" all angle brackets should be converted to the ampersand xx semicolon > syntax when rendering the value of the "value" attribute as the value of the > component. > There is an automatic XML detection, but this is broken, as only predefined > MIME-types are recognized (application/xhtml+xml, application/xml, text/xml). > This bug prevents using JSF for generating other content (e.g. SVG, MIME-type > image/svg+xml). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1396) Too much escaping
[ http://issues.apache.org/jira/browse/MYFACES-1396?page=comments#action_12459946 ] Paul Pogonyshev commented on MYFACES-1396: -- I didn't create a patch since I didn't feel it is a proper fix for upstream version. And now I can't create one since SVN checkout commands on your site are broken. Anyway, let me describe it in more words: - when instance of org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlResponseWriterImpl is created (note: shared_tomahawk, not shared_impl!), it is passed "UTF8", without hyphen, as `characterEncoding'; - in all (or at least all relevant) cases before, charset is "UTF-8", with hyphen, as expected; in particular this is true for org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlResponseWriterImpl (note: shared_impl, not shared_tomahawk); - I fixed it by converting "UTF8" string to "UTF-8" in HtmlResponseWriterImpl constructor; - a proper fix would be find out why charset becomes "UTF8", without hyphen, in the first place; ad-hoc fix above could be included too, as a way to make HtmlResponseWriterImpl more robust. > Too much escaping > - > > Key: MYFACES-1396 > URL: http://issues.apache.org/jira/browse/MYFACES-1396 > Project: MyFaces Core > Issue Type: Bug > Components: General >Reporter: Tomas Fischer > Assigned To: Martin Marinschek >Priority: Blocker > Attachments: test.jsf > > > HTMLOutputText (which delegates to HTMLEncoder) escapes not only XML-invalid > charactres (like <, >, &), but also german umlauts. This is OK if generating > (X)HTML, but not OK if generating XML. However, according to the official > documentation to the outputText Tag the german umlauts should not be quoted: > If the "escape" attribute is not present, or it is present and its value is > "true" all angle brackets should be converted to the ampersand xx semicolon > syntax when rendering the value of the "value" attribute as the value of the > component. > There is an automatic XML detection, but this is broken, as only predefined > MIME-types are recognized (application/xhtml+xml, application/xml, text/xml). > This bug prevents using JSF for generating other content (e.g. SVG, MIME-type > image/svg+xml). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1424) Incorrect source repository commands
[ http://issues.apache.org/jira/browse/MYFACES-1424?page=comments#action_12459944 ] Paul Pogonyshev commented on MYFACES-1424: -- Is that really so hard to fix? Popcorn: that command doesn't work either. > Incorrect source repository commands > > > Key: MYFACES-1424 > URL: http://issues.apache.org/jira/browse/MYFACES-1424 > Project: MyFaces Core > Issue Type: Bug > Components: website >Reporter: Popcorn >Priority: Critical > > On the website on the page http://myfaces.apache.org/source-repository.html, > the source repository commands have the following URL: > http://svn.apache.org/repos/asf/myfaces/site/trunk > This doesn't point to the MyFaces source code. > It needs to be fixed. I cannot figure out which path I should get source from > for the current release. > For example it says: > "The source can be checked out anonymously from SVN with this command: > $ svn checkout http://svn.apache.org/repos/asf/myfaces/site/trunk myfaces" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1396) Too much escaping
[ http://issues.apache.org/jira/browse/MYFACES-1396?page=comments#action_12459938 ] Paul Spencer commented on MYFACES-1396: --- Paul, Please submit a patch or describe "I just fixed it by converting "UTF8" to "UTF-8" in HtmlResponseWriterImpl class.". I just checked org.apache.myfaces.shared.renderkit.html.HtmlResponceWriterImpl in the shared project. It has been UTF-8 for a while, so I am not sure what you fixed. Paul Spencer > Too much escaping > - > > Key: MYFACES-1396 > URL: http://issues.apache.org/jira/browse/MYFACES-1396 > Project: MyFaces Core > Issue Type: Bug > Components: General >Reporter: Tomas Fischer > Assigned To: Martin Marinschek >Priority: Blocker > Attachments: test.jsf > > > HTMLOutputText (which delegates to HTMLEncoder) escapes not only XML-invalid > charactres (like <, >, &), but also german umlauts. This is OK if generating > (X)HTML, but not OK if generating XML. However, according to the official > documentation to the outputText Tag the german umlauts should not be quoted: > If the "escape" attribute is not present, or it is present and its value is > "true" all angle brackets should be converted to the ampersand xx semicolon > syntax when rendering the value of the "value" attribute as the value of the > component. > There is an automatic XML detection, but this is broken, as only predefined > MIME-types are recognized (application/xhtml+xml, application/xml, text/xml). > This bug prevents using JSF for generating other content (e.g. SVG, MIME-type > image/svg+xml). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1396) Too much escaping
[ http://issues.apache.org/jira/browse/MYFACES-1396?page=comments#action_12459919 ] Paul Pogonyshev commented on MYFACES-1396: -- I have fixed this locally since we have a release soon and it is not fixed in upstream (stable) versions. I spent 1.5 (!) days debugging stuff. It all went down to UTF-8 charset suddenly spelled as "UTF8" (while it was with hyphen at earlier stages.) I have no idea why the change happened, I just fixed it by converting "UTF8" to "UTF-8" in HtmlResponseWriterImpl class. BTW, you have a really weird package structure. For some reason, there is a shared_tomahawk package, but it seems identical to shared_impl and even not present in the sources. This made my debugging three times longer than it could be... > Too much escaping > - > > Key: MYFACES-1396 > URL: http://issues.apache.org/jira/browse/MYFACES-1396 > Project: MyFaces Core > Issue Type: Bug > Components: General >Reporter: Tomas Fischer > Assigned To: Martin Marinschek >Priority: Blocker > Attachments: test.jsf > > > HTMLOutputText (which delegates to HTMLEncoder) escapes not only XML-invalid > charactres (like <, >, &), but also german umlauts. This is OK if generating > (X)HTML, but not OK if generating XML. However, according to the official > documentation to the outputText Tag the german umlauts should not be quoted: > If the "escape" attribute is not present, or it is present and its value is > "true" all angle brackets should be converted to the ampersand xx semicolon > syntax when rendering the value of the "value" attribute as the value of the > component. > There is an automatic XML detection, but this is broken, as only predefined > MIME-types are recognized (application/xhtml+xml, application/xml, text/xml). > This bug prevents using JSF for generating other content (e.g. SVG, MIME-type > image/svg+xml). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TOMAHAWK-825) Locale support for inputDate months
Locale support for inputDate months --- Key: TOMAHAWK-825 URL: http://issues.apache.org/jira/browse/TOMAHAWK-825 Project: MyFaces Tomahawk Issue Type: Improvement Affects Versions: 1.1.5-SNAPSHOT Environment: Java EE 1.4, JSF 1.2, Sun Application Server PE9, Tomahawk 1.1.5 SNAPSHOT nightly build from november 16th Reporter: Bjørn Stenfeldt Priority: Minor Fix For: 1.1.3 I am pretty sure this worked in Tomahawk 1.1.3, but I could be wrong... The drop down with months always display the month names in English. Would be great if the names were in their locale names instead. Here is a piece of code that display English month names, where I actually wanted Danish names instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: MyFaces 1.1.5 Release Status?
AFAICT, we don't yet have a contributor agreement from Nikolay Petrov for MYFACES-1411. right! Martin can you contact him, since you are working with him ? -- Wendy -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: spring conversation start (@manfred)
On 12/19/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > By the way, is this similar to (or identical to) your idea for a preupdate() > method in Shale's ViewController (SHALE-338)? If so, I still like the idea > ... just need to see the follow through :-). :) I am on it, but got "blocked" by other *tasks* Boy do I know *that* story :-). Looking forward to the results, whenever they happen, although we're really close to rolling 1.0.4 now, so it might have to wait for the next feature release. Stay tuned -M Craig Craig > > > Just my $0.02 > > > > -M > > > > On 12/20/06, Werner Punz < [EMAIL PROTECTED]> wrote: > > > Craig McClanahan schrieb: > > > > > > > > One of the architectural approaches that MyFaces developers seem to do > > > > pretty often, even when they don't have to, is think of everything as > > > > needing a component. To me, this involves the person building the > view > > > > in decisions that really belong to the person working on the business > > > > logic. Yes, it's often the same person, but where is the separation > of > > > > concerns? > > > > > > > That was indeed the concerns of the original scope tag > > > (I am using it currently btw. it is excellent work) > > > the original intent was to have a viable replacement for savestate > > > which would allow quick and dirty scoping with a > > > a visual/tag approach. > > > > > > Mario did this approach and he solved it in an excellent way > > > and yes, there is a break in separation of concerns and it was > > > intended by design to ease the development of small applications, > > > > > > you basically push the scope control and parts of the transaction > > > handling into the visual part. > > > > > > But the idea was to have a tag like way for those things, and if you > > > need it differently (which many apps do but many small ones dont) > > > have other frameworks deal with it. > > > > > > Now Mario, now he is moving into the Spring domain with his stuff, seems > > > to be covering, let other frameworks do the scope control approach, > > > as well. > > > > > > Btw. The scope tag of Mario is really excellent you should give it a > > > try, but I agree, separation of concerns is not really there and cannot > > > be by design principle, but there are other frameworks and solutions > > > to deal with this. > > > > > > > > > > > > -- > > Matthias Wessendorf > > http://tinyurl.com/fmywh > > > > further stuff: > > blog: http://jroller.com/page/mwessendorf > > mail: mwessendorf-at-gmail-dot-com > > > > -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: spring conversation start (@manfred)
On 12/19/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > Just out of curiousity, where did they add "it"? I don't see any reference > to updateActionListener in 1.2. it is named setPropertyActionListener in the spec and in trinidad setActinListener Thanks ... I had not recalled that from when I last did a detailed review of all the 1.2 changes. Hmm, between that and , JSF has a pretty good analog to the "Beans Binding" JSR for Swing (JSR-296) :-), but only if you're using JSP :-(. I presume that the alternative view handlers like Clay and Facelets will deal with that issue on their own. -M Craig By the way, is this similar to (or identical to) your idea for a preupdate() > method in Shale's ViewController (SHALE-338)? If so, I still like the idea > ... just need to see the follow through :-). > > Craig > > > Just my $0.02 > > > > -M > > > > On 12/20/06, Werner Punz < [EMAIL PROTECTED]> wrote: > > > Craig McClanahan schrieb: > > > > > > > > One of the architectural approaches that MyFaces developers seem to do > > > > pretty often, even when they don't have to, is think of everything as > > > > needing a component. To me, this involves the person building the > view > > > > in decisions that really belong to the person working on the business > > > > logic. Yes, it's often the same person, but where is the separation > of > > > > concerns? > > > > > > > That was indeed the concerns of the original scope tag > > > (I am using it currently btw. it is excellent work) > > > the original intent was to have a viable replacement for savestate > > > which would allow quick and dirty scoping with a > > > a visual/tag approach. > > > > > > Mario did this approach and he solved it in an excellent way > > > and yes, there is a break in separation of concerns and it was > > > intended by design to ease the development of small applications, > > > > > > you basically push the scope control and parts of the transaction > > > handling into the visual part. > > > > > > But the idea was to have a tag like way for those things, and if you > > > need it differently (which many apps do but many small ones dont) > > > have other frameworks deal with it. > > > > > > Now Mario, now he is moving into the Spring domain with his stuff, seems > > > to be covering, let other frameworks do the scope control approach, > > > as well. > > > > > > Btw. The scope tag of Mario is really excellent you should give it a > > > try, but I agree, separation of concerns is not really there and cannot > > > be by design principle, but there are other frameworks and solutions > > > to deal with this. > > > > > > > > > > > > -- > > Matthias Wessendorf > > http://tinyurl.com/fmywh > > > > further stuff: > > blog: http://jroller.com/page/mwessendorf > > mail: mwessendorf-at-gmail-dot-com > > > > -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
