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:
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
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 ;)
[
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...
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
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
[
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
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
[
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.
[ 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
[
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
[
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
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
[
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();
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
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
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
[
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
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
[
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
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
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
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
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
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
[
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
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
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
[
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.
[
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'
[
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
[
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'
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'
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
[
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
+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
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
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
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
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]
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.
[ 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
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
@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
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
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
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
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
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
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 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
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
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]
===
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
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
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
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
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
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
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
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
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
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
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
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
[
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.
[
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
67 matches
Mail list logo
