Re: [continuum] BUILD FAILURE: Impl
no,
I just pulled current12 and the build didn't fail
-M
On 10/5/06, Bruno Aranda [EMAIL PROTECTED] wrote:
I am not sure why this keeps failing. I think it is running before the
shared module, so it does not get the proper shared-impl package? I
clean and build over and over again the current12 branch and it does
not fail. Can someone reproduce it?
Thanks!
Bruno
On 10/4/06, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Online report :
http://myfaces.zones.apache.org:8080/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/64/buildId/4855
Build statistics:
State: Failed
Previous State: Failed
Started at: Wed, 4 Oct 2006 22:03:31 +
Finished at: Wed, 4 Oct 2006 22:03:50 +
Total time: 19s
Build Trigger: Schedule
Exit code: 1
Building machine hostname: myfaces.zones.apache.org
Operating system : SunOS(unknown)
Java version : 1.5.0_07(Sun Microsystems Inc.)
Changes
baranda Fixed license header
/myfaces/core/branches/jsf12/impl/src/test/java/org/apache/myfaces/renderkit/html/HtmlMessagesRendererTest.java
baranda Implemented MYFACES-1267 (JSR-252 Issue #122) -
Clarified renderkit docs with respect to what gets rendered for disabled command
link attributes
- Implemented behaviour of disabled as defined in the renderkit javadocs
- Added test
/myfaces/core/branches/jsf12/impl/src/test/java/org/apache/myfaces/renderkit/html/HtmlLinkRendererTest.java
/myfaces/shared/branches/3_0_0/core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlLinkRendererBase.java
/myfaces/shared/branches/3_0_0/core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlRendererUtils.java
Output:
[INFO] Scanning for projects...
[INFO]
[INFO] Building Impl
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/64/target
[INFO] Deleting directory
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/64/target/classes
[INFO] Deleting directory
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/64/target/test-classes
[INFO] [xslt:transform {execution: default}]
[INFO] # of XML files: 2
[INFO] transform, srcFile:
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/64/src/main/tld/myfaces_core.tld,
destFile:
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/64/target/classes/META-INF/myfaces_core.tld
[INFO] transform, srcFile:
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/64/src/main/tld/myfaces_html.tld,
destFile:
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/64/target/classes/META-INF/myfaces_html.tld
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
Compiling 182 source files to
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/64/target/classes
[INFO] [dependency:unpack {execution: unpack-shared-impl}]
[INFO] Configured Artifact:
org.apache.myfaces.shared:myfaces-shared-impl:null:3.0.0-SNAPSHOT:jar
[INFO] Expanding:
/export/home/mrmaven/.m2/repository/org/apache/myfaces/shared/myfaces-shared-impl/3.0.0-SNAPSHOT/myfaces-shared-impl-3.0.0-SNAPSHOT.jar
into
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/64/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
Compiling 18 source files to
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/64/target/test-classes
[INFO] [surefire:test]
[INFO] Setting reports dir:
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/64/target/surefire-reports
---
T E S T S
---
[surefire] Running org.apache.myfaces.renderkit.html.HtmlMessagesRendererTest
[surefire] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.106 sec
FAILURE !!
Component: {Component-Path : [Class:
javax.faces.component.html.HtmlSelectOneRadio,Id: _id0]}
WARNING: Component _id0 just got an automatic id, because there was no id
assigned yet. If this component was created dynamically (i.e. not by a JSP tag)
you should assign it an explicit static id or assign it the id you get from the
createUniqueId from the current UIViewRoot component right after creation!
[surefire] Running org.apache.myfaces.renderkit.html.HtmlRadioRendererTest
[surefire] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.032 sec
RE: [jira] Commented: (TOBAGO-115) myFaces/Tobago does not work in Internet Explorer on Windows 2000 2003
Let me try the new release today first. I should have a definitive by EOW. Thanks, John -Original Message- From: Bernd Bohmann (JIRA) [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 04, 2006 12:35 PM To: John Subject: [jira] Commented: (TOBAGO-115) myFaces/Tobago does not work in Internet Explorer on Windows 2000 2003 [ http://issues.apache.org/jira/browse/TOBAGO-115?page=comments#action_124 39949 ] Bernd Bohmann commented on TOBAGO-115: -- Can we close this issue with the latest changes in Tobago? myFaces/Tobago does not work in Internet Explorer on Windows 2000 2003 -- -- Key: TOBAGO-115 URL: http://issues.apache.org/jira/browse/TOBAGO-115 Project: MyFaces Tobago Issue Type: Bug Affects Versions: 1.0.8 Environment: Internet Explorer 6 on Windows 2000 Pro, 2000 Server, 2003 Server Reporter: John Allan The application functions fine within Firefox on Windows XP, Windows 2000 PRO, Windows 2000 Server, Windows 2003 Server. The application functions almost correctly exhibits behavior on first click only within Internet Explorer on Windows XP SP2 The Application: Consists of a login screen which verifies against a database and then goes to a main.jsp page which is composed of 3 tag files. The main.jsp page has a tabgroup. Bug: Login works great, even on problem platforms. However, once in main.jsp. Clicking on tabs does nothing nor does clicking on any action buttons. It just refreshes. I know it sounds like caching behavior, but we have verified cache headers are outputing correctly and there are no server side caches between the client and Tomcat running our app. This has been escalated to Microsoft IE team, as well as their Windows 2000 team, which has been monitoring the app html communication at length. They claim the app is simply re-sending the same page and this explains the behavior. They have verified also that a cache is not involved. -- 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: Tree2
Hi *, yes, I'd also like to do an Ajaxified version, but that's not the first thing I'm looking at. I believe that extending from UIData is not really what we should do - UIData is totally row-based, and a row-index doesn't make so much sense for a dynamic tree. What are the tree and the table of trinidad sharing with the UIXCollection interface? regards, Martin On 10/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi M- On 10/4/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, I'm reviewing the tree2 currently, and I was wondering if we could have a discussion about some of the concepts. First thing I'd like to discuss is what happens with selected nodes. Currently, selecting a node fires an action-listener. This is somewhat ok, but I believe the selection-model of a tree should rather be a list of values, stored at a useful place. Therefore, the tree should implement the EditableValueHolder-interface, then we could do a lot more with the values of the tree as well. I am not really sure about the EditableValueHolder. In Trinidad the Tree (UIXTree) is type of UIXCollection, which is also used by UIXTable. I remember some discussions from Sean in the past that they Tree2 should extend UIData instead of UIComponent(Base) The change would necessitate to move the current value attribute to some other name - I suppose the name model would be more appropriate nothing wrong w/ using model instead of value, since value makes sense on (editable)valueHolders to me... (like UIOutput, UIInput, UISelect*,...) anyways (I've never understood why a dataTable has a value-attribute, by the way, the semantics for the value-attribute are generally quite different). I guess they just simply introduced that since there was a value of (edit.)value:_holders Additionally, the tree is doing a lot with respect to the markup of the component. I'm not sure if this is useful as very large HTML-bases result from this. I suspect it would be better to only transfer the data-model to the client (and maybe templates for each node-type), and then render the nodes on the client dynamically. you mean sending xml to the client and using a JS_engine to render on the client side? -Matthias Thoughts? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Resolved: (MYFACES-1358) PortletExternalContextImpl should massage RenderResponse.getNamespace() into acceptable ID
[ http://issues.apache.org/jira/browse/MYFACES-1358?page=all ]
Martin Marinschek resolved MYFACES-1358.
Resolution: Invalid
PortletExternalContextImpl should massage RenderResponse.getNamespace() into
acceptable ID
--
Key: MYFACES-1358
URL: http://issues.apache.org/jira/browse/MYFACES-1358
Project: MyFaces Core
Issue Type: Bug
Components: Portlet_Support
Affects Versions: 1.1.3
Environment: MacOS X, JDK 5, GridSphere Portal
Reporter: Jason Novotny
Hi,
I've been testing the most basic portlet in our GridSphere framework and
ran into this error:
java.lang.IllegalArgumentException: Subsequent characters of component
identifier must be a letter, a digit, an underscore ('_'), or a dash ('-')!
But component identifier contains #
at
javax.faces.component.UIComponentBase.isIdValid(UIComponentBase.java:1049)
It appears that PortletExternalContextImpl is using the
RenderResponse.getNamespace() method which in our case will return a string
containing a #.
The JSR168 spec. does not specify any disallowed characters in getNamespace()
so I think this is a bug in the PortletExternalContextImpl class-- probably
in the
public String encodeNamespace(String name)
method, it should conert the response.getNamespace into a form that the
UIComponentBase.isValid method can deal with.
Thanks, Jason
--
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: Tree2
I think a tree is much more about sturctured data instead of input data The UIXCollection is a base clazz for the stamping, that you can say var on those tags. UIComponent | + - UIXComponent | + - UIXComponentBase | + UIXCollection Collection has some subclasses like UIXHierarchy | + UIXTree and UIXIterator | + UIXTable The Trinidad Tree uses a TreeModel which extends CollectionModel (Trin) which extends DataModel (Faces). CollectionModel is also used by the Trin Table. But, I am not really sure, why the table should be EditableValueHolder ? Thanks! -Matthias On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, yes, I'd also like to do an Ajaxified version, but that's not the first thing I'm looking at. I believe that extending from UIData is not really what we should do - UIData is totally row-based, and a row-index doesn't make so much sense for a dynamic tree. What are the tree and the table of trinidad sharing with the UIXCollection interface? regards, Martin On 10/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi M- On 10/4/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, I'm reviewing the tree2 currently, and I was wondering if we could have a discussion about some of the concepts. First thing I'd like to discuss is what happens with selected nodes. Currently, selecting a node fires an action-listener. This is somewhat ok, but I believe the selection-model of a tree should rather be a list of values, stored at a useful place. Therefore, the tree should implement the EditableValueHolder-interface, then we could do a lot more with the values of the tree as well. I am not really sure about the EditableValueHolder. In Trinidad the Tree (UIXTree) is type of UIXCollection, which is also used by UIXTable. I remember some discussions from Sean in the past that they Tree2 should extend UIData instead of UIComponent(Base) The change would necessitate to move the current value attribute to some other name - I suppose the name model would be more appropriate nothing wrong w/ using model instead of value, since value makes sense on (editable)valueHolders to me... (like UIOutput, UIInput, UISelect*,...) anyways (I've never understood why a dataTable has a value-attribute, by the way, the semantics for the value-attribute are generally quite different). I guess they just simply introduced that since there was a value of (edit.)value:_holders Additionally, the tree is doing a lot with respect to the markup of the component. I'm not sure if this is useful as very large HTML-bases result from this. I suspect it would be better to only transfer the data-model to the client (and maybe templates for each node-type), and then render the nodes on the client dynamically. you mean sending xml to the client and using a JS_engine to render on the client side? -Matthias Thoughts? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Tree2
Hi Matthias, for the reason that every component that has changing values needs to be an editable value holder. Imagine the case of a tree embedded in a data-table - a data-table, at least the ones of both MyFaces and the RI (I know, Trinidad's data-table does something different) only save whatever is part of the EditableValueHolder interface. So the selection model of a tree won't be saved in a dataTable, except it is part of the EditableValueHolder interface. regards, Martin On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree is much more about sturctured data instead of input data The UIXCollection is a base clazz for the stamping, that you can say var on those tags. UIComponent | + - UIXComponent | + - UIXComponentBase | + UIXCollection Collection has some subclasses like UIXHierarchy | + UIXTree and UIXIterator | + UIXTable The Trinidad Tree uses a TreeModel which extends CollectionModel (Trin) which extends DataModel (Faces). CollectionModel is also used by the Trin Table. But, I am not really sure, why the table should be EditableValueHolder ? Thanks! -Matthias On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, yes, I'd also like to do an Ajaxified version, but that's not the first thing I'm looking at. I believe that extending from UIData is not really what we should do - UIData is totally row-based, and a row-index doesn't make so much sense for a dynamic tree. What are the tree and the table of trinidad sharing with the UIXCollection interface? regards, Martin On 10/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi M- On 10/4/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, I'm reviewing the tree2 currently, and I was wondering if we could have a discussion about some of the concepts. First thing I'd like to discuss is what happens with selected nodes. Currently, selecting a node fires an action-listener. This is somewhat ok, but I believe the selection-model of a tree should rather be a list of values, stored at a useful place. Therefore, the tree should implement the EditableValueHolder-interface, then we could do a lot more with the values of the tree as well. I am not really sure about the EditableValueHolder. In Trinidad the Tree (UIXTree) is type of UIXCollection, which is also used by UIXTable. I remember some discussions from Sean in the past that they Tree2 should extend UIData instead of UIComponent(Base) The change would necessitate to move the current value attribute to some other name - I suppose the name model would be more appropriate nothing wrong w/ using model instead of value, since value makes sense on (editable)valueHolders to me... (like UIOutput, UIInput, UISelect*,...) anyways (I've never understood why a dataTable has a value-attribute, by the way, the semantics for the value-attribute are generally quite different). I guess they just simply introduced that since there was a value of (edit.)value:_holders Additionally, the tree is doing a lot with respect to the markup of the component. I'm not sure if this is useful as very large HTML-bases result from this. I suspect it would be better to only transfer the data-model to the client (and maybe templates for each node-type), and then render the nodes on the client dynamically. you mean sending xml to the client and using a JS_engine to render on the client side? -Matthias Thoughts? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Tree2
I think a tree should display structured data and not be an input component. What should the input be? So you are willing register also validators on the tree? maybe that is more specialized use case instead a generic tree use case you are looking at. On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Matthias, for the reason that every component that has changing values needs to be an editable value holder. Imagine the case of a tree embedded in a data-table - a data-table, at least the ones of both MyFaces and the RI (I know, Trinidad's data-table does something different) only save whatever is part of the EditableValueHolder interface. So the selection model of a tree won't be saved in a dataTable, except it is part of the EditableValueHolder interface. regards, Martin On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree is much more about sturctured data instead of input data The UIXCollection is a base clazz for the stamping, that you can say var on those tags. UIComponent | + - UIXComponent | + - UIXComponentBase | + UIXCollection Collection has some subclasses like UIXHierarchy | + UIXTree and UIXIterator | + UIXTable The Trinidad Tree uses a TreeModel which extends CollectionModel (Trin) which extends DataModel (Faces). CollectionModel is also used by the Trin Table. But, I am not really sure, why the table should be EditableValueHolder ? Thanks! -Matthias On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, yes, I'd also like to do an Ajaxified version, but that's not the first thing I'm looking at. I believe that extending from UIData is not really what we should do - UIData is totally row-based, and a row-index doesn't make so much sense for a dynamic tree. What are the tree and the table of trinidad sharing with the UIXCollection interface? regards, Martin On 10/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi M- On 10/4/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, I'm reviewing the tree2 currently, and I was wondering if we could have a discussion about some of the concepts. First thing I'd like to discuss is what happens with selected nodes. Currently, selecting a node fires an action-listener. This is somewhat ok, but I believe the selection-model of a tree should rather be a list of values, stored at a useful place. Therefore, the tree should implement the EditableValueHolder-interface, then we could do a lot more with the values of the tree as well. I am not really sure about the EditableValueHolder. In Trinidad the Tree (UIXTree) is type of UIXCollection, which is also used by UIXTable. I remember some discussions from Sean in the past that they Tree2 should extend UIData instead of UIComponent(Base) The change would necessitate to move the current value attribute to some other name - I suppose the name model would be more appropriate nothing wrong w/ using model instead of value, since value makes sense on (editable)valueHolders to me... (like UIOutput, UIInput, UISelect*,...) anyways (I've never understood why a dataTable has a value-attribute, by the way, the semantics for the value-attribute are generally quite different). I guess they just simply introduced that since there was a value of (edit.)value:_holders Additionally, the tree is doing a lot with respect to the markup of the component. I'm not sure if this is useful as very large HTML-bases result from this. I suspect it would be better to only transfer the data-model to the client (and maybe templates for each node-type), and then render the nodes on the client dynamically. you mean sending xml to the client and using a JS_engine to render on the client side? -Matthias Thoughts? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Tree2
also why should a tree, used for navigation structure be an editable value holder? It just structures data :) On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree should display structured data and not be an input component. What should the input be? So you are willing register also validators on the tree? maybe that is more specialized use case instead a generic tree use case you are looking at. On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Matthias, for the reason that every component that has changing values needs to be an editable value holder. Imagine the case of a tree embedded in a data-table - a data-table, at least the ones of both MyFaces and the RI (I know, Trinidad's data-table does something different) only save whatever is part of the EditableValueHolder interface. So the selection model of a tree won't be saved in a dataTable, except it is part of the EditableValueHolder interface. regards, Martin On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree is much more about sturctured data instead of input data The UIXCollection is a base clazz for the stamping, that you can say var on those tags. UIComponent | + - UIXComponent | + - UIXComponentBase | + UIXCollection Collection has some subclasses like UIXHierarchy | + UIXTree and UIXIterator | + UIXTable The Trinidad Tree uses a TreeModel which extends CollectionModel (Trin) which extends DataModel (Faces). CollectionModel is also used by the Trin Table. But, I am not really sure, why the table should be EditableValueHolder ? Thanks! -Matthias On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, yes, I'd also like to do an Ajaxified version, but that's not the first thing I'm looking at. I believe that extending from UIData is not really what we should do - UIData is totally row-based, and a row-index doesn't make so much sense for a dynamic tree. What are the tree and the table of trinidad sharing with the UIXCollection interface? regards, Martin On 10/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi M- On 10/4/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, I'm reviewing the tree2 currently, and I was wondering if we could have a discussion about some of the concepts. First thing I'd like to discuss is what happens with selected nodes. Currently, selecting a node fires an action-listener. This is somewhat ok, but I believe the selection-model of a tree should rather be a list of values, stored at a useful place. Therefore, the tree should implement the EditableValueHolder-interface, then we could do a lot more with the values of the tree as well. I am not really sure about the EditableValueHolder. In Trinidad the Tree (UIXTree) is type of UIXCollection, which is also used by UIXTable. I remember some discussions from Sean in the past that they Tree2 should extend UIData instead of UIComponent(Base) The change would necessitate to move the current value attribute to some other name - I suppose the name model would be more appropriate nothing wrong w/ using model instead of value, since value makes sense on (editable)valueHolders to me... (like UIOutput, UIInput, UISelect*,...) anyways (I've never understood why a dataTable has a value-attribute, by the way, the semantics for the value-attribute are generally quite different). I guess they just simply introduced that since there was a value of (edit.)value:_holders Additionally, the tree is doing a lot with respect to the markup of the component. I'm not sure if this is useful as very large HTML-bases result from this. I suspect it would be better to only transfer the data-model to the client (and maybe templates for each node-type), and then render the nodes on the client dynamically. you mean sending xml to the client and using a JS_engine to render on the client side? -Matthias Thoughts? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail:
commandButton behaviour differs to commandLink
Hello there,
Hopefully someone can help - I have looked through the existing queries and
can't just find what I'm after. I have posted this to users but to no avail,
please could somebody confirm if this is a bug in the software or if I'm
doing something incorrectly?
I have a main record with asociated files - the files are uploaded through
my web app and are downloaded from the same page that lists the files in a
dataTable. I have a series of commandLinks that display the file names - a
user selects the file and it downloads.
The problem I have is that when a user downloads a file then immediately
trys to upload another, they are prompted to download the file that they
have already previously downloaded. If however I replace the commandLinks
for commandButtons the application behaves correctly.
I have seen an associated link that mentions similar behaviour
(http://blogs.sun.com/tor/entry/creating_downloadable_files), however I do
not want to use the command buttons in this manner, and I use an
actionListener rather than an action so I may retrieve information from the
list of dynamically created files. I am not receiving any errors, just the
strange behaviour with commandLinks.
My code is as follows:
public void downloadFile(ActionEvent ev) {
UIData fileList = findParentHtmlDataTable(ev.getComponent());
AssociatedFile associatedFile = (AssociatedFile)
fileList.getRowData();
String downloadPath = download path retrieved here...;
try {
byte[] fileData = InternalUtil.readFile(downloadPath);
HttpServletResponse response =
(HttpServletResponse)
getFacesContext().getExternalContext().getResponse();
response.setHeader(Content-disposition, attachment;
filename=\ +
associatedFile.getName() +
\);
response.setContentLength(fileData.length);
response.setContentType(associatedFile.getContentType());
ServletOutputStream out = response.getOutputStream();
out.write(fileData);
getFacesContext().getApplication().getStateManager().saveSerializedView(getFacesContext());
getFacesContext().responseComplete();
} catch (FileSystemException e) {
getFacesContext().addMessage(null, new FacesMessage(Error
downloading file: +
e.getMessage()));
} catch (IOException e) {
getFacesContext().addMessage(null, new FacesMessage(Error
downloading file: +
e.getMessage()));
}
}
Any help would be greatly appreciated!
Thanks in anticipation, Carl
--
View this message in context:
http://www.nabble.com/commandButton-behaviour-differs-to-commandLink-tf2387145.html#a6654728
Sent from the My Faces - Dev mailing list archive at Nabble.com.
Re: Tree2
I haven't said that there is no value for that. But I am abit against a super tree component :) Maybe there is value for a specialized editable tree or what ever. I know scenarios where that would be nice. but on the other hand you don't want this overhead when just displaying structured data. I think same is true for an editable table (not a table w/ inputText in it... ;) ) -M On 10/5/06, Zubin Wadia [EMAIL PROTECTED] wrote: Matthias, I think the Tree component can be used in contexts beyond navigation - for example, it can be implemented for Content/Document management where a Category-DocumentType heirarchy needs to be user managed and editable based on their changing business process and the type of content they wish to classify. In the .NET world - this excellent Tree component also supports Node editing for such scenarios: http://www.componentart.com/treeview/features.aspx I believe there is value in the use-case Martin is describing. Cheers, Zubin. On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: also why should a tree, used for navigation structure be an editable value holder? It just structures data :) On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree should display structured data and not be an input component. What should the input be? So you are willing register also validators on the tree? maybe that is more specialized use case instead a generic tree use case you are looking at. On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Matthias, for the reason that every component that has changing values needs to be an editable value holder. Imagine the case of a tree embedded in a data-table - a data-table, at least the ones of both MyFaces and the RI (I know, Trinidad's data-table does something different) only save whatever is part of the EditableValueHolder interface. So the selection model of a tree won't be saved in a dataTable, except it is part of the EditableValueHolder interface. regards, Martin On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree is much more about sturctured data instead of input data The UIXCollection is a base clazz for the stamping, that you can say var on those tags. UIComponent | + - UIXComponent | + - UIXComponentBase | + UIXCollection Collection has some subclasses like UIXHierarchy | + UIXTree and UIXIterator | + UIXTable The Trinidad Tree uses a TreeModel which extends CollectionModel (Trin) which extends DataModel (Faces). CollectionModel is also used by the Trin Table. But, I am not really sure, why the table should be EditableValueHolder ? Thanks! -Matthias On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, yes, I'd also like to do an Ajaxified version, but that's not the first thing I'm looking at. I believe that extending from UIData is not really what we should do - UIData is totally row-based, and a row-index doesn't make so much sense for a dynamic tree. What are the tree and the table of trinidad sharing with the UIXCollection interface? regards, Martin On 10/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi M- On 10/4/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, I'm reviewing the tree2 currently, and I was wondering if we could have a discussion about some of the concepts. First thing I'd like to discuss is what happens with selected nodes. Currently, selecting a node fires an action-listener. This is somewhat ok, but I believe the selection-model of a tree should rather be a list of values, stored at a useful place. Therefore, the tree should implement the EditableValueHolder-interface, then we could do a lot more with the values of the tree as well. I am not really sure about the EditableValueHolder. In Trinidad the Tree (UIXTree) is type of UIXCollection, which is also used by UIXTable. I remember some discussions from Sean in the past that they Tree2 should extend UIData instead of UIComponent(Base) The change would necessitate to move the current value attribute to some other name - I suppose the name model would be more appropriate nothing wrong w/ using model instead of value, since value makes sense on (editable)valueHolders to me... (like UIOutput, UIInput, UISelect*,...) anyways (I've never understood why a dataTable has a value-attribute, by the way, the semantics for the value-attribute are generally quite different). I guess they just simply introduced that since there was
Re: Tree2
For better scope control perhaps we should have a baseTree and an advancedTree component set? yeah, maybe we go the route like Faces does it self. A generic component (UITree) and some more specialized (EditableTree) or what ever. -M Cheers, Zubin. On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I haven't said that there is no value for that. But I am abit against a super tree component :) Maybe there is value for a specialized editable tree or what ever. I know scenarios where that would be nice. but on the other hand you don't want this overhead when just displaying structured data. I think same is true for an editable table (not a table w/ inputText in it... ;) ) -M On 10/5/06, Zubin Wadia [EMAIL PROTECTED] wrote: Matthias, I think the Tree component can be used in contexts beyond navigation - for example, it can be implemented for Content/Document management where a Category-DocumentType heirarchy needs to be user managed and editable based on their changing business process and the type of content they wish to classify. In the .NET world - this excellent Tree component also supports Node editing for such scenarios: http://www.componentart.com/treeview/features.aspx I believe there is value in the use-case Martin is describing. Cheers, Zubin. On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: also why should a tree, used for navigation structure be an editable value holder? It just structures data :) On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree should display structured data and not be an input component. What should the input be? So you are willing register also validators on the tree? maybe that is more specialized use case instead a generic tree use case you are looking at. On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Matthias, for the reason that every component that has changing values needs to be an editable value holder. Imagine the case of a tree embedded in a data-table - a data-table, at least the ones of both MyFaces and the RI (I know, Trinidad's data-table does something different) only save whatever is part of the EditableValueHolder interface. So the selection model of a tree won't be saved in a dataTable, except it is part of the EditableValueHolder interface. regards, Martin On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree is much more about sturctured data instead of input data The UIXCollection is a base clazz for the stamping, that you can say var on those tags. UIComponent | + - UIXComponent | + - UIXComponentBase | + UIXCollection Collection has some subclasses like UIXHierarchy | + UIXTree and UIXIterator | + UIXTable The Trinidad Tree uses a TreeModel which extends CollectionModel (Trin) which extends DataModel (Faces). CollectionModel is also used by the Trin Table. But, I am not really sure, why the table should be EditableValueHolder ? Thanks! -Matthias On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, yes, I'd also like to do an Ajaxified version, but that's not the first thing I'm looking at. I believe that extending from UIData is not really what we should do - UIData is totally row-based, and a row-index doesn't make so much sense for a dynamic tree. What are the tree and the table of trinidad sharing with the UIXCollection interface? regards, Martin On 10/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi M- On 10/4/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, I'm reviewing the tree2 currently, and I was wondering if we could have a discussion about some of the concepts. First thing I'd like to discuss is what happens with selected nodes. Currently, selecting a node fires an action-listener. This is somewhat ok, but I believe the selection-model of a tree should rather be a list of values, stored at a useful place. Therefore, the tree should implement the EditableValueHolder-interface, then we could do a lot more with the values of the tree as well. I am not really sure about the EditableValueHolder. In Trinidad the Tree (UIXTree) is type of UIXCollection, which is also used by UIXTable. I remember some discussions from Sean in the past that they Tree2 should extend UIData instead
Re: Tree2
regarding the ajaxized version, would be cool if the renderer takes care of dojo. rendering out the dojo:widget / things and adding the dojo.js file to the *header* of the page. So the widget builds the client treee. -M On 10/5/06, Zubin Wadia [EMAIL PROTECTED] wrote: Right on. I think drag and drop node switching and editing should be part of an AJAXized implementation of the Tree component as that model suits it better. For better scope control perhaps we should have a baseTree and an advancedTree component set? Cheers, Zubin. On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I haven't said that there is no value for that. But I am abit against a super tree component :) Maybe there is value for a specialized editable tree or what ever. I know scenarios where that would be nice. but on the other hand you don't want this overhead when just displaying structured data. I think same is true for an editable table (not a table w/ inputText in it... ;) ) -M On 10/5/06, Zubin Wadia [EMAIL PROTECTED] wrote: Matthias, I think the Tree component can be used in contexts beyond navigation - for example, it can be implemented for Content/Document management where a Category-DocumentType heirarchy needs to be user managed and editable based on their changing business process and the type of content they wish to classify. In the .NET world - this excellent Tree component also supports Node editing for such scenarios: http://www.componentart.com/treeview/features.aspx I believe there is value in the use-case Martin is describing. Cheers, Zubin. On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: also why should a tree, used for navigation structure be an editable value holder? It just structures data :) On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree should display structured data and not be an input component. What should the input be? So you are willing register also validators on the tree? maybe that is more specialized use case instead a generic tree use case you are looking at. On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Matthias, for the reason that every component that has changing values needs to be an editable value holder. Imagine the case of a tree embedded in a data-table - a data-table, at least the ones of both MyFaces and the RI (I know, Trinidad's data-table does something different) only save whatever is part of the EditableValueHolder interface. So the selection model of a tree won't be saved in a dataTable, except it is part of the EditableValueHolder interface. regards, Martin On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree is much more about sturctured data instead of input data The UIXCollection is a base clazz for the stamping, that you can say var on those tags. UIComponent | + - UIXComponent | + - UIXComponentBase | + UIXCollection Collection has some subclasses like UIXHierarchy | + UIXTree and UIXIterator | + UIXTable The Trinidad Tree uses a TreeModel which extends CollectionModel (Trin) which extends DataModel (Faces). CollectionModel is also used by the Trin Table. But, I am not really sure, why the table should be EditableValueHolder ? Thanks! -Matthias On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, yes, I'd also like to do an Ajaxified version, but that's not the first thing I'm looking at. I believe that extending from UIData is not really what we should do - UIData is totally row-based, and a row-index doesn't make so much sense for a dynamic tree. What are the tree and the table of trinidad sharing with the UIXCollection interface? regards, Martin On 10/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi M- On 10/4/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, I'm reviewing the tree2 currently, and I was wondering if we could have a discussion about some of the concepts. First thing I'd like to discuss is what happens with selected nodes. Currently, selecting a node fires an action-listener. This is somewhat ok, but I believe the selection-model of a tree should rather be a list of values, stored at a useful place. Therefore, the tree should implement the EditableValueHolder-interface, then we could do a lot more with the values of the tree as well.
Re: Tree2
Precisely! Perhaps Werner can chime in some more on this too..Z.On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:regarding the ajaxized version, would be cool if the renderer takes care of dojo.rendering out the dojo:widget / things and adding the dojo.jsfile to the *header* of the page. So the widget builds the clienttreee.-MOn 10/5/06, Zubin Wadia [EMAIL PROTECTED] wrote: Right on. I think drag and drop node switching and editing should be part of an AJAXized implementation of the Tree component as that model suits it better. For better scope control perhaps we should have a baseTree and an advancedTree component set? Cheers, Zubin. On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I haven't said that there is no value for that. But I am abit against a super tree component :) Maybe there is value for a specialized editable tree or what ever. I know scenarios where that would be nice. but on the other hand you don't want this overhead when just displaying structured data. I think same is true for an editable table (not a table w/ inputText in it... ;) ) -M On 10/5/06, Zubin Wadia [EMAIL PROTECTED] wrote: Matthias, I think the Tree component can be used in contexts beyond navigation - for example, it can be implemented for Content/Document management where a Category-DocumentType heirarchy needs to be user managed and editable based on their changing business process and the type of content they wish to classify. In the .NET world - this excellent Tree component also supports Node editing for such scenarios: http://www.componentart.com/treeview/features.aspx I believe there is value in the use-case Martin is describing. Cheers, Zubin. On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:also why should a tree, used for navigation structure be an editablevalue holder? It just structures data :) On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree should display structured data and not be an input component. What should the input be? So you are willing register also validators on the tree? maybe that is more specialized use case instead a generic tree use case you are looking at. On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Matthias, for the reason that every component that has changing values needs to be an editable value holder. Imagine the case of a tree embedded in a data-table - a data-table, at least the ones of both MyFaces and the RI (I know, Trinidad's data-table does something different) only save whatever is part of the EditableValueHolder interface. So the selection model of a tree won't be saved in a dataTable, except it is part of the EditableValueHolder interface. regards, Martin On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree is much more about sturctured data instead of input data The UIXCollection is a base clazz for the stamping, that you can say var on those tags. UIComponent | + - UIXComponent | + - UIXComponentBase | + UIXCollection Collection has some subclasses like UIXHierarchy | + UIXTree and UIXIterator | + UIXTable The Trinidad Tree uses a TreeModel which extends CollectionModel (Trin) which extends DataModel (Faces). CollectionModel is also used by the Trin Table. But, I am not really sure, why the table should be EditableValueHolder ? Thanks! -Matthias On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote:Hi *, yes, I'd also like to do an Ajaxified version, but that's not thefirst thing I'm looking at. I believe that extending from UIData is not really what we should do -UIData is totally row-based, and a row-index doesn't make so muchsense for a dynamic tree. What are the tree and the table of trinidad sharing with the UIXCollection interface? regards, Martin On 10/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi M- On 10/4/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, I'm reviewing the tree2 currently, and I was wondering if we could have a discussion about some of the concepts. First thing I'd like to discuss is what happens with selected nodes. Currently, selecting a node fires an action-listener. This is somewhat ok, but I believe the selection-model of a tree should rather be a list of values, stored at a useful place. Therefore, the tree should implement the EditableValueHolder-interface,
My faces apps not deploy on jboss 3.2.7
Hi to everyone, ive devloped a web application using tomahawk upload component, Im deployed this application with jbuilder2006 and Jboss3.2.7, this application works great under windows (all windows xp machine), but when Im deploy this application under linux red hat, this application is not deployed (jboss dosent create a tmp file), the joss is the same jboss Im using under windows (change the run.conf file) Im using the JDK 1.5_07, Im not understand why Ive this problem, can someone help me? Sorry for my English, Bye, Fabio.
Re: Tree2
I bet! :) On 10/5/06, Zubin Wadia [EMAIL PROTECTED] wrote: Precisely! Perhaps Werner can chime in some more on this too.. Z. On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: regarding the ajaxized version, would be cool if the renderer takes care of dojo. rendering out the dojo:widget / things and adding the dojo.js file to the *header* of the page. So the widget builds the client treee. -M On 10/5/06, Zubin Wadia [EMAIL PROTECTED] wrote: Right on. I think drag and drop node switching and editing should be part of an AJAXized implementation of the Tree component as that model suits it better. For better scope control perhaps we should have a baseTree and an advancedTree component set? Cheers, Zubin. On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I haven't said that there is no value for that. But I am abit against a super tree component :) Maybe there is value for a specialized editable tree or what ever. I know scenarios where that would be nice. but on the other hand you don't want this overhead when just displaying structured data. I think same is true for an editable table (not a table w/ inputText in it... ;) ) -M On 10/5/06, Zubin Wadia [EMAIL PROTECTED] wrote: Matthias, I think the Tree component can be used in contexts beyond navigation - for example, it can be implemented for Content/Document management where a Category-DocumentType heirarchy needs to be user managed and editable based on their changing business process and the type of content they wish to classify. In the .NET world - this excellent Tree component also supports Node editing for such scenarios: http://www.componentart.com/treeview/features.aspx I believe there is value in the use-case Martin is describing. Cheers, Zubin. On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: also why should a tree, used for navigation structure be an editable value holder? It just structures data :) On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree should display structured data and not be an input component. What should the input be? So you are willing register also validators on the tree? maybe that is more specialized use case instead a generic tree use case you are looking at. On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Matthias, for the reason that every component that has changing values needs to be an editable value holder. Imagine the case of a tree embedded in a data-table - a data-table, at least the ones of both MyFaces and the RI (I know, Trinidad's data-table does something different) only save whatever is part of the EditableValueHolder interface. So the selection model of a tree won't be saved in a dataTable, except it is part of the EditableValueHolder interface. regards, Martin On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree is much more about sturctured data instead of input data The UIXCollection is a base clazz for the stamping, that you can say var on those tags. UIComponent | + - UIXComponent | + - UIXComponentBase | + UIXCollection Collection has some subclasses like UIXHierarchy | + UIXTree and UIXIterator | + UIXTable The Trinidad Tree uses a TreeModel which extends CollectionModel (Trin) which extends DataModel (Faces). CollectionModel is also used by the Trin Table. But, I am not really sure, why the table should be EditableValueHolder ? Thanks! -Matthias On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, yes, I'd also like to do an Ajaxified version, but that's not the first thing I'm looking at. I believe that extending from UIData is not really what we should do - UIData is totally row-based, and a row-index doesn't make so much sense for a dynamic tree. What are the tree and the table of trinidad sharing with the UIXCollection interface? regards, Martin On 10/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi M- On 10/4/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, I'm reviewing the tree2 currently, and I was wondering if we could
[jira] Created: (TOMAHAWK-727) tree2 do not work with clientSideToggle=true and preserveToggle=false
tree2 do not work with clientSideToggle=true and preserveToggle=false - Key: TOMAHAWK-727 URL: http://issues.apache.org/jira/browse/TOMAHAWK-727 Project: MyFaces Tomahawk Issue Type: Bug Components: Tree Affects Versions: 1.1.5-SNAPSHOT Reporter: Mario Ivankovits The reason is that the server side treeModel do not know which nodes are expanded and so do not call decode on them. 1) In HtmlTreeRenderer.decode If a node is expanded or not will be restored from the cookie (client-side) or from a request parameter (server-side) There the case that in client-side toggle there is no cookie will not be honored 2) UITreeData.processNodes There the TreeWalker see a all nodes closed tree and stops traversing -- 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-727) tree2 do not work with clientSideToggle=true and preserveToggle=false
[ http://issues.apache.org/jira/browse/TOMAHAWK-727?page=comments#action_12440099 ] Mario Ivankovits commented on TOMAHAWK-727: --- IMHO the correct solution is to transfer the tree state through a hidden field. The problem one might have then is, that the tree will show the nodes expanded after postback (even without preserverToggle). For me having the nodes expanded is the behavior I await from the tree. Any objections? tree2 do not work with clientSideToggle=true and preserveToggle=false - Key: TOMAHAWK-727 URL: http://issues.apache.org/jira/browse/TOMAHAWK-727 Project: MyFaces Tomahawk Issue Type: Bug Components: Tree Affects Versions: 1.1.5-SNAPSHOT Reporter: Mario Ivankovits The reason is that the server side treeModel do not know which nodes are expanded and so do not call decode on them. 1) In HtmlTreeRenderer.decode If a node is expanded or not will be restored from the cookie (client-side) or from a request parameter (server-side) There the case that in client-side toggle there is no cookie will not be honored 2) UITreeData.processNodes There the TreeWalker see a all nodes closed tree and stops traversing -- 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: Tree2
Let me read the entire thread first :-) later tonight Matthias Wessendorf schrieb: I bet! :) On 10/5/06, Zubin Wadia [EMAIL PROTECTED] wrote: Precisely! Perhaps Werner can chime in some more on this too.. Z.
Re: Tree2
Hello Mattias, I am so new to this list and may be I am not allowed to say this, but I think most developers I have seen use menu related components for only displaying structured data, and most of times data is displayed to user for one of the following purposes: 1) selecting one item 2) selecting multiple item 3) displaying and editing tree structured data (like organization chart, directory services, etc) the first 2 options are currently supported features of tree2, the 3'rd is under debate. May be if we can use same parent for both menu and tree navigation related components and simple tree data structure as said by matias and zubin, for parent of all these components can have following benefits: 1) simplifying development 2) simplifying learning for users 3) making it easier to add more advanced trees later on demand Best regards Arash On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree should display structured data and not be an input component.What should the input be? So you are willing register also validatorson the tree?maybe that is more specialized use case instead a generic tree use case you are looking at.On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Matthias, for the reason that every component that has changing values needs to be an editable value holder. Imagine the case of a tree embedded in a data-table - a data-table, at least the ones of both MyFaces and the RI (I know, Trinidad's data-table does something different) only save whatever is part of the EditableValueHolder interface. So the selection model of a tree won't be saved in a dataTable, except it is part of the EditableValueHolder interface. regards, Martin On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree is much more about sturctured data instead of input data The UIXCollection is a base clazz for the stamping, that you can say var on those tags. UIComponent | + - UIXComponent | + - UIXComponentBase | + UIXCollection Collection has some subclasses like UIXHierarchy | + UIXTree and UIXIterator | + UIXTable The Trinidad Tree uses a TreeModel which extends CollectionModel (Trin) which extends DataModel (Faces). CollectionModel is also used by the Trin Table. But, I am not really sure, why the table should be EditableValueHolder ? Thanks! -Matthias On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, yes, I'd also like to do an Ajaxified version, but that's not the first thing I'm looking at. I believe that extending from UIData is not really what we should do - UIData is totally row-based, and a row-index doesn't make so much sense for a dynamic tree. What are the tree and the table of trinidad sharing with the UIXCollection interface? regards, Martin On 10/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:Hi M- On 10/4/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, I'm reviewing the tree2 currently, and I was wondering if we could have a discussion about some of the concepts. First thing I'd like to discuss is what happens with selected nodes. Currently, selecting a node fires an action-listener. This is somewhat ok, but I believe the selection-model of a tree should rather be a list of values, stored at a useful place. Therefore, the tree should implement the EditableValueHolder-interface, then we could do a lot more with the values of the tree as well. I am not really sure about the EditableValueHolder. In Trinidad theTree (UIXTree) is type of UIXCollection, which is also used by UIXTable. I remember some discussions from Sean in the past that they Tree2should extend UIData instead of UIComponent(Base) The change would necessitate to move the current value attribute to some other name - I suppose the name model would be more appropriate nothing wrong w/ using model instead of value, since value makes sense on(editable)valueHolders to me...(like UIOutput, UIInput, UISelect*,...) anyways (I've never understood why a dataTable has a value-attribute, by the way, the semantics for the value-attribute are generally quite different). I guess they just simply introduced that since there was a value of(edit.)value:_holders Additionally, the tree is doing a lot with respect to the markup of the component. I'm not sure if this is useful as very large HTML-bases result from this. I suspect it would be better to only transfer the data-model to the client (and maybe templates for each node-type), and then render the nodes on the client dynamically. you mean sending xml to the client and using a JS_engine to renderon the client side? -Matthias Thoughts? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and
[jira] Created: (TOBAGO-144) The datepicker of tc:date should surrounded by a form to prevent validation errors from other fields
The datepicker of tc:date should surrounded by a form to prevent validation errors from other fields Key: TOBAGO-144 URL: http://issues.apache.org/jira/browse/TOBAGO-144 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 1.0.8 Environment: Tobago 1.0.8 jdk14retro Reporter: Rainer Rohloff Similarly too the problem of tx:date -- 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: Tree2
hi Arash, sure your feedback is welcome :) like said before, a generic raw version + aditional tree stuff. During that task we should also take a look at tree / treeTable, IMHO. -M On 10/5/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: Hello Mattias, I am so new to this list and may be I am not allowed to say this, but I think most developers I have seen use menu related components for only displaying structured data, and most of times data is displayed to user for one of the following purposes: 1) selecting one item 2) selecting multiple item 3) displaying and editing tree structured data (like organization chart, directory services, etc) the first 2 options are currently supported features of tree2, the 3'rd is under debate. May be if we can use same parent for both menu and tree navigation related components and simple tree data structure as said by matias and zubin, for parent of all these components can have following benefits: 1) simplifying development 2) simplifying learning for users 3) making it easier to add more advanced trees later on demand Best regards Arash On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree should display structured data and not be an input component. What should the input be? So you are willing register also validators on the tree? maybe that is more specialized use case instead a generic tree use case you are looking at. On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Matthias, for the reason that every component that has changing values needs to be an editable value holder. Imagine the case of a tree embedded in a data-table - a data-table, at least the ones of both MyFaces and the RI (I know, Trinidad's data-table does something different) only save whatever is part of the EditableValueHolder interface. So the selection model of a tree won't be saved in a dataTable, except it is part of the EditableValueHolder interface. regards, Martin On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree is much more about sturctured data instead of input data The UIXCollection is a base clazz for the stamping, that you can say var on those tags. UIComponent | + - UIXComponent | + - UIXComponentBase | + UIXCollection Collection has some subclasses like UIXHierarchy | + UIXTree and UIXIterator | + UIXTable The Trinidad Tree uses a TreeModel which extends CollectionModel (Trin) which extends DataModel (Faces). CollectionModel is also used by the Trin Table. But, I am not really sure, why the table should be EditableValueHolder ? Thanks! -Matthias On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, yes, I'd also like to do an Ajaxified version, but that's not the first thing I'm looking at. I believe that extending from UIData is not really what we should do - UIData is totally row-based, and a row-index doesn't make so much sense for a dynamic tree. What are the tree and the table of trinidad sharing with the UIXCollection interface? regards, Martin On 10/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi M- On 10/4/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, I'm reviewing the tree2 currently, and I was wondering if we could have a discussion about some of the concepts. First thing I'd like to discuss is what happens with selected nodes. Currently, selecting a node fires an action-listener. This is somewhat ok, but I believe the selection-model of a tree should rather be a list of values, stored at a useful place. Therefore, the tree should implement the EditableValueHolder-interface, then we could do a lot more with the values of the tree as well. I am not really sure about the EditableValueHolder. In Trinidad the Tree (UIXTree) is type of UIXCollection, which is also used by UIXTable. I remember some discussions from Sean in the past that they Tree2 should extend UIData instead of UIComponent(Base) The change would necessitate to move the current value attribute to some other name - I suppose the name model would be more appropriate nothing wrong w/ using model instead of value, since value makes sense on (editable)valueHolders to me... (like UIOutput, UIInput, UISelect*,...) anyways (I've never understood why a dataTable has a value-attribute, by the way, the semantics for the value-attribute are generally quite different). I guess they just simply introduced that since there was a value of (edit.)value:_holders Additionally, the tree is doing a lot with respect to the markup of the component. I'm not
MyFaces Sanbox Sun JSF
Hi, I try to implement a dévelopment realised with Spring Webflow and JSF in a ExoPortal (www.exoplatform.org). I develop my application with MyFaces Core, MyFaces Tomahawk and MyFace Tomahawk Sanbox. In fact ExoPortal use the Sun JSF RI. So I observe an incompatibility between Sun JSF RI and MyFace Tomahawk Sanbox. My MyFace Tomahawk Sanbox version is dated 4th of Oct. 2006. I have this error : [ERROR] osbo] - Exception lors de l'envoi de l'évènement contexte initialisé (context initialized) à l'instance de classe d'écoute (listener) com.sun.faces.config.ConfigureListener [[EN : Exception at the time of the sending of the event context initialized (context initialized) with the authority of class of listening ]] javax.faces.FacesException: java.lang.ClassCastException: org.apache.myfaces.custom.ajax.api.AjaxDecodePhaseListenerjavax.faces.FacesException: java.lang.ClassCastException: org.apache.myfaces.custom.ajax.api.AjaxDecodePhaseListener at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:336) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3729) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4187) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:809) at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:698) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:472) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1122) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1021) at org.apache.catalina.core.StandardHost.start(StandardHost.java:718) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442) at org.apache.catalina.core.StandardService.start(StandardService.java:450) at org.apache.catalina.core.StandardServer.start(StandardServer.java:709) at org.apache.catalina.startup.Catalina.start(Catalina.java:551) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432) Caused by: java.lang.ClassCastException: org.apache.myfaces.custom.ajax.api.AjaxDecodePhaseListener at com.sun.faces.config.ConfigureListener.configure(ConfigureListener.java:741) at com.sun.faces.config.ConfigureListener.configure(ConfigureListener.java:400) at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:332) ... 24 more libraries used : in CATALINA_HOME/common/lib --- --- activation-1.0.jar antlr-2.7.5H3.jar antlr-2.7.5.jar asm-1.5.3.jar c3p0-0.8.4.5.jar cas-2.0.12.jar casclient-2.1.1.jar cglib-2.1.3.jar commons-beanutils-1.6.jar commons-beanutils-1.7.0.jar commons-collections-3.1.jar commons-dbcp-1.2.1.jar commons-digester-1.6.jar commons-el.jar commons-fileupload-1.0.jar commons-lang-2.1.jar commons-pool-1.2.jar Compiere.jar dom4j-1.4.jar dom4j-1.6.1.jar drools-base-2.0.jar drools-core-2.0.jar drools-io-2.0.jar drools-java-2.0.jar drools-smf-2.0.jar ehcache-1.2.1RC.jar exo-platform.commons-2.0.1.jar exo-platform.container-2.0.1.jar exo-platform.services.backup.api-2.0.1.jar exo-platform.services.backup.impl-2.0.1.jar exo-platform.services.cache.api-2.0.1.jar exo-platform.services.cache.impl-2.0.1.jar exo-platform.services.chart.api-2.0.1.jar exo-platform.services.chart.impl-2.0.1.jar exo-platform.services.common.api-2.0.1.jar exo-platform.services.common.impl-2.0.1.jar exo-platform.services.database.api-2.0.1.jar exo-platform.services.database.impl-2.0.1.jar exo-platform.services.indexing.api-2.0.1.jar exo-platform.services.indexing.impl-2.0.1.jar exo-platform.services.ldap.api-2.0.1.jar exo-platform.services.ldap.impl-2.0.1.jar exo-platform.services.organization.api-2.0.1.jar exo-platform.services.organization.impl-2.0.1.jar exo-platform.services.remote.api-2.0.1.jar exo-platform.services.remote.impl-2.0.1.jar exo-platform.services.resources.api-2.0.1.jar exo-platform.services.resources.impl-2.0.1.jar exo-platform.services.security.api-2.0.1.jar exo-platform.services.security.impl-2.0.1.jar exo-platform.services.templates.api-2.0.1.jar exo-platform.services.templates.impl-2.0.1.jar exo-platform.services.xml-processing.api-2.0.1.jar
Re: Tree2
Well, it wouldn't be a problem to have an extended version of the tree which implements EditableValueHolder, but not if the model of the tree is configured by setting the value-attribute - then extending won't work. regards, Martin On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: hi Arash, sure your feedback is welcome :) like said before, a generic raw version + aditional tree stuff. During that task we should also take a look at tree / treeTable, IMHO. -M On 10/5/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: Hello Mattias, I am so new to this list and may be I am not allowed to say this, but I think most developers I have seen use menu related components for only displaying structured data, and most of times data is displayed to user for one of the following purposes: 1) selecting one item 2) selecting multiple item 3) displaying and editing tree structured data (like organization chart, directory services, etc) the first 2 options are currently supported features of tree2, the 3'rd is under debate. May be if we can use same parent for both menu and tree navigation related components and simple tree data structure as said by matias and zubin, for parent of all these components can have following benefits: 1) simplifying development 2) simplifying learning for users 3) making it easier to add more advanced trees later on demand Best regards Arash On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree should display structured data and not be an input component. What should the input be? So you are willing register also validators on the tree? maybe that is more specialized use case instead a generic tree use case you are looking at. On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Matthias, for the reason that every component that has changing values needs to be an editable value holder. Imagine the case of a tree embedded in a data-table - a data-table, at least the ones of both MyFaces and the RI (I know, Trinidad's data-table does something different) only save whatever is part of the EditableValueHolder interface. So the selection model of a tree won't be saved in a dataTable, except it is part of the EditableValueHolder interface. regards, Martin On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree is much more about sturctured data instead of input data The UIXCollection is a base clazz for the stamping, that you can say var on those tags. UIComponent | + - UIXComponent | + - UIXComponentBase | + UIXCollection Collection has some subclasses like UIXHierarchy | + UIXTree and UIXIterator | + UIXTable The Trinidad Tree uses a TreeModel which extends CollectionModel (Trin) which extends DataModel (Faces). CollectionModel is also used by the Trin Table. But, I am not really sure, why the table should be EditableValueHolder ? Thanks! -Matthias On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, yes, I'd also like to do an Ajaxified version, but that's not the first thing I'm looking at. I believe that extending from UIData is not really what we should do - UIData is totally row-based, and a row-index doesn't make so much sense for a dynamic tree. What are the tree and the table of trinidad sharing with the UIXCollection interface? regards, Martin On 10/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi M- On 10/4/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, I'm reviewing the tree2 currently, and I was wondering if we could have a discussion about some of the concepts. First thing I'd like to discuss is what happens with selected nodes. Currently, selecting a node fires an action-listener. This is somewhat ok, but I believe the selection-model of a tree should rather be a list of values, stored at a useful place. Therefore, the tree should implement the EditableValueHolder-interface, then we could do a lot more with the values of the tree as well. I am not really sure about the EditableValueHolder. In Trinidad the Tree (UIXTree) is type of UIXCollection, which is also used by UIXTable. I remember some discussions from Sean in the past that they Tree2 should extend UIData instead of UIComponent(Base) The change would necessitate to move the current value attribute to some other name - I suppose the name model would be more appropriate nothing wrong w/ using model instead of value, since value makes sense on (editable)valueHolders to me...
[jira] Created: (MYFACES-1433) HTML Response encodes Javascript code with numeric character references for non-UTF8 character encoding
HTML Response encodes Javascript code with numeric character references for non-UTF8 character encoding --- Key: MYFACES-1433 URL: http://issues.apache.org/jira/browse/MYFACES-1433 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.1.3 Environment: Windows XP, BEA Weblogic 8.1, JDK 1.4.2, but probably not restricted to this environment. Reporter: Claus Schmid [A similar issue was already open under MYFACES-218.] We use Ajax4JSF which sends Javascript code embedded in Ajax responses to the server. This Javascript code is used to update client-side state of input components and select components (comboboxes). In the case of comboboxes, the response also contains literal String arrays. We use ISO-8859-1 as the output character set, not UTF-8. The effect that we notice is the same as stated in MYFACES-218, namely that the Javascript strings are rendered with all non-latin-1 characters replaced by numeric character references. As the Javascript strings are used to update input fields or re-render select options, e.g., a combobox would then contain entries where non-latin-1 characters show up with the character references visible instead of the intended characters. In this environment it is no longer easy to go over all the returned strings and use some client-side replacement function, because the client-side code is part of the Ajax4JSF project. Also, implementing some un-escaping functionality on the client side makes the client dependent on particulars of the server-side JSF implementation. Also, in my humble opinion, having the character references in Javascript strings is plain wrong, however, this is from my experience and not from looking through standard documents. But the net effect is that the strings are not rendered correctly (as intended) by the browser. Regards, Claus -- 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: [jira] Updated: (TOMAHAWK-705) t:column tag with attribute groupBy =true doesn't work if column contains t:commandLink
Hello I've got your update about patch for this issue, but i don't see any attachements or subversion commits. Where should i get the patch from? Should i use nightly build 1.1.5 ? Thanks On 10/4/06, Nereida Hoxhaj (JIRA) dev@myfaces.apache.org wrote: [ http://issues.apache.org/jira/browse/TOMAHAWK-705?page=all ]Nereida Hoxhaj updated TOMAHAWK-705: Status: Patch Available(was: Open) t:columntagwith attribute groupBy =true doesn't work if column contains t:commandLink --- Key: TOMAHAWK-705 URL: http://issues.apache.org/jira/browse/TOMAHAWK-705 Project: MyFaces TomahawkIssue Type: BugComponents: ColumnAffects Versions: 1.1.3, 1.1.5-SNAPSHOT Reporter: Furer AlexanderPriority: Blocker t:columntagwith attribute groupBy =true doesn't work if column contains t:commandLink with t:outputTextinside, if column contains only t:outputText it works OK. --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: [jira] Updated: (TOMAHAWK-705) t:column tag with attribute groupBy =true doesn't work if column contains t:commandLink
I'm sorry but there's no patch. I didn't mean to clicke on the patch link, i was clicking somewhere else and i didn't find a way to undo the operation. On 10/5/06, Alexander F [EMAIL PROTECTED] wrote: Hello I've got your update about patch for this issue, but i don't see any attachements or subversion commits. Where should i get the patch from? Should i use nightly build 1.1.5 ? Thanks On 10/4/06, Nereida Hoxhaj (JIRA) dev@myfaces.apache.org wrote: [ http://issues.apache.org/jira/browse/TOMAHAWK-705?page=all ] Nereida Hoxhaj updated TOMAHAWK-705: Status: Patch Available (was: Open) t:column tag with attribute groupBy =true doesn't work if column contains t:commandLink --- Key: TOMAHAWK-705 URL: http://issues.apache.org/jira/browse/TOMAHAWK-705 Project: MyFaces Tomahawk Issue Type: Bug Components: Column Affects Versions: 1.1.3, 1.1.5-SNAPSHOT Reporter: Furer Alexander Priority: Blocker t:column tag with attribute groupBy =true doesn't work if column contains t:commandLink with t:outputText inside, if column contains only t:outputText it works OK. -- 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 -- Se diventi milionario ricordati degli amici... SuperEnalotto online: http://ad.zanox.com/ppc/?3481898C816095969T
[jira] Resolved: (MYFACES-1256) JSR-252 Issue #154: Fixed FacesTag name attribute discrepency - made it a String (was ValueExpression).
[ http://issues.apache.org/jira/browse/MYFACES-1256?page=all ] Bruno Aranda resolved MYFACES-1256. --- Fix Version/s: 1.2.0-SNAPSHOT Resolution: Fixed In MyFaces, we didn't have the discrepancy, but I have added explicitly the type java.lang.String JSR-252 Issue #154: Fixed FacesTag name attribute discrepency - made it a String (was ValueExpression). - Key: MYFACES-1256 URL: http://issues.apache.org/jira/browse/MYFACES-1256 Project: MyFaces Core Issue Type: Improvement Components: JSR-252 Reporter: Stan Silvert Fix For: 1.2.0-SNAPSHOT Fixed FacesTag name attribute discrepency - made it a String (was ValueExpression). See https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=154 -- 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
[offtopic][rollcall] Who's Going To Be At Apache Con?
Can we start a roll call of who is going to be at Apache Con and on what days? I'm posting this to both Shale and MyFaces list since I feel there is a lot of overlap between our two groups. I will be there Tuesday (late afternoon) - Friday (leaving early in the morning) Sean
[jira] Resolved: (MYFACES-1257) JSR-252 Issue #155: Specified columnClasses, rowClasses descriptions for panelGrid in renderkit docs.
[ http://issues.apache.org/jira/browse/MYFACES-1257?page=all ] Bruno Aranda resolved MYFACES-1257. --- Fix Version/s: 1.2.0-SNAPSHOT Resolution: Fixed JSR-252 Issue #155: Specified columnClasses, rowClasses descriptions for panelGrid in renderkit docs. - Key: MYFACES-1257 URL: http://issues.apache.org/jira/browse/MYFACES-1257 Project: MyFaces Core Issue Type: New Feature Components: JSR-252 Reporter: Stan Silvert Fix For: 1.2.0-SNAPSHOT Specified columnClasses, rowClasses descriptions for panelGrid in renderkit docs. See https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=155 -- 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: [offtopic][rollcall] Who's Going To Be At Apache Con?
I will be there Tuesday (late afternoon) - Sunday (late afternooon) On 10/5/06, Sean Schofield [EMAIL PROTECTED] wrote: Can we start a roll call of who is going to be at Apache Con and on what days? I'm posting this to both Shale and MyFaces list since I feel there is a lot of overlap between our two groups. I will be there Tuesday (late afternoon) - Friday (leaving early in the morning) Sean -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Tree2
No, it's a pity that not, but I can't. I'm at a client here in Germany until end of November, can't take off a week. regards, Martin On 10/5/06, Sean Schofield [EMAIL PROTECTED] wrote: Martin: I haven't had time to read this thread yet but I will shortly. Are you going to be at Apache Con this year? If so we can discuss some of your ideas in person as well. Sean On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Well, it wouldn't be a problem to have an extended version of the tree which implements EditableValueHolder, but not if the model of the tree is configured by setting the value-attribute - then extending won't work. regards, Martin On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: hi Arash, sure your feedback is welcome :) like said before, a generic raw version + aditional tree stuff. During that task we should also take a look at tree / treeTable, IMHO. -M On 10/5/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: Hello Mattias, I am so new to this list and may be I am not allowed to say this, but I think most developers I have seen use menu related components for only displaying structured data, and most of times data is displayed to user for one of the following purposes: 1) selecting one item 2) selecting multiple item 3) displaying and editing tree structured data (like organization chart, directory services, etc) the first 2 options are currently supported features of tree2, the 3'rd is under debate. May be if we can use same parent for both menu and tree navigation related components and simple tree data structure as said by matias and zubin, for parent of all these components can have following benefits: 1) simplifying development 2) simplifying learning for users 3) making it easier to add more advanced trees later on demand Best regards Arash On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree should display structured data and not be an input component. What should the input be? So you are willing register also validators on the tree? maybe that is more specialized use case instead a generic tree use case you are looking at. On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Matthias, for the reason that every component that has changing values needs to be an editable value holder. Imagine the case of a tree embedded in a data-table - a data-table, at least the ones of both MyFaces and the RI (I know, Trinidad's data-table does something different) only save whatever is part of the EditableValueHolder interface. So the selection model of a tree won't be saved in a dataTable, except it is part of the EditableValueHolder interface. regards, Martin On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree is much more about sturctured data instead of input data The UIXCollection is a base clazz for the stamping, that you can say var on those tags. UIComponent | + - UIXComponent | + - UIXComponentBase | + UIXCollection Collection has some subclasses like UIXHierarchy | + UIXTree and UIXIterator | + UIXTable The Trinidad Tree uses a TreeModel which extends CollectionModel (Trin) which extends DataModel (Faces). CollectionModel is also used by the Trin Table. But, I am not really sure, why the table should be EditableValueHolder ? Thanks! -Matthias On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, yes, I'd also like to do an Ajaxified version, but that's not the first thing I'm looking at. I believe that extending from UIData is not really what we should do - UIData is totally row-based, and a row-index doesn't make so much sense for a dynamic tree. What are the tree and the table of trinidad sharing with the UIXCollection interface? regards, Martin On 10/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi M- On 10/4/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, I'm reviewing the tree2 currently, and I was wondering if we could have a discussion about some of the concepts. First thing I'd like to discuss is what happens with selected nodes. Currently, selecting a node fires an action-listener. This is somewhat ok, but I believe the selection-model of a tree should rather be a list of values, stored at a useful place. Therefore, the tree should
[jira] Updated: (TOMAHAWK-728) newspaperColumns attribute ignores EL expression
[ http://issues.apache.org/jira/browse/TOMAHAWK-728?page=all ] Michael Matz updated TOMAHAWK-728: -- Status: Patch Available (was: Open) newspaperColumns attribute ignores EL expression Key: TOMAHAWK-728 URL: http://issues.apache.org/jira/browse/TOMAHAWK-728 Project: MyFaces Tomahawk Issue Type: Bug Components: Extended Datatable, Newspaper Table Affects Versions: 1.1.4-SNAPSHOT, 1.1.5-SNAPSHOT Reporter: Michael Matz Attachments: HtmlDataTable.java If you use an EL expression for the newspaperColumns attribute it is ignored and the default value of 1 is used 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
[jira] Commented: (MYFACES-1358) PortletExternalContextImpl should massage RenderResponse.getNamespace() into acceptable ID
[
http://issues.apache.org/jira/browse/MYFACES-1358?page=comments#action_12440234
]
Wendy Smoak commented on MYFACES-1358:
--
Related discussion thread:
http://www.nabble.com/JIRA-Issue-MYFACES-1358-t2386768.html
PortletExternalContextImpl should massage RenderResponse.getNamespace() into
acceptable ID
--
Key: MYFACES-1358
URL: http://issues.apache.org/jira/browse/MYFACES-1358
Project: MyFaces Core
Issue Type: Bug
Components: Portlet_Support
Affects Versions: 1.1.3
Environment: MacOS X, JDK 5, GridSphere Portal
Reporter: Jason Novotny
Hi,
I've been testing the most basic portlet in our GridSphere framework and
ran into this error:
java.lang.IllegalArgumentException: Subsequent characters of component
identifier must be a letter, a digit, an underscore ('_'), or a dash ('-')!
But component identifier contains #
at
javax.faces.component.UIComponentBase.isIdValid(UIComponentBase.java:1049)
It appears that PortletExternalContextImpl is using the
RenderResponse.getNamespace() method which in our case will return a string
containing a #.
The JSR168 spec. does not specify any disallowed characters in getNamespace()
so I think this is a bug in the PortletExternalContextImpl class-- probably
in the
public String encodeNamespace(String name)
method, it should conert the response.getNamespace into a form that the
UIComponentBase.isValid method can deal with.
Thanks, Jason
--
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-1248) JSR-252 Issue #123: Clarified renderkit docs with respect to dataTable attribute rendering
[ http://issues.apache.org/jira/browse/MYFACES-1248?page=all ] Bruno Aranda resolved MYFACES-1248. --- Fix Version/s: 1.2.0-SNAPSHOT Resolution: Fixed Assignee: Bruno Aranda Added scope=col for column headers (th), as mandated by the spec JSR-252 Issue #123: Clarified renderkit docs with respect to dataTable attribute rendering -- Key: MYFACES-1248 URL: http://issues.apache.org/jira/browse/MYFACES-1248 Project: MyFaces Core Issue Type: Improvement Components: JSR-252 Reporter: Stan Silvert Assigned To: Bruno Aranda Fix For: 1.2.0-SNAPSHOT Clarified renderkit docs with respect to dataTable attribute rendering See https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=123 -- 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: [offtopic][rollcall] Who's Going To Be At Apache Con?
On 10/5/06, Sean Schofield [EMAIL PROTECTED] wrote: Can we start a roll call of who is going to be at Apache Con and onwhat days?I'm posting this to both Shale and MyFaces list since Ifeel there is a lot of overlap between our two groups.I will be there Tuesday (late afternoon) - Friday (leaving early in the morning) I'm arriving Monday late afternoon, leaving Friday night. SeanCraig
[jira] Resolved: (MYFACES-1247) JSR-252 Issue #120: Specified in the renderkit docs that commandButton rendering can generate javascript for onclick attribute.
[ http://issues.apache.org/jira/browse/MYFACES-1247?page=all ] Bruno Aranda resolved MYFACES-1247. --- Fix Version/s: 1.2.0-SNAPSHOT Resolution: Invalid Assignee: Bruno Aranda Spec change only, nothing needed for myfaces JSR-252 Issue #120: Specified in the renderkit docs that commandButton rendering can generate javascript for onclick attribute. - Key: MYFACES-1247 URL: http://issues.apache.org/jira/browse/MYFACES-1247 Project: MyFaces Core Issue Type: New Feature Components: JSR-252 Reporter: Stan Silvert Assigned To: Bruno Aranda Fix For: 1.2.0-SNAPSHOT Specified in the renderkit docs that commandButton rendering can generate javascript for onclick attribute. See https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=120 -- 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
JSR-252
Hi, I see that there are a number of Jira's opened with JSR-252 as the component. Does that mean there is a definitive (or even tentative) plan to implement the new specification for JSF 1.2 ?? If so, I'm really just trying to ascertain when to anticipate a MyFaces release based on JSR-252. Thanks much for any information. Tim
Re: JSR-252
Hey Tim, Adam just said that he's forced to use the RI for right now so I'm not sure it really implies anything about Faces. Presumably, however, if we can get Trinidad to run on the RI, then it would make a hell of a testcase for MyFaces JSR252 implementation when it's released. Scott Tim McConnell wrote: Hi, I see that there are a number of Jira's opened with JSR-252 as the component. Does that mean there is a definitive (or even tentative) plan to implement the new specification for JSF 1.2 ?? If so, I'm really just trying to ascertain when to anticipate a MyFaces release based on JSR-252. Thanks much for any information. Tim
[jira] Created: (MYFACES-1434) All attributes in tags must be of type ValueExpression. In the tld, the attributes must contain a deferred-type element with the attribute type
All attributes in tags must be of type ValueExpression. In the tld, the attributes must contain a deferred-type element with the attribute type - Key: MYFACES-1434 URL: http://issues.apache.org/jira/browse/MYFACES-1434 Project: MyFaces Core Issue Type: Improvement Components: JSR-252 Reporter: Bruno Aranda Assigned To: Bruno Aranda Attributes in tags are of type javax.el.ValueExpression. In the tld, following the jsp 2.1 spec we have to put the deferred-type element, with the type of the attribute. This is a major change in the codebase. Now methods such as UIComponentTagUtils.setIntegerProperty, UIComponentTagUtils.setStringProperty, etc, will be deprecated in favor of a unique UIComponentTagUtils.setProperty (accepting a ValueExpression instead of a String). This methods are called in the setProperties() methods of the tags -- 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-1434) All attributes in tags must be of type ValueExpression. In the tld, the attributes must contain a deferred-type element with the attribute type
[ http://issues.apache.org/jira/browse/MYFACES-1434?page=comments#action_12440274 ] Bruno Aranda commented on MYFACES-1434: --- Ah, no, the methods setIntegerProperty, setBooleanProperty, etc, are still useful and should be used... All attributes in tags must be of type ValueExpression. In the tld, the attributes must contain a deferred-type element with the attribute type - Key: MYFACES-1434 URL: http://issues.apache.org/jira/browse/MYFACES-1434 Project: MyFaces Core Issue Type: Improvement Components: JSR-252 Reporter: Bruno Aranda Assigned To: Bruno Aranda Attributes in tags are of type javax.el.ValueExpression. In the tld, following the jsp 2.1 spec we have to put the deferred-type element, with the type of the attribute. This is a major change in the codebase. Now methods such as UIComponentTagUtils.setIntegerProperty, UIComponentTagUtils.setStringProperty, etc, will be deprecated in favor of a unique UIComponentTagUtils.setProperty (accepting a ValueExpression instead of a String). This methods are called in the setProperties() methods of the tags -- 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-1328) UISelectOne and UISelectMany fail with custom converter that returns java.lang.String from getAsObject() method.
[ http://issues.apache.org/jira/browse/MYFACES-1328?page=all ]
Grant Smith resolved MYFACES-1328.
--
Resolution: Fixed
It turns out my application was missing h:messages, so of course, no
validation message was reaching me. I'll close this, although I'm sure we're
going to have a lot of users that got spoiled by having the convenient
conversion. Still, we must follow the behaviour of the RI...
UISelectOne and UISelectMany fail with custom converter that returns
java.lang.String from getAsObject() method.
Key: MYFACES-1328
URL: http://issues.apache.org/jira/browse/MYFACES-1328
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.1.4-SNAPSHOT
Reporter: Alexey Maslov
Assigned To: Martin Marinschek
Fix For: 1.1.5-SNAPSHOT
Attachments: reproducer.zip
The problem seems to be in
javax.faces.component._SelectItemsUtil.matchValue(FacesContext context,
Object value, Iterator selectItemsIter, _ValueConverter converter) method.
Line 63-72:
Object itemValue = item.getValue();
if(converter != null itemValue instanceof String)
{
itemValue = converter.getConvertedValue(context,
(String)itemValue);
}
if (value==itemValue || value.equals(itemValue))
{
return true;
}
If item's value is java.lang.String then this code does duplicate conversion
making matchValue() return false and subsequently resulting in error in
calling method (validateValue() in javax.faces.component.UISelectOne and
javax.faces.component.UISelectMany).
--
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-1435) Change all the tag attributes to ValueExpression
Change all the tag attributes to ValueExpression Key: MYFACES-1435 URL: http://issues.apache.org/jira/browse/MYFACES-1435 Project: MyFaces Core Issue Type: Sub-task Components: JSR-252 Reporter: Bruno Aranda Assigned To: Bruno Aranda All the attributes are ValueExpression now -- 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-1436) Add element deferred-type for elements in the taglibs
Add element deferred-type for elements in the taglibs --- Key: MYFACES-1436 URL: http://issues.apache.org/jira/browse/MYFACES-1436 Project: MyFaces Core Issue Type: Sub-task Components: JSR-252 Reporter: Bruno Aranda -- 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: JSR-252
Hi, An active effort is being done to have a MyFaces 1.2 implementation, so we will have it eventually, sooner or later depending on the participation of the developers/community. It is hard to say when a release will be done, but all the tasks identified are tagged as JSR-252 in JIRA. Although the number of tasks can increase, we believe that almost everything is contained in those taks, so you can estimate how far are we from releasing MyFaces 1.2 Stay tuned, Bruno On 10/5/06, Tim McConnell [EMAIL PROTECTED] wrote: Hi, I see that there are a number of Jira's opened with JSR-252 as the component. Does that mean there is a definitive (or even tentative) plan to implement the new specification for JSF 1.2 ?? If so, I'm really just trying to ascertain when to anticipate a MyFaces release based on JSR-252. Thanks much for any information. Tim
JSR-252 TCK
Hi, As the implementation of JSR-252 is progressing, do we have any news of the TCK? Cheers, Bruno
Re: JSR-252
On 10/5/06, Tim McConnell [EMAIL PROTECTED] wrote: Hi, I see that there are a number of Jira's opened with JSR-252 as the component. Does that mean there is a definitive (or even tentative) plan to implement the new specification for JSF 1.2 ?? If so, I'm really just trying to ascertain when to anticipate a MyFaces release based on JSR-252. Thanks much for any information. We have a branch for the JSF 1.2 implementation, and activity seems to have picked up recently. You can check out the code from this svn externals definition: svn co http://svn.apache.org/repos/asf/myfaces/current12/ -- Wendy
[jira] Created: (MYFACES-1437) Implement UIComponentTagUtils to use ValueExpression and MethodExpression
Implement UIComponentTagUtils to use ValueExpression and MethodExpression - Key: MYFACES-1437 URL: http://issues.apache.org/jira/browse/MYFACES-1437 Project: MyFaces Core Issue Type: Sub-task Components: JSR-252 Reporter: Bruno Aranda Assigned To: Bruno Aranda Fix For: 1.2.0-SNAPSHOT -- 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-1437) Implement UIComponentTagUtils to use ValueExpression and MethodExpression
[ http://issues.apache.org/jira/browse/MYFACES-1437?page=all ] Bruno Aranda resolved MYFACES-1437. --- Resolution: Fixed Implemented (r453433) Implement UIComponentTagUtils to use ValueExpression and MethodExpression - Key: MYFACES-1437 URL: http://issues.apache.org/jira/browse/MYFACES-1437 Project: MyFaces Core Issue Type: Sub-task Components: JSR-252 Reporter: Bruno Aranda Assigned To: Bruno Aranda Fix For: 1.2.0-SNAPSHOT -- 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: JSR-252 TCK
Hi Ed, 1.2 implementation speed has been increasing recently - can you ask your TCK guys if there is any chance of getting a hold on the TCK 1.2 in a decent timeframe? We don't want to run into a situation again where we had a finished implementation for 2 years, just waiting for the TCK to arrive ;) regards, Martin -- Forwarded message -- From: Bruno Aranda [EMAIL PROTECTED] Date: Oct 6, 2006 12:49 AM Subject: JSR-252 TCK To: MyFaces Development dev@myfaces.apache.org Hi, As the implementation of JSR-252 is progressing, do we have any news of the TCK? Cheers, Bruno -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: JSR-252 TCK
I asked the JCP group twice, CCed the list. Never got word back. Dennis Byrne -Original Message- From: Bruno Aranda [mailto:[EMAIL PROTECTED] Sent: Thursday, October 5, 2006 06:49 PM To: 'MyFaces Development' Subject: JSR-252 TCK Hi, As the implementation of JSR-252 is progressing, do we have any news of the TCK? Cheers, Bruno
Fwd: JSR-252 TCK
Hi Geir, I know that there is not too much of your precious time we can ask for - but is there any chance you could work your magic just like you did for the TCK for JSF, version 1.1, to get us a TCK for JSF version 1.2? When we finally asked you, it went mch faster than before... regards, Martin -- Forwarded message -- From: Bruno Aranda [EMAIL PROTECTED] Date: Oct 6, 2006 12:49 AM Subject: JSR-252 TCK To: MyFaces Development dev@myfaces.apache.org Hi, As the implementation of JSR-252 is progressing, do we have any news of the TCK? Cheers, Bruno -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
