[jira] Created: (MYFACES-1003) t:dataTable support for ResultSetDataModel is completely broken
t:dataTable support for ResultSetDataModel is completely broken --- Key: MYFACES-1003 URL: http://issues.apache.org/jira/browse/MYFACES-1003 Project: MyFaces Type: Bug Components: Tomahawk Reporter: Simon Kitching ResultSets just don't work with t:dataModel due to the way that the looping in encodeInnerHtml currently *depends* on a correct dataModel.getRowCount(). Resultsets don't know their rowCount. The UIData component handles this correctly. http://mail-archives.apache.org/mod_mbox/myfaces-users/200601.mbox/browser -- 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: [maven] Latest maven changes
Here is a more detail description of my thoughts If myfaces is a project without separate release cycle, a possible svn structure: myfaces/trunk/api myfaces/trunk/impl myfaces/trunk/commons myfaces/trunk/tomahawk myfaces/trunk/sandbox myfaces/trunk/examples or the examples belongs to the subprojects myfaces/trunk/assembly or build-tool(s) with checkstyle configuration, assembly maven plugin... I like the parent refs in the pom.xml. I don't like the svn externals they are painful for branching and taging. If myfaces has separate release cycles, a possible structure would be: myfaces/core/trunk/api myfaces/core/trunk/impl myfaces/core/trunk/example myfaces/core/trunk/assembly myfaces/commons/trunk myfaces/tomahawk/trunk myfaces/tomahawk/trunk/example myfaces/tomahawk/trunk/assembly myfaces/sandbox/trunk myfaces/sandbox/trunk/example myfaces/sandbox/trunk/assembly maybe a myfaces/common-examples/trunk and myfaces/[build|build-tool(s)]/trunk for checkstyle pmd maven-plugins With the second option I expect faster release cycles. This would be nice for a faster tobago and adf integration. Which a snapshot repository or a mavenized released version on a maven repository, it should not be a problem to checkout tomahawk only and compile it (indepent of the first option or the second option). Best Regards Bernd Martin Marinschek schrieb: I'll put in my 2cents. Let's see if we can get the machine to work with those ;) currently, we treat myfaces as a project with an integrated release-cycle. We don't release things separately here so far. (except tobago). So I'd say we should go with this for now - I'd say that the Maven-POMs are easily enough changed. I really like how they decreased the ant-clutter. regards, Martin
Re: Maven Build (Ongoing Work Thread)
See http://maven.apache.org/plugins/maven-eclipse-plugin/ mvn eclipse:eclipse he he, yes I saw. I was meaning something like multi-module project ;)
[jira] Commented: (MYFACES-874) popup not rendering over h:inputText text. / popup in IE fubar.
[
http://issues.apache.org/jira/browse/MYFACES-874?page=comments#action_12361822
]
jeff porter commented on MYFACES-874:
-
I still see this behaviour in IE with nightly build myfaces-20051230.zip
See image...
http://www.porter.eu.com/jeff/IEmyfaces-20051230.jpg
popup not rendering over h:inputText text. / popup in IE fubar.
Key: MYFACES-874
URL: http://issues.apache.org/jira/browse/MYFACES-874
Project: MyFaces
Type: Bug
Versions: 1.1.1
Environment: MyFaces 1.11
jdk1.5.0_04
Firefox 1.07
IE 6.0.2900.2180 xpsp_sp2_gdr.050301-1519
Windows XP - SP2
Reporter: jeff porter
Fix For: Nightly
Attachments: theTest4.jsp
3 Parts to this possible bug.
1: The examples in myfaces-1.1.1-src shows the user of x:popup, but the web
site say uses t:popup /
In this case I've followed examples, not the website. Which is correct?
2: Firefox: Popups do not render of text created with the h:textInput / tag.
See image ...
http://www.porter.eu.com/jeff/example.JPG
3: IE: Popups do not render correctly, a large textarea box is shown.
See image...
http://www.porter.eu.com/jeff/example2.JPG
Code used
%@ taglib uri=http://myfaces.apache.org/extensions; prefix=x%
x:popup id=x
styleClass=popup
closePopupOnExitingElement=true
closePopupOnExitingPopup=true
displayAtDistanceX=-500
displayAtDistanceY=10
f:verbatimimg src=images/help.jpg/f:verbatim
f:facet name=popup
h:panelGroup
h:panelGrid columns=1
h:outputText value=This is the document./
/h:panelGrid
/h:panelGroup
/f:facet
/x:popup
Style.css
.popup {
background-color:#6699FF;
color: #00;
border: 1px solid #CC;
font-size:smaller;
padding: 5px;
}
--
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: Maven Build (Ongoing Work Thread)
Could the ProjectSet-plugin be what you are looking for? http://www.ejbprovider.de/homepage/index.html hth Alexander -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Thursday, January 05, 2006 9:58 AM To: MyFaces Development Subject: Re: Maven Build (Ongoing Work Thread) See http://maven.apache.org/plugins/maven-eclipse-plugin/ mvn eclipse:eclipse he he, yes I saw. I was meaning something like multi-module project ;)
Re: [maven] Latest maven changes
Hi, Sooner or later, the MyFaces core will stabilise while tomahawk charges ahead. So at *some* time the release cycles will have to separate. I think it's beneficial to split them sooner rather than later, so I'd like to see a structure set up now that makes that easier. Sooner or later, real bugfix releases should also be supported; MyFaces has just ignored that issue so far. Again, this is much easier to do when the libraries have separate release cycles; I'd hate to see a new myfaces-impl.jar release just because a nasty bug was found in t:dataTable... On the subject of externals, I dislike them a lot. Sometimes they are necessary, but I'd prefer to see them kept to a minimum. Note that it's perfectly possible in SVN to copy several dirs into a tags dir, eg svn cp myfaces/trunk/commons tags/spec/x.y.z/commons svn cp myfaces/trunk/api tags/spec/x.y.z/api to make a tag dir containing the two parts of MyFaces required to implement the specification (commons and core). In other words, how the subprojects are grouped for releases doesn't have to mirror their repository layout. It makes creating a tag fractionally more complicated (it *is* nicer just to be able to copy some common root dir) but I would still prefer this over externals. Regards, Simon On Thu, 2006-01-05 at 09:53 +0100, Bernd Bohmann wrote: Here is a more detail description of my thoughts If myfaces is a project without separate release cycle, a possible svn structure: [snip] With the second option I expect faster release cycles. This would be nice for a faster tobago and adf integration. Which a snapshot repository or a mavenized released version on a maven repository, it should not be a problem to checkout tomahawk only and compile it (indepent of the first option or the second option). [snip] Best Regards Bernd Martin Marinschek schrieb: I'll put in my 2cents. Let's see if we can get the machine to work with those ;) currently, we treat myfaces as a project with an integrated release-cycle. We don't release things separately here so far. (except tobago). So I'd say we should go with this for now - I'd say that the Maven-POMs are easily enough changed. I really like how they decreased the ant-clutter. regards, Martin
[jira] Commented: (MYFACES-985) UIData with multihierarchical children inside produces NPE
[ http://issues.apache.org/jira/browse/MYFACES-985?page=comments#action_12361830 ] Mathias Broekelmann commented on MYFACES-985: - what version of myfaces do you use? UIData with multihierarchical children inside produces NPE -- Key: MYFACES-985 URL: http://issues.apache.org/jira/browse/MYFACES-985 Project: MyFaces Type: Bug Components: Implementation Environment: Tomcat 5.0 JDK 1.4 Reporter: Andrew Kharchenko Attachments: UIData NPE Sample.rar I've found incorrect UIData behaviour under MyFaces which produces NullPointerException on runtime and which works fine under Sun implementation. Here it is: I have a custom component which is extentor from UIInput. This component has UIPanel extentor component as child which is added to children list of UIInput component on rendering. For one's turn, UIPanel extentor has one more UIInput extentor component as child which is added to children list of UIPanel component on rendering. This component works fine standalone, but when it is added to UIData, I have NPE on runtime. Here is the part of listing: java.lang.NullPointerException at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:223) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.setRowIndex(UIData.java:178) I will also attach sample component's classes, definitions and test page if it will be granted after issue creation. -- 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-1005) Calender is shown outside window area
Calender is shown outside window area - Key: MYFACES-1005 URL: http://issues.apache.org/jira/browse/MYFACES-1005 Project: MyFaces Type: Improvement Components: Tomahawk Versions: 1.1.1 Environment: Windows XP SP2, IE 6.0, FF 1.5, Opera 8.5.1, JBoss 4.0.2, MYFaces 1.1.1 Reporter: Lars Kruse Pedersen Priority: Minor When clicking on the calendar icon close a the window edge, the calendar pops up with contents showing outside the window. The calendar should be moved so it is shown inside the window area. -- 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-985) UIData with multihierarchical children inside produces NPE
[ http://issues.apache.org/jira/browse/MYFACES-985?page=comments#action_12361832 ] Mathias Broekelmann commented on MYFACES-985: - You are modifying the component tree by removing a component while rendering the children, which is the problem. Why do you need to remove a component child in the renderer? UIData with multihierarchical children inside produces NPE -- Key: MYFACES-985 URL: http://issues.apache.org/jira/browse/MYFACES-985 Project: MyFaces Type: Bug Components: Implementation Environment: Tomcat 5.0 JDK 1.4 Reporter: Andrew Kharchenko Attachments: UIData NPE Sample.rar I've found incorrect UIData behaviour under MyFaces which produces NullPointerException on runtime and which works fine under Sun implementation. Here it is: I have a custom component which is extentor from UIInput. This component has UIPanel extentor component as child which is added to children list of UIInput component on rendering. For one's turn, UIPanel extentor has one more UIInput extentor component as child which is added to children list of UIPanel component on rendering. This component works fine standalone, but when it is added to UIData, I have NPE on runtime. Here is the part of listing: java.lang.NullPointerException at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:223) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.setRowIndex(UIData.java:178) I will also attach sample component's classes, definitions and test page if it will be granted after issue creation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-1005) Calender is shown outside window area
[ http://issues.apache.org/jira/browse/MYFACES-1005?page=all ] Lars Kruse Pedersen updated MYFACES-1005: - Attachment: calendar-improvement.js Attached a file containing the nessary modifications to the existing popcalendar.js to make the calendar show within the window if possible. It contains 2 new functions and modifications to the existing jscalendarPopUpCalendar_Show() function. The solution works in IE 6.0, FF 1.5 and Opera 8.51 :-) Calender is shown outside window area - Key: MYFACES-1005 URL: http://issues.apache.org/jira/browse/MYFACES-1005 Project: MyFaces Type: Improvement Components: Tomahawk Versions: 1.1.1 Environment: Windows XP SP2, IE 6.0, FF 1.5, Opera 8.5.1, JBoss 4.0.2, MYFaces 1.1.1 Reporter: Lars Kruse Pedersen Priority: Minor Attachments: calendar-improvement.js When clicking on the calendar icon close a the window edge, the calendar pops up with contents showing outside the window. The calendar should be moved so it is shown inside the window area. -- 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-985) UIData with multihierarchical children inside produces NPE
[ http://issues.apache.org/jira/browse/MYFACES-985?page=comments#action_12361836 ] Andrew Kharchenko commented on MYFACES-985: I'm just trying to avoid multiple adding of the same children. OK, this is the way to check children presence in component tree and do not add it again. I'll try to implement my component in such way but still I'm not sure it will help. UIData with multihierarchical children inside produces NPE -- Key: MYFACES-985 URL: http://issues.apache.org/jira/browse/MYFACES-985 Project: MyFaces Type: Bug Components: Implementation Environment: Tomcat 5.0 JDK 1.4 Reporter: Andrew Kharchenko Assignee: Mathias Broekelmann Attachments: UIData NPE Sample.rar I've found incorrect UIData behaviour under MyFaces which produces NullPointerException on runtime and which works fine under Sun implementation. Here it is: I have a custom component which is extentor from UIInput. This component has UIPanel extentor component as child which is added to children list of UIInput component on rendering. For one's turn, UIPanel extentor has one more UIInput extentor component as child which is added to children list of UIPanel component on rendering. This component works fine standalone, but when it is added to UIData, I have NPE on runtime. Here is the part of listing: java.lang.NullPointerException at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:223) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.setRowIndex(UIData.java:178) I will also attach sample component's classes, definitions and test page if it will be granted after issue creation. -- 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-1005) Calender is shown outside window area
[ http://issues.apache.org/jira/browse/MYFACES-1005?page=comments#action_12361837 ] Lars Kruse Pedersen commented on MYFACES-1005: -- Please ignore/remove that last statement in the attached file enableEventHandlers(); it is my own modification that has nothing to do with the showing outside window issue ;-) Calender is shown outside window area - Key: MYFACES-1005 URL: http://issues.apache.org/jira/browse/MYFACES-1005 Project: MyFaces Type: Improvement Components: Tomahawk Versions: 1.1.1 Environment: Windows XP SP2, IE 6.0, FF 1.5, Opera 8.5.1, JBoss 4.0.2, MYFaces 1.1.1 Reporter: Lars Kruse Pedersen Priority: Minor Attachments: calendar-improvement.js When clicking on the calendar icon close a the window edge, the calendar pops up with contents showing outside the window. The calendar should be moved so it is shown inside the window area. -- 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: Prototype library and portlets
There is also a Shale proposal{1] related to some of this.
Sean
[1] http://www.mail-archive.com/dev@struts.apache.org/msg16683.html
On 1/5/06, Martin Cooper [EMAIL PROTECTED] wrote:
Sorry for the delay. See below...
On 1/3/06, Werner Punz [EMAIL PROTECTED] wrote:
Actually this all or nothing or common ground approach is not what I had
in mind.
What I am thinking of is something along these lines.
You already have some kind of dynamic loading infrastructure in there
with
dojo.require(dojo.a);
dojo.require(dojo.b);
now the problem as discussed is that this triggers
xmlhttp requests and is slow
the alternate solution to this dynamic linking is a static linking via
an ant build to drop everything into a single file.
Also bad, because one time you download a single huge file (well
compresset but still)
This isn't as bad as you think. You do get one large-ish (not huge ;)
download, but you save because of only one request to get it, and the
browser will cache it, so it really is only one download.
Admittedly, there is a little more pain when using this with JSF because
the JavaScript will be evaluated on each page load, and JSF is still
fundamentally page-oriented. There's not much I can do about that. ;-)
This is a viable approach for a webapp but not for a component library
where one component needs part a of dojo and part b and another one
needs part a and c.
The infrastructure is there to make dynamic includes upon the given
needs of the components currently used.
So theoretically if only one component is loaded than an include of part
a and b is done.
If the second one is added an additional one for part c also is done.
It is sort of a semi dynamic linking where myfaces adds the needed
includes and neither the build system nor the javascript runtime.
When you refer to needed includes here, what do you mean? Are you talking
about dynamically adding script src=... elements to the page, so that
the browser then fetches them? If so, then I would be _extremely_ surprised
if there's any noticeable performance difference between that and what Dojo
is doing for you, since it ultimately boils down to the same thing.
If that's not what you mean, then I'm afraid I still don't get it. ;-(
However, from what Adam said, it sounds like ADF Faces will provide it if
Dojo doesn't, so you should be all set.
--
Martin Cooper
You get the benefits of both approaches that way, less code download
because only the parts needed are loaded and still excellent browser
caching, due to standard javascript includes.
So my question, does dojo already support such an approach?
Werner
Martin Cooper wrote:
I'm not 100% sure I understand what you're looking for, since I'm not
completely familiar with the way MyFaces components do things today. But
here are a few thoughts:
1) If you're going to use Dojo, I would suggest that you either use the
kitchen sink profile (that includes everything) or one that includes
what all of the widgets in your library need, rather than trying to load
only what each widget needs. While that would result in a larger dojo.js
file than each widget might need by itself, it means that you get a
one-time download to the browser that is then cached, ultimately leading
to better performance for the page as a whole.
2) If you render code on the fly that has something like
'dojo.require (foo)', then Dojo will request foo and any
dependencies
of foo, as it would in development mode, but only if they're not
already loaded into the browser (e.g. through the profile build). While
this isn't what you want as a general solution, it does ensure that your
code doesn't break if something got left out of the profile build. Also
note that foo need not be part of Dojo itself, so you can use Dojo to
load your own code too.
3) In theory (meaning, I don't know if anyone has tried it ;), you could
generate profile builds on the fly that include only the pieces you
need. This sounds cool, but it's not really practical in the long
run.The problem is that each custom on-the-fly would be a separate
entity as far as the browser is concerned, so you'd be downloading it
every time and it wouldn't be cached. Using the approach in #1 is a
better way of handling this.
Did I answer your question? I'm not sure. If not, let me know what I'm
missing, and I'll try again. ;-)
--
Martin Cooper
On 1/3/06, *Werner Punz* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
wrote:
Hi Martin, thanks for the clarification,
but one question, given that myfaces has its own
loading mechanism which renders the includes dynamically.
Does dojo have something which could support this.
The reason why I am asking is, that
usually the components basically determine themselves
(with
[jira] Commented: (MYFACES-985) UIData with multihierarchical children inside produces NPE
[
http://issues.apache.org/jira/browse/MYFACES-985?page=comments#action_12361838
]
Andrew Kharchenko commented on MYFACES-985:
As I said, I've replaced this part of code in renderer:
for (Iterator iterator = children.iterator(); iterator.hasNext();) {
UIComponent child = (UIComponent) iterator.next();
if (child instanceof UIInputTestComponent) {
children.remove(child);
break;
}
}
UIInputTestComponent itc = (UIInputTestComponent)
context.getApplication().createComponent(UIInputTestComponent.COMPONENT_TYPE);
itc.setId(component.getId() + _id);
itc.setNeedChildren(false);
children.add(itc);
with this one:
boolean isPresent = false;
for (Iterator iterator = children.iterator(); iterator.hasNext();) {
UIComponent child = (UIComponent) iterator.next();
if (child instanceof UIInputTestComponent) {
isPresent = true;
break;
}
}
if (!isPresent) {
UIInputTestComponent itc = (UIInputTestComponent)
context.getApplication().createComponent(UIInputTestComponent.COMPONENT_TYPE);
itc.setId(component.getId() + _id);
itc.setNeedChildren(false);
children.add(itc);
}
but it still has the same effect :(
UIData with multihierarchical children inside produces NPE
--
Key: MYFACES-985
URL: http://issues.apache.org/jira/browse/MYFACES-985
Project: MyFaces
Type: Bug
Components: Implementation
Environment: Tomcat 5.0
JDK 1.4
Reporter: Andrew Kharchenko
Assignee: Mathias Broekelmann
Attachments: UIData NPE Sample.rar
I've found incorrect UIData behaviour under MyFaces which produces
NullPointerException on runtime and which works fine under Sun implementation.
Here it is:
I have a custom component which is extentor from UIInput. This component has
UIPanel extentor component as child which is added to children list of
UIInput component on rendering.
For one's turn, UIPanel extentor has one more UIInput extentor component as
child which is added to children list of UIPanel component on rendering.
This component works fine standalone, but when it is added to UIData, I have
NPE on runtime. Here is the part of listing:
java.lang.NullPointerException
at
javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:223)
at
javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235)
at
javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235)
at
javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235)
at javax.faces.component.UIData.setRowIndex(UIData.java:178)
I will also attach sample component's classes, definitions and test page if
it will be granted after issue creation.
--
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: svn commit: r365935 - /incubator/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/script/dateConverter.js
Hello Volker,
the log function was used in the unit test to track down my localization
problems -- i.e. invoking JavaScript per Rhino. I doubt that currently
the LOG from Tobago will work inside this limited environment. Perhaps
something like HttpUnit will provide enough DOM Level 0 and higher
support to make this work. I will check this...
Regards,
Arvid
Volker Weber wrote:
Arvid,
if you removed this because log() is undefined:
In tobago javascript you can use LOG.debug(), LOG.info(), LOG.warn(),
and LOG.error() for logging on client side.
Currently the error level mades no difference, but this is a todo.
If the client is in debug mode (to force this add a accepted language of
'to_ba_go' in your browser config) a normaly hidden logging panel is
rendered which can be opened by LOG.show() eg. type
javascript:LOG.show() in the address bar.
@Udo: This is the place where the debug output goes which i removed last
week from the created html source.
Regards,
Volker
[EMAIL PROTECTED] wrote:
Author: idus
Date: Wed Jan 4 08:33:08 2006
New Revision: 365935
URL: http://svn.apache.org/viewcvs?rev=365935view=rev
Log:
removed debug stuff
Modified:
incubator/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/script/dateConverter.js
Modified:
incubator/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/script/dateConverter.js
URL:
http://svn.apache.org/viewcvs/incubator/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/script/dateConverter.js?rev=365935r1=365934r2=365935view=diff
==
---
incubator/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/script/dateConverter.js
(original)
+++
incubator/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/script/dateConverter.js
Wed Jan 4 08:33:08 2006
@@ -241,9 +241,6 @@
if (patternSub.length == 3) {
var fragment = dateStr.substr(dateIndex, 3);
var index = this._indexOf(this.dateFormatSymbols.shortMonths, fragment);
-log(shortMonths: + this.dateFormatSymbols.shortMonths);
-log(fragment: + fragment);
-log(index: + index);
if (index != -1) {
context.month = index;
context.newIndex = dateIndex + 3;
@@ -260,7 +257,6 @@
this._parseNum(context, dateStr, 2, dateIndex);
context.month = context.retValue - 1;
}
- log(month: + context.month);
} else {
if (patternSub.length == 3) {
context.dateStr += this.dateFormatSymbols.shortMonths[context.month];
Re: Maven Build (Ongoing Work Thread)
Sorry, I think the eclipse plugin is reactor aware. But I don't know how it is activated. Maybe this helps: http://maven.apache.org/guides/mini/guide-ide-eclipse.html Bernd Matthias Wessendorf schrieb: See http://maven.apache.org/plugins/maven-eclipse-plugin/ mvn eclipse:eclipse he he, yes I saw. I was meaning something like multi-module project ;) -- Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333
Re: Maven Build (Ongoing Work Thread)
Hi Matthias, AFAIK there is no way to make a multi-module maven project into a single Eclipse project. I find though once I got over the initial irritation at the multi- project approach I did not mind so much. Make sure to use a working set so that you don't always have to look at the list of jar files. Another thing to take a look at is the Maven2 plugin for Eclipse. I've been using it for a couple of days and so far so good. TTFN, -bd- On Jan 4, 2006, at 1:05 PM, Matthias Wessendorf wrote: Hi, I just made a 'mvn idea:idea' in common, api, impl, tomahawk, sandbox, and examples/sandbox dirs. After creating a new 'multi module' idea project and adding the created *.iml, i just neet to setup the dependencies. there is no such thing for eclipse w/ maven2 ? Do I have to *remain* with serveral eclipse projects for MyFaces? -Matthias I haven't realy worked with this setup, but it seems to be ok. changing of a class in tomahawk is directly available in sandbox example code. no need to run maven beetwen. Martin Marinschek wrote: Well, I know next to nothing about Maven, but had to get the examples working. What do you mean by your first proposal? I don't want to end up with a solution where I do a change in the MyFaces code and then have to run maven before I can start the examples-app. What did you mean with 'before I can start the examples-app'? You don't want to have the changes running in tomcat without rebuild and deploy the jar/war ? Regards Volker -- Don't answer to From: address! Mail to this account are droped if not recieved via mailinglist. To contact me direct create the mail address by concatenating my forename to my senders domain. -- Matthias Wessendorf Zülpicher Wall 12, 239 50674 Köln http://www.wessendorf.net mwessendorf-at-gmail-dot-com
[jira] Commented: (MYFACES-985) UIData with multihierarchical children inside produces NPE
[ http://issues.apache.org/jira/browse/MYFACES-985?page=comments#action_12361840 ] Mathias Broekelmann commented on MYFACES-985: - You are still modifing the component tree while rendering. Why don´t you add your component in the the base component when it is created? UIData with multihierarchical children inside produces NPE -- Key: MYFACES-985 URL: http://issues.apache.org/jira/browse/MYFACES-985 Project: MyFaces Type: Bug Components: Implementation Environment: Tomcat 5.0 JDK 1.4 Reporter: Andrew Kharchenko Assignee: Mathias Broekelmann Attachments: UIData NPE Sample.rar I've found incorrect UIData behaviour under MyFaces which produces NullPointerException on runtime and which works fine under Sun implementation. Here it is: I have a custom component which is extentor from UIInput. This component has UIPanel extentor component as child which is added to children list of UIInput component on rendering. For one's turn, UIPanel extentor has one more UIInput extentor component as child which is added to children list of UIPanel component on rendering. This component works fine standalone, but when it is added to UIData, I have NPE on runtime. Here is the part of listing: java.lang.NullPointerException at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:223) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.setRowIndex(UIData.java:178) I will also attach sample component's classes, definitions and test page if it will be granted after issue creation. -- 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: [maven] Latest maven changes
Simon Kitching schrieb: Hi, Sooner or later, the MyFaces core will stabilise while tomahawk charges ahead. So at *some* time the release cycles will have to separate. I think it's beneficial to split them sooner rather than later, so I'd like to see a structure set up now that makes that easier. Yes Sooner or later, real bugfix releases should also be supported; MyFaces has just ignored that issue so far. Again, this is much easier to do when the libraries have separate release cycles; I'd hate to see a new myfaces-impl.jar release just because a nasty bug was found in t:dataTable... Yes :-) On the subject of externals, I dislike them a lot. Sometimes they are necessary, but I'd prefer to see them kept to a minimum. Yes Note that it's perfectly possible in SVN to copy several dirs into a tags dir, eg svn cp myfaces/trunk/commons tags/spec/x.y.z/commons svn cp myfaces/trunk/api tags/spec/x.y.z/api to make a tag dir containing the two parts of MyFaces required to implement the specification (commons and core). In other words, how the subprojects are grouped for releases doesn't have to mirror their repository layout. Yes, this is possible. But the current stucture is: myfaces/commons/trunk myfaces/api/trunk Do you mean: svn cp myfaces/commons/trunk tags/spec/x.y.z/commons svn cp myfaces/api/trunk tags/spec/x.y.z/api Why do you want to change the layout in a branch or tag only? You only need some svn moves and some changes in the poms. Every user can see the current state of the structure and what he can expect in the next release cycle. And I don't think this works with the release-plugin from maven. Maven provides some little help for performing a release. If we decide to use maven we should go the maven way. See: http://maven.apache.org/guides/mini/guide-releasing.html But I never try it. It makes creating a tag fractionally more complicated (it *is* nicer just to be able to copy some common root dir) but I would still prefer this over externals. This would be correct. if svn doesn't support move. And if externals are a common use case, why I never see it? Regards, Simon Regards Bernd
[jira] Commented: (MYFACES-985) UIData with multihierarchical children inside produces NPE
[ http://issues.apache.org/jira/browse/MYFACES-985?page=comments#action_12361845 ] Andrew Kharchenko commented on MYFACES-985: Do you mean in the component's constructor? Is it good style? UIData with multihierarchical children inside produces NPE -- Key: MYFACES-985 URL: http://issues.apache.org/jira/browse/MYFACES-985 Project: MyFaces Type: Bug Components: Implementation Environment: Tomcat 5.0 JDK 1.4 Reporter: Andrew Kharchenko Assignee: Mathias Broekelmann Attachments: UIData NPE Sample.rar I've found incorrect UIData behaviour under MyFaces which produces NullPointerException on runtime and which works fine under Sun implementation. Here it is: I have a custom component which is extentor from UIInput. This component has UIPanel extentor component as child which is added to children list of UIInput component on rendering. For one's turn, UIPanel extentor has one more UIInput extentor component as child which is added to children list of UIPanel component on rendering. This component works fine standalone, but when it is added to UIData, I have NPE on runtime. Here is the part of listing: java.lang.NullPointerException at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:223) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.setRowIndex(UIData.java:178) I will also attach sample component's classes, definitions and test page if it will be granted after issue creation. -- 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
[maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes
On 1/5/06, Bernd Bohmann [EMAIL PROTECTED] wrote: Here is a more detail description of my thoughts If myfaces is a project without separate release cycle, a possible svn structure: myfaces/trunk/api myfaces/trunk/impl myfaces/trunk/commons myfaces/trunk/tomahawk myfaces/trunk/sandbox myfaces/trunk/examples or the examples belongs to the subprojects myfaces/trunk/assembly or build-tool(s) with checkstyle configuration, assembly maven plugin... I like the parent refs in the pom.xml. I don't like the svn externals they are painful for branching and taging. Can you give me the arguments for parent refs? I still haven't heard a good reason. I'm not against the idea, I just don't know what they give you (other then a common version.) I think we can all agree that the externals are suboptimal. The question is what to do about it. If myfaces has separate release cycles, a possible structure would be: myfaces/core/trunk/api myfaces/core/trunk/impl myfaces/core/trunk/example myfaces/core/trunk/assembly myfaces/commons/trunk myfaces/tomahawk/trunk myfaces/tomahawk/trunk/example myfaces/tomahawk/trunk/assembly myfaces/sandbox/trunk myfaces/sandbox/trunk/example myfaces/sandbox/trunk/assembly maybe a myfaces/common-examples/trunk and myfaces/[build|build-tool(s)]/trunk for checkstyle pmd maven-plugins A good start. Here is a revised proposal based on Bernd's original one core myfaces/core/trunk/api myfaces/core/trunk/impl myfaces/core/trunk/assembly commons === myfaces/commons/trunk tomahawk === myfaces/tomahawk/trunk myfaces/tomahawk/trunk/example myfaces/tomahawk/trunk/assembly myfaces/sandbox/trunk myfaces/sandbox/trunk/example myfaces/sandbox/trunk/assembly maven-tools = custom maven plugins, etc. NOTES: I took out the examples from core. The examples are 99% tomahawk related (other then the blank example which shows basic setup.) I think its easier to just leave examples out of core instead of having two copies, separate examples or svn externals. I merged sandbox and tomahawk together. A while back we decided to put the sandbox stuff in the tomahawk.jar. Since the sandbox is experimental it doesn't need its own release cycle. Also, stuff moves from sandbox to tomahawk so you will often update both anyways. The examples for tomahawk would be the current examples (minus sandbox). The sandbox examples would go under sandbox. With the second option I expect faster release cycles. This would be nice for a faster tobago and adf integration. Yes faster release cycles would be good. I suppose MyFaces commons will be released everytime *either* the core or tomahawk stuff is released. There are bound to be minor changes either time. That still saves us the trouble of branching, testing and merging the core stuff. We had talked about a core project a while ago - but as an svn:external. I like this better. You are correct that branching and tagging will be much easier. Which a snapshot repository or a mavenized released version on a maven repository, it should not be a problem to checkout tomahawk only and compile it (indepent of the first option or the second option). I had thought about this. Is there a way to tell Maven Use my local repository if it is newer then the maven repository? Things could get kind of confusing if you are using your latest commons code in the IDE but Maven is using the last official release ... Best Regards Bernd Sean
Re: [maven] Latest maven changes
Hi, Sooner or later, the MyFaces core will stabilise while tomahawk charges ahead. So at *some* time the release cycles will have to separate. I think it's beneficial to split them sooner rather than later, so I'd like to see a structure set up now that makes that easier. I think you are correct on this Simon. While we have everyone focused on Maven we might figure out a solution to this. Sooner or later, real bugfix releases should also be supported; MyFaces has just ignored that issue so far. Again, this is much easier to do when the libraries have separate release cycles; I'd hate to see a new myfaces-impl.jar release just because a nasty bug was found in t:dataTable... True. The one issue to be aware of is when commons changes. If containers ship with an older version of MyFaces (including the commons jar) there could be conflicts. No big deal though. We just make sure to remind people to upgrade commons if they are downloading the tomahawk only release. (We should probably include the commons.jar in the tomahawk release as well.) On the subject of externals, I dislike them a lot. Sometimes they are necessary, but I'd prefer to see them kept to a minimum. +1 for minimizing externals. As we see from the poor user trying to access 1.1.1 source code, the externals can really make a mess of things. There are 2 easy steps we can take to reduce usage of externals. 1.) Get rid of the shared build directory. (Already done - maven makes it easier to do recursive builds so we don't need the one file to build them all ant script.) 2.) Use svn copy for the release directory (instead of using externals.) Note that it's perfectly possible in SVN to copy several dirs into a tags dir, eg svn cp myfaces/trunk/commons tags/spec/x.y.z/commons svn cp myfaces/trunk/api tags/spec/x.y.z/api to make a tag dir containing the two parts of MyFaces required to implement the specification (commons and core). In other words, how the subprojects are grouped for releases doesn't have to mirror their repository layout. It makes creating a tag fractionally more complicated (it *is* nicer just to be able to copy some common root dir) but I would still prefer this over externals. The tags are the only place where I believe externals make sense at all (and that's all we would use them for now that we have maven.) I guess you are suggesting we make a tags module and use the assembly step to pull things together? That might work. I'm not sure how the XSLT step would go though ... Regards, Simon Sean
Re: [jira] Created: (MYFACES-1003) t:dataTable support for ResultSetDataModel is completely broken
Mathias, You are the table expert. Any ideas? Also, where have you been lately? We haven't seen you on the list in a while ... Sean On 1/5/06, Simon Kitching (JIRA) dev@myfaces.apache.org wrote: t:dataTable support for ResultSetDataModel is completely broken --- Key: MYFACES-1003 URL: http://issues.apache.org/jira/browse/MYFACES-1003 Project: MyFaces Type: Bug Components: Tomahawk Reporter: Simon Kitching ResultSets just don't work with t:dataModel due to the way that the looping in encodeInnerHtml currently *depends* on a correct dataModel.getRowCount(). Resultsets don't know their rowCount. The UIData component handles this correctly. http://mail-archives.apache.org/mod_mbox/myfaces-users/200601.mbox/browser -- 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
TreeNode problem
I am having some problems with tree node, using MyFaces 1.1.1. I am constructing a tree node with the following statement but isLeaf returns true. treeNode= new TreeNodeBase(nodeType.toString(), node, false); This is still the case even if I explicitly call setLeaf(false); after creating the TreeNode. The following debug places stright after creating the treenode statements output the messages detailed below: DEBUG STATEMENTS logger.debug(new treeNode.description: + treeNode.getDescription()); logger.debug(new treeNode.type: + treeNode.getType()); logger.debug(new treeNode.isLeaf: + treeNode.isLeaf()); MESSAGES 2006-01-05 15:16:33,669 DEBUG [uk.co.ifdsgroup.security.form.SecurityHierarchyForm] new treeNode.description: eSecurity 2006-01-05 15:16:33,669 DEBUG [uk.co.ifdsgroup.security.form.SecurityHierarchyForm] new treeNode.type: root 2006-01-05 15:16:33,669 DEBUG [uk.co.ifdsgroup.security.form.SecurityHierarchyForm] new treeNode.isLeaf: true Has anyone else experienced this, or am I doing something strange! Regards Jamie INTERNATIONAL FINANCIAL DATA SERVICES (UK) LTD Tel: +44 1268 44 3000 ** N O T I C E * This message and any attachments is intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential or prohibited from disclosure or unauthorised use. If the recipient of this transmission is not the intended recipient, or the employee or agent responsible for delivering such materials to the intended recipient, you are hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message or its attachments other than by it's intended recipient is strictly prohibited by the sender. If you have received it in error, please notify us immediately by telephone on the number above and destroy the message and all copies in your possession. International Financial Data Services (UK) Ltd is authorised and regulated by the Financial Services Authority. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. **
Re: TreeNode problem
Please post these types of questions to the user list. Your fellow users will likely be able to help you there. Regards, Sean On 1/5/06, Cash, Jamie [EMAIL PROTECTED] wrote: I am having some problems with tree node, using MyFaces 1.1.1. I am constructing a tree node with the following statement but isLeaf returns true. treeNode= new TreeNodeBase(nodeType.toString(), node, false); This is still the case even if I explicitly call setLeaf(false); after creating the TreeNode. The following debug places stright after creating the treenode statements output the messages detailed below: DEBUG STATEMENTS logger.debug(new treeNode.description: + treeNode.getDescription()); logger.debug(new treeNode.type: + treeNode.getType()); logger.debug(new treeNode.isLeaf: + treeNode.isLeaf()); MESSAGES 2006-01-05 15:16:33,669 DEBUG [uk.co.ifdsgroup.security.form.SecurityHierarchyForm] new treeNode.description: eSecurity 2006-01-05 15:16:33,669 DEBUG [uk.co.ifdsgroup.security.form.SecurityHierarchyForm] new treeNode.type: root 2006-01-05 15:16:33,669 DEBUG [uk.co.ifdsgroup.security.form.SecurityHierarchyForm] new treeNode.isLeaf: true Has anyone else experienced this, or am I doing something strange! Regards Jamie INTERNATIONAL FINANCIAL DATA SERVICES (UK) LTD Tel: +44 1268 44 3000 ** N O T I C E * This message and any attachments is intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential or prohibited from disclosure or unauthorised use. If the recipient of this transmission is not the intended recipient, or the employee or agent responsible for delivering such materials to the intended recipient, you are hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message or its attachments other than by it's intended recipient is strictly prohibited by the sender. If you have received it in error, please notify us immediately by telephone on the number above and destroy the message and all copies in your possession. International Financial Data Services (UK) Ltd is authorised and regulated by the Financial Services Authority. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. **
[jira] Commented: (MYFACES-985) UIData with multihierarchical children inside produces NPE
[ http://issues.apache.org/jira/browse/MYFACES-985?page=comments#action_12361866 ] Mathias Broekelmann commented on MYFACES-985: - Can you explain what you want to achieve with your component? UIData with multihierarchical children inside produces NPE -- Key: MYFACES-985 URL: http://issues.apache.org/jira/browse/MYFACES-985 Project: MyFaces Type: Bug Components: Implementation Environment: Tomcat 5.0 JDK 1.4 Reporter: Andrew Kharchenko Assignee: Mathias Broekelmann Attachments: UIData NPE Sample.rar I've found incorrect UIData behaviour under MyFaces which produces NullPointerException on runtime and which works fine under Sun implementation. Here it is: I have a custom component which is extentor from UIInput. This component has UIPanel extentor component as child which is added to children list of UIInput component on rendering. For one's turn, UIPanel extentor has one more UIInput extentor component as child which is added to children list of UIPanel component on rendering. This component works fine standalone, but when it is added to UIData, I have NPE on runtime. Here is the part of listing: java.lang.NullPointerException at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:223) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.setRowIndex(UIData.java:178) I will also attach sample component's classes, definitions and test page if it will be granted after issue creation. -- 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] Created: (MYFACES-1003) t:dataTable support for ResultSetDataModel is completely broken
I changed my job and I currently have to learn a lot about steel manufacturing which isn´t quite related to jsf or myfaces yet :( But I´m still reading the mails whenever it is possible. I will try to keep up the response for UIData issues as far as I can. I think it should be no problem to support ResultSetDataModel for t:dataTable. I will have a look into it through the next days. 2006/1/5, Sean Schofield [EMAIL PROTECTED]: Mathias, You are the table expert. Any ideas? Also, where have you been lately? We haven't seen you on the list in a while ... Sean On 1/5/06, Simon Kitching (JIRA) dev@myfaces.apache.org wrote: t:dataTable support for ResultSetDataModel is completely broken --- Key: MYFACES-1003 URL: http://issues.apache.org/jira/browse/MYFACES-1003 Project: MyFaces Type: Bug Components: Tomahawk Reporter: Simon Kitching ResultSets just don't work with t:dataModel due to the way that the looping in encodeInnerHtml currently *depends* on a correct dataModel.getRowCount(). Resultsets don't know their rowCount. The UIData component handles this correctly. http://mail-archives.apache.org/mod_mbox/myfaces-users/200601.mbox/browser -- 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 -- Mathias
[jira] Created: (MYFACES-1006) Datatable do not support multple o
Datatable do not support multple o -- Key: MYFACES-1006 URL: http://issues.apache.org/jira/browse/MYFACES-1006 Project: MyFaces Type: Improvement Reporter: Guy Bashan Data tables usually have the following look and feel: 1) rows are light/dark. 2) when moving over a row it is shown selected. For showing rows light/dark it is possible to do: rowClasses=reportRowLight,reportRowDark For showing selected row it is possible to do: rowOnMouseOver=this.className='reportRowOver' rowOnMouseOut=this.className='reportRowLight' but, it is not possible restoring the previous color of the row before the selection. since: rowOnMouseOut property do not support multiple rows. for example, something like this: rowOnMouseOver=this.className='reportRowOver' rowOnMouseOut=this.className='reportRowLight',this.className='reportRowLight' -- 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-1006) Datatable do not support multple o
[ http://issues.apache.org/jira/browse/MYFACES-1006?page=comments#action_12361867 ] Mathias Broekelmann commented on MYFACES-1006: -- I´m not sure if I understand it right. But you can use value bindings or el expressions to solve this. Datatable do not support multple o -- Key: MYFACES-1006 URL: http://issues.apache.org/jira/browse/MYFACES-1006 Project: MyFaces Type: Improvement Reporter: Guy Bashan Data tables usually have the following look and feel: 1) rows are light/dark. 2) when moving over a row it is shown selected. For showing rows light/dark it is possible to do: rowClasses=reportRowLight,reportRowDark For showing selected row it is possible to do: rowOnMouseOver=this.className='reportRowOver' rowOnMouseOut=this.className='reportRowLight' but, it is not possible restoring the previous color of the row before the selection. since: rowOnMouseOut property do not support multiple rows. for example, something like this: rowOnMouseOver=this.className='reportRowOver' rowOnMouseOut=this.className='reportRowLight',this.className='reportRowLight' -- 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-1006) Datatable do not support multple o
[
http://issues.apache.org/jira/browse/MYFACES-1006?page=comments#action_12361869
]
Volker Weber commented on MYFACES-1006:
---
have you tried:
rowOnMouseOver=this.className=this.className + ' reportRowOver'
rowOnMouseOut=this.className=this.className.replace('reportRowOver', ')
Datatable do not support multple o
--
Key: MYFACES-1006
URL: http://issues.apache.org/jira/browse/MYFACES-1006
Project: MyFaces
Type: Improvement
Reporter: Guy Bashan
Data tables usually have the following look and feel:
1) rows are light/dark.
2) when moving over a row it is shown selected.
For showing rows light/dark it is possible to do:
rowClasses=reportRowLight,reportRowDark
For showing selected row it is possible to do:
rowOnMouseOver=this.className='reportRowOver'
rowOnMouseOut=this.className='reportRowLight'
but, it is not possible restoring the previous color of the row before the
selection. since: rowOnMouseOut property do not support multiple rows. for
example, something like this:
rowOnMouseOver=this.className='reportRowOver'
rowOnMouseOut=this.className='reportRowLight',this.className='reportRowLight'
--
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-1006) Datatable do not support multple o
[ http://issues.apache.org/jira/browse/MYFACES-1006?page=comments#action_12361870 ] Guy Bashan commented on MYFACES-1006: - You understand right. I can do it with value bindings, but then you can ask why also support multiple row/column classes and not use valueBindings. Anyway, I solved it easily with java script by doing: rowOnMouseOver=selectedRow = this.className; this.className='reportRowOver' rowOnMouseOut=this.className = selectedRow I know it is a weak improvement . . . ;-) Thanks for you reply. Datatable do not support multple o -- Key: MYFACES-1006 URL: http://issues.apache.org/jira/browse/MYFACES-1006 Project: MyFaces Type: Improvement Reporter: Guy Bashan Data tables usually have the following look and feel: 1) rows are light/dark. 2) when moving over a row it is shown selected. For showing rows light/dark it is possible to do: rowClasses=reportRowLight,reportRowDark For showing selected row it is possible to do: rowOnMouseOver=this.className='reportRowOver' rowOnMouseOut=this.className='reportRowLight' but, it is not possible restoring the previous color of the row before the selection. since: rowOnMouseOut property do not support multiple rows. for example, something like this: rowOnMouseOver=this.className='reportRowOver' rowOnMouseOut=this.className='reportRowLight',this.className='reportRowLight' -- 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-1006) Datatable do not support multple o
[
http://issues.apache.org/jira/browse/MYFACES-1006?page=comments#action_12361871
]
Volker Weber commented on MYFACES-1006:
---
have you tried:
rowOnMouseOver=this.className=this.className + ' reportRowOver'
rowOnMouseOut=this.className=this.className.replace('reportRowOver', '')
Datatable do not support multple o
--
Key: MYFACES-1006
URL: http://issues.apache.org/jira/browse/MYFACES-1006
Project: MyFaces
Type: Improvement
Reporter: Guy Bashan
Data tables usually have the following look and feel:
1) rows are light/dark.
2) when moving over a row it is shown selected.
For showing rows light/dark it is possible to do:
rowClasses=reportRowLight,reportRowDark
For showing selected row it is possible to do:
rowOnMouseOver=this.className='reportRowOver'
rowOnMouseOut=this.className='reportRowLight'
but, it is not possible restoring the previous color of the row before the
selection. since: rowOnMouseOut property do not support multiple rows. for
example, something like this:
rowOnMouseOver=this.className='reportRowOver'
rowOnMouseOut=this.className='reportRowLight',this.className='reportRowLight'
--
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] Created: (MYFACES-1006) Datatable do not support multple o
Hi!
For showing selected row it is possible to do:
rowOnMouseOver=this.className='reportRowOver'
rowOnMouseOut=this.className='reportRowLight'
what about
rowOnMouseOver=if (!this.oldClassName){this.oldClassName=this.className;}
this.className='reportRowOver'
rowOnMouseOut=this.className=this.oldClassName
I havent tried it, but it should work.
Ciao,
Mario
Re: Prototype library and portlets
On 1/5/06, Sean Schofield [EMAIL PROTECTED] wrote:
There is also a Shale proposal{1] related to some of this.Sean[1] http://www.mail-archive.com/dev@struts.apache.org/msg16683.html
Some code that meets the objectives I've outlined here has been checked in to Shale as well, and is part of the current nightly builds. Check out the javadocs for the org.apache.shale.remoting
package[1]. In particular, for static resource serving, this code supports conditional GETs so the client browser can cache the resources it retrieves ... and that works across pages too, if they all share a common URL for the resource. This tends to dramatically reduce the penalty of using a single large resource (such as the kitchen sink version of DOJO).
Craig[1] http://struts.apache.org/struts-shale/shale-core/apidocs/index.html?org/apache/shale/remoting/package-summary.html
[jira] Commented: (MYFACES-919) JSF's component not functioning properly after clicking Browser's Back Button .
[ http://issues.apache.org/jira/browse/MYFACES-919?page=comments#action_12361877 ] paul commented on MYFACES-919: -- Will this fix be in the 1.1.2 release? If so, is there any time estimate for a 1.1.2 release? I prefer to use server-side state saving for my current project, and I would like to have the back button working correctly. Note that this problem also occurs when the user hits the refresh button on a page that was displayed by pressing a commandLink or commandButton.The previous page will end up being displayed when the user hits the refresh button. If the user hits the refresh button a second time, then it works correctly. JSF's component not functioning properly after clicking Browser's Back Button . --- Key: MYFACES-919 URL: http://issues.apache.org/jira/browse/MYFACES-919 Project: MyFaces Type: Bug Components: General Versions: 1.1.1 Environment: MY Faces 1.1.1 , Internet Explorer 6.0 , Tomcat 5.x, windows 2000 professional Reporter: Naveen Modi For Example. Suppose there is a JSF page with pagination. Now user is on third page (pagination) and now if user clicks some hyper link on that page which takes him/her to some target page. Now if user clicks Browser's Back Button he/she returns back to the original page (third page where he/she was). But now if he/she clicks the same hyperlink once again then page refreshes but not redirected to the target page. -- 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: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes
+1 for Sean's proposal.. On 1/5/06, Sean Schofield [EMAIL PROTECTED] wrote: I'll attempt the reorg tomorrow if I don't hear any objections. Please try to get your comments in by then since its simpler to do email iterations vs. svn iterations I'll make a copy of everything in the legacy folder and we can always go back or further refine. Lets try to get the svn shuffle over with ASAP so we can get back to the nightly builds and another release. Sean On 1/5/06, Sean Schofield [EMAIL PROTECTED] wrote: On 1/5/06, Bernd Bohmann [EMAIL PROTECTED] wrote: Here is a more detail description of my thoughts If myfaces is a project without separate release cycle, a possible svn structure: myfaces/trunk/api myfaces/trunk/impl myfaces/trunk/commons myfaces/trunk/tomahawk myfaces/trunk/sandbox myfaces/trunk/examples or the examples belongs to the subprojects myfaces/trunk/assembly or build-tool(s) with checkstyle configuration, assembly maven plugin... I like the parent refs in the pom.xml. I don't like the svn externals they are painful for branching and taging. Can you give me the arguments for parent refs? I still haven't heard a good reason. I'm not against the idea, I just don't know what they give you (other then a common version.) I think we can all agree that the externals are suboptimal. The question is what to do about it. If myfaces has separate release cycles, a possible structure would be: myfaces/core/trunk/api myfaces/core/trunk/impl myfaces/core/trunk/example myfaces/core/trunk/assembly myfaces/commons/trunk myfaces/tomahawk/trunk myfaces/tomahawk/trunk/example myfaces/tomahawk/trunk/assembly myfaces/sandbox/trunk myfaces/sandbox/trunk/example myfaces/sandbox/trunk/assembly maybe a myfaces/common-examples/trunk and myfaces/[build|build-tool(s)]/trunk for checkstyle pmd maven-plugins A good start. Here is a revised proposal based on Bernd's original one core myfaces/core/trunk/api myfaces/core/trunk/impl myfaces/core/trunk/assembly commons === myfaces/commons/trunk tomahawk === myfaces/tomahawk/trunk myfaces/tomahawk/trunk/example myfaces/tomahawk/trunk/assembly myfaces/sandbox/trunk myfaces/sandbox/trunk/example myfaces/sandbox/trunk/assembly maven-tools = custom maven plugins, etc. NOTES: I took out the examples from core. The examples are 99% tomahawk related (other then the blank example which shows basic setup.) I think its easier to just leave examples out of core instead of having two copies, separate examples or svn externals. I merged sandbox and tomahawk together. A while back we decided to put the sandbox stuff in the tomahawk.jar. Since the sandbox is experimental it doesn't need its own release cycle. Also, stuff moves from sandbox to tomahawk so you will often update both anyways. The examples for tomahawk would be the current examples (minus sandbox). The sandbox examples would go under sandbox. With the second option I expect faster release cycles. This would be nice for a faster tobago and adf integration. Yes faster release cycles would be good. I suppose MyFaces commons will be released everytime *either* the core or tomahawk stuff is released. There are bound to be minor changes either time. That still saves us the trouble of branching, testing and merging the core stuff. We had talked about a core project a while ago - but as an svn:external. I like this better. You are correct that branching and tagging will be much easier. Which a snapshot repository or a mavenized released version on a maven repository, it should not be a problem to checkout tomahawk only and compile it (indepent of the first option or the second option). I had thought about this. Is there a way to tell Maven Use my local repository if it is newer then the maven repository? Things could get kind of confusing if you are using your latest commons code in the IDE but Maven is using the last official release ... Best Regards Bernd Sean
Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes
Sean Schofield schrieb: Can you give me the arguments for parent refs? I still haven't heard a good reason. I'm not against the idea, I just don't know what they give you (other then a common version.) I think we can all agree that the externals are suboptimal. The question is what to do about it. The argument for parent refs is to define many things at one place. The version is not really the reason, because it is defined in the parent ref. Without parent refs you have to define the issueManagement ciManagement developers reports in every pom. A legitimate question: Is the core pom a parent of the tomahawk pom, this depends on the differences of the poms. If tomahawk has a different groupId it can't be a child of core. A good start. Here is a revised proposal based on Bernd's original one core myfaces/core/trunk/api myfaces/core/trunk/impl myfaces/core/trunk/assembly Unfortunaly in maven style the directories should have the same name as the artifact name (I don't like it) pom in myfaces/core/trunk/ modules modulemyfaces-api/module modulemyfaces-impl/module moduleassembly/module modules myfaces/core/trunk/myfaces-api myfaces/core/trunk/myfaces-impl myfaces/core/trunk/assembly (The assembly generates not really an artifact) We should find a better name for assembly some examples: continuum continuum-plexus-application maven maven-core maybe myfaces-core commons === myfaces/commons/trunk I think commons should have a parent ref to myfaces. tomahawk === myfaces/tomahawk/trunk myfaces/tomahawk/trunk/example myfaces/tomahawk/trunk/assembly myfaces/sandbox/trunk myfaces/sandbox/trunk/example myfaces/sandbox/trunk/assembly TODO find a better name for assembly maven-tools = custom maven plugins, etc. Not only maven tools. I would suggest myfaces-tools or myfaces-build-tools? NOTES: I took out the examples from core. The examples are 99% tomahawk related (other then the blank example which shows basic setup.) I think its easier to just leave examples out of core instead of having two copies, separate examples or svn externals. I merged sandbox and tomahawk together. A while back we decided to put the sandbox stuff in the tomahawk.jar. Since the sandbox is experimental it doesn't need its own release cycle. Also, stuff moves from sandbox to tomahawk so you will often update both anyways. The examples for tomahawk would be the current examples (minus sandbox). The sandbox examples would go under sandbox. I think the experimental stuff should only released as a nighly build. Yes faster release cycles would be good. I suppose MyFaces commons will be released everytime *either* the core or tomahawk stuff is released. There are bound to be minor changes either time. That still saves us the trouble of branching, testing and merging the core stuff. and tobago is released :-) We had talked about a core project a while ago - but as an svn:external. I like this better. You are correct that branching and tagging will be much easier. :-) I had thought about this. Is there a way to tell Maven Use my local repository if it is newer then the maven repository? Things could get kind of confusing if you are using your latest commons code in the IDE but Maven is using the last official release .. Yes, of cause. I will describe a possible release cycle of myfaces-commons, first. Current development version 1.1.4-SNAPSHOT Ready for a release create a branch 1.1.4 (maven-release-plugin) and then change the version in trunk to 1.1.5-SNAPSHOT. On the branch you can apply last patches and finally perform a release. If you have made changes in tomahawk that depends on myfaces-commons-1.1.5-SNAPSHOT you must change the dependency in the tomahawk pom. If you have made local changes in commons for tomahawk, you only must install a new myfaces-commons-1.1.5-SNAPSHOT in your local repository with mvn install(and change the dependeny to 1.1.5-SNAPSHOT). After you are finished you have to commit your changes in common and tomahawk. A continuum server updates automatically the myfaces snapshot repository. If an other developer perform an update of tomahawk, the next call of mvn fetch the new snapshot of commons into his local repository from the myfaces snapshot repository. TODO setup continuum TODO define the snapshot repository Sean Regards Bernd
Re: Prototype library and portlets
Werner- I just played w/ pluto1.0.1 and MyFacesGenericPortlet to look at ajax-faces-portlet-stuff. However, I wasn't able to get s:inputSuggestAjax / runing :-( I thought the problem could be the ServletFilter for resource serving, but as I wrote yet another ajax input suggest component w/ using PhaseListener for serving resource, I also wasn't able to get this stuff running. (standalone as *traditional* JSF app, it works (both)) -Matthias
Re: [maven] Latest maven changes
On 1/5/06, Sean Schofield [EMAIL PROTECTED] wrote: True. The one issue to be aware of is when commons changes. If containers ship with an older version of MyFaces (including the commons jar) there could be conflicts. No big deal though. We just make sure to remind people to upgrade commons if they are downloading the tomahawk only release. (We should probably include the commons.jar in the tomahawk release as well.) Another sooner rather than later task we should complete is to make the build process package commons separately for impl and for tomahawk.Then we don't have to worry about conflicts. We don't want to force a new release of impl just because we've added extra functionality to commons.
Re: [maven] Latest maven changes
Definitely. We basically decided that a long time ago. We just haven't done a release like this yet (but that will change.) So do you like the revised proposal (as far as layout goes?) Sean On 1/5/06, Mike Kienenberger [EMAIL PROTECTED] wrote: On 1/5/06, Sean Schofield [EMAIL PROTECTED] wrote: True. The one issue to be aware of is when commons changes. If containers ship with an older version of MyFaces (including the commons jar) there could be conflicts. No big deal though. We just make sure to remind people to upgrade commons if they are downloading the tomahawk only release. (We should probably include the commons.jar in the tomahawk release as well.) Another sooner rather than later task we should complete is to make the build process package commons separately for impl and for tomahawk.Then we don't have to worry about conflicts. We don't want to force a new release of impl just because we've added extra functionality to commons.
Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes
I really think we need the parent pom as Bernd points out below it keeps all the project level stuff in one place. TTFN, -bd- On Jan 5, 2006, at 12:21 PM, Bernd Bohmann wrote: Sean Schofield schrieb: Can you give me the arguments for parent refs? I still haven't heard a good reason. I'm not against the idea, I just don't know what they give you (other then a common version.) I think we can all agree that the externals are suboptimal. The question is what to do about it. The argument for parent refs is to define many things at one place. The version is not really the reason, because it is defined in the parent ref. Without parent refs you have to define the issueManagement ciManagement developers reports in every pom. A legitimate question: Is the core pom a parent of the tomahawk pom, this depends on the differences of the poms. If tomahawk has a different groupId it can't be a child of core. A good start. Here is a revised proposal based on Bernd's original one core myfaces/core/trunk/api myfaces/core/trunk/impl myfaces/core/trunk/assembly Unfortunaly in maven style the directories should have the same name as the artifact name (I don't like it) pom in myfaces/core/trunk/ modules modulemyfaces-api/module modulemyfaces-impl/module moduleassembly/module modules myfaces/core/trunk/myfaces-api myfaces/core/trunk/myfaces-impl myfaces/core/trunk/assembly (The assembly generates not really an artifact) We should find a better name for assembly some examples: continuum continuum-plexus-application maven maven-core maybe myfaces-core commons === myfaces/commons/trunk I think commons should have a parent ref to myfaces. tomahawk === myfaces/tomahawk/trunk myfaces/tomahawk/trunk/example myfaces/tomahawk/trunk/assembly myfaces/sandbox/trunk myfaces/sandbox/trunk/example myfaces/sandbox/trunk/assembly TODO find a better name for assembly maven-tools = custom maven plugins, etc. Not only maven tools. I would suggest myfaces-tools or myfaces- build-tools? NOTES: I took out the examples from core. The examples are 99% tomahawk related (other then the blank example which shows basic setup.) I think its easier to just leave examples out of core instead of having two copies, separate examples or svn externals. I merged sandbox and tomahawk together. A while back we decided to put the sandbox stuff in the tomahawk.jar. Since the sandbox is experimental it doesn't need its own release cycle. Also, stuff moves from sandbox to tomahawk so you will often update both anyways. The examples for tomahawk would be the current examples (minus sandbox). The sandbox examples would go under sandbox. I think the experimental stuff should only released as a nighly build. Yes faster release cycles would be good. I suppose MyFaces commons will be released everytime *either* the core or tomahawk stuff is released. There are bound to be minor changes either time. That still saves us the trouble of branching, testing and merging the core stuff. and tobago is released :-) We had talked about a core project a while ago - but as an svn:external. I like this better. You are correct that branching and tagging will be much easier. :-) I had thought about this. Is there a way to tell Maven Use my local repository if it is newer then the maven repository? Things could get kind of confusing if you are using your latest commons code in the IDE but Maven is using the last official release .. Yes, of cause. I will describe a possible release cycle of myfaces-commons, first. Current development version 1.1.4-SNAPSHOT Ready for a release create a branch 1.1.4 (maven-release-plugin) and then change the version in trunk to 1.1.5-SNAPSHOT. On the branch you can apply last patches and finally perform a release. If you have made changes in tomahawk that depends on myfaces- commons-1.1.5-SNAPSHOT you must change the dependency in the tomahawk pom. If you have made local changes in commons for tomahawk, you only must install a new myfaces-commons-1.1.5- SNAPSHOT in your local repository with mvn install(and change the dependeny to 1.1.5-SNAPSHOT). After you are finished you have to commit your changes in common and tomahawk. A continuum server updates automatically the myfaces snapshot repository. If an other developer perform an update of tomahawk, the next call of mvn fetch the new snapshot of commons into his local repository from the myfaces snapshot repository. TODO setup continuum TODO define the snapshot repository Sean Regards Bernd
[jira] Closed: (MYFACES-999) Submitting form with selectOneMenu on it gives error Value is not a valid option
[ http://issues.apache.org/jira/browse/MYFACES-999?page=all ]
Mike Kienenberger closed MYFACES-999:
-
Resolution: Invalid
Sounds likely. The value provided must return equals() == true for some
member of the list. That probably won't happen if you're comparing a Short and
an Integer.
Submitting form with selectOneMenu on it gives error Value is not a valid
option
--
Key: MYFACES-999
URL: http://issues.apache.org/jira/browse/MYFACES-999
Project: MyFaces
Type: Bug
Versions: 1.1.1
Reporter: Scott Brissenden
A selectOneMenu that I have been using successfully in MyFaces 1.0.9 is now
broken. Whenever I try to submit my form I get the error Value is not a
valid option
The code looks legal to me and is as follows:
h:selectOneMenu id=prioritySrc value=#{taskList.priority}
f:selectItems value=#{taskForm.priorityItems}/
/h:selectOneMenu
The backing bean code is:
private static SelectItem[] priorityItems = {
new SelectItem(new Integer(1), High),
new SelectItem(new Integer(2), Medium),
new SelectItem(new Integer(3), Low),
};
public SelectItem[] getPriorityItems() {
return priorityItems;
}
I have confirmed that this problem does go away when I switch back to 1.0.9
--
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: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes
The argument for parent refs is to define many things at one place. The version is not really the reason, because it is defined in the parent ref. Without parent refs you have to define the issueManagement ciManagement developers reports in every pom. Ok then we definitely want the parent ref! I thought that those were inherited when you used module. I didn't realize you had to specify that you were the child of a particular POM. Does this mean that if you build the child, it asks the parent to build? If so, then that is interesting (not a problem - just unexpected.) A legitimate question: Is the core pom a parent of the tomahawk pom, this depends on the differences of the poms. If tomahawk has a different groupId it can't be a child of core. I would say tomahawk and core are independent of one another. Actually all of the top level POMS would be independent of one another. So you would have 3 separate group ids. org.apache.myfaces.core org.apache.myfaces.tomahawk org.apache.myfaces.commons What is the significance of the group id? I know that your repository will have one folder for each but what else does it mean? Underneath the group id folder is the version right? If each of these 3 can have their own release cycle then I think we *must* have 3 group ids right? commons === myfaces/commons/trunk I think commons should have a parent ref to myfaces. What do you mean by this? TODO find a better name for assembly +1 maven-tools = custom maven plugins, etc. Not only maven tools. I would suggest myfaces-tools or myfaces-build-tools? What else goes in here besides plugins? I think the experimental stuff should only released as a nighly build. I'm ok with your suggestion but a while back there seemed to be support for including it in tomahawk. I can't remember the arguments off the top of my head. I will do an archive search ... and tobago is released :-) Of course, we shouldn't forget tobago ;-) Its good to have you guys on board. Your Maven experience is already coming in handy. [snip] A continuum server updates automatically the myfaces snapshot repository. If an other developer perform an update of tomahawk, the next call of mvn fetch the new snapshot of commons into his local repository from the myfaces snapshot repository. TODO setup continuum TODO define the snapshot repository OK I think I see what you mean. We can come back to your suggestion later when we get the SVN stuff done. I was interested in continuum before this explanation but now I am *very* interested. Bill Dudney has also expressed interest and now that we have our zone we can do this! First things first though. Lets get *re*organized and get the POMs the way we want them. Thanks for your excellent ideas ... Sean Sean
Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes
@Bill: moving a snip of your comments to this thread ... I'd like to see something like this; myfaces/pom.xml myfaces/api/pom.xml myfaces/commons/pom.xml myfaces/examples/pom.xml myfaces/impl/pom.xml myfaces/sandbox/pom.xml myfaces/tomahawk/pom.xml Is the point of the very top level POM for stuff that is common to 100% of the modules (like mailing list, jira, contributor lists, etc)? Why not combine api and impl in their own core module? IMO there is no point in ever releasing those separately. Both constitute a JSF implementation. One advantage to sandbox within tomahawk is we can cut down on the number of top level modules. Just throw the sandbox stuff into sandbox.jar and provide its own api docs. That stuff goes into the release bundle along with tomahawk.jar and we say sandbox stuff is untested and subject too change or elimination. I also think that the examples should go in tomahawk. They are basically examples of tomahawk in action and any time you add a new tomahawk component (or a significant feature to an existing component) you will want to update the examples. Also, I envision linking the tomahwk documentation to the examples on the website (now that we have our zone.) So I think the examples are tightly coupled to tomahawk/sandbox. Thoughts on this? It would be *much* simpler to combine them Sean
Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes
The other cool thing with a 'parent pom' is that you'd only specify the dependency version once in the top level pom so that we would not have to change it over and over again in the subprojects/modules. I can't think of a single dependency that would apply to *all* projects. If it doesn't apply to all modules then you don't want it in the root POM do you? Otherwise it shows up in the dependency reports even though the dependency is not there ... We wouldn't put commons in the top level POM either would we? That isn't even created until later on down the line. Plus different modules would depend on different versions (since we are releasing independently now ..) -bd- Sean
Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes
Hi Sean, thanks for cross posting this stuff to the correct thread :-) On Jan 5, 2006, at 1:43 PM, Sean Schofield wrote: @Bill: moving a snip of your comments to this thread ... I'd like to see something like this; myfaces/pom.xml myfaces/api/pom.xml myfaces/commons/pom.xml myfaces/examples/pom.xml myfaces/impl/pom.xml myfaces/sandbox/pom.xml myfaces/tomahawk/pom.xml Is the point of the very top level POM for stuff that is common to 100% of the modules (like mailing list, jira, contributor lists, etc)? Yes its to have all the common stuff in one place so you don't have to change it over and over in all the modules. Dependency versions is another big win IMO with a parent pom. Why not combine api and impl in their own core module? IMO there is no point in ever releasing those separately. Both constitute a JSF implementation. Agreed, good point. One advantage to sandbox within tomahawk is we can cut down on the number of top level modules. Just throw the sandbox stuff into sandbox.jar and provide its own api docs. That stuff goes into the release bundle along with tomahawk.jar and we say sandbox stuff is untested and subject too change or elimination. +1 on combining sandbox and tomahawk. Are you thinking of making tomahawk a mid level module that has 2 submodules? myfaces/tomahawk/pom.xml = packaging = pom myfaces/tomahawk/tomahawk myfaces/tomahawk/sandbox This is fine as it reduces the top level clutter. If you want to have two products from a single module I'm not sure but I think it will present problems from maven. I also think that the examples should go in tomahawk. They are basically examples of tomahawk in action and any time you add a new tomahawk component (or a significant feature to an existing component) you will want to update the examples. Also, I envision linking the tomahwk documentation to the examples on the website (now that we have our zone.) So I think the examples are tightly coupled to tomahawk/sandbox. Agreed with this too, so we'd have something like this if I'm understanding correctly; myfaces/pom.xml = packaging = pom modules = (core, commons, tomahawk) myfaces/core/pom.xml = packaging = pom modules = (impl, api) myfaces/core/api/pom.xml = packaging = jar myfaces/core/impl/pom.xml = packaging = jar myfaces/commons/pom.xml = packaging = jar myfaces/tomahawk/pom.xml = packaging = pom modules = (tomahawk, sandbox, examples) myfaces/tomahawk/tomahawk/pom.xml = packaging = jar myfaces/tomahawk/sandbox/pom.xml = packaging = jar myfaces/tomahawk/examples/pom.xml = packaging = war This looks very good and much simpler, no externals etc. easy to branch, tag etc. We also need the publish thing to have an assembly as we have now, although I've had less experience with making assemblies we have on my other project the ability to do an 'mvn release' (or something like that I'll have to look) and have the whole assembly pushed out to the download site. I'll have to look at how we made that work, its great stuff! TTFN, -bd-
Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes
On Jan 5, 2006, at 1:55 PM, Sean Schofield wrote: The other cool thing with a 'parent pom' is that you'd only specify the dependency version once in the top level pom so that we would not have to change it over and over again in the subprojects/modules. I can't think of a single dependency that would apply to *all* projects. If it doesn't apply to all modules then you don't want it in the root POM do you? Otherwise it shows up in the dependency reports even though the dependency is not there ... Well if more than one of the modules depends on it (not all) then I'd put it in the root. That way your are consistently specifying the version you depend on. As far as the dependency report goes each module will get a more specific one, the top level will define all the dependences for everything. In some respects it could be considered better to have the top level specify each and every dependency even if its only used in one module. We wouldn't put commons in the top level POM either would we? That isn't even created until later on down the line. Plus different modules would depend on different versions (since we are releasing independently now ..) Well I'd set the dependency during the development cycle to be consistent. Then at release time for a module you could fix it to the version you are about to release, publish the module then fix it back to the snapshot version. I'm not sure the process is fully baked in my mind though. I'll have to put another thread out for discussion on that. -bd- -bd- Sean
Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes
Sean Schofield wrote: Does this mean that if you build the child, it asks the parent to build? If so, then that is interesting (not a problem - just unexpected.) As far as I understand it Maven only builds child projects if the POM includes a module entry for that child. In general it applies a goal on all included modules. These child modules won't even need a parent entry. Maven just changes into the directory with name in the module entry. The parent entry is more or less for inheriting common stuff. But it won't instruct Maven to build the parent. Regards, Arvid
Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes
On 1/5/06, Bill Dudney [EMAIL PROTECTED] wrote: Well if more than one of the modules depends on it (not all) then I'd put it in the root. That way your are consistently specifying the version you depend on. As far as the dependency report goes each module will get a more specific one, the top level will define all the dependences for everything. In some respects it could be considered better to have the top level specify each and every dependency even if its only used in one module. I don't agree with this at all. For one thing, any webapps you try to build will inherit all of the dependencies and they will all land in WEB-INF/lib. You'll then have a mess of exclusions trying to keep things out. And the list of dependencies will be useless to someone trying to figure out what any one module really depends upon. I haven't tried it, but I'm also concerned that the poms created during the release process will list too many dependencies. For Struts I'm resisting putting *any* dependencies in the parent pom, even if it means repeating a couple of them (servlet-api and junit). In practice, the transitive dependency mechanism will work better than inheritance for making sure each module has the dependencies it needs to compile. -- Wendy
Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes
For Struts I'm resisting putting *any* dependencies in the parent pom, even if it means repeating a couple of them (servlet-api and junit). In practice, the transitive dependency mechanism will work better than inheritance for making sure each module has the dependencies it needs to compile. I agree. Lets keep the dependencies out of the parent POM for the reasons Wendy mentioned. IMO there's no need to keep them consistent as Bill is suggesting. If tomahawk has a dependency on commons-lang-1.2 and impl is dependent on commons-lang-1.1 that is fine by me. In fact, its preferred. That way if I'm only using MyFaces for the JSF implementation I can stick with v. 1.1 of the commons-lang dependency that's already in my app server or whatever. On the other hand. The list of commiters, the mailing list info, etc. should be consistent and only defined in one place. A while back I noticed the Struts site was not consistent with contributor lists and I'm assuming it was due to not using this parent feature. Wendy Sean
Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes
I understood that modules were called from the parent. I was trying to understand the relationship in the other direction. It sounds like it consults the parent POM and inherits its attributes but does *not* build it. That's more of what I would expect ... Sean On 1/5/06, Bill Dudney [EMAIL PROTECTED] wrote: On Jan 5, 2006, at 2:13 PM, Arvid Hülsebus wrote: Sean Schofield wrote: Does this mean that if you build the child, it asks the parent to build? If so, then that is interesting (not a problem - just unexpected.) As far as I understand it Maven only builds child projects if the POM includes a module entry for that child. In general it applies a goal on all included modules. These child modules won't even need a parent entry. Maven just changes into the directory with name in the module entry. The parent entry is more or less for inheriting common stuff. But it won't instruct Maven to build the parent. Sorry Sean, I missed that in my last response. My understanding and experiences mirrors Arvid's. TTFN, -bd-
Viewhandler question/proposal
Hi, a question to the list... I am currently writing a chainable view handler (a view handler which you can pass a sequential list of handlers which are then chained together in the order you give in the parameters - top down, all done in the faces config) Now I rechecked the tlds and I saw that you already can cascade the decorating view handlers. But one question to the people in here more familiar with the specs, does this cascade enforce a calling order or not? I am not talking about the actual implementation here but more about the specs themselves. the * in the view handler tag definition makes that unclear. If it does I can dump the work spent so far on the custom handler if not, then it probably is a good idea to implement it fully.
Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes
I try a summary: core (org.apache.myfaces) [This has a own release cycle] myfaces/core/trunk/pom.xml myfaces/core/trunk/myfaces-api/pom.xml myfaces/core/trunk/myfaces-impl/pom.xml myfaces/core/trunk/assembly/pom.xml commons (org.apache.myfaces) [This has a own release cycle] === myfaces/commons/trunk/pom.xml tomahawk sandbox (org.apache.myfaces.tomahawk) [This has a own release cycle] [Sandbox is not released only in nightly build] === myfaces/tomahawk/trunk/pom.xml myfaces/tomahawk/trunk/example/pom.xml myfaces/tomahawk/trunk/sandbox/pom.xml myfaces/tomahawk/trunk/assembly/pom.xml tools (org.apache.myfaces) [no assembly but release on a maven repository] = myfaces/tools/trunk/pom.xml myfaces/tools/trunk/maven-myfaces-plugin/pom.xml myfaces/tools/trunk/build-tools(checkstyleandpmdconfiguration)/pom.xml site (org.apache.myfaces) [maybe never released only for the main site] = myfaces/site/trunk/pom.xml TODO find a better name for assembly TODO setup continuum TODO define a snapshot repository NOTE: tomahawk has a different groupid the pom is not inherited Is something missing? Best Regards Bernd
Re: Viewhandler question/proposal
On 1/5/06, Werner Punz [EMAIL PROTECTED] wrote: Hi, a question to the list...I am currently writing a chainable view handler(a view handler which you can pass a sequential list of handlerswhich are then chained together in the order you give in the parameters - top down, all done in the faces config)Now I rechecked the tlds and I saw that you already can cascade thedecorating view handlers.But one question to the people in here more familiar with the specs, does this cascade enforce a calling order or not?Within a given faces-config.xml file you should be able to count on ordering (the last one you declare will be the view handler from the point of view of the Application object. However, there's no mandated ordering with respect to view handlers loaded from different faces-config.xml files (for example, those implicitly loaded from the META-INF directory of a component JAR).You may recall some earlier discussion on this list about what the JSF RI currently does -- essentially loading the jar files in alphabetical order. It's a convention, not a mandated requirement, and doesn't address all possible dependency relationships you might want, but it would be better than nothing. CraigI am not talking about the actual implementation herebut more about the specs themselves. the * in the view handler tag definition makes that unclear.If it does I can dump the work spent so far on the custom handlerif not, then it probably is a good idea to implement it fully.
Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes
Hi Wendy, On Jan 5, 2006, at 2:18 PM, Wendy Smoak wrote: On 1/5/06, Bill Dudney [EMAIL PROTECTED] wrote: Well if more than one of the modules depends on it (not all) then I'd put it in the root. That way your are consistently specifying the version you depend on. As far as the dependency report goes each module will get a more specific one, the top level will define all the dependences for everything. In some respects it could be considered better to have the top level specify each and every dependency even if its only used in one module. I don't agree with this at all. For one thing, any webapps you try to build will inherit all of the dependencies and they will all land in WEB-INF/lib. You'll then have a mess of exclusions trying to keep things out. And the list of dependencies will be useless to someone trying to figure out what any one module really depends upon. I haven't tried it, but I'm also concerned that the poms created during the release process will list too many dependencies. Do we really end up with everything from the top level in the lib dir? What I'm thinking is something like this being in a 'user' project. dependency groupidorg.apache.myfaces/groupId artifactIdtomahawk/artifactId /depdency This will cause the transitive dependency thing to pull in everything that tomahawk depends on but won't touch the top level pom as I understand it anyway. Am I wrong about this? For Struts I'm resisting putting *any* dependencies in the parent pom, even if it means repeating a couple of them (servlet-api and junit). In practice, the transitive dependency mechanism will work better than inheritance for making sure each module has the dependencies it needs to compile. I hate to repeat the info though... -- Wendy
Re: Viewhandler question/proposal
Craig McClanahan wrote: Within a given faces-config.xml file you should be able to count on ordering (the last one you declare will be the view handler from the point of view of the Application object. However, there's no mandated ordering with respect to view handlers loaded from different faces-config.xml files (for example, those implicitly loaded from the META-INF directory of a component JAR). You may recall some earlier discussion on this list about what the JSF RI currently does -- essentially loading the jar files in alphabetical order. It's a convention, not a mandated requirement, and doesn't address all possible dependency relationships you might want, but it would be better than nothing. Ok thanks for the clarification, then my work spent on it so far is more or less useless because the JSF api basically implcitely already does what I had in mind :-)
Re: Viewhandler question/proposal
Yep; also, consecutive calling isn't really right because few of the ViewHandler methods return anything indicating hey, I handled it, so everyone else hands off, and because the decoration pattern is in fact often required, to support working off the results of another ViewHandler' and tweaking them. Where Craig says it would be better than nothing (referring to alphabetical order), I agree in so far as making it a convention, but I argued against making it part of the spec, since it's not something I wanted to be stuck with for the rest of eternity. -- Adam On 1/5/06, Werner Punz [EMAIL PROTECTED] wrote: Craig McClanahan wrote: Within a given faces-config.xml file you should be able to count on ordering (the last one you declare will be the view handler from the point of view of the Application object. However, there's no mandated ordering with respect to view handlers loaded from different faces-config.xml files (for example, those implicitly loaded from the META-INF directory of a component JAR). You may recall some earlier discussion on this list about what the JSF RI currently does -- essentially loading the jar files in alphabetical order. It's a convention, not a mandated requirement, and doesn't address all possible dependency relationships you might want, but it would be better than nothing. Ok thanks for the clarification, then my work spent on it so far is more or less useless because the JSF api basically implcitely already does what I had in mind :-)
Re: Viewhandler question/proposal
On 1/5/06, Adam Winer [EMAIL PROTECTED] wrote: Yep;also, consecutive calling isn't really right because few ofthe ViewHandler methods return anything indicating hey, I handled it,so everyone else hands off, and because the decoration pattern is in fact often required, to support working off the results of another ViewHandler'and tweaking them.Where Craig says it would be better than nothing (referringto alphabetical order), I agree in so far as making it a convention, but I argued against making it part of the spec, since it's notsomething I wanted to be stuck with for the rest of eternity.+1 ... a correct solution would support some sort of dependency declaration mechanism to determine ordering. Craig
Re: Viewhandler question/proposal
I thought I'd added a summary of the dependency discussion as comments to the jsf-spec issue #121, but I don't see them now https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=121 On 1/5/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 1/5/06, Adam Winer [EMAIL PROTECTED] wrote: Yep; also, consecutive calling isn't really right because few of the ViewHandler methods return anything indicating hey, I handled it, so everyone else hands off, and because the decoration pattern is in fact often required, to support working off the results of another ViewHandler' and tweaking them. Where Craig says it would be better than nothing (referring to alphabetical order), I agree in so far as making it a convention, but I argued against making it part of the spec, since it's not something I wanted to be stuck with for the rest of eternity. +1 ... a correct solution would support some sort of dependency declaration mechanism to determine ordering. Craig
Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes
Hi Sean, On Jan 5, 2006, at 1:33 PM, Sean Schofield wrote: I would say tomahawk and core are independent of one another. Actually all of the top level POMS would be independent of one another. So you would have 3 separate group ids. org.apache.myfaces.core org.apache.myfaces.tomahawk org.apache.myfaces.commons What is the significance of the group id? I know that your repository will have one folder for each but what else does it mean? Underneath the group id folder is the version right? If each of these 3 can have their own release cycle then I think we *must* have 3 group ids right? Group ID is kind of like the package spec in java, use reverse domain name to uniquely define your whole thing, then artifactId defines the individual parts. I'm thinking something like this; groupIdorg.apache.myfaces/groupId artifactIdcore/artifactId version1.1.2-SNAPSHOT/version groupIdorg.apache.myfaces/groupId artifactIdtomahawk/artifactId version1.3-SNAPSHOT/version groupIdorg.apache.myfaces/groupId artifactIdcommons/artifactId version1.1.2-SNAPSHOT/version then when a user wants to specify a dependency (if we have build our poms correctly) they could specify either tomahawk to get the components and the impl, or just core to get just the impl. I think all of them should be under a single parent pom, then we can easily build all of them as a group. TTFN, -bd-
Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes
On 1/5/06, Bill Dudney [EMAIL PROTECTED] wrote: Do we really end up with everything from the top level in the lib dir? What I'm thinking is something like this being in a 'user' project. dependency groupidorg.apache.myfaces/groupId artifactIdtomahawk/artifactId /depdency This will cause the transitive dependency thing to pull in everything that tomahawk depends on but won't touch the top level pom as I understand it anyway. Am I wrong about this? I don't know for sure, I'd have to experiment with it. I think that if Tomahawk inherits dependencies, then they belong to Tomahawk no matter where they originally came from. If your webapp depends on Tomahawk, you're going to get all of them. I hate to repeat the info though... Lesser of two evils? :) My first experiences with m2 were fending off unwanted transitive dependencies and submitting patches for poms in the repository so my own webapps would contain the right things. I'd rather do the work up front, and make sure that the users get clean poms that express exactly the right dependencies for each module. And so far the only duplication I'm seeing is from the dependencies that are not transitive (the ones with test or provided scope.) -- Wendy
Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes
Do we really end up with everything from the top level in the lib dir? What I'm thinking is something like this being in a 'user' project. dependency groupidorg.apache.myfaces/groupId artifactIdtomahawk/artifactId /depdency This will cause the transitive dependency thing to pull in everything that tomahawk depends on but won't touch the top level pom as I understand it anyway. Am I wrong about this? Won't this be the case either way. The dependencies for tomahawk are the dependencies for tomahawk. It doesn't matter if Maven learns this exclusively from the tomahawk.pom or from a combination of myfaces.pom (parent) and tomahawk.pom. Is this reasoning correct? Sean
Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes
Group ID is kind of like the package spec in java, use reverse domain name to uniquely define your whole thing, then artifactId defines the individual parts. I'm thinking something like this; groupIdorg.apache.myfaces/groupId artifactIdcore/artifactId version1.1.2-SNAPSHOT/version groupIdorg.apache.myfaces/groupId artifactIdtomahawk/artifactId version1.3-SNAPSHOT/version groupIdorg.apache.myfaces/groupId artifactIdcommons/artifactId version1.1.2-SNAPSHOT/version Didn't Bernd say there were some issues with this (everything with the same group id?) then when a user wants to specify a dependency (if we have build our poms correctly) they could specify either tomahawk to get the components and the impl, or just core to get just the impl. There's an interesting issue here. What if you use tomahawk in your project and you want to use the RI? I guess you end up downloading MyFaces api, impl and commons into your m2 repository (for build purposes) but use whatever implementation you want in your WAR. That sound right? I think all of them should be under a single parent pom, then we can easily build all of them as a group. I agreed with you on this earlier. Single parent pom is useful for a single list of developers, etc. Plus as you say, you can run install on the parent pom and install everything. The only matter that remains is whether to declare most of the dependcies there or to repeat them as necessary in the modules that need them (the way we're doing it now.) TTFN, -bd- Sean
Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes
Sean Schofield wrote: Do we really end up with everything from the top level in the lib dir? What I'm thinking is something like this being in a 'user' project. dependency groupidorg.apache.myfaces/groupId artifactIdtomahawk/artifactId /depdency This will cause the transitive dependency thing to pull in everything that tomahawk depends on but won't touch the top level pom as I understand it anyway. Am I wrong about this? Won't this be the case either way. The dependencies for tomahawk are the dependencies for tomahawk. It doesn't matter if Maven learns this exclusively from the tomahawk.pom or from a combination of myfaces.pom (parent) and tomahawk.pom. Is this reasoning correct? I don't believe so. Myfaces-impl can be used without tomahawk. Tomahawk can be used without Myfaces-impl. So neither has transitive dependencies on the other project. And as an earlier post pointed out, myfaces-impl may depend on commons-lang 1.1 while tomahawk may depend on commons-lang 1.2. In this case, people only wanting to use the core myfaces (not tomahawk) should be able to use just commons-lang 1.1. Only if they add tomahawk do they need to upgrade the commons-lang library. There are transitive dependencies between commons and impl, or commons and tomahawk. Regards, Simon
Re: [maven] Revised Reorg Proposal -- Was: [maven] Latest maven changes
Bernd, I think we're close to agreement. I'm going to hold off on the reorg until Saturday. There are enough issues that need to be addressed to make it worth waiting at least one more day. I have a few questions/points for you inline. On 1/5/06, Bernd Bohmann [EMAIL PROTECTED] wrote: I try a summary: core (org.apache.myfaces) [This has a own release cycle] myfaces/core/trunk/pom.xml myfaces/core/trunk/myfaces-api/pom.xml myfaces/core/trunk/myfaces-impl/pom.xml myfaces/core/trunk/assembly/pom.xml commons (org.apache.myfaces) [This has a own release cycle] === myfaces/commons/trunk/pom.xml We should also have myfaces/commons/assembly/pom.xml right? tomahawk sandbox (org.apache.myfaces.tomahawk) [This has a own release cycle] [Sandbox is not released only in nightly build] === myfaces/tomahawk/trunk/pom.xml myfaces/tomahawk/trunk/example/pom.xml myfaces/tomahawk/trunk/sandbox/pom.xml myfaces/tomahawk/trunk/assembly/pom.xml Let me make sure I understand you. Under myfaces/tomahawk/trunk we would have the usual src/main/java src/main, src/test, src/site, etc. all for tomahawk. So in more detail you would have myfaces/tomahawk/trunk/pom.xml myfaces/tomahawk/trunk/src/main myfaces/tomahawk/trunk/src/test myfaces/tomahawk/trunk/src/site myfaces/tomahawk/trunk/example/pom.xml myfaces/tomahawk/trunk/sandbox/pom.xml myfaces/tomahawk/trunk/sandbox/src/main myfaces/tomahawk/trunk/sandbox/src/test myfaces/tomahawk/trunk/sandbox/src/site myfaces/tomahawk/trunk/assembly/pom.xml Is this what you mean? tools (org.apache.myfaces) [no assembly but release on a maven repository] = myfaces/tools/trunk/pom.xml myfaces/tools/trunk/maven-myfaces-plugin/pom.xml myfaces/tools/trunk/build-tools(checkstyleandpmdconfiguration)/pom.xml What is maven-myfaces-plugin? Is this some future plugin TBD or is this something specific you had in mind? Just curious. I think for now we can just reserve myfaces/tools for future use and discuss that later (once the basic build is working.) site (org.apache.myfaces) [maybe never released only for the main site] = myfaces/site/trunk/pom.xml Definitely not released since its just the website. This would have the top level website stuff (overview, etc.) Can we pull the enitre website together in the myfaces/assembly/pom.xml? It would be nice if we could use one pom for running assembly, publishing the nightlies and updating the site. TODO find a better name for assembly TODO setup continuum TODO define a snapshot repository + 1 NOTE: tomahawk has a different groupid the pom is not inherited Why is this necessary to have a different group id. Earlier you explained what happens if they are different but not why the *should* be different. Bernd Sean
[jira] Commented: (MYFACES-985) UIData with multihierarchical children inside produces NPE
[ http://issues.apache.org/jira/browse/MYFACES-985?page=comments#action_12361941 ] Andrew Kharchenko commented on MYFACES-985: Oh, just forgot. I want to notice again, that behaviour in the attached sample project works fine under Sun RI. UIData with multihierarchical children inside produces NPE -- Key: MYFACES-985 URL: http://issues.apache.org/jira/browse/MYFACES-985 Project: MyFaces Type: Bug Components: Implementation Environment: Tomcat 5.0 JDK 1.4 Reporter: Andrew Kharchenko Assignee: Mathias Broekelmann Attachments: UIData NPE Sample.rar I've found incorrect UIData behaviour under MyFaces which produces NullPointerException on runtime and which works fine under Sun implementation. Here it is: I have a custom component which is extentor from UIInput. This component has UIPanel extentor component as child which is added to children list of UIInput component on rendering. For one's turn, UIPanel extentor has one more UIInput extentor component as child which is added to children list of UIPanel component on rendering. This component works fine standalone, but when it is added to UIData, I have NPE on runtime. Here is the part of listing: java.lang.NullPointerException at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:223) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.setRowIndex(UIData.java:178) I will also attach sample component's classes, definitions and test page if it will be granted after issue creation. -- 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-985) UIData with multihierarchical children inside produces NPE
[ http://issues.apache.org/jira/browse/MYFACES-985?page=comments#action_12361940 ] Andrew Kharchenko commented on MYFACES-985: Attached component is just a sample. The real component is a DateChooser which consists with text field, button and popup calendar. DateChooser is extended from UIInput and has popup panel (UIPanel extentor) as child. For one's turn, popup panel has Calendar (UIInput extentor) as child. That's all. In addition, I've tried to move children addition to component's constructor from component's renderer and it helped. So, I think this request can be resolved. Thanx. UIData with multihierarchical children inside produces NPE -- Key: MYFACES-985 URL: http://issues.apache.org/jira/browse/MYFACES-985 Project: MyFaces Type: Bug Components: Implementation Environment: Tomcat 5.0 JDK 1.4 Reporter: Andrew Kharchenko Assignee: Mathias Broekelmann Attachments: UIData NPE Sample.rar I've found incorrect UIData behaviour under MyFaces which produces NullPointerException on runtime and which works fine under Sun implementation. Here it is: I have a custom component which is extentor from UIInput. This component has UIPanel extentor component as child which is added to children list of UIInput component on rendering. For one's turn, UIPanel extentor has one more UIInput extentor component as child which is added to children list of UIPanel component on rendering. This component works fine standalone, but when it is added to UIData, I have NPE on runtime. Here is the part of listing: java.lang.NullPointerException at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:223) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.restoreDescendantComponentStates(UIData.java:235) at javax.faces.component.UIData.setRowIndex(UIData.java:178) I will also attach sample component's classes, definitions and test page if it will be granted after issue creation. -- 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
