RE: Re: Pulse check for org.apache.myfaces.ALLOW_JAVASCRIPT
well accessability laws are not the only requirements... Some companies request that webapps must work with JS disabled for SECURITY reasons. JS is considered a big risk, on the same level as ActiveX. EG. checkout the links on http://ajaxtopics.com/security.html or this article http://www.devarticles.com/c/a/JavaScript/JavaScript-Security/. asking the search engines for security risk javascript you hardly find a hit that claims otherwise... For JSF 2.0 I asked Ed to include a requirement to add gracefull degradation- specifications. Components should behave in a defined way, when some of their dependencies (like missing JS) are not available. I consider designing JS-free UI's a bigger challenge than so called Rich UI's. It is more difficult to come up with a user-friendly solutoin, but I have seen applications migrated from a complex Smalltalk-Fat-client UI to a JS-free webapp UI, and see that the users appreciated the simplification of the UI. It ended up more in a step by step UI, which was easier to understand. regards Alexander -Original Message- From: Adam Winer [mailto:[EMAIL PROTECTED] Sent: Friday, October 27, 2006 4:32 AM To: MyFaces Development Subject: Re: Re: Pulse check for org.apache.myfaces.ALLOW_JAVASCRIPT Jesse, Yes, commandLink is the only component in the JSF impl that emits Javascript. That's because the set of components in the JSF spec is minimal, and the set of features on those few components is minimal. It does not constitute proof that any component that uses Javascript is being silly. I also have yet to see much evidence that JS-free pages are truly necessary today (a common claim that accessibility laws require functioning without Javascript is false.) I'm fine with the goal of avoiding Javascript except when necessary, and fine with documenting which components require it and which don't. Anything more is, well, very 20th century. Regards, Adam Winer On 10/26/06, Jesse Alexander (KSFD 121) [EMAIL PROTECTED] wrote: The newest JSF-RI release (1.2_03) does not emmit anymore JS according to Ed. Only exception is the command-link... and for that one I discussed a possible solution with Ryan, which will be tried sometime soon... regards Alexander and: JS-free pages are definitely necessary... -Original Message- From: Martin Marinschek [mailto:[EMAIL PROTECTED] Sent: Thursday, October 26, 2006 8:14 PM To: MyFaces Development Subject: Re: Pulse check for org.apache.myfaces.ALLOW_JAVASCRIPT Hold on with Tiles support - it works without problems even in the current MyFaces-version. Javascript stuff - yes, we need javascript. No way round it, except you use only command-buttons. regards, Martin On 10/26/06, Dennis Byrne [EMAIL PROTECTED] wrote: Team, Whatever happened to this feature? Does it work in the latest release? I seem to remember the spec (version # anyone) saying js was required. Dennis Byrne -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Thursday, October 26, 2006 02:03 PM To: 'MyFaces Discussion' Subject: Re: status of tiles support JS less :) sure +1 on that. Do you want to start a discussion on the dev list about org.apache.myfaces.ALLOW_JAVASCRIPT ? my friend, that's for you :) back to alaska ? or still in india ? Back from India, to Chicago :) ah I dude, I remember! :) you like it there ? -M Dennis Byrne On 10/26/06, Dennis Byrne [EMAIL PROTECTED] wrote: Hi Matze, Am I the only one who feels the Tiles support and javascriptless feature should officially be retired ? To my knowledge these haven't worked well since the good ol' 1.0.9 days :) Dennis Byrne -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Thursday, October 26, 2006 01:40 PM To: 'MyFaces Discussion' Subject: Re: status of tiles support it is this clazz org.apache.myfaces.tomahawk.application.jsp.JspTilesViewHandlerImpl To be honest, you should try Facelets instead of Tiles for templating a JSF app -Matthias On 10/26/06, Michael Südkamp [EMAIL PROTECTED] wrote: Hello, I wonder what is the status of the tiles support? The myfaces-examples are still at version 1.1.1 and the included tiles web-app will not run with the the 1.1.3 libs (and probably also not with 1.1.4) (java.lang.ClassNotFoundException: org.apache.myfaces.application.jsp.JspTilesViewHandlerImpl). The wiki topic at http://wiki.apache.org/myfaces/Tiles_and_JSF is also not up to date. Can anyone help me how to set it up? Michael -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Component and tags documentation and wiki
Hello All,I want to synchronize the latest web site documentations and Wiki InformationI want to use the following headers and clean the wiki informationI hope if the quality of works was good, the result transferred to web site documentations to. I want to use following headers and mote information into them and complete the definition:[Component Name]DescriptionScreen ShotAPIUsageSyntaxConfigurationInstructionsAdditional Information ExamplesFAQKnown Bugsfirst: does any one has any objections?second: do you suggest another format?Arash Rajaeeyan
[jira] Resolved: (MYFACES-1448) Enhanced initialization code execution
[ http://issues.apache.org/jira/browse/MYFACES-1448?page=all ] Scott O'Bryan resolved MYFACES-1448. Resolution: Won't Fix This is not needed. We ADFFaces can achieve this by making a custom lifecycle. Enhanced initialization code execution -- Key: MYFACES-1448 URL: http://issues.apache.org/jira/browse/MYFACES-1448 Project: MyFaces Core Issue Type: New Feature Components: Portlet_Support Environment: JSR-168 Reporter: Scott O'Bryan The MyFaces Generic Portlet Bridge should be enhanced to allow special code to be executed during Portlet Initialization and Destruction, as well as before and after the lifecycle is run. Phase listeners do not always work for this because there is no guarantee that all phases will be executed for cleanup. This would allow a renderkit to provide SOME of the functionality which is commonly used in filters with the exception of Request/Response wrapping. Specification of these special filters would be defined in the portlet.xml and would be executed in the order that they are specified in that file. -- 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-1383) FacesContextFactoryImpl issue using trinidad any myfaces core
[ http://issues.apache.org/jira/browse/MYFACES-1383?page=comments#action_12445288 ] Scott O'Bryan commented on MYFACES-1383: Looking at this issue again, it seems to me that it would be better to recreate the FacesContext between the execute and render phases of the lifecycle. We would need to preserve messages and some other things, but nothing to difficult to preserve. This would allow wrappers to update their wrapping when the external context changes. The one downfall is that this is a pretty major change from the current functionality of the Faces Bridge Portlet although it is more inline with other Bridge Portlets. Anyone have an issue with this? FacesContextFactoryImpl issue using trinidad any myfaces core - Key: MYFACES-1383 URL: http://issues.apache.org/jira/browse/MYFACES-1383 Project: MyFaces Core Issue Type: Bug Components: Portlet_Support Affects Versions: 1.1.5-SNAPSHOT Environment: pluto 1.1-dev, tomcat 5.5.17 running on linux 2.6.17 Reporter: nicolas kalkhof trinidad won´t run in a portlet environment. problem is, that FacesContextFactoryImpl does not extend ServletFacesContextImpl. therefore this is an internal myfaces core problem that could hopefully be fixed. stacktrace of the crashing portlet using myfaces and trinidad: javax.portlet.PortletException: org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit at org.apache.myfaces.portlet.MyFacesGenericPortlet.handleExceptionFromLifecycle(MyFacesGenericPortlet.java:253) at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:407) Nested Exception is java.lang.ClassCastException: org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:387) at net.portlets.logon.LogonPortlet.doView(LogonPortlet.java:88) -- 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] Updated: (MYFACES-1420) Null Pointer Exception in SelectItemsIterator.next() if binding is null
[ http://issues.apache.org/jira/browse/MYFACES-1420?page=all ] Steve Ziegler updated MYFACES-1420: --- Status: Patch Available (was: Open) Null Pointer Exception in SelectItemsIterator.next() if binding is null --- Key: MYFACES-1420 URL: http://issues.apache.org/jira/browse/MYFACES-1420 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.1.5-SNAPSHOT, 1.1.4 Environment: Linux Fedora core 5 Reporter: Horia Barca Fix For: 1.1.5-SNAPSHOT Attachments: SelectItemsIterator_modified.java NPE is thrown at line 183 of org.apache.myfaces.shared_impl.util.SelectItemsIterator.next() if value binding property of the current UISelectItems component is null. This is not relevant, as the exception expected at that place in the code is IllegalArgumentException. By constructing the IllegalArgumentException message, a check whether the binding is null should be made, like it's done at line 143 of the same class. -- 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
