date:20081014

hello,

i suggest to talk about the right place for new (and independent) components
in general.

regards,
gerhard



2008/10/14 Hazem Saleh [EMAIL PROTECTED]

 Hello Team,

 I had previous old discussions with Volker about the future of the
 ExporterActionListener.

 And we agreed on moving this component to the MyFaces commons project.

 But after a discussion with Leonardo I know that commons does not include
 any components module?

 Now the two possible ways are:

 1. Promoting the component to Tomahawk.
 2. Making a new components module in commons and promote the component to
 it.

 I need your suggestions regarding that!

 Thanks all!

 --
 Hazem Ahmed Saleh Ahmed

 Author of (The Definitive Guide to Apache MyFaces and Facelets):

 http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370

 Web blog: http://www.jroller.com/page/HazemBlog

 [Web 2.0] Google Maps Integration with JSF:
 http://code.google.com/p/gmaps4jsf/




-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: ExporterActionListener to commons

2008-10-14 Thread Hazem Saleh

I think that If commons should include components, then these components
should be independent + have no UI.

On Tue, Oct 14, 2008 at 4:35 PM, Gerhard Petracek 
[EMAIL PROTECTED] wrote:

 hello,

 i suggest to talk about the right place for new (and independent)
 components in general.

 regards,
 gerhard



 2008/10/14 Hazem Saleh [EMAIL PROTECTED]

 Hello Team,

 I had previous old discussions with Volker about the future of the
 ExporterActionListener.

 And we agreed on moving this component to the MyFaces commons project.

 But after a discussion with Leonardo I know that commons does not include
 any components module?

 Now the two possible ways are:

 1. Promoting the component to Tomahawk.
 2. Making a new components module in commons and promote the component to
 it.

 I need your suggestions regarding that!

 Thanks all!

 --
 Hazem Ahmed Saleh Ahmed

 Author of (The Definitive Guide to Apache MyFaces and Facelets):

 http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370

 Web blog: http://www.jroller.com/page/HazemBlog

 [Web 2.0] Google Maps Integration with JSF:
 http://code.google.com/p/gmaps4jsf/




 --

 http://www.irian.at

 Your JSF powerhouse -
 JSF Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces




-- 
Hazem Ahmed Saleh Ahmed

Author of (The Definitive Guide to Apache MyFaces and Facelets):
http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370

Web blog: http://www.jroller.com/page/HazemBlog

[Web 2.0] Google Maps Integration with JSF:
http://code.google.com/p/gmaps4jsf/

[jira] Commented: (MYFACES-2006) getTableIndex: Integer to String (ClassCastException)

2008-10-14 Thread Taro App (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12639448#action_12639448
 ] 

Taro App commented on MYFACES-2006:
---

I have voted for this issue. This is more serious for me. The problem is not 
just inputText's tabindex, but more wide spread. For example,
- binding for inputText's size and maxlength must be an Integer and not null.
- binding for inputText's tabindex must be a String and not null.
- binding for inputText's disabled and readonly must not return null.
- binding for inputTextarea's rows and cols must be an Integer and not null.
- binding for graphicsImage's width and height must be a String and not null.

Firstly, it does not seem consistent. For example, inputText's size is an 
Integer, where graphicsImage's width is a String. If a value binding does not 
return matching data type, ClassCastException is thrown. In the previous 
releases, it just worked.
Secondly, it does not default. If a value binding returns null, 
NullPointerException is thrown. In the previous releases, default value is used 
instead.
Thirdly, arithmatic expression binding cannot be used. For example, setting 
size=#{bean.value * 10} for inputText raises ClassCastExpression because the 
calculated value is a Long.

I have a large application which has been working on MyFaces Core 1.1.3 and 
Tomahawk 1.1.3. I am trying to upgrade to MyFaces Core 1.1.6 and Tomahawk 
1.1.7, but this is the blocking issue.

 getTableIndex: Integer to String (ClassCastException)
 -

 Key: MYFACES-2006
 URL: https://issues.apache.org/jira/browse/MYFACES-2006
 Project: MyFaces Core
  Issue Type: Bug
Affects Versions: 1.1.6
Reporter: Paris Holley

 Have a project using MyFaces 1.1.5 and Tomahawk 1.1.7. When MyFaces 1.1.5 is 
 upgraded to 1.1.6 classcast exceptions are thrown when elements such as 
 HtmlInputText try to access getTabIndex through an EL expression that returns 
 an int. Though the spec states that the EL expression should return a 
 string, this was not a problem in the previous version. If tag attributes are 
 more strict in the latest release, it would help to have stated so in the 
 release notes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [ExtVal] internationalized message bundles

hello simon,

so far MessageFormat isn't used, because there are just simple messages (one
argument at most).
currently there is a straightforward interface [1] for message resolving.

we could change it to:

public interface MessageResolver
{
String getMessage(String key, Locale locale);
String getMessage(String key, Locale locale, Object args[]);
}

regards,
gerhard

[1]
http://svn.apache.org/viewvc/myfaces/extensions/validator/trunk/core/src/main/java/org/apache/myfaces/extensions/validator/core/validation/message/resolver/MessageResolver.java?revision=694858view=markup



2008/10/14 Simon Lessard [EMAIL PROTECTED]

 Hi all,

 Are we using MessageFormat to add the dynamic variables to the messages or
 another class? If the former, then all languages needs to escape ' with '' .


 Regards,

 ~ Simon


 On Mon, Oct 13, 2008 at 3:29 PM, Simon Lessard [EMAIL PROTECTED]wrote:

 That's true, I somehow mistook champ for an invariant like cours. Anyway,
 I'll commit them tomorrow.


 Regards,

 ~ Simon


 On Mon, Oct 13, 2008 at 4:30 AM, Marc Schneider 
 [EMAIL PROTECTED] wrote:

 Hi Gilles,

 I see an issue, which is a typo one.
 When there is only ONE field, there is no 's' at the end.

 For example :
 Ce champ (and NOT : Ce champs).

 All files are concerned.

 Marc.

 Gilles Demarty a écrit :
  Le fichier corrigé est en attachement
 
 
 
  On Fri, Oct 10, 2008 at 8:16 PM, Simon Lessard
  [EMAIL PROTECTED] wrote:
  Hi Gilles,
 
  HTML entity for 'é' is eacute, not ecute, so
 
  // crossval-message-bundle-validation_messages.properties
  duplicated_content_required=les champs sont diffeacute;rents
  duplicated_content_required_details=les champs sont diffeacute;rents
 
  duplicated_content_denied=les champs doivent ecirc;tre
 diffeacute;rents
  duplicated_content_denied_details=les champs doivent ecirc;tre
  diffeacute;rents
 
  wrong_date_not_before=La date doit ecirc;tre apregrave;s {0}
  wrong_date_not_before_details=La date doit ecirc;tre apregrave;s {0}
 
  wrong_date_not_equal=La date n'est pas eacute;gale agrave; {0}
  wrong_date_not_equal_details=La date n'est pas eacute;gale agrave;
 {0}
 
  // baseval-message-bundle-validation_messages.properties
  Nothing
 
  // baseval-message-bundle-jpa_messages_fr.properties
  One message contains a è
  field_too_long_details=Le contenu de ce champs est trop long ({0}
  caractegrave;res au maximum)
 
 
  I don't see any other issues.
 
 
  Regards,
 
  ~ Simon
 
  On Fri, Oct 10, 2008 at 2:01 PM, Gilles Demarty 
 [EMAIL PROTECTED]
  wrote:
  Here are the french versions. Simon, can you do a double-check ?
 
 
  On Fri, Oct 10, 2008 at 1:54 PM, Hazem Saleh [EMAIL PROTECTED]
 wrote:
  I did the Arabic translation, and Turkish translation done thanks to
  Mert.
 
  On Fri, Oct 10, 2008 at 12:51 PM, Glauco P. Gomes
  [EMAIL PROTECTED] wrote:
  Gerhard Petracek escreveu:
  what's your suggestion for the replacement of wrong?
  (the annotation is responsible to compare if one date value is
  before/after a second one)
  +1 to invalid
 
  Glauco P. Gomes
 
 
  --
  Hazem Ahmed Saleh Ahmed
 
  Author of (The Definitive Guide to Apache MyFaces and Facelets):
 
 
 http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370
 
  Web blog: http://www.jroller.com/page/HazemBlog
 
  [Web 2.0] Google Maps Integration with JSF:
  http://code.google.com/p/gmaps4jsf/
 
 






-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: [ExtVal] internationalized message bundles

2008-10-14 Thread Simon Lessard

ok, good. Commited the French message without doubling the '.

On Tue, Oct 14, 2008 at 11:59 AM, Gerhard Petracek 
[EMAIL PROTECTED] wrote:

 hello simon,

 so far MessageFormat isn't used, because there are just simple messages
 (one argument at most).
 currently there is a straightforward interface [1] for message resolving.

 we could change it to:

 public interface MessageResolver
 {
 String getMessage(String key, Locale locale);
 String getMessage(String key, Locale locale, Object args[]);
 }

 regards,
 gerhard

 [1]
 http://svn.apache.org/viewvc/myfaces/extensions/validator/trunk/core/src/main/java/org/apache/myfaces/extensions/validator/core/validation/message/resolver/MessageResolver.java?revision=694858view=markup



 2008/10/14 Simon Lessard [EMAIL PROTECTED]

 Hi all,

 Are we using MessageFormat to add the dynamic variables to the messages or
 another class? If the former, then all languages needs to escape ' with '' .


 Regards,

 ~ Simon


 On Mon, Oct 13, 2008 at 3:29 PM, Simon Lessard [EMAIL PROTECTED]
  wrote:

 That's true, I somehow mistook champ for an invariant like cours. Anyway,
 I'll commit them tomorrow.


 Regards,

 ~ Simon


 On Mon, Oct 13, 2008 at 4:30 AM, Marc Schneider 
 [EMAIL PROTECTED] wrote:

 Hi Gilles,

 I see an issue, which is a typo one.
 When there is only ONE field, there is no 's' at the end.

 For example :
 Ce champ (and NOT : Ce champs).

 All files are concerned.

 Marc.

 Gilles Demarty a écrit :
  Le fichier corrigé est en attachement
 
 
 
  On Fri, Oct 10, 2008 at 8:16 PM, Simon Lessard
  [EMAIL PROTECTED] wrote:
  Hi Gilles,
 
  HTML entity for 'é' is eacute, not ecute, so
 
  // crossval-message-bundle-validation_messages.properties
  duplicated_content_required=les champs sont diffeacute;rents
  duplicated_content_required_details=les champs sont diffeacute;rents
 
  duplicated_content_denied=les champs doivent ecirc;tre
 diffeacute;rents
  duplicated_content_denied_details=les champs doivent ecirc;tre
  diffeacute;rents
 
  wrong_date_not_before=La date doit ecirc;tre apregrave;s {0}
  wrong_date_not_before_details=La date doit ecirc;tre apregrave;s
 {0}
 
  wrong_date_not_equal=La date n'est pas eacute;gale agrave; {0}
  wrong_date_not_equal_details=La date n'est pas eacute;gale agrave;
 {0}
 
  // baseval-message-bundle-validation_messages.properties
  Nothing
 
  // baseval-message-bundle-jpa_messages_fr.properties
  One message contains a è
  field_too_long_details=Le contenu de ce champs est trop long ({0}
  caractegrave;res au maximum)
 
 
  I don't see any other issues.
 
 
  Regards,
 
  ~ Simon
 
  On Fri, Oct 10, 2008 at 2:01 PM, Gilles Demarty 
 [EMAIL PROTECTED]
  wrote:
  Here are the french versions. Simon, can you do a double-check ?
 
 
  On Fri, Oct 10, 2008 at 1:54 PM, Hazem Saleh [EMAIL PROTECTED]
 wrote:
  I did the Arabic translation, and Turkish translation done thanks
 to
  Mert.
 
  On Fri, Oct 10, 2008 at 12:51 PM, Glauco P. Gomes
  [EMAIL PROTECTED] wrote:
  Gerhard Petracek escreveu:
  what's your suggestion for the replacement of wrong?
  (the annotation is responsible to compare if one date value is
  before/after a second one)
  +1 to invalid
 
  Glauco P. Gomes
 
 
  --
  Hazem Ahmed Saleh Ahmed
 
  Author of (The Definitive Guide to Apache MyFaces and Facelets):
 
 
 http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370
 
  Web blog: http://www.jroller.com/page/HazemBlog
 
  [Web 2.0] Google Maps Integration with JSF:
  http://code.google.com/p/gmaps4jsf/
 
 






 --

 http://www.irian.at

 Your JSF powerhouse -
 JSF Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces

Re: [orchestra] release orchestra-core version 1.3?

2008-10-14 Thread Mario Ivankovits


Hi!

Great!

I think it is a good time to make another Orchestra Core release. 
There is nothing radical in this new version,

Yep, the radical stuff is kept for the next version ;-)

Ciao,
Mario

Re: [orchestra] release orchestra-core version 1.3?

2008-10-14 Thread Bruno Aranda

+1 I am using the snapshot, so I would love to see that released :)

2008/10/14 Gerhard Petracek [EMAIL PROTECTED]

 hello simon,

 sounds good to me.

 regards,
 gerhard



 2008/10/14 Simon Kitching [EMAIL PROTECTED]

 Hi All,

 I think it is a good time to make another Orchestra Core release. There is
 nothing radical in this new version, but there are a couple of nice new
 features and a couple of useful bugfixes. See the release notes for further
 details:

 http://svn.apache.org/repos/asf/myfaces/orchestra/trunk/core/RELEASE-NOTES.txt

 The previous release of core was version 1.2 on 15 Jun 2008.

 Unless there are any objections, I will create a release branch and a
 release candidate in a couple of days time.


 Regards,
 Simon




 --

 http://www.irian.at

 Your JSF powerhouse -
 JSF Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces

[jira] Commented: (TRINIDAD-636) Skinning an icon does not pick up base skin's non-overridden properties

[
https://issues.apache.org/jira/browse/TRINIDAD-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12639528#action_12639528
]

Jeanne Waldman commented on TRINIDAD-636:
-

From my initial investigation, his is a really hard one to fix because the
Icon APIs were not written to do
this. Originally the style selectors were in an .xss file (Oracle's own
css-type file) and the icons were registered separately. The style selectors
are all in the StyleSheetDocument object, whereas only the icons that are
defined in a skin css file are in the StyleSheetDocument (confusing!) and the
other icons are registered on the Skin object directly. The IconNode nor the
Icon APIs
currently have property information. Icons hold 'inlineStyle' information.

The entire Icon framework in the skinning framework would have to be
rewritten, but we probably have to keep the 'registerIcon' API on the Skin
since that is a public API.

One idea:
1. beef up IconNode to hold the properties, and maybe other things like
includes so that -tr-rule-ref will work like it does with styles.
2. figure out when a good time to 'merge' icons together is. For styles, we
do this in FileSystemStyleCache-StyleSheetDocument's resolveStyles. For
icons, we only have the icons that were in the skin css file at this point.
We would have to also get all the icons from the skin and all the base skins
and merge them together and put them into the StyleSheetDocument. Then when
we getIcon, we'll get it from the StyleSheetDocument, and not the Skin, like
we do now.

Skinning an icon does not pick up base skin's non-overridden properties
---

Key: TRINIDAD-636
URL: https://issues.apache.org/jira/browse/TRINIDAD-636
Project: MyFaces Trinidad
Issue Type: Bug
Components: Skinning
Reporter: Jeanne Waldman
Priority: Minor

Skinning an icon does not pick up base skin's non-overridden properties.
Skinning a style does pick up the base skin's non-overridden properties.
This is inconsistent.
Let's say the purple skin has this in it:
af|selectOrderShuttle::reorder-up-icon {
content: url(/skins/purple/images/shuttleOrderUp.png);
width: 16px;
height: 16px;
border: 2px black solid;
}
And the skin writer wants to override the icon. He'd probably do this:
af|selectOrderShuttle::reorder-up-icon {
content: url(/skins/purple/images/prev.png);
}
and the skin writer would expect the width/height/border to be picked up as
they do when you skin styles.
What actually happens, however, that the icon is overridden completely. None
of the base skin's icon's non-overridden attributes are picked up.
The styles and the icons should work consistently. Everyone is familiar with
how you extend styles, so icons should work the same way.
I know this is not a simple task to implement, and it isn't critical to fix,
but it should be tracked.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TRINIDAD-636) Skinning an icon does not pick up base skin's non-overridden properties

[
https://issues.apache.org/jira/browse/TRINIDAD-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12639529#action_12639529
]

Jeanne Waldman commented on TRINIDAD-636:
-

The entire Icon framework in the skinning framework would have to be
rewritten, but we probably have to keep the 'registerIcon' API on the Skin
since that is a public API.

Skinning an icon does not pick up base skin's non-overridden properties
---

Key: TRINIDAD-636
URL: https://issues.apache.org/jira/browse/TRINIDAD-636
Project: MyFaces Trinidad
Issue Type: Bug
Components: Skinning
Reporter: Jeanne Waldman
Priority: Minor

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: JIRA: project entry needed for sandbox

2008-10-14 Thread Volker Weber

Hi,

2008/10/14 Simon Kitching [EMAIL PROTECTED]:
 Any JIRA admins here?

 There currently is no JIRA project defined for the myfaces sandbox. It
 appears that people have simply been using TOMAHAWK to file bugs against.
 But as recent releases has used a jira report as the release notes this is
 causing confusion.

a Myfaces-Commons is also missing.


 Can someone please create it? The name SANDBOX is already taken, so perhaps
 MF-SANDBOX or similar could be used.

Myfaces-(Tomahawk-)Sandbox ?

all other has the Myfaces- prefix.


 Perhaps we should file a jira issue to create the new project? :-)




Regards,
Volker

-- 
inexso - information exchange solutions GmbH
Bismarckstraße 13  | 26122 Oldenburg
Tel.: +49 441 4082 356 |
FAX:  +49 441 4082 355 | www.inexso.de

Re: [orchestra] release orchestra-core version 1.3?

hello simon,

sounds good to me.

regards,
gerhard



2008/10/14 Simon Kitching [EMAIL PROTECTED]

 Hi All,

 I think it is a good time to make another Orchestra Core release. There is
 nothing radical in this new version, but there are a couple of nice new
 features and a couple of useful bugfixes. See the release notes for further
 details:

 http://svn.apache.org/repos/asf/myfaces/orchestra/trunk/core/RELEASE-NOTES.txt

 The previous release of core was version 1.2 on 15 Jun 2008.

 Unless there are any objections, I will create a release branch and a
 release candidate in a couple of days time.


 Regards,
 Simon




-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: JIRA: project entry needed for sandbox

But Sandbox IS a part of Tomahawk and not a single project, so I do
not see the problem here.
Sandbox issues SHOULD be filed using TOMAHAWK and - of course - the
regarding component (SubForm, PPRPanelGroup, ...).

-1 for a new Jira project(!)

--Manfred


On Tue, Oct 14, 2008 at 4:06 PM, Simon Kitching [EMAIL PROTECTED] wrote:
 Any JIRA admins here?

 There currently is no JIRA project defined for the myfaces sandbox. It
 appears that people have simply been using TOMAHAWK to file bugs against.
 But as recent releases has used a jira report as the release notes this is
 causing confusion.

 Can someone please create it? The name SANDBOX is already taken, so perhaps
 MF-SANDBOX or similar could be used.

 Perhaps we should file a jira issue to create the new project? :-)

Re: JIRA: project entry needed for sandbox

2008-10-14 Thread Matthias Wessendorf

On Tue, Oct 14, 2008 at 9:33 PM, Manfred Geiler [EMAIL PROTECTED] wrote:
 But Sandbox IS a part of Tomahawk and not a single project, so I do
 not see the problem here.
 Sandbox issues SHOULD be filed using TOMAHAWK and - of course - the
 regarding component (SubForm, PPRPanelGroup, ...).

 -1 for a new Jira project(!)

for tomahawk, right ?
+1 on that

myfaces-commons is missing.
Not sure if your -1 is also for not adding a commons project


 --Manfred


 On Tue, Oct 14, 2008 at 4:06 PM, Simon Kitching [EMAIL PROTECTED] wrote:
 Any JIRA admins here?

 There currently is no JIRA project defined for the myfaces sandbox. It
 appears that people have simply been using TOMAHAWK to file bugs against.
 But as recent releases has used a jira report as the release notes this is
 causing confusion.

 Can someone please create it? The name SANDBOX is already taken, so perhaps
 MF-SANDBOX or similar could be used.

 Perhaps we should file a jira issue to create the new project? :-)






-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Re: JIRA: project entry needed for sandbox

On Tue, Oct 14, 2008 at 5:35 PM, Volker Weber [EMAIL PROTECTED] wrote:
 Hi,

 2008/10/14 Simon Kitching [EMAIL PROTECTED]:
 Any JIRA admins here?

 There currently is no JIRA project defined for the myfaces sandbox. It
 appears that people have simply been using TOMAHAWK to file bugs against.
 But as recent releases has used a jira report as the release notes this is
 causing confusion.

 a Myfaces-Commons is also missing.

Other than Tomahawk Sandbox the MyFaces Commons is a standalone
project under the MyFaces umbrella. So a Jira project makes sense
here.
This also demands a project site under
http://myfaces.apache.org/commons; and a Commons logo of course. Any
volunteers?  ;-)

If everyone is ok with it, I will create the Jira project for MyFaces
Commons with the Jira-ID MFCOMMONS.

--Manfred

Re: JIRA: project entry needed for sandbox

On Tue, Oct 14, 2008 at 9:40 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 On Tue, Oct 14, 2008 at 9:33 PM, Manfred Geiler [EMAIL PROTECTED] wrote:
 But Sandbox IS a part of Tomahawk and not a single project, so I do
 not see the problem here.
 Sandbox issues SHOULD be filed using TOMAHAWK and - of course - the
 regarding component (SubForm, PPRPanelGroup, ...).

 -1 for a new Jira project(!)

 for tomahawk, right ?
 +1 on that

you mean +1 for my -1 ?
Wow!
:-)

That's like:
   I am against being in favor
or:
   I am in favor of being against

Which is actually the same. Is it? Hmm. Very philosophical... :-)

--Manfred

Re: ExporterActionListener to commons

2008-10-14 Thread Volker Weber

Hi,

2008/10/14 Hazem Saleh [EMAIL PROTECTED]:
 I think that If commons should include components, then these components
 should be independent + have no UI.

+1 for those myfaces-commons-components


Regards,
Volker


 On Tue, Oct 14, 2008 at 4:35 PM, Gerhard Petracek
 [EMAIL PROTECTED] wrote:

 hello,

 i suggest to talk about the right place for new (and independent)
 components in general.

 regards,
 gerhard



 2008/10/14 Hazem Saleh [EMAIL PROTECTED]

 Hello Team,

 I had previous old discussions with Volker about the future of the
 ExporterActionListener.

 And we agreed on moving this component to the MyFaces commons project.

 But after a discussion with Leonardo I know that commons does not include
 any components module?

 Now the two possible ways are:

 1. Promoting the component to Tomahawk.
 2. Making a new components module in commons and promote the component to
 it.

 I need your suggestions regarding that!

 Thanks all!

 --
 Hazem Ahmed Saleh Ahmed

 Author of (The Definitive Guide to Apache MyFaces and Facelets):

 http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370

 Web blog: http://www.jroller.com/page/HazemBlog

 [Web 2.0] Google Maps Integration with JSF:
 http://code.google.com/p/gmaps4jsf/



 --

 http://www.irian.at

 Your JSF powerhouse -
 JSF Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces



 --
 Hazem Ahmed Saleh Ahmed

 Author of (The Definitive Guide to Apache MyFaces and Facelets):
 http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370

 Web blog: http://www.jroller.com/page/HazemBlog

 [Web 2.0] Google Maps Integration with JSF:
 http://code.google.com/p/gmaps4jsf/




-- 
inexso - information exchange solutions GmbH
Bismarckstraße 13  | 26122 Oldenburg
Tel.: +49 441 4082 356 |
FAX:  +49 441 4082 355 | www.inexso.de

[jira] Created: (TRINIDAD-1258) GenericEntry allows invalid locale parameter - XSS vulnerability in LocaleInfoScriptlet

2008-10-14 Thread Yee-Wah Lee (JIRA)

GenericEntry allows invalid locale parameter - XSS vulnerability in 
LocaleInfoScriptlet
---

 Key: TRINIDAD-1258
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1258
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.2.9-core
Reporter: Yee-Wah Lee
Priority: Minor


1. Run the inputDate demo
http://www.irian.at/trinidad-demo/faces/components/inputDate.jspx

2. Open the inputDate popup and copy its URL using right click/Properties 
http://www.irian.at/trinidad-demo/faces/__ADFv__?_t=fred_red=cdvalue=122402520loc=enenc=utf-8

3. Modify the URL to replace the loc parameter value with 
scriptalert(document.cookie)/script
http://www.irian.at/trinidad-demo/faces/__ADFv__?_t=fred_red=cdvalue=122402520loc=en%3Cscript%3Ealert%28document.cookie%29%3C/script%3Eenc=utf-8

4. Load the modified URL in the browser - an alert popup appears. 


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: JIRA: project entry needed for sandbox

2008-10-14 Thread Matthias Wessendorf

On Tue, Oct 14, 2008 at 9:52 PM, Manfred Geiler
[EMAIL PROTECTED] wrote:
 On Tue, Oct 14, 2008 at 9:40 PM, Matthias Wessendorf [EMAIL PROTECTED] 
 wrote:
 On Tue, Oct 14, 2008 at 9:33 PM, Manfred Geiler [EMAIL PROTECTED] wrote:
 But Sandbox IS a part of Tomahawk and not a single project, so I do
 not see the problem here.
 Sandbox issues SHOULD be filed using TOMAHAWK and - of course - the
 regarding component (SubForm, PPRPanelGroup, ...).

 -1 for a new Jira project(!)

 for tomahawk, right ?
 +1 on that

 you mean +1 for my -1 ?
 Wow!
 :-)

 That's like:
   I am against being in favor
 or:
   I am in favor of being against

 Which is actually the same. Is it? Hmm. Very philosophical... :-)

I was just supporting your -1 :-)
Now we are nominated for the philosophic nobel price...   ? :-)


 --Manfred




-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Re: JIRA: project entry needed for sandbox

 This also demands a project site under
 http://myfaces.apache.org/commons; and a Commons logo of course. Any
 volunteers?  ;-)

Just saw that there IS already a site under http://myfaces.apache.org/commons/
Cool!
What's just missing is the menu entry on the main MyFaces page.

--Manfred

[jira] Commented: (TRINIDAD-17) Need to support mapping icons via -tr-rule-ref like we do with styles.


[ 
https://issues.apache.org/jira/browse/TRINIDAD-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12639583#action_12639583
 ] 

Jeanne Waldman commented on TRINIDAD-17:


make sure to update the skinning.xml file when this is fixed, since the 
documentation now mentions this limitation.
Also, this issue is related to  TRINIDAD-636 if we fix 636, we can probably 
pretty easily fix this one after.

 Need to support mapping icons via -tr-rule-ref like we do with styles.
 --

 Key: TRINIDAD-17
 URL: https://issues.apache.org/jira/browse/TRINIDAD-17
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Skinning
Affects Versions: 1.2.1-core
 Environment: Windows.
Reporter: Bill Baggett

 Trinidad skinning supports mapping styles in a css file via the -tr-rule-ref. 
  But, it doesn't support mapping icons this way.  We need to support this.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TRINIDAD-636) Skinning an icon does not pick up base skin's non-overridden properties

[
https://issues.apache.org/jira/browse/TRINIDAD-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12639584#action_12639584
]

Jeanne Waldman commented on TRINIDAD-636:
-

make sure to update the skinning.xml file when this is fixed, since the
documentation now mentions this limitation.
Also, this issue is related to TRINIDAD-17. We can probably more easily fix 17
after this issue is fixed.

Skinning an icon does not pick up base skin's non-overridden properties
---

Key: TRINIDAD-636
URL: https://issues.apache.org/jira/browse/TRINIDAD-636
Project: MyFaces Trinidad
Issue Type: Bug
Components: Skinning
Reporter: Jeanne Waldman
Priority: Minor

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: JIRA: project entry needed for sandbox

+1

2008/10/14 Manfred Geiler [EMAIL PROTECTED]

 On Tue, Oct 14, 2008 at 5:35 PM, Volker Weber [EMAIL PROTECTED] wrote:
  Hi,
 
  2008/10/14 Simon Kitching [EMAIL PROTECTED]:
  Any JIRA admins here?
 
  There currently is no JIRA project defined for the myfaces sandbox. It
  appears that people have simply been using TOMAHAWK to file bugs
 against.
  But as recent releases has used a jira report as the release notes
 this is
  causing confusion.
 
  a Myfaces-Commons is also missing.

 Other than Tomahawk Sandbox the MyFaces Commons is a standalone
 project under the MyFaces umbrella. So a Jira project makes sense
 here.
 This also demands a project site under
 http://myfaces.apache.org/commons; and a Commons logo of course. Any
 volunteers?  ;-)

 If everyone is ok with it, I will create the Jira project for MyFaces
 Commons with the Jira-ID MFCOMMONS.

 --Manfred




-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

[jira] Created: (TRINIDAD-1259) Using dialogs with useWindow=true causes page to display hour glass

2008-10-14 Thread Rupesh dhakal (JIRA)

Using dialogs with useWindow=true causes page to display hour glass
---

 Key: TRINIDAD-1259
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1259
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 1.0.9-core,  1.0.8-core
 Environment: Windows XP/ Fedora release 7/ IE 7
Reporter: Rupesh dhakal


In my application, I open a dialog box with a commandLink tag with useWindow 
attribute set to true. No validations are involved. When the new dialog is 
closed, clicking on any non-clickable area in the parent window causes the 
browser to display an hour glass and becomes unresponsive to clicks. Once a 
mouse click is performed outside the parent browser window, things get back to 
normal. Firefox does not display similar issue because firefox does not display 
the modal behavior.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [ExtVal] internationalized message bundles

2008-10-14 Thread Simon Lessard

Hi all,

Are we using MessageFormat to add the dynamic variables to the messages or
another class? If the former, then all languages needs to escape ' with '' .


Regards,

~ Simon

On Mon, Oct 13, 2008 at 3:29 PM, Simon Lessard [EMAIL PROTECTED]wrote:

 That's true, I somehow mistook champ for an invariant like cours. Anyway,
 I'll commit them tomorrow.


 Regards,

 ~ Simon


 On Mon, Oct 13, 2008 at 4:30 AM, Marc Schneider 
 [EMAIL PROTECTED] wrote:

 Hi Gilles,

 I see an issue, which is a typo one.
 When there is only ONE field, there is no 's' at the end.

 For example :
 Ce champ (and NOT : Ce champs).

 All files are concerned.

 Marc.

 Gilles Demarty a écrit :
  Le fichier corrigé est en attachement
 
 
 
  On Fri, Oct 10, 2008 at 8:16 PM, Simon Lessard
  [EMAIL PROTECTED] wrote:
  Hi Gilles,
 
  HTML entity for 'é' is eacute, not ecute, so
 
  // crossval-message-bundle-validation_messages.properties
  duplicated_content_required=les champs sont diffeacute;rents
  duplicated_content_required_details=les champs sont diffeacute;rents
 
  duplicated_content_denied=les champs doivent ecirc;tre
 diffeacute;rents
  duplicated_content_denied_details=les champs doivent ecirc;tre
  diffeacute;rents
 
  wrong_date_not_before=La date doit ecirc;tre apregrave;s {0}
  wrong_date_not_before_details=La date doit ecirc;tre apregrave;s {0}
 
  wrong_date_not_equal=La date n'est pas eacute;gale agrave; {0}
  wrong_date_not_equal_details=La date n'est pas eacute;gale agrave;
 {0}
 
  // baseval-message-bundle-validation_messages.properties
  Nothing
 
  // baseval-message-bundle-jpa_messages_fr.properties
  One message contains a è
  field_too_long_details=Le contenu de ce champs est trop long ({0}
  caractegrave;res au maximum)
 
 
  I don't see any other issues.
 
 
  Regards,
 
  ~ Simon
 
  On Fri, Oct 10, 2008 at 2:01 PM, Gilles Demarty 
 [EMAIL PROTECTED]
  wrote:
  Here are the french versions. Simon, can you do a double-check ?
 
 
  On Fri, Oct 10, 2008 at 1:54 PM, Hazem Saleh [EMAIL PROTECTED]
 wrote:
  I did the Arabic translation, and Turkish translation done thanks to
  Mert.
 
  On Fri, Oct 10, 2008 at 12:51 PM, Glauco P. Gomes
  [EMAIL PROTECTED] wrote:
  Gerhard Petracek escreveu:
  what's your suggestion for the replacement of wrong?
  (the annotation is responsible to compare if one date value is
  before/after a second one)
  +1 to invalid
 
  Glauco P. Gomes
 
 
  --
  Hazem Ahmed Saleh Ahmed
 
  Author of (The Definitive Guide to Apache MyFaces and Facelets):
 
 
 http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370
 
  Web blog: http://www.jroller.com/page/HazemBlog
 
  [Web 2.0] Google Maps Integration with JSF:
  http://code.google.com/p/gmaps4jsf/

[jira] Commented: (TRINIDAD-1257) [Trinidad] tr:inputFile simple=true still shows error message and label

2008-10-14 Thread JIRA


[ 
https://issues.apache.org/jira/browse/TRINIDAD-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12639404#action_12639404
 ] 

Matthias Weßendorf commented on TRINIDAD-1257:
--

can you upload a screenshot ?
I only see the a name=_msgAnc_input/, in the rendered markup
However, that is *present* for something like:

  tr:inputText simple=true required=true id=input/

as well

 [Trinidad] tr:inputFile simple=true still shows error message and label
 -

 Key: TRINIDAD-1257
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1257
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 1.2.9-core, 1.2.10-core, 1.2.10-sandbox
 Environment: Java 1.6.0_04, Windows XP Pro Service Pack 2
Reporter: James Barrow

 Hi,
 I am using Trinidad 1.2.9 and 1.2.10-SNAPSHOT, but in both versions it
 seems that, as in the below example, an inputFile with simple=true
 still renders the Trinidad error icon next to the component (I'm
 uploading a file that is too large), and also leaves out the links
 style of 'AFErrorIconStyle'. I want to only use the FacesContext error
 message that is generated (in 1.2.10) that notifies a user that the
 upload file was too large, and don't want to display any Trinidad
 errors next to the actual component, but it seems to be generating the
 error icon still.
 =
 Example:
 tr:inputFile id=inputFileID simple=true
 valueChangeListener=#{mybean.uploadMethod}/
 will generate:
 a name=_msgAnc_j_id21:inputFileID/
   span class=af_inputFile
   input id=j_id21:inputFileID class=af_inputFile_content
 type=file name=j_id21:inputFileID/
 /span
 -
 tr:inputFile id=inputFileID simple=false
 valueChangeListener=#{mybean.uploadMethod}/
 generates:
 table id=j_id21:inputFileID__xc_ class=af_inputFile
 cellspacing=0 cellpadding=0 border=0 summary=
   tbody
 tr
   td class=af_inputFile_label nowrap=
 span id=j_id21:inputFileID::icon
 a class=AFErrorIconStyle title=Error
 name=_msgAnc_j_id21:inputFileIDX/a
 /span
   /td
   td class=AFContentCell nowrap= valign=top
 input id=j_id21:inputFileID class=af_inputFile_content
 type=file name=j_id21:inputFileID/
   /td
 /tr
 tr
   td/
   td class=AFComponentMessageCell
 span id=j_id21:inputFileID::msg
 class=OraInlineErrorTextThe file could not be uploaded because it
 is too large./span
   /td
 /tr
   /tbody
 /table
 =
 And I really don't want that table being generated, rather just a nice
 simple input. Is the generating of the link a bug? Or is this how
 simple=true is intended to work... and if so, why does it not
 generate the style? Then I could just use the below to solve my
 problem of seeing the icon.
 .AFErrorIconStyle {
   display: none;
 }
 Regards,
 James Barrow 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TRINIDAD-1257) [Trinidad] tr:inputFile simple=true still shows error message and label

2008-10-14 Thread James Barrow (JIRA)

[Trinidad] tr:inputFile simple=true still shows error message and label
-

 Key: TRINIDAD-1257
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1257
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 1.2.9-core, 1.2.10-core, 1.2.10-sandbox
 Environment: Java 1.6.0_04, Windows XP Pro Service Pack 2
Reporter: James Barrow


Hi,

I am using Trinidad 1.2.9 and 1.2.10-SNAPSHOT, but in both versions it
seems that, as in the below example, an inputFile with simple=true
still renders the Trinidad error icon next to the component (I'm
uploading a file that is too large), and also leaves out the links
style of 'AFErrorIconStyle'. I want to only use the FacesContext error
message that is generated (in 1.2.10) that notifies a user that the
upload file was too large, and don't want to display any Trinidad
errors next to the actual component, but it seems to be generating the
error icon still.

=

Example:

tr:inputFile id=inputFileID simple=true
valueChangeListener=#{mybean.uploadMethod}/

will generate:

a name=_msgAnc_j_id21:inputFileID/
  span class=af_inputFile
  input id=j_id21:inputFileID class=af_inputFile_content
type=file name=j_id21:inputFileID/
/span

-

tr:inputFile id=inputFileID simple=false
valueChangeListener=#{mybean.uploadMethod}/

generates:

table id=j_id21:inputFileID__xc_ class=af_inputFile
cellspacing=0 cellpadding=0 border=0 summary=
  tbody
tr
  td class=af_inputFile_label nowrap=
span id=j_id21:inputFileID::icon
a class=AFErrorIconStyle title=Error
name=_msgAnc_j_id21:inputFileIDX/a
/span
  /td
  td class=AFContentCell nowrap= valign=top
input id=j_id21:inputFileID class=af_inputFile_content
type=file name=j_id21:inputFileID/
  /td
/tr
tr
  td/
  td class=AFComponentMessageCell
span id=j_id21:inputFileID::msg
class=OraInlineErrorTextThe file could not be uploaded because it
is too large./span
  /td
/tr
  /tbody
/table

=

And I really don't want that table being generated, rather just a nice
simple input. Is the generating of the link a bug? Or is this how
simple=true is intended to work... and if so, why does it not
generate the style? Then I could just use the below to solve my
problem of seeing the icon.

.AFErrorIconStyle {
  display: none;
}

Regards,

James Barrow 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TRINIDAD-1260) Allow

2008-10-14 Thread Blake Sullivan (JIRA)

Allow
-

 Key: TRINIDAD-1260
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1260
 Project: MyFaces Trinidad
  Issue Type: Improvement
Affects Versions: 1.2.9-core, 1.2.10-core
 Environment: All
Reporter: Blake Sullivan
 Attachments: JIRA_1260_1291.patch

AttributeComponentChange should support setting ValueExpressions and 
ValueBindings as well as attribute values.  When a ValueExpression or 
ValueBinding is set, the attribute with that name should be removed so that the 
ValueExpression or ValueBinding can take precedence.

In addition, the AttributeComponentChange constructor should check that the 
attributeValue is Serializable so that Serialization problems are detected 
earlier.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TRINIDAD-1261) remove UIXCookie as the values are no longer used

2008-10-14 Thread Gabrielle Crawford (JIRA)

remove UIXCookie as the values are no longer used
-

 Key: TRINIDAD-1261
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1261
 Project: MyFaces Trinidad
  Issue Type: Bug
Reporter: Gabrielle Crawford


UIXCookie seems to be dead code that should be removed.

UIXCookie is supposed to supports the following state:

* The accessibility mode chosen by the user
* The TimeZone of the user


As far as I can tell, the info on the cookie for the tz and accessibility mode 
are never used.

TimeZone

* Server: UIXCookie.setTimeZone, the only way to assign
   the UIXCookie tz, is never called on the server.
* Client: There is a script written to the client in
   HeadRenderer, which on the client writes tz info
   into the uixcookie. However this value is never used
   on either the client or server. It used to be used on
   the server in RequestContextImpl.getTimeZone, but that
   code has been commented out long ago.
* Conclusion: We're needlessly writing out a cookie script
   when the value set on the client is never used.


Accessibility Mode

* Server: UIXCookie.setAccessibilityMode, the only way to
   assign the UIXCookie accessibility mode, is never called
* Client: I see no references on the client to the
   accessibility mode cookie value.
* Conclusion: I don't see how the mode could be set on
   the cookie. Andy Schwartz, who has worked extensively on 
   accessibility issues, thinks this is old code that is no
   longer in use.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

TRINIDAD-1261 remove UIXCookie as the values are no longer used

2008-10-14 Thread Gabrielle Crawford


Hi,

As far as I can tell, the UIXCookie tz and accessibility mode values are 
either never set, or if set, never used. I believe both were used in the 
past but have become obsolete. I'm therefore planning to remove UIXCookie.


Let me know if there are objections.

Thanks,

Gabrielle

Gabrielle Crawford (JIRA) wrote:

remove UIXCookie as the values are no longer used
-

 Key: TRINIDAD-1261
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1261
 Project: MyFaces Trinidad
  Issue Type: Bug
Reporter: Gabrielle Crawford


UIXCookie seems to be dead code that should be removed.

UIXCookie is supposed to supports the following state:

* The accessibility mode chosen by the user
* The TimeZone of the user


As far as I can tell, the info on the cookie for the tz and accessibility mode 
are never used.

TimeZone

* Server: UIXCookie.setTimeZone, the only way to assign
   the UIXCookie tz, is never called on the server.
* Client: There is a script written to the client in
   HeadRenderer, which on the client writes tz info
   into the uixcookie. However this value is never used
   on either the client or server. It used to be used on
   the server in RequestContextImpl.getTimeZone, but that
   code has been commented out long ago.
* Conclusion: We're needlessly writing out a cookie script
   when the value set on the client is never used.


Accessibility Mode

* Server: UIXCookie.setAccessibilityMode, the only way to
   assign the UIXCookie accessibility mode, is never called
* Client: I see no references on the client to the
   accessibility mode cookie value.
* Conclusion: I don't see how the mode could be set on
   the cookie. Andy Schwartz, who has worked extensively on 
   accessibility issues, thinks this is old code that is no

   longer in use.

Re: JIRA: project entry needed for sandbox

2008-10-14 Thread Leonardo Uribe

On Tue, Oct 14, 2008 at 3:26 PM, Manfred Geiler [EMAIL PROTECTED] wrote:

  This also demands a project site under
  http://myfaces.apache.org/commons; and a Commons logo of course. Any
  volunteers?  ;-)

 Just saw that there IS already a site under
 http://myfaces.apache.org/commons/
 Cool!
 What's just missing is the menu entry on the main MyFaces page.


There is a link to commons in:

http://myfaces.apache.org/otherProjects.html

so you can reach it from home page - others - myfaces commons.

+1 for a separate JIRA for myfaces commons.

regards

Leonardo Uribe


 --Manfred

[jira] Commented: (MYFACES-2011) Javascript error on links after clicking a popup/download link


[ 
https://issues.apache.org/jira/browse/MYFACES-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12639642#action_12639642
 ] 

Leonardo Uribe commented on MYFACES-2011:
-

Very strange issue (I spent a lot of time checking code to figure it out what's 
happening).

It does not happen with the following combinations:

myfaces 1.1.x and tomahawk 1.1.7
myfaces 1.2.4 and tomahawk12-1.1.7

but the combination myfaces 1.2.4 and tomahawk 1.1.7 causes the problem.

On myfaces 1.1.x when you use code like this:

h:commandLink value=Sample 1 action=go_sample1
f:param name=param1 value=somevalue1/
/h:commandLink

The tag h:form adds the the param as a hidden field like this:

input type=hidden name=param1 /

In 1.1.x (inclusive tomahawk for 1.1 or tomahawk-1.1.7.jar), the input hidden 
fields are not added and removed from dom tree, instead the javascript function 
clearFormHiddenParams is used to clear the values.

In 1.2.x (inclusive tomahawk for 1.2 or tomahawk12-1.1.7.jar) the input hidden 
fields are added and removed from the tree. The reason to change it from 
previous behavior was enhance compatibility of myfaces core with trinidad 
(tr:form does not render hidden fields like h:form). This solution has other 
nasty problems with IE but everything was solved. The only exception of this 
rule is jscook_action hidden field (no special reason, and maybe changes in the 
future).

The solution is use tomahawk12 when you are using myfaces core 1.2.x. but maybe 
add some code on clearFormHiddenParams to check if the param exists or not does 
not harm. Something like this to check if the hidden field exists:

function clearFormHiddenParams_j_id_id20() {
  var f = document.forms['j_id_id20'];
  var elem0 = f.elements['param1'];
  if(typeof elem0 !='undefined'  elem0.nodeName=='INPUT'){
if (elem0.value != '') {
  elem0.value='';
}
  }

If no objections, I'll add this code to clearFormHiddenParams generation (on 
shared 3.0.x). 


 Javascript error on links after clicking a popup/download link
 --

 Key: MYFACES-2011
 URL: https://issues.apache.org/jira/browse/MYFACES-2011
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 1.2.4
 Environment: MyFaces 1.2.4 IE7
Reporter: Daniel Campagnoli
 Fix For: 1.2.5-SNAPSHOT


 We have just upgraded from 1.1.6 to 1.2.4 and come across an issue that looks 
 similar to MYFACES-1804 in effect but looks to have a slightly different 
 cause.
 The issue occurs when you first click on a download/popup link and then go to 
 click another link on the same page.  
 This calls oamSubmitForm which at the end calls oamClearHiddenInput which 
 removes the hidden field from the dom.
 Now when you go and click on another link on the original page it calls 
 oamSubmitForm.  This first calls clearFormHiddenParams_formname which tries 
 to get the hidden field and set the value to empty, but because it has 
 already been removed from the dom the field null and an exception occurs.
 My workaround was to override oamSetHiddenInput and oamClearHiddenInput to 
 instead of removing/adding the hidden field from the dom, was to (dis)enabled 
 it instead.  Alternatively clearFormHiddenParams_form could check to see if 
 the hidden field exists before trying to set the value on it.
 Note this error happens in IE7 and not in Firefox 3

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TOMAHAWK-1354) Tomahawk for JSF 1.2 should be compiled with Java 5 compatibility


[ 
https://issues.apache.org/jira/browse/TOMAHAWK-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12639654#action_12639654
 ] 

Leonardo Uribe commented on TOMAHAWK-1354:
--

on tomahawk 1.2 pom there is this plugin configuration for compile.

  plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
  source1.5/source
  target1.5/target
/configuration
  /plugin

so the jar available on central maven repo is java 5 compatible (but it was 
built on a machine with jdk 6).

I'll close this issue as invalid.

 Tomahawk for JSF 1.2 should be compiled with Java 5 compatibility
 -

 Key: TOMAHAWK-1354
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1354
 Project: MyFaces Tomahawk
  Issue Type: Improvement
  Components: Build Process (Assembly)
Affects Versions: 1.1.7
 Environment: Java 5, Tomcat 6
Reporter: Rogério Pereira Araújo

 The jar available at central maven repo has been compiled with Java 6 
 compatibility only, is it correct?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TOMAHAWK-1354) Tomahawk for JSF 1.2 should be compiled with Java 5 compatibility


 [ 
https://issues.apache.org/jira/browse/TOMAHAWK-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leonardo Uribe resolved TOMAHAWK-1354.
--

Resolution: Invalid
  Assignee: Leonardo Uribe

 Tomahawk for JSF 1.2 should be compiled with Java 5 compatibility
 -

 Key: TOMAHAWK-1354
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1354
 Project: MyFaces Tomahawk
  Issue Type: Improvement
  Components: Build Process (Assembly)
Affects Versions: 1.1.7
 Environment: Java 5, Tomcat 6
Reporter: Rogério Pereira Araújo
Assignee: Leonardo Uribe

 The jar available at central maven repo has been compiled with Java 6 
 compatibility only, is it correct?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TOMAHAWK-1351) tomahawk12 should have jstl 1.2 provided dependency instead jstl 1.1.0 compile dependency


 [ 
https://issues.apache.org/jira/browse/TOMAHAWK-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leonardo Uribe resolved TOMAHAWK-1351.
--

   Resolution: Fixed
Fix Version/s: 1.1.8-SNAPSHOT

 tomahawk12 should have jstl 1.2 provided dependency instead jstl 1.1.0 
 compile dependency
 -

 Key: TOMAHAWK-1351
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1351
 Project: MyFaces Tomahawk
  Issue Type: Bug
Affects Versions: 1.1.7
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
 Fix For: 1.1.8-SNAPSHOT




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TOMAHAWK-1355) t:message(s) replaceIdWithLabel defaults to false in Tomahawk 1.1.7

2008-10-14 Thread Taro App (JIRA)

t:message(s) replaceIdWithLabel defaults to false in Tomahawk 1.1.7
---

 Key: TOMAHAWK-1355
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1355
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Message(s)
Affects Versions: 1.1.7
Reporter: Taro App


Up until Tomahawk 1.1.6, replaceIdWithLabel defaulted to true for t:message and 
t:messages. In Tomahawk 1.1.7, however, replaceIdWithLabel=true needs to be 
specified explicitly to make this function work, because it defaults to false. 
TLD still says it default to true.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TOMAHAWK-1355) t:message(s) replaceIdWithLabel defaults to false in Tomahawk 1.1.7