[jira] Created: (TOMAHAWK-893) Incorrect filter mapping documentation for the Tomahawk Extensions Filter
Incorrect filter mapping documentation for the Tomahawk Extensions Filter - Key: TOMAHAWK-893 URL: https://issues.apache.org/jira/browse/TOMAHAWK-893 Project: MyFaces Tomahawk Issue Type: Bug Components: Tabbed Pane Affects Versions: 1.1.5-SNAPSHOT Reporter: Craig McClanahan Among other places, the documentation at http://myfaces.apache.org/tomahawk/extensionsFilter.html tells you to map the extension filter to the URL pattern: /faces/myFaces/extensionResources/* in addition to mapping it to the same path as the JSF servlet. However, at least for the Tabbed Pane component, this does not work ... it causes the exception message stating that resources could not be delivered, and references the documentation URL above. The Tomahawk examples in the trunk use: /faces/* instead, and that does indeed seem to work. The docs and wiki pages should be updated to reflect this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-894) User specified style classes do not behave as expected
User specified style classes do not behave as expected -- Key: TOMAHAWK-894 URL: https://issues.apache.org/jira/browse/TOMAHAWK-894 Project: MyFaces Tomahawk Issue Type: Bug Components: Tabbed Pane Affects Versions: 1.1.5-SNAPSHOT Reporter: Craig McClanahan The TLD docs for the t:panelTabbedPane have these definitions for two of the style class overrides: activeTabStyleClassStyle class of the active tab cell inactiveTabStyleClass Style class of the inactive tab cells This implies to the reader that I can say something like: t:panelTabbedPane ... activeTabStyleClass=menu-sel inactiveTabStyleClass=menu .../ and expect my custom style classes to take effect. However, that is not what actually happens, because the component still emits the default Tomahawk style class first (myFaces_panelTabbedPane_activeHeaderCell or myFaces_panelTabbedPane_inactiveHeaderCell). That means my styles get ignored *unless* I create a cascade in my stylesheet definitions, or I use the !important modifier on EVERY SINGLE ENTRY. That is very poor usability -- it would be much better to *replace* the default style class when the user specifies one, so they don't have to go through all the pain of figuring out why their styles seem to be ignored. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-894) User specified style classes do not behave as expected
[ https://issues.apache.org/jira/browse/TOMAHAWK-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472070 ] Craig McClanahan commented on TOMAHAWK-894: --- It should go without saying that, if this kind of change is made to Tabbed Pane, the same philosophy would be consistently applied across the entire component library. User specified style classes do not behave as expected -- Key: TOMAHAWK-894 URL: https://issues.apache.org/jira/browse/TOMAHAWK-894 Project: MyFaces Tomahawk Issue Type: Bug Components: Tabbed Pane Affects Versions: 1.1.5-SNAPSHOT Reporter: Craig McClanahan The TLD docs for the t:panelTabbedPane have these definitions for two of the style class overrides: activeTabStyleClassStyle class of the active tab cell inactiveTabStyleClass Style class of the inactive tab cells This implies to the reader that I can say something like: t:panelTabbedPane ... activeTabStyleClass=menu-sel inactiveTabStyleClass=menu .../ and expect my custom style classes to take effect. However, that is not what actually happens, because the component still emits the default Tomahawk style class first (myFaces_panelTabbedPane_activeHeaderCell or myFaces_panelTabbedPane_inactiveHeaderCell). That means my styles get ignored *unless* I create a cascade in my stylesheet definitions, or I use the !important modifier on EVERY SINGLE ENTRY. That is very poor usability -- it would be much better to *replace* the default style class when the user specifies one, so they don't have to go through all the pain of figuring out why their styles seem to be ignored. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1383) FacesContextFactoryImpl issue using trinidad any myfaces core
[ http://issues.apache.org/jira/browse/MYFACES-1383?page=comments#action_12445431 ] Craig McClanahan 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. I would recommend that this suggestion be implemented ... not just for consistency with the other bridges, but because the portlet lifecycle is different from a standard webapp lifecycle in one crucial respect. Consider the scenario where you have six portlets on a particular page, all created with MyFaces (yeah :-). On any given request, *one* of the six portlets will go through the Restore View through Invoke Application phases, while *all* six portlets will have the Render Response phase executed. Thus, it is important for portlet developers to understand that they need to be prepared to rerender their current contents at any time, whether or not they were the portlet that received this particular postback. The easiest way to do that is to treat a single portlet request as two JSF requests ... one for the execute part of the lifecycle, and one for the render part. And that, by the way, is why the Lifecycle API has these two subsets of the overall lifecycle split into two methods. 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] Commented: (MYFACES-1467) Validation doesn't run for required fields if submitted value is null
[ http://issues.apache.org/jira/browse/MYFACES-1467?page=comments#action_12442362 ] Craig McClanahan commented on MYFACES-1467: --- On a sidenote - I believe that it is bad to skip validation at all if the value of a field is null. I haven't looked to see if this changed in 1.2, but I can tell you with certainty that this behavior is *exactly* what was intended for version 1.0. The reasoning was that, if there is no value, then there is nothing to be validated. Indeed, this is the entire reason that required exists as a property, instead of as a validator, in the first place. Craig Validation doesn't run for required fields if submitted value is null - Key: MYFACES-1467 URL: http://issues.apache.org/jira/browse/MYFACES-1467 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.0-SNAPSHOT, 1.1.5-SNAPSHOT Reporter: David Chandler Assigned To: Matthias Weßendorf Attachments: patch.txt A component with a required value will not fail validation as expected if the submitted value is null. This issue is not seen normally because browsers send the value for an empty text field as an empty string. That is, the POST data for an empty field1 will contain the field name but no value, like field1=field2=something. However, if you use a man-in-the-middle proxy such as Paros to remove fieldname= from the POST data, the submitted value will be null. UIInput.validate() skips validation for null submitted values, but since requiredness is also part of validation, the requiredness check gets skipped, too. -- 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-1467) Validation doesn't run for required fields if submitted value is null
[ http://issues.apache.org/jira/browse/MYFACES-1467?page=comments#action_12442364 ] Craig McClanahan commented on MYFACES-1467: --- what do you say to my reasoning for cases where required is either true or false, depending on the value of another component? I say two things: * JSF validation is all about single values -- cross field validation is left to the application, or to frameworks built on top of JSF (i.e. it's reasonable to build a validation framework extending JSF that does this kind of thing, but it's out of scope for the JSF validation APIs themselves, at least for 1.0). * Firing validators on null values doesn't solve your use case anyway. You are going to need to do something application specific anyway. The current APIs are nowhere near rich enough to express all of the possible cross field scenarios that you would need to cover to be complete. In the short term (i.e. before you can convince some future JSF expert group to change this), the best advice might be to build a standalone validation framework that deals with all the possible cross-field type issues, rather than trying to coerce individual components to behave differently than the JSF standard ones do. Also, keep an eye on JSRs like #303 (annotations based validation rules), which will be playing in this same space. Validation doesn't run for required fields if submitted value is null - Key: MYFACES-1467 URL: http://issues.apache.org/jira/browse/MYFACES-1467 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.0-SNAPSHOT, 1.1.5-SNAPSHOT Reporter: David Chandler Assigned To: Matthias Weßendorf Attachments: patch.txt A component with a required value will not fail validation as expected if the submitted value is null. This issue is not seen normally because browsers send the value for an empty text field as an empty string. That is, the POST data for an empty field1 will contain the field name but no value, like field1=field2=something. However, if you use a man-in-the-middle proxy such as Paros to remove fieldname= from the POST data, the submitted value will be null. UIInput.validate() skips validation for null submitted values, but since requiredness is also part of validation, the requiredness check gets skipped, too. -- 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: (MYFACES-1092) HtmlTableRendererBase.encodeInnerHtml() fails when data model returns -1 for getRowCount()
HtmlTableRendererBase.encodeInnerHtml() fails when data model returns -1 for
getRowCount()
--
Key: MYFACES-1092
URL: http://issues.apache.org/jira/browse/MYFACES-1092
Project: MyFaces
Type: Bug
Components: Implementation
Versions: 1.1.1
Reporter: Craig McClanahan
Per the JSF spec, ResultSetDataModel.getRowCount() returns -1, to avoid the
potential of scrolling through a very large result set to find the number of
rows. This means that components that might be bound to such a result set
(such as the value property on an HtmlDataTable component) must take into
account that they might get a -1 back when asking for the row count.
The logic in the encodeInnerHtml() method of HtmlTableRendererBase fails to
account for this possibility in the calculation of the last index to be
rendered, and causes zero rows to be printed in a scenario where the table
component is bound directly to a ResultSetDataModel, no matter how many rows
the result set actually returns. For example:
h:dataTable ... value=#{mybean.rsdm} var=current .../
where the rsdm property is a ResultSetDataModel that wraps a ResultSet that
returns a non-zero number of rows. This scenario works correctly with the JSF
RI implementation.
For example apps that illustrate this, check the SQL Browser example in Shale,
or the UIData example from the JSF RI's standard demo application.
--
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: (MYFACES-829) h:selectManyCheckbox with value bound to an array of int fails
h:selectManyCheckbox with value bound to an array of int fails
Key: MYFACES-829
URL: http://issues.apache.org/jira/browse/MYFACES-829
Project: MyFaces
Type: Bug
Components: Implementation
Versions: 1.1.0
Environment: Linux, JDK 1.5.0_05
Reporter: Craig McClanahan
The Shale use cases example includes a page where an h:selectManyCheckbox
component is bound to an array of int that represents selected values. A bug
was reported against this app:
http://issues/apache.org/bugzilla/show_bug.cgi?id=37361
However, further investigation shows that this case works correctly with the
JSF RI, leading to the belief that it represents an implementation error in
MyFaces. See the above bug report for more details.
For reference, the page includes the following component:
h:selectManyCheckbox id=categories layout=pageDirection
value=#{dialog.data.categories}
h:selectItems value=#{domains.supportedCategories}/
/h:selectManyCheckbox
where the binding expressions point at values of the following types:
* #{dialog.data.categories} points at an array of int representing
the currently selected categories
* #{domains.supportedCategories} points at an array of SelectItem,
where the value property of each is an Integer representing the
primary key for that category.
--
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-655) RequestMap doesn't implement putAll as it should
[ http://issues.apache.org/jira/browse/MYFACES-655?page=comments#action_12331258 ] Craig McClanahan commented on MYFACES-655: -- Matthias has a fair question (about why the TCK requires UnsupportedOperattionException) here. Forwarded to the spec leads for further comment. Craig RequestMap doesn't implement putAll as it should Key: MYFACES-655 URL: http://issues.apache.org/jira/browse/MYFACES-655 Project: MyFaces Type: Bug Versions: 1.1.0 Reporter: Colin Sampaleanu Assignee: Mathias Broekelmann The JSF description of for the ExternalContext.getRequestMap() method says: Return a mutable Map representing the request scope attributes for the current application. The returned Map must implement the entire contract for a modifiable map as described in the JavaDocs for java.util.Map. Modifications made in the Map must cause the corresponding changes in the set of request scope attributes. yet MyFaces returns a RequestMap class which throws UnsupportedOperationException for both the putAll() and the clear() methods. This is a major bug which will break apps (like mine) that depend on being able to add params via putAll(), for example. -- 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
