Hi *,
please welcome Mike to our team.
Mike has been providing many patches over the very long time he has
been active with Apache MyFaces, and has donated invaluable help to
all users of Apache MyFaces - most of you can confirm this from your
own experience.
For the record - Mike would have
[
http://issues.apache.org/jira/browse/MYFACES-705?page=comments#action_12358352
]
Volker Weber commented on MYFACES-705:
--
I just did a fresh checkout and revert my changes. the problem in IE still
occurs, so it must something other.
I will look for
Documentation is our single biggest weakness right now IMO (especially
the code documentation but javadoc is not far behind.) So if you are
reasonably certain your docs are right don't hesitate to add them!
For every 1 mistake you make you will be adding 99 pieces of valuable
documentation and
myfaces examples support for JSP 1.2 / Servlet 2.3 containers
-
Key: MYFACES-867
URL: http://issues.apache.org/jira/browse/MYFACES-867
Project: MyFaces
Type: Bug
Components: General
Versions: 1.1.1
dataList treatment inside panelGrid
---
Key: MYFACES-868
URL: http://issues.apache.org/jira/browse/MYFACES-868
Project: MyFaces
Type: Improvement
Components: Tomahawk
Versions: 1.1.1, Nightly
Environment: 11/22/2005
radio does no function within dataList
--
Key: MYFACES-869
URL: http://issues.apache.org/jira/browse/MYFACES-869
Project: MyFaces
Type: Bug
Components: Tomahawk
Versions: 1.1.1, Nightly
Environment: 11/22/05 Nightly
Simon,
There are a few very long threads on this in the archives (when
forceId first came about.) Not only is it awkward to add
form1:subview2 etc to every reference in your javascript but if you
change your JSF form structure all of your javascript needs to change
too! (NOTE: Its not always
Additionally,
the colon is a reserved character in CSS - for pseudo-selectors. You
can run into major problems with CSS and the standard client-ids.
regards,
Martin
On 11/23/05, Sean Schofield [EMAIL PROTECTED] wrote:
Simon,
There are a few very long threads on this in the archives (when
What if someone reported with affects [Nightly]. If we rename
Nightly to 1.1.x on releasing, the issue would now have the
property affects 1.1.x, which is wrong. Because the bug was actually
FIXED in 1.1.x.
Then the issue was found and fixed in the same version. That just
means it was
A couple days ago our project ran into the need to emit nonstandard HTML
attributes to support a certain security-related feature. We ended up
subclassing HtmlInputTextTag to add a setter/getter for the attribute.
While it's not a lot of code, a standard method for adding these
sorts of attributes
IE6: NPE in JavaScript when using t:calendarInput
---
Key: MYFACES-870
URL: http://issues.apache.org/jira/browse/MYFACES-870
Project: MyFaces
Type: Bug
Versions: 1.1.1
Environment: Windows XP SP2
IE6
Doesn't look too clean to me.. If you need those
non-standard attributes for specific tags (possibly with certain values), why
not just write a filter that would do an XSL transformation and add them to the
response?
Kalle
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Sent:
On 11/23/05, Sean Schofield [EMAIL PROTECTED] wrote:
For every 1 mistake you make you will be adding 99 pieces of valuable
documentation and someone will eventually catch the 1 mistake!
I agree. In fact, this is my practice in answering emails too. I
answer them even when I'm unsure, because
[
http://issues.apache.org/jira/browse/MYFACES-869?page=comments#action_12358398
]
Mike Kienenberger commented on MYFACES-869:
---
I read something recently that seemed to indicate that h:panelGroup might
affect finding components.
Try removing the
Apologies. I thought the bug yesterday was not opened because JIRA
timed out as it was posting. I noticed the email this morning after
creating this enhancement request. I also realized this morning before
requesting this enhancement that this was working as intended. Since
dataList is a component
I reduced the jsp to the following and get the same error:
t:selectOneRadio id=test forceId=true layout=spread
f:selectItems value=#{tonyTester.selectItems}/
/t:selectOneRadio
t:dataList var=helper value=#{tonyTester.helpers} rowIndexVar=index
t:radio for="" index=#{index}/
/t:dataList
Tony,
What happens if you take out the forceId from test?
My understanding of forceId is that it changes the namespace of the id
value, so using it might break the non-forceId radio below it.
I've never use radio buttons with JSF, so I'm no authority on them.
I remember seeing posts in the
dataList is an iterating tag. But it's going to iterate at render
time and output html. c:forEach is an iterating jsp tag that
iterates at component tree building time and can output components,
at least when used with facelets (not sure how it works with the
standard JSF JSP view handler.)
[ http://issues.apache.org/jira/browse/MYFACES-870?page=all ]
Bruno Aranda closed MYFACES-870:
Fix Version: Nightly
Resolution: Fixed
I've fixed that in the sources following your solution. Thanks Roland! I cannot
try it since I only have a
2005/11/23, Sean Schofield [EMAIL PROTECTED]:
What if someone reported with affects [Nightly]. If we rename
Nightly to 1.1.x on releasing, the issue would now have the
property affects 1.1.x, which is wrong. Because the bug was actually
FIXED in 1.1.x.
Then the issue was found and fixed
I believe the radio bug is actually a problem. This is the bug I intended to respond to:
Sorry, I didn't think my bug yesterday got logged because I got a
timeout error when I posted it. I realized this morning that it was
expected behavior since t:dataList is a component and should all be in
one
Ok. Looks like it's just a client issue. The diff shown in my
commit message seems fine.
On 11/23/05, Mike Kienenberger [EMAIL PROTECTED] wrote:
I'm doing a pre-commit diff of contributors.xml in (Windows) Eclipse
with subeclipse, and I'm seeing that every line is different, unless I
turn
On 11/23/05, Mike Kienenberger [EMAIL PROTECTED] wrote:
I'm doing a pre-commit diff of contributors.xml in (Windows) Eclipsewith subeclipse, and I'm seeing that every line is different, unless Iturn on the ignore-whitespace option.I'm guessing I need to somehow configure my svn eof setting for
Thanks, Martin.
It didn't affect my current situation, but it needed to be done for new files.
I've borrowed your words and added them to our wiki :)
On 11/23/05, Martin Cooper [EMAIL PROTECTED] wrote:
On 11/23/05, Mike Kienenberger [EMAIL PROTECTED] wrote:
I'm doing a pre-commit diff of
There is a full set of examples in the sandbox under AJAX Form
Components or directly at inputAjax.jsf.
Travis
On 11/22/05, Grant Smith [EMAIL PROTECTED] wrote:
Good work Travis! Any chance of creating some examples for these ?
--
Grant Smith
Does anyone have any comment on whether this is a bug or not:
As you can see UIComponentTag.doEndTag calls internalRelease(). But
strangely, members _id, _rendered and _binding are cleared only in
release(), not internalRelease(). Maybe that's a bug?
[ http://issues.apache.org/jira/browse/MYFACES-868?page=all ]
Mike Kienenberger resolved MYFACES-868:
---
Fix Version: Nightly
Resolution: Won't Fix
Assign To: Mike Kienenberger
Problem needs to be solved using other means: dataTable
Should I be closing invalid or won't fix jira issues at the same time
I resolve them?
[ http://issues.apache.org/jira/browse/MYFACES-858?page=all ]
Mike Kienenberger closed MYFACES-858:
-
Fix Version: Nightly
Resolution: Fixed
Assign To: Mike Kienenberger
Fixed. Thanks, Jeff.
You'll need to find the answers to your
[ http://issues.apache.org/jira/browse/MYFACES-868?page=all ]
Mike Kienenberger closed MYFACES-868:
-
dataList treatment inside panelGrid
---
Key: MYFACES-868
URL:
Is there a reason why we can't change all of these
org.apache.myfaces.tree2.xyz attributes to xyz?
// Tree2 attributes
public static final String SHOW_NAV=
org.apache.myfaces.tree2.SHOW_NAV;
public static final String SHOW_LINES =
Sounds like it is a bug, though that's a very quick impression
without serious thought.
Re: what happens if the number of tags change from one request
to the next: this is why JSF tags inside of c:if are required to have
an explicitly set ID (think this is stated explicitly in the JSF spec).
Hi Steve,
[EMAIL PROTECTED] wrote:
Both tomahawk/tld/myfaces_ext.dl and tomahawk/tld/tomahawk.tld will need
some additional external entities added to pick up the standard HTML
stuff that I have in my patch.
I had a look at your patch. To summarise for others:
The patch moves definitions
I think Simon's question is not about why forceId exists
in the first place, but why AJAX would *require* its use.
The former was discussed long ago. The latter is a new
question which deserves careful consideration.
-- Adam
On 11/23/05, Sean Schofield [EMAIL PROTECTED] wrote:
Simon,
There
Hi Mike,
Mike Kienenberger wrote:
Should I be closing invalid or won't fix jira issues at the same time
I resolve them?
I would personally have marked this particular issue invalid rather
than wontfix.
invalid: the report is not a bug.
wontfix: it's agreed that it is a bug or misfeature
Martin Marinschek wrote:
Hi *,
please welcome Mike to our team.
Congrats Mike. And welcome from a fellow MyFaces newbie committer :-)
Cheers, Simon
Yeah, the other projects I've been on that use JIRA mark bugs closed
after a public release is made. I did a quick search and only Thomas
was marking things resolved but not closed, so I went ahead and closed
it.Since the second report was submitted as an improvment, WON'T
FIX is probably
I haven't used AJAX, but isn't the javascript concerned *generated* by
JSF tags? If so, the generated javascript should be able to create
document.getElementById(form1:subview2:button1)
Or is it that AJAX is commonly combined with user-provided javascript
that manipulates the same DOM
scripts from script.aculo.us needs updated
--
Key: MYFACES-871
URL: http://issues.apache.org/jira/browse/MYFACES-871
Project: MyFaces
Type: Bug
Components: Sandbox
Versions: Nightly
Reporter: Volker Weber
[
http://issues.apache.org/jira/browse/MYFACES-705?page=comments#action_12358429
]
Volker Weber commented on MYFACES-705:
--
The problem seems because somone has commited a updated version of
prototype.js without also updateing the control.js.
Is
[ http://issues.apache.org/jira/browse/MYFACES-871?page=all ]
Volker Weber updated MYFACES-871:
-
Attachment: relocate.bmp
Attached screenshot to illustrate the new IE problem
scripts from script.aculo.us needs updated
I see that originally _id etc were reset in internalRelease, and they
were moved to the release method by this commit:
r166747 | manolito | 2004-04-27 00:01:39 +1200 (Tue, 27 Apr 2004) | 2 lines
more reluctant releasing
Mike,
I don't know much about facelets but I'm curious to know what is
causing the problem. If facelets doesn't support attribute properties
with '.' characters in the name then IMO that is really the source of
the problem.
Its considered good practice to have fully qualifies names in your
Well, if Simon's point is that Ajax should not *require* forceId then
I agree with him (or whoever is making that point.) We're not
requiring it right now but I think that is what Travis is suggesting
(with the reasoning be that you almost always want to use it anyways.)
As for why you would
Adam Winer wrote:
Re: what happens if the number of tags change from one request
to the next: this is why JSF tags inside of c:if are required to have
an explicitly set ID (think this is stated explicitly in the JSF spec).
This whole mess is why I proposed JspIdConsumer for JSP 2.1,
which lets
Hi,
I've recently fixed a couple of files without any svn:eol-style setting
and it has generated big diffs.
I think what's happening is that when svn:eol-style gets set on a file
that didn't have it, the file gets normalised before committing. And
normalisation happens to mean convert to
-Original Message-
From: Sean Schofield [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 23, 2005 8:14 AM
To: MyFaces Development
Subject: Re: Plan for 1.1.2?
[Snip]
I'm not wild about multiple nightly versions, etc. Perhaps we could
use the roadmap as is being suggested
On 11/23/05, Simon Kitching [EMAIL PROTECTED] wrote:
So if the file
was originally committed without svn:eol-style, but from a unix machine,
then setting svn:eol-style doesn't cause any diffs. If the file was
originally committed from a Windows machine (or Mac), however, then
every line in
-Original Message-
From: Manfred Geiler [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 23, 2005 11:23 AM
To: MyFaces Development
Subject: Re: Plan for 1.1.2?
2005/11/23, Sean Schofield [EMAIL PROTECTED]:
What if someone reported with affects [Nightly]. If we rename
[ http://issues.apache.org/jira/browse/MYFACES-866?page=all ]
Steve Peterson updated MYFACES-866:
---
Attachment: new_files.tar
This attachment contains new files that were not included in the patch. They
are necessary to make the patch work. Thanks
[ http://issues.apache.org/jira/browse/MYFACES-866?page=all ]
Steve Peterson updated MYFACES-866:
---
Attachment: tomahawk.tld.patch
This patch updates tomahawk/tld/tomahawk.tld to work with the first patch.
Updates to standard tag TLD documentation
I submitted 2 more files: a tar that contains the new files that
were missing from the .patch, and a patch for tomahawk/tld/tomahawk.tld
that brings it up to date with the first patch.
SteveOn 11/23/05, Simon Kitching [EMAIL PROTECTED] wrote:
Hi Steve,[EMAIL PROTECTED] wrote: Both
Here's the specific scenario that led me down this path.
The app I'm working on is used by call center reps to enter orders,
which include credit card numbers. The autocomplete feature in
most modern browsers will cache previous entries in fields. We
didn't (for obvious reasons) want this to
Thanks very much Steve.
As this patch is a reasonably significant change, I'd like to wait at
least 24 hours for other MyFaces committers to have a look at least at
my summary of this patch (see below). If there are no objections during
that period I'll then test and commit your patch as soon
I've looked at it.
forget about the one time performance hit at build time, I'd say.
for me, this is ok.
regards,
Martin
On 11/24/05, Simon Kitching [EMAIL PROTECTED] wrote:
Thanks very much Steve.
As this patch is a reasonably significant change, I'd like to wait at
least 24 hours for
Manolito would be Manfred Geiler.
I suppose that release is called when the tag is given back to the
ServletContainer anyways?
regards,
Martin
On 11/24/05, Simon Kitching [EMAIL PROTECTED] wrote:
I see that originally _id etc were reset in internalRelease, and they
were moved to the release
[
http://issues.apache.org/jira/browse/MYFACES-705?page=comments#action_12358448
]
Martin Marinschek commented on MYFACES-705:
---
Thanks Volker for this evaluation!
That must have been me with the prototype.js update. I tried to update
Sorry, I didn't think my bug yesterday got logged because I got a
timeout error when I posted it. I realized this morning that it was
expected behavior since t:dataList is a component and should all be in
one column of a panelGrid. However, I'd like to propose extending
dataList to support the
I'd say that for you, Mike, it's that 1% or much lesser ;)
regards,
Martin
On 11/23/05, Mike Kienenberger [EMAIL PROTECTED] wrote:
On 11/23/05, Sean Schofield [EMAIL PROTECTED] wrote:
For every 1 mistake you make you will be adding 99 pieces of valuable
documentation and someone will
Right.
I would never, ever want to force users to use forceId for working with AJAX.
So, my opinion is on record ;)
regards,
Martin
On 11/24/05, Sean Schofield [EMAIL PROTECTED] wrote:
Well, if Simon's point is that Ajax should not *require* forceId then
I agree with him (or whoever is
+1 for closing immediately.
We can always reopen later ;).
The last time I closed Thomas bugs, I'll talk to him to use close
instead of resolve as well.
regards,
Martin
On 11/23/05, Mike Kienenberger [EMAIL PROTECTED] wrote:
Yeah, the other projects I've been on that use JIRA mark bugs
Hmm, in fact, the autocomplete attribute is supported during
rendering of components - we needed that for customized drop-down
lists.
So you could do a component binding, and add the autocomplete
attribute to the componentAttributesMap, and the renderer will render
the corresponding attribute, if
Hello,
I would like to change the groupId of Tobago to follow the naming
convention of maven.
Change from
groupIdtobago/groupId
to
groupIdorg.apache.myfaces.tobago/groupId
See http://maven.apache.org/guides/mini/guide-naming-conventions.html
I think myfaces should follow this naming
63 matches
Mail list logo
