Wait a minute - Martin posted that he had a solution to this problem, right?
regards,
Martin
On 11/1/05, Luiz Augusto Ruiz [EMAIL PROTECTED] wrote:
I have the same problem, attribute showRootNode doesn't work with Facelets.
Luiz Augusto Ruiz
Sergipe - Brasil
2005/10/25, Martin Mavrov
And does it work if you remove the id attribute from your graphicImage
component in the facet? (id=theproblem)
Regards,
Bruno
2005/11/2, John Sherwood [EMAIL PROTECTED]:
I've been having a heap of trouble getting the DataScroller object
working. It simply refuses to allow me to have facets.
Hey,
we can discuss this Ajax-thingy off or on list if you want - cause you
wrote that it caused you major pain ;)
regards,
Martin
On 11/2/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: prophecy
Date: Tue Nov 1 16:35:57 2005
New Revision: 330166
URL:
[
http://issues.apache.org/jira/browse/MYFACES-771?page=comments#action_12356579
]
Joris Verschoor commented on MYFACES-771:
-
Ofcourse it should only be done when internet explorer is detected.
action in a submit button is not triggered on IE
[
http://issues.apache.org/jira/browse/MYFACES-702?page=comments#action_12356580
]
Martin Marinschek commented on MYFACES-702:
---
Nothing in the MyFaces-implementation does this, as far as I can see.
Hmm - I don't know much about the portlet
[
http://issues.apache.org/jira/browse/MYFACES-770?page=comments#action_12356581
]
Martin Marinschek commented on MYFACES-770:
---
Hi Wayne,
the collapsed state can now be found in the attribute value of the component
- best, if you want to set
serverSideTabSwitch attribute in x:panelTabbedPane shows wrong behaviour
Key: MYFACES-773
URL: http://issues.apache.org/jira/browse/MYFACES-773
Project: MyFaces
Type: Bug
Components: Tomahawk
[ http://issues.apache.org/jira/browse/MYFACES-773?page=all ]
Martin Marinschek closed MYFACES-773:
-
Fix Version: Nightly
Resolution: Fixed
Thanks to Luciano Medina
serverSideTabSwitch attribute in x:panelTabbedPane shows wrong behaviour
[ http://issues.apache.org/jira/browse/MYFACES-770?page=all ]
Martin Marinschek closed MYFACES-770:
-
Resolution: Won't Fix
use a value-binding for the attribute value if you want to know the collapsed
state of the component.
[
http://issues.apache.org/jira/browse/MYFACES-757?page=comments#action_12356587
]
Martin Marinschek commented on MYFACES-757:
---
This is the code where getActionURL is used for redirects - is that causing any
problem for you? For me, it looks
[
http://issues.apache.org/jira/browse/MYFACES-748?page=comments#action_12356588
]
Mathias Werlitz commented on MYFACES-748:
-
The problem is that the Sun RI does not call saveState() and restoreState()
with server-side state saving.
I think the
UIComponentTagUtils.setActionProperty checks for UICommand instead of
ActionSource
--
Key: MYFACES-774
URL: http://issues.apache.org/jira/browse/MYFACES-774
Project: MyFaces
Type: Bug
[ http://issues.apache.org/jira/browse/MYFACES-774?page=all ]
Martin Marinschek closed MYFACES-774:
-
Fix Version: Nightly
Resolution: Fixed
Assign To: Martin Marinschek
Thanks Nico for pointing this out.
[ http://issues.apache.org/jira/browse/MYFACES-760?page=all ]
sean schofield updated MYFACES-760:
---
Priority: Major (was: Blocker)
Tree2 setLeaf(false) error
--
Key: MYFACES-760
URL:
forceId only affects the clientId not the component id.
sean
On 10/28/05, Travis Reeder [EMAIL PROTECTED] wrote:
I tried this without setting the id, works fine.
I set the id, works fine.
Added forceId=true and it cannot find it.
Even though when I print out the component tree, the
Agreed. However, the reason is out of date because the projects are now
separated (as they should be).
Separating the projects makes it easier for someone to use Tomahawk
stuff with the RI. So that is a major plus. I don't think it makes
our reasoning out of date because the same group of
Forrest is also not building ... Please try to run the Forrest build
before checking in. It only takes 30 seconds.
sean
-- Forwarded message --
[echo] Loading project specific properties from
/home/sjs4/bootstrap/myfaces-current/forrest/build/forrest.properties
I'm going to merge down everything from the 1.1. branch (since the
last merge) unless I hear any objections. Nobody has done this yet
right?
sean
Build has been failing all weekend long ...
-- Forwarded message --
From: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Nov 1, 2005 11:03 PM
Subject: Build Failure
To: [EMAIL PROTECTED], dev@myfaces.apache.org
[echo] build.dir: /home/sjs4/bootstrap/myfaces-current/build
I should have done this. Unfortunately my forrest build fails building
a lot earlier saying:
BUILD FAILED
C:\java\myfaces\workspace\myfaces\forrest\build\build.xml:49: The
following error occurred while executing this line:
C:\java\apache-forrest-0.6\src\core\targets\validate.xml:143: Could
not
A couple of conflicts but not too bad considering the frantic pace of
MyFaces development these days. Next time we branch please remember
to fix the problem once and only once in order to avoid this problem.
There is one conflict that I don't feel comfortable resolving
(HtmlButtonRendererBase).
[ http://issues.apache.org/jira/browse/MYFACES-696?page=all ]
Thomas Spiegl resolved MYFACES-696:
---
Fix Version: Nightly
Resolution: Fixed
Using t:navigationMenuItem inside a form is not working. Id assign problemm.
[ http://issues.apache.org/jira/browse/MYFACES-697?page=all ]
Thomas Spiegl resolved MYFACES-697:
---
Fix Version: Nightly
Resolution: Fixed
fixed: itemValue=0 no longer necessary
fixed: action of navigationMenuItem is now recognized as
[ http://issues.apache.org/jira/browse/MYFACES-290?page=all ]
Thomas Spiegl resolved MYFACES-290:
---
Fix Version: Nightly
Resolution: Fixed
x:datascroller does not have the immediate attribute to by pass the
validation and update model
[ http://issues.apache.org/jira/browse/MYFACES-392?page=all ]
Thomas Spiegl resolved MYFACES-392:
---
Fix Version: 1.1.0
Resolution: Fixed
When using x:navigationMenuItems in jsCookMenu, only top-level is displayed
Hi John,
On Nov 1, 2005, at 10:25 PM, John Fallows wrote:
If you want to use a version of tomahawk that is incompatible with
your MyFaces implementation on the web server, just upgrade the
MyFaces version. Yes its a pain but it certainly doesn't seem to be
insurmountable.
This just proves
Exception in inputDate
--
Key: MYFACES-775
URL: http://issues.apache.org/jira/browse/MYFACES-775
Project: MyFaces
Type: Bug
Components: Tomahawk
Versions: 1.1.1
Environment: myfaces-api.jar, myfaces-impl.jar, tomahawk.jar
@srcs not compiling:
That's Travis working on JDK1.5 who hasn't ensured backwards
compatibility. Shame on you, Travis ;)
As for forrest, I don't know, I'll try to run a validation at home.
regards,
Martin
On 11/2/05, Mathias Brökelmann [EMAIL PROTECTED] wrote:
I should have done this.
Yes, this is another option.
make myfaces-share something like a common-jsf-utils or so.
Thing is that changes should not happen very often in there, then. And
incompatible changes never.
regards,
Martin
On 11/2/05, Bill Dudney [EMAIL PROTECTED] wrote:
Hi John,
On Nov 1, 2005, at 10:25 PM,
very good.
+1
On 11/2/05, Sean Schofield [EMAIL PROTECTED] wrote:
I'm going to merge down everything from the 1.1. branch (since the
last merge) unless I hear any objections. Nobody has done this yet
right?
sean
--
http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and
@Sean - isn't that the same problem as with inputSuggestAjax? We
really should be able to find a component, even if it has forceId set
to true.
There should be something like a central hashmap for all forceId'd
components. We can also do a duplicate check then.
regards,
Martin
On 11/2/05, Sean
[ http://issues.apache.org/jira/browse/MYFACES-697?page=all ]
Martin Marinschek closed MYFACES-697:
-
Non-standard behaviour of t:navigationMenuItem (in t:jscookMenu) breaks
facelets
[ http://issues.apache.org/jira/browse/MYFACES-392?page=all ]
Martin Marinschek closed MYFACES-392:
-
When using x:navigationMenuItems in jsCookMenu, only top-level is displayed
[ http://issues.apache.org/jira/browse/MYFACES-696?page=all ]
Martin Marinschek closed MYFACES-696:
-
Using t:navigationMenuItem inside a form is not working. Id assign problemm.
[
http://issues.apache.org/jira/browse/MYFACES-705?page=comments#action_12356635
]
Martin Marinschek commented on MYFACES-705:
---
Hi Volker,
is this the final patch that is currently appended?
Or do you plan to work more on this - I didn't find
[
http://issues.apache.org/jira/browse/MYFACES-760?page=comments#action_12356644
]
Andrew Efremov commented on MYFACES-760:
I found it
!-- Note that tree will not work as-is. Tree either needs a facelets
TagHandler, or a refactoring of
-1 for Java 5.0 (for the time being.)
sean
On 11/2/05, Heinz Drews [EMAIL PROTECTED] wrote:
I just want to remind that there are still a significant number of
sites which cannot move to Java 5 because of restrictions implied by
the Application Server used.
WebSphere would be here candidate
Hi Travis,
no need to fix it anymore - Thomas did it already for you; no problem.
regards,
Martin
On 11/2/05, Travis Reeder [EMAIL PROTECTED] wrote:
Sorry guys, my bad. I'll fix asap.
Travis
On 11/2/05, Martin Marinschek [EMAIL PROTECTED] wrote:
@srcs not compiling:
That's Travis
I think that basically we all know that your approach would be the
best, John. It is just a matter of getting it to work automatically.
Is there any chance to do so?
regards,
Martin
On 11/2/05, John Fallows [EMAIL PROTECTED] wrote:
On 11/2/05, Sean Schofield [EMAIL PROTECTED] wrote:
Simon Kitching [mailto:[EMAIL PROTECTED] writes:
I'd rather see detection of *any* protocol on the front of the URL
rather than checking just for http:. The protocols
https:, mail:
etc are also useful.
== proposal: ==
The URL *always* has menu_id: on the start, so presumably the
Tree2 state problem when using dynamic trees
Key: MYFACES-776
URL: http://issues.apache.org/jira/browse/MYFACES-776
Project: MyFaces
Type: Bug
Environment: JSF RI 1.1.01
Tomahawk nightly build from 10-30-2005
ya, saw that when i got merge conflicts. ;)
Travis
On 11/2/05, Martin Marinschek [EMAIL PROTECTED] wrote:
Hi Travis,
no need to fix it anymore - Thomas did it already for you; no problem.
regards,
Martin
On 11/2/05, Travis Reeder [EMAIL PROTECTED] wrote:
Sorry guys, my bad. I'll fix
That would be great Sean, it's a blocker for these ajax components.
Travis
On 11/2/05, Sean Schofield [EMAIL PROTECTED] wrote:
Its the same problem as inputSuggestAjax. Chris Barlow and I wrote a
patch for it but we haven't committed it yet. I'll try to get to it
later today or tomorrow ...
[
http://issues.apache.org/jira/browse/MYFACES-223?page=comments#action_12356662
]
Alessandro Polverini commented on MYFACES-223:
--
I can confirm it works well with tomcat 5.0.30 and myfaces 1.1.1
Can't share myfaces jars globally in tomcat
I find that forceId works half the time and doesn't the other half,
for example, i just tried it on a dataTable and it's picking up the
surrounding forms id so it should be:
myTable, but it ends up being _id6:myTable where _id6 is the id of the form tag.
What makes somethings override the forceId
Thanks Sean,
All three files are up to date now.
TTFN,
-bd-
On Nov 2, 2005, at 11:56 AM, Sean Schofield wrote:
Thanks. I have committed the changes (r330309). I did get one other
weird result which was that SVN was complaining that the following
*test* files were already in SVN:
Yep. Same problem. Does the code work for anyone else? It's an ArrayList of
Message objects that I'm using.
java.lang.IllegalStateException: Client-id : _id6 is duplicated in the faces
tree.
Thanks,
John
Bruno Aranda wrote:
And does it work if you remove the id attribute from your
On 11/2/05, Martin Marinschek [EMAIL PROTECTED] wrote:
Yes, this is another option.make myfaces-share something like a common-jsf-utils or so.Thing is that changes should not happen very often in there, then. Andincompatible changes never.
Right.
This requires that the shared code be promoted
Ok, let's have a look at this.
Although I doubt that we will get rid of the *Renderer*Base classes.
regards,
Martin
On 11/2/05, John Fallows [EMAIL PROTECTED] wrote:
On 11/2/05, Martin Marinschek [EMAIL PROTECTED] wrote:
Yes, this is another option.
make myfaces-share something like a
I have a page using HtmlSelectManyAjax that is built inside the bean,
not on the jsp. When it's created, it has onSuccess=someFunction.
I put a system out in the setOnSuccess and getOnSuccess to see what's
going on. So after I use a commandButton, the onSuccess value is set
to null and the
Set a breakpoint on the constructor.
Probably you're not saving the state of the onSuccess attribute, and a
new component is created without initializing that field.
On 11/2/05, Travis Reeder [EMAIL PROTECTED] wrote:
I have a page using HtmlSelectManyAjax that is built inside the bean,
not on
Thanks Mike, you're probably dead on, I wasn't saving state in those components.
Travis
On 11/2/05, Mike Kienenberger [EMAIL PROTECTED] wrote:
Set a breakpoint on the constructor.
Probably you're not saving the state of the onSuccess attribute, and a
new component is created without
AddResource uses static StringBuffer ADDITIONAL_JAVASCRIPT_TO_BODY_TAG for
per-request data
---
Key: MYFACES-777
URL: http://issues.apache.org/jira/browse/MYFACES-777
Project: MyFaces
I'm not too wild about a new jar. Craig made some good arguments a
while back about keeping myfaces just two jars (impl and api).
Perhaps he can be persuaded to share his thoughts with us again? He
has some relevant experience with this in the RI and trying to use the
RI and MyFaces with Shale.
On 11/2/05, Sean Schofield [EMAIL PROTECTED] wrote:
I'm not too wild about a new jar.Craig made some good arguments awhile back about keeping myfaces just two jars (impl and api).Perhaps he can be persuaded to share his thoughts with us again?Hehas some relevant experience with this in the RI and
55 matches
Mail list logo
