Re: List of available images in inputHTML component
On 11/14/05, Sylvain Vieujot [EMAIL PROTECTED] wrote: I don't like this external config file. I think the proper way of doing this is to overload the Kupu method that configures the images library box. So, we could pass to the inputHtml tag a Map containing images URLs as Key, and Images descriptions as held Objects. What do you think ? Yes, we could. Sure. I had thought before looking how Kupu works, that I could pass a list of ItemSelect to this component, and fill the combo list of the image toolbox with it. Or give it the name of a directory and fill it with everything it contains. But this will not show the beutiful dialog box with images, previews, and so on. Propably I can generate kupu's imagelibrary configuration file automatically from both sources (list of something and directory name), so we can use kupu's dialog box, which could be more pleasant, but probably without image preview (or preview it the same size, I'll take a look). Anyway, I will try to remove this config file, neither do I like it. al.
[jira] Closed: (MYFACES-818) AddResource unit test
[ http://issues.apache.org/jira/browse/MYFACES-818?page=all ]
Bruno Aranda closed MYFACES-818:
Fix Version: Nightly
Resolution: Fixed
Added to the SVN. Many thanks, Simon, for your valuable contributions!
AddResource unit test
-
Key: MYFACES-818
URL: http://issues.apache.org/jira/browse/MYFACES-818
Project: MyFaces
Type: Improvement
Reporter: Simon Kitching
Priority: Minor
Fix For: Nightly
Attachments: AddResourceTest.java
Attached is a proposed unit test case for the AddResource class. The unit
tests cover only a small percentage of the functionality of the AddResource
class but it's a start.
This test also demonstrates an existing bug in the AddResource class; the
unit test fails (correctly!) because of this code:
if(bodyInsertPosition0)
{
.
buf.append(\);
originalResponse.insert( bodyInsertPosition-1, +
buf.toString());
}
which is causing body to always be transformed into body regardless of
whether there is any stuff to insert into the body's onload method or not.
--
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-690) tree2 server-side-toggle example: Encountered a node [0:0:0] + with an illogical state...
[ http://issues.apache.org/jira/browse/MYFACES-690?page=comments#action_12357570 ] Mathias Werlitz commented on MYFACES-690: - This is a duplicate of MYFACES-568 ... there is already a patch .. but still not applied yet. tree2 server-side-toggle example: Encountered a node [0:0:0] + with an illogical state... - Key: MYFACES-690 URL: http://issues.apache.org/jira/browse/MYFACES-690 Project: MyFaces Type: Bug Components: Tomahawk Versions: 1.1.0 Environment: http://www.irian.at/myfaces/tree2.jsf Reporter: Erik Mellegård Attachments: patch.txt Server side toggle tree2 example throws exception. To reproduce the error: 1. Open http://www.irian.at/myfaces/tree2.jsf 2. Expand Inbox and Frank Foo folders 3. Click on the line that attaches Frank Foo with Requires Foo (where there would have been a plus if Requires Foo would have contained children) This generates the following exception: type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception javax.servlet.ServletException: Encountered a node [0:0:0] + with an illogical state. Node is expanded but it is also considered a leaf (a leaf cannot be considered expanded. javax.faces.webapp.FacesServlet.service(FacesServlet.java:109) org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:122) root cause java.lang.IllegalStateException: Encountered a node [0:0:0] + with an illogical state. Node is expanded but it is also considered a leaf (a leaf cannot be considered expanded. org.apache.myfaces.custom.tree2.HtmlTreeRenderer.encodeNavigation(HtmlTreeRenderer.java:463) org.apache.myfaces.custom.tree2.HtmlTreeRenderer.encodeCurrentNode(HtmlTreeRenderer.java:346) org.apache.myfaces.custom.tree2.HtmlTreeRenderer.encodeTree(HtmlTreeRenderer.java:248) org.apache.myfaces.custom.tree2.HtmlTreeRenderer.encodeTree(HtmlTreeRenderer.java:276) org.apache.myfaces.custom.tree2.HtmlTreeRenderer.encodeTree(HtmlTreeRenderer.java:276) org.apache.myfaces.custom.tree2.HtmlTreeRenderer.encodeChildren(HtmlTreeRenderer.java:200) javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:319) javax.faces.webapp.UIComponentTag.encodeChildren(UIComponentTag.java:343) javax.faces.webapp.UIComponentTag.doEndTag(UIComponentTag.java:251) org.apache.jsp.tree2_jsp._jspx_meth_t_tree2_1(org.apache.jsp.tree2_jsp:1050) org.apache.jsp.tree2_jsp._jspx_meth_h_form_0(org.apache.jsp.tree2_jsp:225) org.apache.jsp.tree2_jsp._jspx_meth_f_view_0(org.apache.jsp.tree2_jsp:182) org.apache.jsp.tree2_jsp._jspService(org.apache.jsp.tree2_jsp:126) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:291) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:415) org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:234) org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:300) javax.faces.webapp.FacesServlet.service(FacesServlet.java:95) org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:122) note The full stack trace of the root cause is available in the Apache Tomcat/5.5.9 logs. -- 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-690) tree2 server-side-toggle example: Encountered a node [0:0:0] + with an illogical state...
[ http://issues.apache.org/jira/browse/MYFACES-690?page=comments#action_12357573 ] Marius Kreis commented on MYFACES-690: -- The issue of MYFACES-568 is the deletion/repositon of nodes. This doesn't fit to this bug report: In this case the problem is caused by clicking of the links in front of a node (notice the description 3. Click on the line that attaches Frank Foo with Requires Foo (where there would have been a plus if Requires Foo would have contained children)) Its a simple error in the renderer because the lines in front of leafs are rendered as hyperlinks. tree2 server-side-toggle example: Encountered a node [0:0:0] + with an illogical state... - Key: MYFACES-690 URL: http://issues.apache.org/jira/browse/MYFACES-690 Project: MyFaces Type: Bug Components: Tomahawk Versions: 1.1.0 Environment: http://www.irian.at/myfaces/tree2.jsf Reporter: Erik Mellegård Attachments: patch.txt Server side toggle tree2 example throws exception. To reproduce the error: 1. Open http://www.irian.at/myfaces/tree2.jsf 2. Expand Inbox and Frank Foo folders 3. Click on the line that attaches Frank Foo with Requires Foo (where there would have been a plus if Requires Foo would have contained children) This generates the following exception: type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception javax.servlet.ServletException: Encountered a node [0:0:0] + with an illogical state. Node is expanded but it is also considered a leaf (a leaf cannot be considered expanded. javax.faces.webapp.FacesServlet.service(FacesServlet.java:109) org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:122) root cause java.lang.IllegalStateException: Encountered a node [0:0:0] + with an illogical state. Node is expanded but it is also considered a leaf (a leaf cannot be considered expanded. org.apache.myfaces.custom.tree2.HtmlTreeRenderer.encodeNavigation(HtmlTreeRenderer.java:463) org.apache.myfaces.custom.tree2.HtmlTreeRenderer.encodeCurrentNode(HtmlTreeRenderer.java:346) org.apache.myfaces.custom.tree2.HtmlTreeRenderer.encodeTree(HtmlTreeRenderer.java:248) org.apache.myfaces.custom.tree2.HtmlTreeRenderer.encodeTree(HtmlTreeRenderer.java:276) org.apache.myfaces.custom.tree2.HtmlTreeRenderer.encodeTree(HtmlTreeRenderer.java:276) org.apache.myfaces.custom.tree2.HtmlTreeRenderer.encodeChildren(HtmlTreeRenderer.java:200) javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:319) javax.faces.webapp.UIComponentTag.encodeChildren(UIComponentTag.java:343) javax.faces.webapp.UIComponentTag.doEndTag(UIComponentTag.java:251) org.apache.jsp.tree2_jsp._jspx_meth_t_tree2_1(org.apache.jsp.tree2_jsp:1050) org.apache.jsp.tree2_jsp._jspx_meth_h_form_0(org.apache.jsp.tree2_jsp:225) org.apache.jsp.tree2_jsp._jspx_meth_f_view_0(org.apache.jsp.tree2_jsp:182) org.apache.jsp.tree2_jsp._jspService(org.apache.jsp.tree2_jsp:126) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:291) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:415) org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:234) org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:300) javax.faces.webapp.FacesServlet.service(FacesServlet.java:95) org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:122) note The full stack trace of the root cause is available in the Apache Tomcat/5.5.9 logs. -- 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-776) Tree2 state problem when using dynamic trees
[ http://issues.apache.org/jira/browse/MYFACES-776?page=comments#action_12357572 ] Mathias Werlitz commented on MYFACES-776: - This is related to MYFACES-568 ... there is already a patch, that will fix the Exception .. but still not applied yet. Simply numbering the nodes does not solve the problem, because when a node becomes a leaf (former node with childs) the problem still exists. Tree2 state problem when using dynamic trees Key: MYFACES-776 URL: http://issues.apache.org/jira/browse/MYFACES-776 Project: MyFaces Type: Bug Environment: JSF RI 1.1.01 Tomahawk nightly build from 10-30-2005 Reporter: Vinnie Fazio I saw this note: http://mail-archives.apache.org/mod_mbox/myfaces-users/200504.mbox/[EMAIL PROTECTED] I couldn't find a bug for this and I am having the same problem. I've done a little resarch and I think I understand the problem. The tree2 js stores the tree state in a cookie named with the component id. I have a page where the tree changes between requests. Because the rest of the page is the same, the component id does not change. The js tries to open up the same nodes as was open in the old tree. The problem occurs when the new tree has a leaf node that was not a leaf in the old tree and was open in the old tree. I get this error java.lang.IllegalStateException: Encountered a node [0:0:0] + with an illogical state. Node is expanded but it is also considered a leaf. For me, I could get around this problem if I could name the component (or the cookie) dynamically using a managed bean value. Since I cannot name the id in this manner, I have a problem. Maybe a solution would be a new paramerter to specify the cookie name. Thanks! Here is the full stack trace java.lang.IllegalStateException: Encountered a node [0:0:0] + with an illogical state. Node is expanded but it is also considered a leaf (a leaf cannot be considered expanded. org.apache.myfaces.custom.tree2.HtmlTreeRenderer.encodeNavigation(HtmlTreeRenderer.java:462) org.apache.myfaces.custom.tree2.HtmlTreeRenderer.encodeCurrentNode(HtmlTreeRenderer.java:345) org.apache.myfaces.custom.tree2.HtmlTreeRenderer.encodeTree(HtmlTreeRenderer.java:247) org.apache.myfaces.custom.tree2.HtmlTreeRenderer.encodeTree(HtmlTreeRenderer.java:275) org.apache.myfaces.custom.tree2.HtmlTreeRenderer.encodeChildren(HtmlTreeRenderer.java:210) javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:701) javax.faces.webapp.UIComponentTag.encodeChildren(UIComponentTag.java:607) javax.faces.webapp.UIComponentTag.doEndTag(UIComponentTag.java:544) org.apache.jsp.WEB_002dINF.panels.favorites_jsp._jspx_meth_x_tree2_0(favorites_jsp.java:254) org.apache.jsp.WEB_002dINF.panels.favorites_jsp._jspx_meth_h_form_0(favorites_jsp.java:141) org.apache.jsp.WEB_002dINF.panels.favorites_jsp._jspx_meth_f_subview_0(favorites_jsp.java:114) org.apache.jsp.WEB_002dINF.panels.favorites_jsp._jspService(favorites_jsp.java:87) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.taglibs.standard.tag.common.core.ImportSupport.acquireString(Unknown Source) org.apache.taglibs.standard.tag.common.core.ImportSupport.doEndTag(Unknown Source) org.apache.jsp.idp_jsp._jspx_meth_c_import_0(idp_jsp.java:536) org.apache.jsp.idp_jsp._jspx_meth_c_if_1(idp_jsp.java:509) org.apache.jsp.idp_jsp._jspx_meth_c_forEach_0(idp_jsp.java:405) org.apache.jsp.idp_jsp._jspx_meth_t_htmlTag_4(idp_jsp.java:357) org.apache.jsp.idp_jsp._jspx_meth_t_htmlTag_3(idp_jsp.java:307) org.apache.jsp.idp_jsp._jspx_meth_t_htmlTag_0(idp_jsp.java:166) org.apache.jsp.idp_jsp._jspx_meth_f_view_0(idp_jsp.java:129) org.apache.jsp.idp_jsp._jspService(idp_jsp.java:94) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:322)
[jira] Created: (MYFACES-821) Usage of request attributes for caching
Usage of request attributes for caching --- Key: MYFACES-821 URL: http://issues.apache.org/jira/browse/MYFACES-821 Project: MyFaces Type: Bug Versions: 1.1.0 Environment: liferay 3.6.1 Reporter: Michael Lipp Priority: Blocker JspStateManagerImpl (and maybe other classes) uses request attributes for caching state. This causes a wrong view to be used if there is more than one JSF-based portlet on a single page. MyFaces saves the serialized view of the first portlet on the page as a request attribute. To avoid re-serialization, MyFaces subsequently checks if there already is a request attribute with a serialized view. As request attributes are not scoped to a single portlet (the portlet specification does not require this), the serialized view of the first portlet will be found and used by the second portlet. This usage of request attributes may also be the cause of MYFACES-549. As JSF, of course, does not need to know about the portlet environment, it cannot be required that MyFaces saves such information per view, e.g. by prepending the viewId to the key for the request attribute (although this would solve the problem). IMHO any request attributes added during lifecycle.render() should be removed after lifecycle() render by the portlet bridge. (The same applies to request attributes added during lifecycle.execute(), but these should also be re-added before lifecycle.render().) I have implemented this in my portlet bridge as a workaround. -- 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-822) Tabs in panelTabbedPane are shown as buttons on IExplorer
Tabs in panelTabbedPane are shown as buttons on IExplorer -- Key: MYFACES-822 URL: http://issues.apache.org/jira/browse/MYFACES-822 Project: MyFaces Type: Bug Components: Tomahawk Versions: 1.1.1 Environment: Windows XP Professional SP2, IE 6.0 SP2, Exadel Studio 3.0.4 Reporter: Javor Petkov Hello, The tabs in panelTabbedPane are shown as buttons when using Internet Explorer 6.0 SP2 and the XP theme for the MyFaces 1.1.1 version. Tested with IE 6.0 without updates - same behaviour, tabs shown as buttons - more visible if the default XP theme is used. With Firefox tabs are fine (displayed as tabs). With version 1.0.9 of MyFaces and IE the tabs are also rendered fine so this seems to be a new feature/bug in MyFaces 1.1.1. The problem is reproducible with the Tabbed Pane example of Exadel Studio 3.0.4. Mail me for screenshots if needed. Thanks for having a look :) -- 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-816) Tiles
[
http://issues.apache.org/jira/browse/MYFACES-816?page=comments#action_12357600
]
Lauri Lüüs commented on MYFACES-816:
Yes everything now works, after several hours intencive code crawlint, I found
that in
my menu.jsp I used f:view .blablabla /f:view
and when I used some form vith h:commandButton I also added on that form
f:view
so there was this problem that suddenly on one page (thanks to tiles merge)
there is multiple f:view tags.
f:view menu /f:view
f:view page /f:view
No wonder that this was'nt working :)
Tiles
-
Key: MYFACES-816
URL: http://issues.apache.org/jira/browse/MYFACES-816
Project: MyFaces
Type: Bug
Components: Tomahawk
Versions: 1.1.1
Environment: WIN XP Tomcat 5.5.7
Reporter: Lauri Lüüs
Priority: Blocker
Hi!
Well I have tryed million different way but with Tiles commandButton does'nt
work. It kind of eating events.
When I remove Tiles from faces-config.xml all navigation, submitting works
perfectly.
But when I include Tiles there are no action events :( Specially with buttons.
Form is typical jsf form: (userList.jsp)
f:view
h:form id=frmUserList
h:panelGrid columns=2
h:outputText id=lblName value=First name/
h:inputText id=fldName value=#{userList.firstName}/
h:outputText id=lblLast value=Last name/
h:inputText id=fldLast value=#{userList.lastName}/
/h:panelGrid
h:commandButton id=cmdFind value=Find styleClass=button10
action=#{userList.onSearchUser}/
/h:form
/view
(tiles.xml)
tiles-definitions
!-- define main template, witch is used for default showing--
definition name=layout path=/template/main_template.jsp
put name=menu value=/template/menu.jsp/!-- panel for
showing meny --
/definition
definition name=/user/userList.tiles extends=layout
put name=body value=/user/userList.jsp/
/definition
...
/tiles-definitions
And my faces config is:
view-handlerorg.apache.myfaces.application.jsp.JspTilesViewHandlerImpl/view-handler
navigation-rule
description
Navigation rules for navigation component.
/description
from-view-id*/from-view-id
navigation-case
from-outcomego_userList/from-outcome
to-view-id/user/userList.jsp/to-view-id
/navigation-case
navigation-case
from-outcomego_userEdit/from-outcome
to-view-id/user/usrEdit.jsp/to-view-id
/navigation-case
/navigation-rule
Please help me I'm kind a desperate.
--
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
Fwd: Build Failure
More forrest problems ... -- Forwarded message -- From: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Nov 13, 2005 11:33 PM Subject: Build Failure To: [EMAIL PROTECTED], dev@myfaces.apache.org [echo] Loading project specific properties from /home/sjs4/bootstrap/myfaces-current/forrest/build/forrest.properties [echo] Loading user specific properties from /home/sjs4/forrest.properties [echo] Loading default properties from /usr/local/forrest/src/core/context/default-forrest.properties [echo] [echo] -- Warning -- [echo] Using skin forrest-site which is deprecated. [echo] Please migrate to one of the new skins listed in forrest.properties. [echo] The skin that most likely resembles these ones is called 'pelt'. [echo] ...validated xdocs [echo] ...validated skinconf [echo] ...validated sitemap [echo] ...validated existence of skin 'forrest-site' [echo] [echo] Copying the various non-generated resources to site. [echo] Warnings will be issued if the optional project resources are not found. [echo] This is often the case, because they are optional and so may not be available. [echo] Copying project resources and images to site ... [echo] Copying main skin images to site ... [echo] Copying project skin images to site ... [echo] Copying main skin css and js files to site ... [echo] Copying project skin css and js files to site ... [echo] Finished copying the non-generated resources. [echo] Now Cocoon will generate the rest ... [echo] [echo] Static site will be generated at: [echo] /home/sjs4/bootstrap/myfaces-current/build/temp/site [echo] [echo] Note that there are various reasons for build failed messages. [echo] * Cocoon will report the status of each document: [echo] - in column 1: *=okay X=brokenLink ^=pageSkipped (see FAQ). [echo] * Even if only one link is broken, you will still get failed. [echo] * Your site would still be generated, but some pages would be broken. [echo] * Please check the file: [echo] /home/sjs4/bootstrap/myfaces-current/build/temp/forrest/tmp/brokenlinks.xml [echo] for any broken links in the generated site. [java] Cannot find CatalogManager.properties BUILD FAILED /home/sjs4/bootstrap/bootstrap.xml:101: The following error occurred while executing this line: /home/sjs4/bootstrap/myfaces-current/forrest/build/build.xml:49: The following error occurred while executing this line: /usr/local/forrest/src/core/targets/site.xml:43: Java returned: 1 Total time: 3 minutes 11 seconds
Re: Build Failure
images/inputdate2.png is referenced by tomahawk/inputDate.xml, but file is missing. I uncommented the affected line. Forrest build works again. On 11/14/05, Sean Schofield [EMAIL PROTECTED] wrote: More forrest problems ... -- Forwarded message -- From: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Nov 13, 2005 11:33 PM Subject: Build Failure To: [EMAIL PROTECTED], dev@myfaces.apache.org [echo] Loading project specific properties from /home/sjs4/bootstrap/myfaces-current/forrest/build/forrest.properties [echo] Loading user specific properties from /home/sjs4/forrest.properties [echo] Loading default properties from /usr/local/forrest/src/core/context/default-forrest.properties [echo] [echo] -- Warning -- [echo] Using skin forrest-site which is deprecated. [echo] Please migrate to one of the new skins listed in forrest.properties. [echo] The skin that most likely resembles these ones is called 'pelt'. [echo] ...validated xdocs [echo] ...validated skinconf [echo] ...validated sitemap [echo] ...validated existence of skin 'forrest-site' [echo] [echo] Copying the various non-generated resources to site. [echo] Warnings will be issued if the optional project resources are not found. [echo] This is often the case, because they are optional and so may not be available. [echo] Copying project resources and images to site ... [echo] Copying main skin images to site ... [echo] Copying project skin images to site ... [echo] Copying main skin css and js files to site ... [echo] Copying project skin css and js files to site ... [echo] Finished copying the non-generated resources. [echo] Now Cocoon will generate the rest ... [echo] [echo] Static site will be generated at: [echo] /home/sjs4/bootstrap/myfaces-current/build/temp/site [echo] [echo] Note that there are various reasons for build failed messages. [echo] * Cocoon will report the status of each document: [echo] - in column 1: *=okay X=brokenLink ^=pageSkipped (see FAQ). [echo] * Even if only one link is broken, you will still get failed. [echo] * Your site would still be generated, but some pages would be broken. [echo] * Please check the file: [echo] /home/sjs4/bootstrap/myfaces-current/build/temp/forrest/tmp/brokenlinks.xml [echo] for any broken links in the generated site. [java] Cannot find CatalogManager.properties BUILD FAILED /home/sjs4/bootstrap/bootstrap.xml:101: The following error occurred while executing this line: /home/sjs4/bootstrap/myfaces-current/forrest/build/build.xml:49: The following error occurred while executing this line: /usr/local/forrest/src/core/targets/site.xml:43: Java returned: 1 Total time: 3 minutes 11 seconds -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Closed: (MYFACES-568) tree2 TreeState wrong after node deletion/reposition, causes Servlet Exception
[ http://issues.apache.org/jira/browse/MYFACES-568?page=all ]
Martin Marinschek closed MYFACES-568:
-
Fix Version: Nightly
Resolution: Fixed
Assign To: Martin Marinschek
Thanks to Mathias Werlitz - sorry for the delay.
tree2 TreeState wrong after node deletion/reposition, causes Servlet Exception
--
Key: MYFACES-568
URL: http://issues.apache.org/jira/browse/MYFACES-568
Project: MyFaces
Type: Bug
Components: Tomahawk
Versions: 1.1.1
Environment: Tomcat 4.1.31, SDK 1.4.2, windows XP Pro
Reporter: Bett Koch
Assignee: Martin Marinschek
Fix For: Nightly
Attachments: tree2_bitmask.txt
We are using the tree2 component in a situation where nodes can be
dynamically added, deleted and re-parented.
The tree can also be completely re-populated with a different version of data.
We have also simulated multiple node selection, by placing a checkbox
next to certain nodes. Clicking a button then causes bulk-deletion of all
ticked nodes.
We were using the myfaces 1.0.9 version in this way:
t:tree2 value=#{xxx.treeData}
var=n
varNodeToggler=tn
clientSideToggle=false
The backing bean is in Session Scope; treeData was a TreeNode.
All this was basically working, with the exception of a refresh problem after
a re-population (reported in MYFACES-404),
and a problem whereby you had to click twice to expand the root node when the
page first displayed.
We want to migrate to the nightly builds, in which these two issues are fixed
(thanks!)
But we hit problems with the new TreeState: (using nightly build of 11-Sep-05)
1. When moving to another page and then coming back, the tree is always
collapsed.
2. When re-populating the tree with a different data set, OR
3. When deleting or reparenting a node, often this kind of error (eventually)
occurs:
javax.servlet.ServletException:
Encountered a node [0:4] + with an illogical state.
Node is expanded but it is also considered a leaf (a leaf cannot be
considered expanded.
By reading thru the various postings and forums I have fixed:
1 by creating our own TreeModel and value-binding to that (rather than a
TreeNode)
(Incidentally, adding a component-binding, ie t:tree2
binding=#{xxx.treeComponent} value=#{xxx.treeNode}..
also fixed the problem without using our own TreeModel)
2 by setting the Transient property of our TreeModel's TreeState to True
(which I understand is OK since our backing bean is session-scoped)
But I can't figure out 3.
How can you fix up the TreeState after programatically causing nodes to
change positions or disappear,
since the TreeState maintains its node expansion knowledge via a Hashmap
keyed on positional node ids
(0:1:4, etc).
As a work-around I've thought of collapsing any node (and its subnodes)
before trying to delete or move it, or even
collapsing the whole tree, but I can't work out how
UITreeData only gives you the nodeId of the 'current' node, so I don't
understand how you get at
nodeIds of arbitrary nodes to feed to the new collapsePath() method.
(Incidentally, maybe a collapseAll() method might be useful to have as well
as expandAll()?)
Thanks for any help, and please set me straight if I've misunderstood
anything about the changes made to tree2 along the way!
Regards, Bett
--
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
Anchors, navigation cases, and commandLinks/outputLinks
Hello, I'm trying to accomplish the following scenario and could use some assistance from someone who's accomplished this seemingly simple task: 1) Click on a commandLink on a page 2) Execute code from method binding on commandLink that was just clicked 3) Navigate to a page (possibly the same page)AND SCROLLto an anchor listed on the page I've tried to accomplish this by having my method binding return a string value which represents a unique navigation case that has a to-view-id of a URL with an anchor appended on it such as this: navigation-rule navigation-case from-outcomeanAction/from-outcome to-view-id/somePage.jsp#someAnchor/to-view-id redirect/ /navigation-case /navigation-rule With an anchor on the page like this: f:verbatima name="/f:verbatimh:outputText value="someAnchor" /f:verbatim" //f:verbatim This results in the application appending a .jsp extension to the end of the to-view-id URL value (ex: /somePage.jsp#someAnchor.jsp) instead of just /somePage.jsp#someAnchor I've also tried wrapping a commandLink with an outputLink--hoping to somehow fire both the navigation to the outputLink value along with the bean.methodName code: h:outputLink value="module.faces##someAnchor"h:outputText value="Test Link" /h:commandLink action=""h:outputText value="Bean Backed Test Link"//h:outputLink The outputLink works just fine by itself; however, I need a bean method to fire as well before the navigation takes place. This seems like a simple task that would be very common. I would greatly appreciate some guidance from anyone who has done this or accomplished the same desired outcome via different means or techniques. If this isn't possible, perhaps I should log it as a wish list item in JIRA? Thanks, Dan -- This message may contain confidential information, and is intended only for the use of the individual(s) to whom it is addressed. --
[OT] Any Tobago developers going to Apache Con San Diego?
I have been meaning to learn more about this incubator project. I'd love to talk in person if you are planning on going. sean
[jira] Created: (MYFACES-823) Non-default Tiles extension is not applied on the first request
Non-default Tiles extension is not applied on the first request
---
Key: MYFACES-823
URL: http://issues.apache.org/jira/browse/MYFACES-823
Project: MyFaces
Type: Bug
Components: Tomahawk
Versions: 1.1.0
Reporter: Colin Sharples
Priority: Minor
The changes made for MYFACES-150 allow a different extension to be used for
Tiles definitions (the default is .tiles). However, there is a bug in the
implementation of this. The definitions factory is lazily loaded by
getDefinitionsFactory(), and a non-default extension will be set at this time.
The first time renderView() is called, though, it calculates the tilesId
*before* getDefinitionsFactory() gets called, and will therefore use the
default extension. On subsequent calls, the correct extension will be used. To
fix this, a call needs to be made to getDefinitionsFactory() before the tilesId
is calculated, e.g.:
DefinitionsFactory factory = getDefinitionsFactory();
String tilesId = viewId;
int idx = tilesId.lastIndexOf('.');
if (idx 0)
{
tilesId = tilesId.substring(0, idx) + tilesExtension;
}
else
{
tilesId = tilesId + tilesExtension;
}
...
definition = factory.getDefinition(tilesId, request,
servletContext);
--
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: Ajax lifecircle integration
[snip] You cannot expect that you want to show the same autocomplete to every user that comes in - this really is a very seldom case. You want to depicture I18N, session information and user permissions just like with a JSF component. I have been reading up on Craig's remoting solution for the (b) case. The o.a.s.r.RemoteCommand sets up the FacesContext for you so you can access it in your code using FacesContext.getCurrentInstance(). This means that you *can* have some of the JSF goodness without the overhead of the lifecycle. You can use method and value binding expressions as well as locale stuff. Remember - the JSF framework was an outcome of seeing the necessity of componentization, state saving, etc. Why should that be any different for AJAX components? Because it may be overkill in some instances. I don't think an Ajax component that goes through the entire JSF lifecycle with every keystroke will scale very well. In inputSuggestAjax, the list of possible choices is meaningless. It's not necessary to store in the state. Only their final answer is important. I agree that more complicated components (like an AjaxTree) would need to worry about this. In fact, that is a big PITA right now with tree2 and the client side script. You need to post back (via a cookie) your client side state changes so you can sync them up. Only exception: the performance is bad. Well, with every new technology, the performance was bad in the beginning when taking the abstraction to a new level. Then the programmers of the world worked hard to find remedies to this. And today, we seldom use Assembler to programm ;) Ah yes but how many Java GUI programs were you writing when Java 1.0.2 was out and all you had was the crappy AWT? regards, Martin sean
[jira] Created: (MYFACES-824) if submittedValue==null, required==true not checked
if submittedValue==null, required==true not checked --- Key: MYFACES-824 URL: http://issues.apache.org/jira/browse/MYFACES-824 Project: MyFaces Type: Bug Components: JSR-127 Versions: Nightly Reporter: Dave Brondsema Priority: Minor In UIInput.java, in validate() at line 263 there is if (submittedValue == null) return; This seems to be incorrect to me. If submittedValue is set to null, then validate returns without checking to see if required=true. According to the UIInput spec javadocs If the component wishes to indicate that no particular value was submitted, it can either do nothing, or set the submitted value to null. -- 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-824) if submittedValue==null, required==true not checked
[ http://issues.apache.org/jira/browse/MYFACES-824?page=comments#action_12357637 ] Simon Kitching commented on MYFACES-824: I think that submittedValue will be null only if the submitted form did not contain that UIInput component at all. In this case, validation is *not* required. When the component is in the form, but has no value, I expect submittedValue is set to an empty string (not null). See HtmlRendererUtils.decodeUIInput. if submittedValue==null, required==true not checked --- Key: MYFACES-824 URL: http://issues.apache.org/jira/browse/MYFACES-824 Project: MyFaces Type: Bug Components: JSR-127 Versions: Nightly Reporter: Dave Brondsema Priority: Minor In UIInput.java, in validate() at line 263 there is if (submittedValue == null) return; This seems to be incorrect to me. If submittedValue is set to null, then validate returns without checking to see if required=true. According to the UIInput spec javadocs If the component wishes to indicate that no particular value was submitted, it can either do nothing, or set the submitted value to null. -- 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
Christian Rüedi/GK/Konzern/Globus-Gruppe ist außer Haus.
Ich werde ab 14.11.2005 nicht im Büro sein. Ich kehre zurück am 05.12.2005. Ich werde Ihre Nachrichten am 06.12.05 empfangen.
[jira] Commented: (MYFACES-824) if submittedValue==null, required==true not checked
[ http://issues.apache.org/jira/browse/MYFACES-824?page=comments#action_12357644 ] Dave Brondsema commented on MYFACES-824: I'm working on a custom component that binds to a Date value. It calls setSubmittedValue(myDate) but sometimes myDate is null. You're saying that if myDate is null it should call setSubmittedValue() instead? It seems a little weird. if submittedValue==null, required==true not checked --- Key: MYFACES-824 URL: http://issues.apache.org/jira/browse/MYFACES-824 Project: MyFaces Type: Bug Components: JSR-127 Versions: Nightly Reporter: Dave Brondsema Priority: Minor In UIInput.java, in validate() at line 263 there is if (submittedValue == null) return; This seems to be incorrect to me. If submittedValue is set to null, then validate returns without checking to see if required=true. According to the UIInput spec javadocs If the component wishes to indicate that no particular value was submitted, it can either do nothing, or set the submitted value to null. -- 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: Ajax lifecircle integration
On 11/14/05, Sean Schofield [EMAIL PROTECTED] wrote:
[snip]
You cannot expect that you want to show the same autocomplete to every
user that comes in - this really is a very seldom case. You want to
depicture I18N, session information and user permissions just like
with a JSF component.
I have been reading up on Craig's remoting solution for the (b) case.
The o.a.s.r.RemoteCommand sets up the FacesContext for you so you can
access it in your code using FacesContext.getCurrentInstance().
This means that you *can* have some of the JSF goodness without the
overhead of the lifecycle. You can use method and value binding
expressions as well as locale stuff.
... which is nice, but not as nice as actually having the actual
component instance.
Remember - the JSF framework was an outcome of seeing the necessity
of componentization, state saving, etc. Why should that be any
different for AJAX components?
Because it may be overkill in some instances. I don't think an Ajax
component that goes through the entire JSF lifecycle with every
keystroke will scale very well.
Certainly not - but that's just about what we can do today.
If this could scale, you've got more options.
In inputSuggestAjax, the list of
possible choices is meaningless. It's not necessary to store in the
state. Only their final answer is important.
But OTOH, the component - and what model its bound to -
is of course correlated to which list of possible choices make
sense.
It'd be excellent to have:
t:inputSuggestAjax value=#{theValue}
possibleValues=#{aListOfPossibleValues}/
... and this is worlds simpler than setting up an XMLHttp
endpoint. The problem is that today this simply isn't scalable;
the issue for JSF is making it so.
I agree that more complicated components (like an AjaxTree) would need
to worry about this. In fact, that is a big PITA right now with tree2
and the client side script. You need to post back (via a cookie) your
client side state changes so you can sync them up.
A good candidate for mixing in some component-tree-based AJAX
requests, though you'd certainly want to buffer them up
instead of sending requests on very expand/collapse, unless
you needed extra data sent across (another example of something
that's far easier to achieve with the component tree than without).
BTW, other than following existing hype conventions, what's
the reason for putting Ajax in the name of these tags (or,
even worse, Java method names)? The abstraction
(asynchronous granular requests) is what matters, not the
latest rubric or the particular transport protocol.
Cheers,
Adam Winer
[jira] Commented: (MYFACES-824) if submittedValue==null, required==true not checked
[ http://issues.apache.org/jira/browse/MYFACES-824?page=comments#action_12357646 ] Simon Kitching commented on MYFACES-824: I don't understand what you are saying here. The method setSubmittedValue is only ever called from the decode method of the component's renderer, during the apply request values phase of processing. It tells the component what String value was found in the submitted form (ie in the http request paramMap). If the current page contains two forms, and the input field was in one form but the user submitted the other then on decode the component will see there is *no* value for it in the http request params. I bet in this case _submittedValue is null. Perhaps this link may be useful: http://wiki.apache.org/myfaces/StudyGuide if submittedValue==null, required==true not checked --- Key: MYFACES-824 URL: http://issues.apache.org/jira/browse/MYFACES-824 Project: MyFaces Type: Bug Components: JSR-127 Versions: Nightly Reporter: Dave Brondsema Priority: Minor In UIInput.java, in validate() at line 263 there is if (submittedValue == null) return; This seems to be incorrect to me. If submittedValue is set to null, then validate returns without checking to see if required=true. According to the UIInput spec javadocs If the component wishes to indicate that no particular value was submitted, it can either do nothing, or set the submitted value to null. -- 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: (MYFACES-824) if submittedValue==null, required==true not checked
[ http://issues.apache.org/jira/browse/MYFACES-824?page=all ] sean schofield resolved MYFACES-824: Resolution: Won't Fix This is not a bug. It is part of the spec. Many have taken issue with it and I believe its being revisited in the next version of the spec. if submittedValue==null, required==true not checked --- Key: MYFACES-824 URL: http://issues.apache.org/jira/browse/MYFACES-824 Project: MyFaces Type: Bug Components: JSR-127 Versions: Nightly Reporter: Dave Brondsema Priority: Minor In UIInput.java, in validate() at line 263 there is if (submittedValue == null) return; This seems to be incorrect to me. If submittedValue is set to null, then validate returns without checking to see if required=true. According to the UIInput spec javadocs If the component wishes to indicate that no particular value was submitted, it can either do nothing, or set the submitted value to null. -- 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-757) Using a custom getActionURL creates a 404 error
[ http://issues.apache.org/jira/browse/MYFACES-757?page=comments#action_12357652 ] Ryan Dewell commented on MYFACES-757: - Please close this issue. It turned out to be a problem that was coming from another JSF component (facelets). They have fixed it. Apologies for the mix up. Using a custom getActionURL creates a 404 error --- Key: MYFACES-757 URL: http://issues.apache.org/jira/browse/MYFACES-757 Project: MyFaces Type: Bug Components: Implementation Reporter: Ryan Dewell A change has been made between the MyFaces that shipped with JBoss 4.0.3 RC2, and the MyFaces that ships with JBoss 4.0.3 SP1. I have isolated it to MyFaces by copying the two myfaces libraries from 4.0.3 RC2 TO 4.0.3 SP1. My code only works when 4.0.3 SP1 is using the MyFaces libraries from 4.0.3 RC2. Here is the problem. I use a custom ViewHandler which returns a getActionURL to a custom location. This location is virtual, it does not have a physical location as a file. When using the later MyFaces build mentioned above, I visit: http://localhost:8080/bm-hosted/nextup/ Oddly, I then receive a 404 error FOR the URL returned by getActionURL The requested resource (http://localhost:8080/bm-hosted/nextup/view) is not available. even though that is not the URL I visited at this time. It is important to note that this ALL works perfectly with the older MyFaces libraries. It almost seems like the later version of MyFaces is somehow checking for the existence of getActionURL, and returning 404 when it can't find it?? -- 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-824) if submittedValue==null, required==true not checked
[ http://issues.apache.org/jira/browse/MYFACES-824?page=comments#action_12357653 ] Adam Winer commented on MYFACES-824: It's not a bug, nor is it being revisited. I'm not aware of many taking issue to this - perhaps you're thinking of the fact that validators are not executed if required is true? submittedValue being set to null means nothing was submitted - which is different from a null value was submitted, or the empty string was submitted. This is the proper value for submittedValue for a disabled or readonly text field, for instance. This does create some oddities if you want to reflect the value that was submitted should be null, in which case Renderer.decode() needs to store some non-null value (Boolean.FALSE, etc.), which getConvertedValue() can recognize and change to null. if submittedValue==null, required==true not checked --- Key: MYFACES-824 URL: http://issues.apache.org/jira/browse/MYFACES-824 Project: MyFaces Type: Bug Components: JSR-127 Versions: Nightly Reporter: Dave Brondsema Priority: Minor In UIInput.java, in validate() at line 263 there is if (submittedValue == null) return; This seems to be incorrect to me. If submittedValue is set to null, then validate returns without checking to see if required=true. According to the UIInput spec javadocs If the component wishes to indicate that no particular value was submitted, it can either do nothing, or set the submitted value to null. -- 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-819) ClassCastException in HtmlFileUploadRenderer
[
http://issues.apache.org/jira/browse/MYFACES-819?page=comments#action_12357658
]
jack terranova commented on MYFACES-819:
My apologies... My environment was setup incorrectly.
Please close this artifact.
ClassCastException in HtmlFileUploadRenderer
Key: MYFACES-819
URL: http://issues.apache.org/jira/browse/MYFACES-819
Project: MyFaces
Type: Bug
Components: Tomahawk
Versions: 1.1.1
Environment: XP, Tomcat 5.0.28
Reporter: jack terranova
JSP with t:inputFileUpload/ tag will not render due to ClassCastException
in HtmlFileUploadRenderer at line 57.
uiComponent.value() is null and is being cast to UploadedFile class. No
apparent workaround as initial rendering of page would mean no UploadedFile
exists at that point.
Subsequent code appears to expect a null in some instances...
UploadedFile value =
(UploadedFile)((HtmlInputFileUpload)uiComponent).getValue();
if (value != null)
{
if( value.getName() != null )
{
writer.writeAttribute(HTML.VALUE_ATTR, value.getName(),
null);
}
}
... but the cast will ensure a blow up.
--
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-825) AddResource creates invalid body tag
[ http://issues.apache.org/jira/browse/MYFACES-825?page=all ] Simon Kitching updated MYFACES-825: --- Attachment: AddResource.java.patch.txt Patch to fix quote-in-body problem AddResource creates invalid body tag Key: MYFACES-825 URL: http://issues.apache.org/jira/browse/MYFACES-825 Project: MyFaces Type: Bug Reporter: Simon Kitching Attachments: AddResource.java.patch.txt When there are no attributes to be inserted into the body tag, AddResource still inserts a space and a quote, resulting in a malformed body tag. Result: body/body becomes body /body. This is handled reasonably gracefully by firefox (the bad quote doesn't even appear in view-source) but it stuffs up IE very well. Issue MYFACES-818 provided a unit test that demonstrated the problem; the unit test was committed to SVN but the issue was then closed without fixing the actual AddResource bug. -- 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-825) AddResource creates invalid body tag
AddResource creates invalid body tag Key: MYFACES-825 URL: http://issues.apache.org/jira/browse/MYFACES-825 Project: MyFaces Type: Bug Reporter: Simon Kitching Attachments: AddResource.java.patch.txt When there are no attributes to be inserted into the body tag, AddResource still inserts a space and a quote, resulting in a malformed body tag. Result: body/body becomes body /body. This is handled reasonably gracefully by firefox (the bad quote doesn't even appear in view-source) but it stuffs up IE very well. Issue MYFACES-818 provided a unit test that demonstrated the problem; the unit test was committed to SVN but the issue was then closed without fixing the actual AddResource bug. -- 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: Ajax lifecircle integration
On 11/14/05, Adam Winer [EMAIL PROTECTED] wrote:
On 11/14/05, Sean Schofield [EMAIL PROTECTED] wrote:
[snip]
You cannot expect that you want to show the same autocomplete to every
user that comes in - this really is a very seldom case. You want to
depicture I18N, session information and user permissions just like
with a JSF component.
I have been reading up on Craig's remoting solution for the (b) case.
The o.a.s.r.RemoteCommand sets up the FacesContext for you so you can
access it in your code using FacesContext.getCurrentInstance().
This means that you *can* have some of the JSF goodness without the
overhead of the lifecycle. You can use method and value binding
expressions as well as locale stuff.
... which is nice, but not as nice as actually having the actual
component instance.
In the case of inputSuggestAjax we don't need the component instance.
We just want a refined list of possible choices based on the user's
latest keystroke. I think the Tomahawk components that use Ajax will
want to allow this option.
Remember - the JSF framework was an outcome of seeing the necessity
of componentization, state saving, etc. Why should that be any
different for AJAX components?
Because it may be overkill in some instances. I don't think an Ajax
component that goes through the entire JSF lifecycle with every
keystroke will scale very well.
Certainly not - but that's just about what we can do today.
If this could scale, you've got more options.
But for right now we need something other then complete JSF lifecycle
for certain ajax components. So what do we do about that in the here
and now?
My suggestion is that we don't require a JSF postback every keystroke.
I think we can modify inputSuggestAjax and other similar components
that fall under the (b) case and make them more flexible. Allow the
user to use Shale's remote command if they want to. Don't lock them
into the full JSF lifecycle.
In inputSuggestAjax, the list of
possible choices is meaningless. It's not necessary to store in the
state. Only their final answer is important.
But OTOH, the component - and what model its bound to -
is of course correlated to which list of possible choices make
sense.
It'd be excellent to have:
t:inputSuggestAjax value=#{theValue}
possibleValues=#{aListOfPossibleValues}/
... and this is worlds simpler than setting up an XMLHttp
endpoint. The problem is that today this simply isn't scalable;
the issue for JSF is making it so.
I agree that more complicated components (like an AjaxTree) would need
to worry about this. In fact, that is a big PITA right now with tree2
and the client side script. You need to post back (via a cookie) your
client side state changes so you can sync them up.
A good candidate for mixing in some component-tree-based AJAX
requests, though you'd certainly want to buffer them up
instead of sending requests on very expand/collapse, unless
you needed extra data sent across (another example of something
that's far easier to achieve with the component tree than without).
I thought about the buffering issue. While it speeds things up, it
also certainly complicates things. For large trees, the client-side
toggle is too slow (especially on IE browsers.) So some type of Ajax
solution would be nice. I'd definitely consider working on an Ajax
tree with anyone who was interested. I just don't want to get stuck
doing all of the work myself.
BTW, other than following existing hype conventions, what's
the reason for putting Ajax in the name of these tags (or,
even worse, Java method names)? The abstraction
(asynchronous granular requests) is what matters, not the
latest rubric or the particular transport protocol.
Well I had already contributed an inputSuggest to the sandbox that did
*not* use Ajax. So the authors of this one decided to distinguish it.
I've lost interest in the original inputSuggest, however, because its
just not very good with large lists (too slow.) It has some good
javascript and DHTML that we can make use of in the Ajax version but
perhaps its time to abandon it.
I'm ok with dropping ajax from the names but you'll have to convince
a bunch of others.
Cheers,
Adam Winer
sean
[jira] Commented: (MYFACES-824) if submittedValue==null, required==true not checked
[ http://issues.apache.org/jira/browse/MYFACES-824?page=comments#action_12357660 ] sean schofield commented on MYFACES-824: @Adam: Yes that is what I was referring to. Thanks for the clarification. if submittedValue==null, required==true not checked --- Key: MYFACES-824 URL: http://issues.apache.org/jira/browse/MYFACES-824 Project: MyFaces Type: Bug Components: JSR-127 Versions: Nightly Reporter: Dave Brondsema Priority: Minor In UIInput.java, in validate() at line 263 there is if (submittedValue == null) return; This seems to be incorrect to me. If submittedValue is set to null, then validate returns without checking to see if required=true. According to the UIInput spec javadocs If the component wishes to indicate that no particular value was submitted, it can either do nothing, or set the submitted value to null. -- 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] Closed: (MYFACES-757) Using a custom getActionURL creates a 404 error
[ http://issues.apache.org/jira/browse/MYFACES-757?page=all ] Martin Marinschek closed MYFACES-757: - Fix Version: Nightly Resolution: Fixed Assign To: Martin Marinschek Using a custom getActionURL creates a 404 error --- Key: MYFACES-757 URL: http://issues.apache.org/jira/browse/MYFACES-757 Project: MyFaces Type: Bug Components: Implementation Reporter: Ryan Dewell Assignee: Martin Marinschek Fix For: Nightly A change has been made between the MyFaces that shipped with JBoss 4.0.3 RC2, and the MyFaces that ships with JBoss 4.0.3 SP1. I have isolated it to MyFaces by copying the two myfaces libraries from 4.0.3 RC2 TO 4.0.3 SP1. My code only works when 4.0.3 SP1 is using the MyFaces libraries from 4.0.3 RC2. Here is the problem. I use a custom ViewHandler which returns a getActionURL to a custom location. This location is virtual, it does not have a physical location as a file. When using the later MyFaces build mentioned above, I visit: http://localhost:8080/bm-hosted/nextup/ Oddly, I then receive a 404 error FOR the URL returned by getActionURL The requested resource (http://localhost:8080/bm-hosted/nextup/view) is not available. even though that is not the URL I visited at this time. It is important to note that this ALL works perfectly with the older MyFaces libraries. It almost seems like the later version of MyFaces is somehow checking for the existence of getActionURL, and returning 404 when it can't find it?? -- 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
