date:20060921

 [ http://issues.apache.org/jira/browse/MYFACES-1389?page=all ]

Martin Marinschek resolved MYFACES-1389.


Fix Version/s: 1.1.5-SNAPSHOT
   Resolution: Fixed
 Assignee: Martin Marinschek

Thanks to Nikolay Petrov for clearing this up.

regards,

Martin

 Impossible to escape {, } characters in parameterized messages.
 ---

 Key: MYFACES-1389
 URL: http://issues.apache.org/jira/browse/MYFACES-1389
 Project: MyFaces Core
  Issue Type: Bug
Affects Versions: 1.1.3
Reporter: Guy Bashan
 Assigned To: Martin Marinschek
Priority: Minor
 Fix For: 1.1.5-SNAPSHOT


 It seems like using the {, } characters in messages (in resource bundles) 
 is impossible (Unless it is used for params: {0}, {1} etc'). The 
 FacesUtil.subtituteParams seems to be throwing an exception. I tried escaping 
 the characters by using \{ but it still not working.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Reopened: (MYFACES-1389) Impossible to escape {, } characters in parameterized messages.

 [ http://issues.apache.org/jira/browse/MYFACES-1389?page=all ]

Martin Marinschek reopened MYFACES-1389:


 

 Impossible to escape {, } characters in parameterized messages.
 ---

 Key: MYFACES-1389
 URL: http://issues.apache.org/jira/browse/MYFACES-1389
 Project: MyFaces Core
  Issue Type: Bug
Affects Versions: 1.1.3
Reporter: Guy Bashan
 Assigned To: Martin Marinschek
Priority: Minor

 It seems like using the {, } characters in messages (in resource bundles) 
 is impossible (Unless it is used for params: {0}, {1} etc'). The 
 FacesUtil.subtituteParams seems to be throwing an exception. I tried escaping 
 the characters by using \{ but it still not working.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (MYFACES-1389) Impossible to escape {, } characters in parameterized messages.

 [ http://issues.apache.org/jira/browse/MYFACES-1389?page=all ]

Martin Marinschek resolved MYFACES-1389.


Fix Version/s: (was: 1.1.5-SNAPSHOT)
   Resolution: Invalid

 Impossible to escape {, } characters in parameterized messages.
 ---

 Key: MYFACES-1389
 URL: http://issues.apache.org/jira/browse/MYFACES-1389
 Project: MyFaces Core
  Issue Type: Bug
Affects Versions: 1.1.3
Reporter: Guy Bashan
 Assigned To: Martin Marinschek
Priority: Minor

 It seems like using the {, } characters in messages (in resource bundles) 
 is impossible (Unless it is used for params: {0}, {1} etc'). The 
 FacesUtil.subtituteParams seems to be throwing an exception. I tried escaping 
 the characters by using \{ but it still not working.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

RE: JScookMenu is not rendered with Facelets

2006-09-21 Thread alexeinov




Tom Innes wrote:
 
 
 There is a bug however if you try to override the Stylesheet.
 
 

Thanks for reply, Tom. My problem is that the menu is not rendered at all.
The following line of HTML is all that I get in the rendered page:
!-- Start: javax.faces.Command[_id0] --input id=_id0 name=_id0
type=submit value=

I never come to the point where the stylesheet could be a problem. Anyway, I
applied the fix suggested in
https://issues.apache.org/jira/browse/TOMAHAWK-575 but it does not change
anything.

I tried MyFaces and Tomahawk both 1.1.3 and 1.1.5 snapshot - same result.

There must be something special about Facelets and JSCookMenu that I'm
missing. The tag is described in /WEB-INF/tomahawk.taglib.xml as

tag
tag-namejscookMenu/tag-name
component
component-typeorg.apache.myfaces.JSCookMenu/component-type
/component
/tag

faces-config definse JSCookMenu as
component
component-typeorg.apache.myfaces.JSCookMenu/component-type
component-classorg.apache.myfaces.custom.navmenu.jscookmenu.HtmlCommandJSCookMenu/component-class
/component

Still something is wrong
-- 
View this message in context: 
http://www.nabble.com/JScookMenu-is-not-rendered-with-Facelets-tf2303975.html#a6423955
Sent from the My Faces - Dev mailing list archive at Nabble.com.

Re: JScookMenu is not rendered with Facelets

2006-09-21 Thread Thomas Spiegl

So now we got it. The rederer-type is missing in your
/WEB-INF/tomahawk.taglib.xml

tag
tag-namejscookMenu/tag-name
component
component-typeorg.apache.myfaces.JSCookMenu/component-type
renderer-typeorg.apache.myfaces.JSCookMenu/renderer-type
/component
/tag

-Thomas

On 9/21/06, alexeinov [EMAIL PROTECTED] wrote:

Tom Innes wrote:

There is a bug however if you try to override the Stylesheet.

Thanks for reply, Tom. My problem is that the menu is not rendered at all.
The following line of HTML is all that I get in the rendered page:
!-- Start: javax.faces.Command[_id0] --input id=_id0 name=_id0
type=submit value=

I never come to the point where the stylesheet could be a problem. Anyway, I
applied the fix suggested in
https://issues.apache.org/jira/browse/TOMAHAWK-575 but it does not change
anything.

I tried MyFaces and Tomahawk both 1.1.3 and 1.1.5 snapshot - same result.

There must be something special about Facelets and JSCookMenu that I'm
missing. The tag is described in /WEB-INF/tomahawk.taglib.xml as

tag
tag-namejscookMenu/tag-name
component
component-typeorg.apache.myfaces.JSCookMenu/component-type
/component
/tag

faces-config definse JSCookMenu as
component
component-typeorg.apache.myfaces.JSCookMenu/component-type
component-classorg.apache.myfaces.custom.navmenu.jscookmenu.HtmlCommandJSCookMenu/component-class
/component

Still something is wrong
--
View this message in context:
http://www.nabble.com/JScookMenu-is-not-rendered-with-Facelets-tf2303975.html#a6423955
Sent from the My Faces - Dev mailing list archive at Nabble.com.

--
http://www.irian.at

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

Professional Support for Apache MyFaces

Re: Outcome of the Google Sommer of Code project Partial State Saving

2006-09-21 Thread Martin Haimberger

Hy,

Thanks for your great interrest. Sorry for the delay, but i had a lot of work the last days.

The chosen strategie was to save the
UIViewRoot as a template of the JSP's after executing the first time on the server.
Before the UIViewRoot gets serialized for statesaving, we will diff the saved template UIViewRoot and the
current UIViewRoot and save only the components which have different component states. The other components
are marked to be the same like in the template. In the restoreview Phase these marked components were taken
from the template and a whole UIViewRoot is restored.
As a secound aspect the strings for the component classes are hold at the server and only id's are saved, which also saves about 5-10% of the savestate.

I hope that helps.

regards
Martin Haimberger
On 9/17/06, Adam Winer [EMAIL PROTECTED] wrote:
Martin,Hey, very cool!Have you written up anything describing (a)?I'm very curious about the strategy chosen.
-- AdamOn 9/13/06, Martin Haimberger [EMAIL PROTECTED] wrote: Hy everyone, my name is Martin Haimberger and i took part in the GSoC 2006 with the
Partial State Saving project for myfaces. The two mayor things to implement werea) Create an partial State Saving Treeb) Render the Tree without calling dispatch() and let the jsp render it
I used the tomahowk simple examples to do first performancetests. I activated Clientside statesaving and compaired their length: displayValueOnly
11.450 org.savestate 6.060 partial.save.state Partial Savestate: 52,9% home.jsp
22.754 org.savestate6.316 partial.save.state Partial Savestate: 27,7% masterDetail
13.870 org.savestate 10.300 partial.save.state Partial Savestate: 74,3%selectbox
15.310 org.savestate 10.808 partial.save.state Partial Savestate with ID Map: 70,6%selectonecountry
3.494 org.savestate 1.896 partial.save.state Partial Savestate: 54,3%
tree2NiceWrap 9.902 org.savestate 6.464 partial.save.state Partial Savestate: 65,3%
dynamiclists 5.998 org.savestate 4.760 partial.save.state Partial Savestate with ID Map: 79,3%
The secound test was a speed test how fast the page gets rendered without dispatching to the jsp. The problem is that the response times of the same request fluctuatea lot if it is called a certain times. So measuring is very difficult.
But what i can say is that it is (after the first request) about 20% faster than alway dispatching to the jsp who it was done till now. In the next weeks my Mentor, Martin Marinschek and I will adapt the code and
commit it to the svn server. Regards Martin Haimberger

[jira] Created: (MYFACES-1418) javax.faces.validator - DoubleRangeValidator, LengthValidator, LongRangeValidator are very similar, refactor common behaviour

javax.faces.validator - DoubleRangeValidator, LengthValidator, 
LongRangeValidator are very similar, refactor common behaviour
-

 Key: MYFACES-1418
 URL: http://issues.apache.org/jira/browse/MYFACES-1418
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-127
Affects Versions: 1.1.4
Reporter: Nikolay Petrov
 Fix For: 1.1.5-SNAPSHOT


The 3 classes are very similar to each other except the type of minimum and 
maximum (and value of course). Therefore I'll suggest extracting the common 
behaviour in common parent class. 


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MYFACES-1418) javax.faces.validator - DoubleRangeValidator, LengthValidator, LongRangeValidator are very similar, refactor common behaviour

 [ http://issues.apache.org/jira/browse/MYFACES-1418?page=all ]

Nikolay Petrov updated MYFACES-1418:


Status: Patch Available  (was: Open)

 javax.faces.validator - DoubleRangeValidator, LengthValidator, 
 LongRangeValidator are very similar, refactor common behaviour
 -

 Key: MYFACES-1418
 URL: http://issues.apache.org/jira/browse/MYFACES-1418
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-127
Affects Versions: 1.1.4
Reporter: Nikolay Petrov
 Fix For: 1.1.5-SNAPSHOT

 Attachments: validator.patch


 The 3 classes are very similar to each other except the type of minimum and 
 maximum (and value of course). Therefore I'll suggest extracting the common 
 behaviour in common parent class. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MYFACES-1418) javax.faces.validator - DoubleRangeValidator, LengthValidator, LongRangeValidator are very similar, refactor common behaviour

 [ http://issues.apache.org/jira/browse/MYFACES-1418?page=all ]

Martin Marinschek updated MYFACES-1418:
---

Status: Resolved  (was: Patch Available)
Resolution: Fixed
  Assignee: Martin Marinschek

Thanks to Nikolay Petrov for this fix.

I wonder - should the new base-class be prefixed by an underscore, to really 
make sure that this is not part of the public API? It's already 
package-private, so its ok to add it, but maybe we should have an additional 
indicator here.

regards,

Martin

 javax.faces.validator - DoubleRangeValidator, LengthValidator, 
 LongRangeValidator are very similar, refactor common behaviour
 -

 Key: MYFACES-1418
 URL: http://issues.apache.org/jira/browse/MYFACES-1418
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-127
Affects Versions: 1.1.4
Reporter: Nikolay Petrov
 Assigned To: Martin Marinschek
 Fix For: 1.1.5-SNAPSHOT

 Attachments: validator.patch


 The 3 classes are very similar to each other except the type of minimum and 
 maximum (and value of course). Therefore I'll suggest extracting the common 
 behaviour in common parent class. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (MYFACES-1029) Duplicate sibling ids allowed

 [ http://issues.apache.org/jira/browse/MYFACES-1029?page=all ]

Martin Marinschek resolved MYFACES-1029.


Fix Version/s: 1.1.5-SNAPSHOT
   Resolution: Fixed
 Assignee: Martin Marinschek  (was: Dennis Byrne)

I've taken the freedom to use the exception-throwing alternative. This is 
really something that should never happen, so we'll have no problem with this. 
If the tests complain, we'll change it back and file a test-challenge.

regards,

Martin

 Duplicate sibling ids allowed
 -

 Key: MYFACES-1029
 URL: http://issues.apache.org/jira/browse/MYFACES-1029
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 1.1.2-SNAPSHOT
Reporter: Dennis Byrne
 Assigned To: Martin Marinschek
Priority: Minor
 Fix For: 1.1.5-SNAPSHOT

 Attachments: lower_impact_patch.txt, patch.txt


 MyFaces will let you do this (same ids, renders two trees):
 t:tree id=tree value=#{treeModel}
 styleClass=tree
 nodeClass=treenode
 selectedNodeClass=treenodeSelected
 expandRoot=true
 /t:tree
 h:outputText id=tree value=This text will not be rendered /
 See my comments in http://issues.apache.org/jira/browse/MYFACES-1020 for an 
 explanation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: JScookMenu is not rendered with Facelets

2006-09-21 Thread alexeinov




Thomas Spiegl wrote:
 
 So now we got it. The rederer-type is missing in your
 /WEB-INF/tomahawk.taglib.xml
 

Bingo! It was that. I took taglib from MyFaces Wiki, and the renderer-type
was missing in it for some reason.

Thanks a lot Thomas! 
You saved my day.

/Alexei
-- 
View this message in context: 
http://www.nabble.com/JScookMenu-is-not-rendered-with-Facelets-tf2303975.html#a6426441
Sent from the My Faces - Dev mailing list archive at Nabble.com.

[jira] Created: (TOBAGO-132) javascript error in DatePicker

javascript error in DatePicker
--

 Key: TOBAGO-132
 URL: http://issues.apache.org/jira/browse/TOBAGO-132
 Project: MyFaces Tobago
  Issue Type: Bug
Reporter: Volker Weber
 Assigned To: Volker Weber
 Fix For: 1.0.9




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (TOBAGO-132) javascript error in DatePicker

 [ http://issues.apache.org/jira/browse/TOBAGO-132?page=all ]

Volker Weber resolved TOBAGO-132.
-

Resolution: Fixed

javascript rendering in CalendarRenderer fixed

 javascript error in DatePicker
 --

 Key: TOBAGO-132
 URL: http://issues.apache.org/jira/browse/TOBAGO-132
 Project: MyFaces Tobago
  Issue Type: Bug
Reporter: Volker Weber
 Assigned To: Volker Weber
 Fix For: 1.0.9




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (TOBAGO-133) DatePicker popup renders on wrong z-index

DatePicker popup renders on wrong z-index
-

 Key: TOBAGO-133
 URL: http://issues.apache.org/jira/browse/TOBAGO-133
 Project: MyFaces Tobago
  Issue Type: Bug
Reporter: Volker Weber
 Fix For: 1.0.9


If DatePicker is on a popup than the DatePicker popup is on the same z-index 
level as the originating control.
This could result in a unusable view.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (TOBAGO-134) z-index calculation needed

z-index calculation needed
--

 Key: TOBAGO-134
 URL: http://issues.apache.org/jira/browse/TOBAGO-134
 Project: MyFaces Tobago
  Issue Type: Bug
Reporter: Volker Weber
 Fix For: 1.0.9


We need a z-index calculation strategie.

Currently popups are rendered with z-index = 3, this results in unexpected 
views if nested popups are used. (TOBAGO-133)
menues are rendred at higher levels, they are rendered always infront of all 
popups.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: JScookMenu is not rendered with Facelets


Pleaaaseee put the fix back in the wiki as well.

regards,

Martin

On 9/21/06, alexeinov [EMAIL PROTECTED] wrote:




Thomas Spiegl wrote:

 So now we got it. The rederer-type is missing in your
 /WEB-INF/tomahawk.taglib.xml


Bingo! It was that. I took taglib from MyFaces Wiki, and the renderer-type
was missing in it for some reason.

Thanks a lot Thomas!
You saved my day.

/Alexei
--
View this message in context: 
http://www.nabble.com/JScookMenu-is-not-rendered-with-Facelets-tf2303975.html#a6426441
Sent from the My Faces - Dev mailing list archive at Nabble.com.





--

http://www.irian.at

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

Professional Support for Apache MyFaces

[jira] Created: (MYFACES-1419) javax.faces.convert - refactor common behaviour + DateTimeConverter changes

javax.faces.convert - refactor common behaviour + DateTimeConverter changes
---

 Key: MYFACES-1419
 URL: http://issues.apache.org/jira/browse/MYFACES-1419
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-127
Affects Versions: 1.1.4
Reporter: Nikolay Petrov
Priority: Minor
 Fix For: 1.1.5-SNAPSHOT


All available converters look very similar. Extract the common behavior in base 
class.

Also DateTimeConverter can be migrated to work with type safe enums for style 
and type properties.
There are comments in source like //TODO: validate timeStyle. According to java 
doc of DateTimeConverter on sun there should not have validation. The 
validation of these will be performed when asString/asObject methods are called.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MYFACES-1419) javax.faces.convert - refactor common behaviour + DateTimeConverter changes

 [ http://issues.apache.org/jira/browse/MYFACES-1419?page=all ]

Nikolay Petrov updated MYFACES-1419:


Status: Patch Available  (was: Open)

 javax.faces.convert - refactor common behaviour + DateTimeConverter changes
 ---

 Key: MYFACES-1419
 URL: http://issues.apache.org/jira/browse/MYFACES-1419
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-127
Affects Versions: 1.1.4
Reporter: Nikolay Petrov
Priority: Minor
 Fix For: 1.1.5-SNAPSHOT


 All available converters look very similar. Extract the common behavior in 
 base class.
 Also DateTimeConverter can be migrated to work with type safe enums for style 
 and type properties.
 There are comments in source like //TODO: validate timeStyle. According to 
 java doc of DateTimeConverter on sun there should not have validation. The 
 validation of these will be performed when asString/asObject methods are 
 called.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (TOMAHAWK-682) Editor does not work anymore in Firefox

2006-09-21 Thread Mathias Werlitz (JIRA)

[ 
http://issues.apache.org/jira/browse/TOMAHAWK-682?page=comments#action_12436525 
] 

Mathias Werlitz commented on TOMAHAWK-682:
--

Sorry, my initial assumtion was wrong. It is not a bug in the used kupu lib 
(1.3.5). Just downloaded this version and did a raw test ... and the editor 
works. The error seems to be in the myfaces integration code.

 Editor does not work anymore in Firefox
 ---

 Key: TOMAHAWK-682
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-682
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Html Editor
Affects Versions: 1.1.5-SNAPSHOT
 Environment: WinXP Firefox 1.5.0.7 
Reporter: Mathias Werlitz
Priority: Blocker

 It seems to me that with the update to the latest kupu library there was 
 introduced an JS bug that prevents the editor from working in Firefox 
 (Mozilla) (my version 1.5.0.7). You get an js alert  Couldn't set design 
 mode. Kupu will not work on this browser.
 This error can be produced with the examples.
 With Tomahawk 1.1.1 and (if I remember correctly with 1.1.3) everything works 
 fine.
 Maybe we should downgrade the kupu version until this error is fixed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: JScookMenu is not rendered with Facelets

2006-09-21 Thread alexeinov




Martin Marinschek wrote:
 
 Pleaaaseee put the fix back in the wiki as well.
 

As I discovered now, there already is a fixed version of a taglib there. It
was just very stupid of me not to notice it :(

/Alexei
-- 
View this message in context: 
http://www.nabble.com/JScookMenu-is-not-rendered-with-Facelets-tf2303975.html#a6428171
Sent from the My Faces - Dev mailing list archive at Nabble.com.

[jira] Updated: (MYFACES-1419) javax.faces.convert - refactor common behaviour + DateTimeConverter changes

 [ http://issues.apache.org/jira/browse/MYFACES-1419?page=all ]

Martin Marinschek updated MYFACES-1419:
---

Status: Resolved  (was: Patch Available)
Resolution: Fixed

Thanks to Nikolay Petrov for supplying this patch. 

Same reasoning applies here as with Validators, eventually we should prefix the 
base-class.

regards,

Martin

 javax.faces.convert - refactor common behaviour + DateTimeConverter changes
 ---

 Key: MYFACES-1419
 URL: http://issues.apache.org/jira/browse/MYFACES-1419
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-127
Affects Versions: 1.1.4
Reporter: Nikolay Petrov
 Assigned To: Martin Marinschek
Priority: Minor
 Fix For: 1.1.5-SNAPSHOT

 Attachments: converter.patch


 All available converters look very similar. Extract the common behavior in 
 base class.
 Also DateTimeConverter can be migrated to work with type safe enums for style 
 and type properties.
 There are comments in source like //TODO: validate timeStyle. According to 
 java doc of DateTimeConverter on sun there should not have validation. The 
 validation of these will be performed when asString/asObject methods are 
 called.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[OT] Job offer

2006-09-21 Thread Matthias Wessendorf


Maybe sb on this is interested:


Are you a passionate and creative developer with a desire to apply
your J2EE: JSF, JSP, Web User Interface Skills in a meaningful,
productive way?   If yes, then Oracle is definitely the place for you
right now!
The Application Development Framework View (ADFview) team that builds
the web user interface technology for Oracle's new Fusion Middleware
is seeking several passionate, highly motivated and creative
developers to work on our next-generation rich client interface
architecture based on Java Server Faces and AJAX.
Preferred Skills and Experience
1) BS/MS equivalent in Computer Science or related.
2) Strong communication skills and be able to work in a highly
collaborative and diverse environment.
3) Experience building and maintaining application frameworks/tools.
4) Experience with the J2EE platform including Java, Java Server
Pages, Java Server Faces, servlets, Struts and Enterprise Java beans
5) 4+ years of commercial software experience/3+ year's professional
experience with Java, HTML, CSS, JavaScript.
6) Intimate knowledge of object-oriented JavaScript in multiple browsers.
7) Good notions of graphical and layout design.
8) Solid knowledge of DHTML/CSS in multiple browsers.

Join our team and you will...
1) Design and develop the most advanced Web User Interface Components
on the market.
2) Become an expert in Oracles ADF.
3) Advance your skills to unimaginable heights and pack your resume
with highly sought-after skills and experiences.
4) Become very active in the Open Source community, as we have several
members of the Java Server Faces Expert group on our team, multiple
JSRs and the primary sponsor of the Apache Trinidad Podling Incubator
project.
5) Work for one of the most revered and sophisticated Software
Development companies in the World.
6) Receive a highly competitive compensation structure, a blue ribbon
benefit plans, continuous training and education, career advancements
and work environments in bay area and worldwide, including small,
flexible and collaborative teams.

About ADFview
The new rich client architecture will utilize the latest in DHTML
technologies to build a set of highly interactive and scalable user
interface components to build world class, enterprise applications.
The architecture allows the application developer to build a single
meta-data driven application with multiple rendering technologies and
deployable on multiple platforms and environments.  The new
architecture allows the application developer to build highly
interactive desktop applications for a browser client.  Features
include drag-and-drop, pop up menuing, look and feel customization
(skinning), animation, charting and push channel support for real-time
client data visualization.
How to Apply: Please send your resume to
[EMAIL PROTECTED]  Also, as part of our overall
application process, you must register and submit your resume online
to us through our online system to be considered.  To submit your
candidacy for this opportunity, please take a moment to register for
this position at http://irecruitment.oracle.com   1) Register as a
user 2) Enter  IRC794078  in the Keyword(s) search field.  This will
bring up the listing for the position and 3) Answer a few basic
questions and document your application for this position by attaching
your resume.
Oracle is committed to creating a diverse environment and is proud to
be an equal opportunity employer.

[jira] Commented: (MYFACES-1409) incorrect behavior after RESTORE_VIEW responseComplete

[ 
http://issues.apache.org/jira/browse/MYFACES-1409?page=comments#action_12436541 
] 

Nikolay Petrov commented on MYFACES-1409:
-

After calling listeners in restore view phase(and every other) there is the 
following snippet:
...
if (isResponseComplete(facesContext, executor.getPhase(), false)
|| shouldRenderResponse(facesContext, 
executor.getPhase(), false)) {
// since this phase is completed we don't need to return right 
away even if the response is completed
skipFurtherProcessing = true;
}

if (!skipFurtherProcessing  log.isTraceEnabled()) {
log.trace(exiting  + executor.getPhase() +  in  + 
LifecycleImpl.class.getName());
}

return skipFurtherProcessing;
...
This breaks the phase execution cycle and returns back to the servlet, where 
render of the Lifecycle is executed. And the method starts with:
...
public void render(FacesContext facesContext) throws FacesException {
// if the response is complete we should not be invoking the phase 
listeners
if(isResponseComplete(facesContext, renderExecutor.getPhase(), true)) {
return;
}
...
This means that render response phase is actually not executed. So the next 
thing on request comming through jsf servlet would be restore view phase again. 
Is that correct?

 incorrect behavior after RESTORE_VIEW responseComplete
 --

 Key: MYFACES-1409
 URL: http://issues.apache.org/jira/browse/MYFACES-1409
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 1.1.5-SNAPSHOT
 Environment: Windows XP, apache-tomcat-5.5.17
Reporter: Leonid Mikhailov
 Fix For: 1.1.5-SNAPSHOT


 The following behavior appears to be incorrect in myfaces implementation of 
 JSF. 
 After FacesContext.responseComplete is issued in the afterPhase method of  
 the PhaseListener at the RESTORE_VIEW phase, myfaces implementation skips to  
 RENDER_RESPONSE phase. This appears to be incorrect, as following a call to  
 FacesContext.responseComplete JSF implementation should exit JSF lifecycle  
 completely, i.e. the next phase of the lifecycle should be again  
 RESTORE_VIEW. 
  
 This problem can be observed when running Sun's Progress Bar with JSF and  
 AJAX Sample with myfaces libraries on Tomcat. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (TOBAGO-135) Changed MyFaces Core dependency to provided

2006-09-21 Thread Bernd Bohmann (JIRA)

Changed MyFaces Core dependency to provided
---

 Key: TOBAGO-135
 URL: http://issues.apache.org/jira/browse/TOBAGO-135
 Project: MyFaces Tobago
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.0.7
Reporter: Bernd Bohmann
 Assigned To: Bernd Bohmann
Priority: Minor
 Fix For: 1.0.8


You have to add the dependency to your desired JSF Implementation in your 
project. Some container already provided a own JSF Implementation (Websphere).


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (TOBAGO-135) Changed MyFaces Core dependency to provided

2006-09-21 Thread Bernd Bohmann (JIRA)

 [ http://issues.apache.org/jira/browse/TOBAGO-135?page=all ]

Bernd Bohmann resolved TOBAGO-135.
--

Resolution: Fixed

 Changed MyFaces Core dependency to provided
 ---

 Key: TOBAGO-135
 URL: http://issues.apache.org/jira/browse/TOBAGO-135
 Project: MyFaces Tobago
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.0.7
Reporter: Bernd Bohmann
 Assigned To: Bernd Bohmann
Priority: Minor
 Fix For: 1.0.8


 You have to add the dependency to your desired JSF Implementation in your 
 project. Some container already provided a own JSF Implementation (Websphere).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MYFACES-1416) MyFaces doesnt work with Tomcat 5.0.28 and 5.5

2006-09-21 Thread bansi (JIRA)

[ 
http://issues.apache.org/jira/browse/MYFACES-1416?page=comments#action_12436573 
] 

bansi commented on MYFACES-1416:


Hi Martin
Thanks for quick response. I will definately give a try with new release . Pl 
let me know where i can get the download version. Also i would really 
appreciate if someone helps me in fixing the reported issue

Regards
Bansi


 MyFaces doesnt work with Tomcat 5.0.28 and 5.5
 --

 Key: MYFACES-1416
 URL: http://issues.apache.org/jira/browse/MYFACES-1416
 Project: MyFaces Core
  Issue Type: Bug
  Components: website
Affects Versions: 1.0.9m9, 1.1.1
 Environment: Tomcat 5.0.28 and 5.5
Reporter: bansi

  I have experiencing a wierd problem with MyFaces while deploying it to 
 Tomcat Application Server
 -Deploying the web application for the first time works using MyFaces 1.1.1 
 or MyFaces 1.0.9 onto Tomcat 5.0.28 or 5.5
 - When i Undeploy the application using Tomcat Manager Console the problem 
 starts
  1)   it doesnt removes the application completely from the webapps directory 
 of Tomcat. The left over folder will be WEB-INF/lib/myfaces*.jar files
  2) when i try to physically delete this folder it pops up with a Alert 
 saying myfaces.jar is used by another person or program whereas the fact is 
 no other program is deployed onto Tomcat or i see no references of it. Anyhow 
 Undeploy from Tomcat should completly remove the web application without 
 leaving a foot print of   WEB-INF/lib/myfaces*.jar  folder saying its 
 referenced by other program
 3) So finally i stop the Tomcat application server. Now i am in a position to 
 physically delete the web application under webapps directory i.e. 
 WEB-INF/lib/myfaces*.jar 
 4) Now onwards subsequent  fresh deployments of web application will not go 
 thru and give following error message
 Sep 20, 2006 5:18:18 PM org.apache.catalina.startup.HostConfig deployWAR
 INFO: Deploying web application archive TestFaces.war
 log4j:WARN No appenders could be found for logger 
 (org.apache.commons.digester.Digester.sax).
 log4j:WARN Please initialize the log4j system properly.
 Sep 20, 2006 5:18:22 PM org.apache.catalina.core.StandardContext start
 SEVERE: Error listenerStart
 Sep 20, 2006 5:18:22 PM org.apache.catalina.core.StandardContext start
 SEVERE: Context [/TestFaces] startup failed due to previous errors
 5) So i look at the webapp folder quite amazingly the application got 
 deployed successfully with all the jar files etc i mean the packaging is 
 perfect but the tomcat console shows the error and also the application doest 
 show up on Tomcat Manager Console
 6) Also i figured out the application automatically got undeployed by 
 refreshing the tomcat console from the following message  webapp folder
 Sep 20, 2006 5:20:17 PM org.apache.catalina.core.ApplicationContext log
 INFO: HTMLManager: undeploy: Undeploying web application at '/TestFaces'
 Sep 20, 2006 5:20:17 PM org.apache.catalina.core.StandardContext stop
 INFO: Container 
 org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/TestFaces] 
 has not been started
 Sep 20, 2006 5:20:17 PM org.apache.catalina.startup.HostConfig checkResources
 INFO: Undeploying context [/TestFaces]
 Sep 20, 2006 5:20:17 PM org.apache.catalina.core.ApplicationContext log
 INFO: HTMLManager: list: Listing contexts for virtual host 'localhost'
 Sep 20, 2006 5:20:20 PM org.apache.catalina.core.ApplicationContext log
 INFO: HTMLManager: undeploy: Undeploying web application at '/TestFaces'
 Sep 20, 2006 5:20:20 PM org.apache.catalina.core.ApplicationContext log
 INFO: HTMLManager: list: Listing contexts for virtual host 'localhost'
 Sep 20, 2006 5:20:23 PM org.apache.catalina.core.ApplicationContext log
 INFO: HTMLManager: undeploy: Undeploying web application at '/TestFaces'
 Sep 20, 2006 5:20:23 PM org.apache.catalina.startup.HostConfig checkResources
 INFO: Undeploying context [/TestFaces]
 Sep 20, 2006 5:20:23 PM org.apache.catalina.core.ApplicationContext log
 INFO: HTMLManager: list: Listing contexts for virtual host 'localhost'
 Sep 20, 2006 5:20:24 PM org.apache.catalina.core.ApplicationContext log
 INFO: HTMLManager: undeploy: Undeploying web application at '/TestFaces'
 Sep 20, 2006 5:20:24 PM org.apache.catalina.core.ApplicationContext log
 INFO: HTMLManager: list: Listing contexts for virtual host 'localhost'
 Sep 20, 2006 5:20:33 PM org.apache.catalina.core.ApplicationContext log
 INFO: HTMLManager: list: Listing contexts for virtual host 'localhost'
 Any pointers/suggestion to [EMAIL PROTECTED] will be highly appreciated
 Regards
 Bansi

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [continuum] BUILD ERROR: Apache Incubator Trinidad Podling

2006-09-21 Thread Wendy Smoak


On 9/21/06, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:

Online report :

Build Error:

Provider message: The svn command failed.
Command output:
---
svn: Working copy '.' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
Type 'svn help' for usage.
---


I added a Troubleshooting section and this 'problem' to the wiki.  Is
this one that resolves on its own, or do we need to run svn cleanup?
If so, where is the working copy?

  http://wiki.apache.org/myfaces/Continuum_Build

--
Wendy

Re: [continuum] BUILD ERROR: Apache Incubator Trinidad Podling

2006-09-21 Thread Bernd Bohmann


Hello,

in /usr/local/continuum/apps/continuum/working-directory/projectId

you will find the working directory

the projectId for  Apache Incubator Trinidad Podling is 146.

Already invoke svn cleanup on this dir :-)

Bernd



Grant Smith wrote:

As far as I know, the working directory is purged each build. I'll check it
out

p.s. sorry I missed your #myfaces message in irc yesterday

On 9/21/06, Wendy Smoak [EMAIL PROTECTED] wrote:


On 9/21/06, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
 Online report :

 


 Build Error:

 


 Provider message: The svn command failed.
 Command output:

--- 


 svn: Working copy '.' locked
 svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
details)
 Type 'svn help' for usage.

--- 



I added a Troubleshooting section and this 'problem' to the wiki.  Is
this one that resolves on its own, or do we need to run svn cleanup?
If so, where is the working copy?

   http://wiki.apache.org/myfaces/Continuum_Build

--
Wendy

[jira] Commented: (TOMAHAWK-606) t:commandLink does not work - gives javascript error

[ 
http://issues.apache.org/jira/browse/TOMAHAWK-606?page=comments#action_12436600 
] 

Martin Marinschek commented on TOMAHAWK-606:



Mail from Mahbub:

-- Forwarded message --
From: Mahbub Rahman [EMAIL PROTECTED]
To: Martin Marinschek \(JIRA\) dev@myfaces.apache.org
Date: Thu, 21 Sep 2006 09:08:56 -0700 (PDT)
Subject: Re: [jira] Resolved: (TOMAHAWK-606) t:commandLink does not work - 
gives javascript error
Still getting javascript error on command link/column sort header etc.
On ie6 the javascript error message now changed to:
'undefined' is null or not an object

Thanks,
Mahbub

Mahbub, can you tell me which element is undefined? Some javascript-debugging 
should show you the problem...

regards,

Martin



 t:commandLink does not work - gives javascript error
 

 Key: TOMAHAWK-606
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-606
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Extended CommandLink/CommandButton
Affects Versions: 1.1.5-SNAPSHOT
 Environment: Tomcat tomcat-4.1.31 / WebLogic 8.1 sp 4, 
 myfaces-core-1.1.4-SNAPSHOT, tomahawk-1.1.5-SNAPSHOT
Reporter: Mahbub Rahman
 Assigned To: Martin Marinschek
Priority: Blocker
 Fix For: 1.1.5-SNAPSHOT


 t:commandLink and t:commandSortHeader does not work with 
 tomahawk-1.1.5-SNAPSHOT + jsp.
 h:commandLink works fine where ever t:commandLink fails with javascript error.
 jsp fragment
 f:view
   h:form id=testForm
 h:panelGrid columns=2 
  h:outputLabel value=First Number for=firstNumber/
  h:inputText id=firstNumber 
 value=#{testBean.firstNumber} required=true/
  h:outputLabel value=Second Number for=secondNumber /
  h:inputText id=secondNumber 
 value=#{testBean.secondNumber} required=true/
   /h:panelGrid
   h:panelGroup
   t:commandLink id=submitTest action=#{testBean.add} 
 value=Add/
 /h:panelGroup
   /h:form
 /f:view
 gives following javascript error:
 ie6:  Error: 
 'document.forms.testForm.elements.testForm:_idcl' is null or not an object
 Firefox 1.0: Error: document.forms.testForm.elements['testForm:_idcl'] 
 has no properties

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MYFACES-1415) WebXmlParser needs to be aware of changes in web.xml in version 2.4 of the Servlet spec

2006-09-21 Thread Dan Allen (JIRA)

 [ http://issues.apache.org/jira/browse/MYFACES-1415?page=all ]

Dan Allen updated MYFACES-1415:
---

Status: Patch Available  (was: Open)

 WebXmlParser needs to be aware of changes in web.xml in version 2.4 of the 
 Servlet spec
 ---

 Key: MYFACES-1415
 URL: http://issues.apache.org/jira/browse/MYFACES-1415
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 1.1.4
Reporter: Gert Vanthienen
Priority: Trivial

 When using a Servlet 2.4 compliant web.xml, warnings are shown for some 
 elements that are valid according to the spec.  This is purely a cosmetic 
 issue, with no loss of function whatsoever.  It does create some confusion 
 when users see this message (e.g. 
 http://www.mail-archive.com/users@myfaces.apache.org/msg28066.html), so it 
 might be worth fixing at some time.
 WARN [WebXmlParser] Ignored element 'dispatcher' as child of 'filter-mapping'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MYFACES-1415) WebXmlParser needs to be aware of changes in web.xml in version 2.4 of the Servlet spec

2006-09-21 Thread Dan Allen (JIRA)

[ 
http://issues.apache.org/jira/browse/MYFACES-1415?page=comments#action_12436615 
] 

Dan Allen commented on MYFACES-1415:


Oh, and the above patch applies to the branch 
http://svn.apache.org/repos/asf/myfaces/shared/branches/2_0_3

 WebXmlParser needs to be aware of changes in web.xml in version 2.4 of the 
 Servlet spec
 ---

 Key: MYFACES-1415
 URL: http://issues.apache.org/jira/browse/MYFACES-1415
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 1.1.4
Reporter: Gert Vanthienen
Priority: Trivial
 Attachments: MYFACES-1415.txt


 When using a Servlet 2.4 compliant web.xml, warnings are shown for some 
 elements that are valid according to the spec.  This is purely a cosmetic 
 issue, with no loss of function whatsoever.  It does create some confusion 
 when users see this message (e.g. 
 http://www.mail-archive.com/users@myfaces.apache.org/msg28066.html), so it 
 might be worth fixing at some time.
 WARN [WebXmlParser] Ignored element 'dispatcher' as child of 'filter-mapping'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (TOMAHAWK-50) equals validator shows text (nit nice by validating passwords...)

 [ http://issues.apache.org/jira/browse/TOMAHAWK-50?page=all ]

Martin Marinschek updated TOMAHAWK-50:
--

   Status: Resolved  (was: Patch Available)
Fix Version/s: 1.1.4-SNAPSHOT
   Resolution: Fixed
 Assignee: Martin Marinschek  (was: Matthias Weßendorf)

Mike had already something close to this to tomahawk. I've been trying to do a 
merge where it made sense, e.g. I find the addition of a summaryMessage 
attribute definitely useful, also the resolving of the FacesMessage is somehow 
handled better.

What I've seen throughout the validator code - the value-bindings are never set 
as value-bindings, but always as pure string-values. Is that really what we 
want to do?

regards,

Martin



 equals validator shows text (nit nice by validating passwords...)
 -

 Key: TOMAHAWK-50
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-50
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Validators
Reporter: Matthias Weßendorf
 Assigned To: Martin Marinschek
 Fix For: 1.1.4-SNAPSHOT

 Attachments: myfaces-991.zip


 dave
 I am using t:validateEqual for password. when two passwords are not equal, 
 the passwords(clear) show up on client browser in validation error message. 
 Would it be nice if there is a flag to hide the passard on server side?
 /dave

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [jira] Updated: (TOMAHAWK-50) equals validator shows text (nit nice by validating passwords...)


On 9/21/06, Martin Marinschek (JIRA) dev@myfaces.apache.org wrote:

 [ http://issues.apache.org/jira/browse/TOMAHAWK-50?page=all ]

Martin Marinschek updated TOMAHAWK-50:
--

   Status: Resolved  (was: Patch Available)
Fix Version/s: 1.1.4-SNAPSHOT
   Resolution: Fixed
 Assignee: Martin Marinschek  (was: Matthias Weßendorf)

Mike had already something close to this to tomahawk. I've been trying to do a 
merge where it made sense, e.g. I find the addition of a summaryMessage 
attribute definitely useful, also the resolving of the FacesMessage is somehow 
handled better.

What I've seen throughout the validator code - the value-bindings are never set 
as value-bindings, but always as pure string-values. Is that really what we 
want to do?


Sure.  I think we should update ValidatorBase to support
summaryMessage and detailMessage as well as message.

I also think this entire equalsTo component needs to become a subclass
of validateCompareTo with some of the attributes hardcoded.

Re: [jira] Updated: (TOMAHAWK-50) equals validator shows text (nit nice by validating passwords...)


The only issues I see keeping validateCompareTo in the sandbox are localization.

On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:

I also think this entire equalsTo component needs to become a subclass
of validateCompareTo with some of the attributes hardcoded.

Validator message changes broke facelets backward compatiblity [Was: Re: svn commit: r448673 - [...validator message changes...]]


Martin, this was a valiant attempt, but you've just destroyed facelets
compatibility for all of the validator components using the message
attribute.

Please don't put any processing logic in the Tag classes.   In fact,
I'm hoping that we will soon code-generate all jsf Tag classes since
they should all be cookie-cutter pass-through implementations.

You need to handle the various checking and fetching of the message
combinations in the component itself not in the Tag class.


On 9/21/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

Author: mmarinschek
Date: Thu Sep 21 13:44:09 2006
New Revision: 448673

URL: http://svn.apache.org/viewvc?view=revrev=448673
Log:
fixed TOMAHAWK-50 : custom validator messages (e.g. to prevent equals validator 
showing password texts)

Added:

myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/validator/AttachedListStateWrapper.java

myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/validator/AttachedStateWrapper.java
Modified:

myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/util/MessageUtils.java

myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/creditcardvalidator/CreditCardValidator.java

myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/creditcardvalidator/ValidateCreditCardTag.java

myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/emailvalidator/EmailValidator.java

myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/emailvalidator/ValidateEmailTag.java

myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/equalvalidator/EqualValidator.java

myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/equalvalidator/ValidateEqualTag.java

myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/regexprvalidator/RegExprValidator.java

myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/regexprvalidator/ValidateRegExprTag.java

myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/validator/ValidatorBase.java

myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/validator/ValidatorBaseTag.java

myfaces/tomahawk/trunk/core/src/main/tld/entities/ext_validator_base_attributes.xml
myfaces/tomahawk/trunk/examples/simple/src/main/webapp/validate.jsp

myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/urlvalidator/UrlValidator.java

myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/urlvalidator/ValidateUrlTag.java
myfaces/tomahawk/trunk/sandbox/core/src/main/tld/myfaces_sandbox.tld

Modified: 
myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/util/MessageUtils.java
URL: 
http://svn.apache.org/viewvc/myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/util/MessageUtils.java?view=diffrev=448673r1=448672r2=448673
==
--- 
myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/util/MessageUtils.java
 (original)
+++ 
myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/util/MessageUtils.java
 Thu Sep 21 13:44:09 2006
@@ -247,18 +247,26 @@
  */
 public static FacesMessage getMessage(String bundleBaseName, String 
messageId, Object params[])
 {
-Locale locale = null;
+return getMessage(bundleBaseName, getCurrentLocale(), messageId, 
params);
+}
+
+/**
+ *
+ * @return  currently applicable Locale for this request.
+ */
+public static Locale getCurrentLocale() {
+Locale locale;
+
 FacesContext context = FacesContext.getCurrentInstance();
-if(context != null  context.getViewRoot() != null)
-{
+if(context != null  context.getViewRoot() != null) {
 locale = context.getViewRoot().getLocale();
 if(locale == null)
 locale = Locale.getDefault();
-} else
-{
+} else {
 locale = Locale.getDefault();
 }
-return getMessage(bundleBaseName, locale, messageId, params);
+
+return locale;
 }

 /**
@@ -288,7 +296,7 @@
   if (bundleBaseName == null)
   {
   throw new NullPointerException(
-  Unable to locate ResrouceBundle: bundle is null);
+  Unable to locate ResourceBundle: bundle is null);
   }

   ResourceBundle bundle = ResourceBundle.getBundle(bundleBaseName, locale);
@@ -357,11 +365,7 @@
 {
 if(context == null || messageId == null)
 throw new NullPointerException( context  + context +  messageId 
 + messageId);
-Locale locale = null;
-if(context != null  context.getViewRoot() != null)
-locale = context.getViewRoot().getLocale();
-else
-locale = Locale.getDefault();
+Locale locale = getCurrentLocale();
 if(null == locale)
 throw new

[jira] Updated: (MYFACES-1415) WebXmlParser needs to be aware of changes in web.xml in version 2.4 of the Servlet spec

 [ http://issues.apache.org/jira/browse/MYFACES-1415?page=all ]

Martin Marinschek updated MYFACES-1415:
---

   Status: Resolved  (was: Patch Available)
Fix Version/s: 1.1.5-SNAPSHOT
   Resolution: Fixed
 Assignee: Martin Marinschek

Thanks to Dan Allen for providing this patch.

regards,

Martin

 WebXmlParser needs to be aware of changes in web.xml in version 2.4 of the 
 Servlet spec
 ---

 Key: MYFACES-1415
 URL: http://issues.apache.org/jira/browse/MYFACES-1415
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 1.1.4
Reporter: Gert Vanthienen
 Assigned To: Martin Marinschek
Priority: Trivial
 Fix For: 1.1.5-SNAPSHOT

 Attachments: MYFACES-1415.txt


 When using a Servlet 2.4 compliant web.xml, warnings are shown for some 
 elements that are valid according to the spec.  This is purely a cosmetic 
 issue, with no loss of function whatsoever.  It does create some confusion 
 when users see this message (e.g. 
 http://www.mail-archive.com/users@myfaces.apache.org/msg28066.html), so it 
 might be worth fixing at some time.
 WARN [WebXmlParser] Ignored element 'dispatcher' as child of 'filter-mapping'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Validator message changes broke facelets backward compatiblity [Was: Re: svn commit: r448673 - [...validator message changes...]]


Hmmm... Why not provide a custom Facelets-Tag for this?

The thing is that also the component will be generated - so we can't
really have much custom code there, right?

regards,

Martin

On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:

Martin, this was a valiant attempt, but you've just destroyed facelets
compatibility for all of the validator components using the message
attribute.

Please don't put any processing logic in the Tag classes.   In fact,
I'm hoping that we will soon code-generate all jsf Tag classes since
they should all be cookie-cutter pass-through implementations.

You need to handle the various checking and fetching of the message
combinations in the component itself not in the Tag class.


On 9/21/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 Author: mmarinschek
 Date: Thu Sep 21 13:44:09 2006
 New Revision: 448673

 URL: http://svn.apache.org/viewvc?view=revrev=448673
 Log:
 fixed TOMAHAWK-50 : custom validator messages (e.g. to prevent equals 
validator showing password texts)

 Added:
 
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/validator/AttachedListStateWrapper.java
 
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/validator/AttachedStateWrapper.java
 Modified:
 
myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/util/MessageUtils.java
 
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/creditcardvalidator/CreditCardValidator.java
 
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/creditcardvalidator/ValidateCreditCardTag.java
 
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/emailvalidator/EmailValidator.java
 
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/emailvalidator/ValidateEmailTag.java
 
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/equalvalidator/EqualValidator.java
 
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/equalvalidator/ValidateEqualTag.java
 
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/regexprvalidator/RegExprValidator.java
 
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/regexprvalidator/ValidateRegExprTag.java
 
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/validator/ValidatorBase.java
 
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/validator/ValidatorBaseTag.java
 
myfaces/tomahawk/trunk/core/src/main/tld/entities/ext_validator_base_attributes.xml
 myfaces/tomahawk/trunk/examples/simple/src/main/webapp/validate.jsp
 
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/urlvalidator/UrlValidator.java
 
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/urlvalidator/ValidateUrlTag.java
 myfaces/tomahawk/trunk/sandbox/core/src/main/tld/myfaces_sandbox.tld

 Modified: 
myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/util/MessageUtils.java
 URL: 
http://svn.apache.org/viewvc/myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/util/MessageUtils.java?view=diffrev=448673r1=448672r2=448673
 ==
 --- 
myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/util/MessageUtils.java
 (original)
 +++ 
myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/util/MessageUtils.java
 Thu Sep 21 13:44:09 2006
 @@ -247,18 +247,26 @@
   */
  public static FacesMessage getMessage(String bundleBaseName, String 
messageId, Object params[])
  {
 -Locale locale = null;
 +return getMessage(bundleBaseName, getCurrentLocale(), messageId, 
params);
 +}
 +
 +/**
 + *
 + * @return  currently applicable Locale for this request.
 + */
 +public static Locale getCurrentLocale() {
 +Locale locale;
 +
  FacesContext context = FacesContext.getCurrentInstance();
 -if(context != null  context.getViewRoot() != null)
 -{
 +if(context != null  context.getViewRoot() != null) {
  locale = context.getViewRoot().getLocale();
  if(locale == null)
  locale = Locale.getDefault();
 -} else
 -{
 +} else {
  locale = Locale.getDefault();
  }
 -return getMessage(bundleBaseName, locale, messageId, params);
 +
 +return locale;
  }

  /**
 @@ -288,7 +296,7 @@
if (bundleBaseName == null)
{
throw new NullPointerException(
 -  Unable to locate ResrouceBundle: bundle is null);
 +  Unable to locate ResourceBundle: bundle is null);
}

ResourceBundle bundle = ResourceBundle.getBundle(bundleBaseName, 
locale);
 @@ -357,11 +365,7 @@
  {
  if(context == null || messageId == null)
  throw new NullPointerException( context  + context +  messageId 
 +

Re: Validator message changes broke facelets backward compatiblity [Was: Re: svn commit: r448673 - [...validator message changes...]]


On 9/21/06, Martin Marinschek [EMAIL PROTECTED] wrote:

Hmmm... Why not provide a custom Facelets-Tag for this?


Because that's the wrong approach to fixing the problem.


The thing is that also the component will be generated - so we can't
really have much custom code there, right?


Why would the component be generated?  That's where all of the
component-specific logic is.

Re: Validator message changes broke facelets backward compatiblity [Was: Re: svn commit: r448673 - [...validator message changes...]]


In case it's not clear, by component I really mean validator in this context.

On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:

On 9/21/06, Martin Marinschek [EMAIL PROTECTED] wrote:
 Hmmm... Why not provide a custom Facelets-Tag for this?

Because that's the wrong approach to fixing the problem.

 The thing is that also the component will be generated - so we can't
 really have much custom code there, right?

Why would the component be generated?  That's where all of the
component-specific logic is.

[jira] Updated: (TOMAHAWK-60) NavigationMenuItem should provide a default constructor

 [ http://issues.apache.org/jira/browse/TOMAHAWK-60?page=all ]

Martin Marinschek updated TOMAHAWK-60:
--

   Status: Resolved  (was: Patch Available)
Fix Version/s: 1.1.4-SNAPSHOT
   Resolution: Fixed
 Assignee: Martin Marinschek

Thanks to Alexandre Poitras for this patch.

regards,

Martin

 NavigationMenuItem should provide a default constructor
 ---

 Key: TOMAHAWK-60
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-60
 Project: MyFaces Tomahawk
  Issue Type: Improvement
  Components: NavigationMenuItem
Reporter: Alexandre Poitras
 Assigned To: Martin Marinschek
 Fix For: 1.1.4-SNAPSHOT

 Attachments: defaultConstructor.patch


 NavigationMenuItem should provide a default constructor so I can initialise 
 it using managed bean factory.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Validator message changes broke facelets backward compatiblity [Was: Re: svn commit: r448673 - [...validator message changes...]]


Sorry, yes, I meant validator as well. Well, at least the property
setting - getting - restoreState and saveState parts are generated. So
where would you incorporate the check?

Maybe we should just get rid of the detailMessage at all, and use
message instead.

regards,

Martin

On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:

In case it's not clear, by component I really mean validator in this context.

On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
 On 9/21/06, Martin Marinschek [EMAIL PROTECTED] wrote:
  Hmmm... Why not provide a custom Facelets-Tag for this?

 Because that's the wrong approach to fixing the problem.

  The thing is that also the component will be generated - so we can't
  really have much custom code there, right?

 Why would the component be generated?  That's where all of the
 component-specific logic is.





--

http://www.irian.at

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

Professional Support for Apache MyFaces

[jira] Commented: (TOMAHAWK-606) t:commandLink does not work - gives javascript error

2006-09-21 Thread Mahbub Rahman (JIRA)

[ 
http://issues.apache.org/jira/browse/TOMAHAWK-606?page=comments#action_12436647 
] 

Mahbub Rahman commented on TOMAHAWK-606:


newInput in javascript function oamSetHiddenInput is coming as undefined.

Regards,
Mahbub

 t:commandLink does not work - gives javascript error
 

 Key: TOMAHAWK-606
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-606
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Extended CommandLink/CommandButton
Affects Versions: 1.1.5-SNAPSHOT
 Environment: Tomcat tomcat-4.1.31 / WebLogic 8.1 sp 4, 
 myfaces-core-1.1.4-SNAPSHOT, tomahawk-1.1.5-SNAPSHOT
Reporter: Mahbub Rahman
 Assigned To: Martin Marinschek
Priority: Blocker
 Fix For: 1.1.5-SNAPSHOT


 t:commandLink and t:commandSortHeader does not work with 
 tomahawk-1.1.5-SNAPSHOT + jsp.
 h:commandLink works fine where ever t:commandLink fails with javascript error.
 jsp fragment
 f:view
   h:form id=testForm
 h:panelGrid columns=2 
  h:outputLabel value=First Number for=firstNumber/
  h:inputText id=firstNumber 
 value=#{testBean.firstNumber} required=true/
  h:outputLabel value=Second Number for=secondNumber /
  h:inputText id=secondNumber 
 value=#{testBean.secondNumber} required=true/
   /h:panelGrid
   h:panelGroup
   t:commandLink id=submitTest action=#{testBean.add} 
 value=Add/
 /h:panelGroup
   /h:form
 /f:view
 gives following javascript error:
 ie6:  Error: 
 'document.forms.testForm.elements.testForm:_idcl' is null or not an object
 Firefox 1.0: Error: document.forms.testForm.elements['testForm:_idcl'] 
 has no properties

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (TOMAHAWK-197) More CSS for TabbedPane (incl. patch with solution)

 [ http://issues.apache.org/jira/browse/TOMAHAWK-197?page=all ]

Martin Marinschek updated TOMAHAWK-197:
---

   Status: Resolved  (was: Patch Available)
Fix Version/s: 1.1.4-SNAPSHOT
   Resolution: Fixed
 Assignee: Martin Marinschek

Thanks to Wolfgang Engelhard for this patch.

 More CSS for TabbedPane (incl. patch with solution)
 ---

 Key: TOMAHAWK-197
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-197
 Project: MyFaces Tomahawk
  Issue Type: New Feature
  Components: Tabbed Pane
 Environment: N/A
Reporter: Wolfgang Engelhard
 Assigned To: Martin Marinschek
Priority: Minor
 Fix For: 1.1.4-SNAPSHOT

 Attachments: patch.txt


 For better control of style on your tabbed pane you need attribute id or 
 style for the tag tr.
 The following patch (created with eclipse and NOT TESTED ) should address 
 this (you need to adjust the paths to your workspace requirements, sorry for 
 the inconvenience). 
 Please test first, even if changes are minor, as I wasn't able to compile 
 this (dependencies and build environment) !
 This may also solve some of Jim Wrights issues, tomahawk-22 and tomahawk-54.
 Expected problems are: 
 - writeAttribute not working as expected and 
 - no documentation of additionally available styles.
 ### patch begin, copy and paste from next line till end ##
 Index: 
 D:/projects/tomahawk/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlTabbedPaneRenderer.java
 ===
 --- 
 D:/projects/tomahawk/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlTabbedPaneRenderer.java
(revision 385479)
 +++ 
 D:/projects/tomahawk/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlTabbedPaneRenderer.java
(working copy)
 @@ -44,15 +44,18 @@
  public class HtmlTabbedPaneRenderer
  extends HtmlRenderer
  {
 +private static final String HEADER_ROW_CLASS = 
 myFaces_pannelTabbedPane_HeaderRow;
  private static final String ACTIVE_HEADER_CELL_CLASS = 
 myFaces_panelTabbedPane_activeHeaderCell;
  private static final String INACTIVE_HEADER_CELL_CLASS = 
 myFaces_panelTabbedPane_inactiveHeaderCell;
  private static final String DISABLED_HEADER_CELL_CLASS = 
 myFaces_panelTabbedPane_disabledHeaderCell;
  private static final String EMPTY_HEADER_CELL_CLASS = 
 myFaces_panelTabbedPane_emptyHeaderCell;
 +private static final String SUB_HEADER_ROW_CLASS = 
 myFaces_pannelTabbedPane_subHeaderRow;
  private static final String SUB_HEADER_CELL_CLASS = 
 myFaces_panelTabbedPane_subHeaderCell;
  private static final String SUB_HEADER_CELL_CLASS_ACTIVE = 
 myFaces_panelTabbedPane_subHeaderCell_active;
  private static final String SUB_HEADER_CELL_CLASS_INACTIVE = 
 myFaces_panelTabbedPane_subHeaderCell_inactive;
  private static final String SUB_HEADER_CELL_CLASS_FIRST = 
 myFaces_panelTabbedPane_subHeaderCell_first;
  private static final String SUB_HEADER_CELL_CLASS_LAST = 
 myFaces_panelTabbedPane_subHeaderCell_last;
 +private static final String CONTENT_ROW_CLASS = 
 myFaces_panelTabbedPane_contentRow;
  private static final String TAB_PANE_CLASS = 
 myFaces_panelTabbedPane_pane;
  
  private static final String DEFAULT_BG_COLOR = white;
 @@ -164,6 +167,7 @@
  writeTableStart(writer, facesContext, tabbedPane);
  HtmlRendererUtils.writePrettyLineSeparator(facesContext);
  writer.startElement(HTML.TR_ELEM, tabbedPane);
 +writer.writeAttribute(HTML.CLASS_ATTR, HEADER_ROW_CLASS, null);
  
  //Tab headers
  int tabIdx = 0;
 @@ -207,6 +211,7 @@
  //Sub header cells
  HtmlRendererUtils.writePrettyLineSeparator(facesContext);
  writer.startElement(HTML.TR_ELEM, tabbedPane);
 +writer.writeAttribute(HTML.CLASS_ATTR, SUB_HEADER_ROW_CLASS, null);
  writeSubHeaderCells(writer, facesContext, tabbedPane, 
 visibleTabCount, visibleTabSelectedIdx);
  HtmlRendererUtils.writePrettyLineSeparator(facesContext);
  writer.endElement(HTML.TR_ELEM);
 @@ -214,6 +219,7 @@
  //Tabs
  HtmlRendererUtils.writePrettyLineSeparator(facesContext);
  writer.startElement(HTML.TR_ELEM, tabbedPane);
 +writer.writeAttribute(HTML.CLASS_ATTR, CONTENT_ROW_CLASS, null);
  writer.startElement(HTML.TD_ELEM, tabbedPane);
  writer.writeAttribute(HTML.COLSPAN_ATTR, 
 Integer.toString(visibleTabCount + 1), null);
  String tabContentStyleClass = tabbedPane.getTabContentStyleClass();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:

[jira] Updated: (TOMAHAWK-214) t:outputText attribute \n - br/

 [ http://issues.apache.org/jira/browse/TOMAHAWK-214?page=all ]

Martin Marinschek updated TOMAHAWK-214:
---

Status: Open  (was: Patch Available)

 t:outputText attribute \n - br/
 --

 Key: TOMAHAWK-214
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-214
 Project: MyFaces Tomahawk
  Issue Type: New Feature
Reporter: Alexander Panzhin
Priority: Minor
 Attachments: TOMAHAWK-214.diff


 A boolean attribute, when set would convert '\n' to 'br/'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Validator message changes broke facelets backward compatiblity [Was: Re: svn commit: r448673 - [...validator message changes...]]


I'd put the check inside the validate method itself.

This is what I've done in my own custom validators that have
interdependent attributes.

On 9/21/06, Martin Marinschek [EMAIL PROTECTED] wrote:

Sorry, yes, I meant validator as well. Well, at least the property
setting - getting - restoreState and saveState parts are generated. So
where would you incorporate the check?

Maybe we should just get rid of the detailMessage at all, and use
message instead.

regards,

Martin

On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
 In case it's not clear, by component I really mean validator in this 
context.

 On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
  On 9/21/06, Martin Marinschek [EMAIL PROTECTED] wrote:
   Hmmm... Why not provide a custom Facelets-Tag for this?
 
  Because that's the wrong approach to fixing the problem.
 
   The thing is that also the component will be generated - so we can't
   really have much custom code there, right?
 
  Why would the component be generated?  That's where all of the
  component-specific logic is.
 



--

http://www.irian.at

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

Professional Support for Apache MyFaces

[jira] Commented: (TOMAHAWK-214) t:outputText attribute \n - br/

[ 
http://issues.apache.org/jira/browse/TOMAHAWK-214?page=comments#action_12436649 
] 

Martin Marinschek commented on TOMAHAWK-214:


Well, I'm not sure. You could surely have a normal output-text where you'd want 
to have breaks showing, or even not showing. This needs definitely to be an 
attribute. I'm therefore cancelling the patch.

regards,

Martin

 t:outputText attribute \n - br/
 --

 Key: TOMAHAWK-214
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-214
 Project: MyFaces Tomahawk
  Issue Type: New Feature
Reporter: Alexander Panzhin
Priority: Minor
 Attachments: TOMAHAWK-214.diff


 A boolean attribute, when set would convert '\n' to 'br/'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Validator message changes broke facelets backward compatiblity [Was: Re: svn commit: r448673 - [...validator message changes...]]


Also, message = summaryMessage + detailMessage, not simply detailMessage.

At least, I'm pretty sure that's how it currently works.

On 9/21/06, Martin Marinschek [EMAIL PROTECTED] wrote:

Sorry, yes, I meant validator as well. Well, at least the property
setting - getting - restoreState and saveState parts are generated. So
where would you incorporate the check?

Maybe we should just get rid of the detailMessage at all, and use
message instead.

regards,

Martin

On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
 In case it's not clear, by component I really mean validator in this 
context.

 On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
  On 9/21/06, Martin Marinschek [EMAIL PROTECTED] wrote:
   Hmmm... Why not provide a custom Facelets-Tag for this?
 
  Because that's the wrong approach to fixing the problem.
 
   The thing is that also the component will be generated - so we can't
   really have much custom code there, right?
 
  Why would the component be generated?  That's where all of the
  component-specific logic is.
 



--

http://www.irian.at

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

Professional Support for Apache MyFaces

[jira] Updated: (TOMAHAWK-97) TabbedPane active sub header uses wrong user defined styleClass

 [ http://issues.apache.org/jira/browse/TOMAHAWK-97?page=all ]

Martin Marinschek updated TOMAHAWK-97:
--

   Status: Resolved  (was: Patch Available)
Fix Version/s: 1.1.4-SNAPSHOT
   Resolution: Fixed
 Assignee: Martin Marinschek

Thanks to Jim Wright for this patch.

regards,

Martin

 TabbedPane active sub header uses wrong user defined styleClass
 ---

 Key: TOMAHAWK-97
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-97
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Tabbed Pane
 Environment: All
Reporter: Jim Wright
 Assigned To: Martin Marinschek
 Fix For: 1.1.4-SNAPSHOT

 Attachments: HTMLPanelTabRendererPatch, tabbedPaneRendererpatch.txt


 When you specify your own styleClass for the activeSubStyle class like this :
 t:panelTabbedPane id=pageTabs selectedIndex=0 
   activeTabStyleClass=activeTab
   inactiveTabStyleClass=inactiveTab
   disabledTabStyleClass=disabledTab
   activeSubStyleClass=activeSub
   inactiveSubStyleClass=inactiveSub
   tabContentStyleClass=tabContent
 the rendered result  clearly shows the active sub header cell using the user 
 defined styleClass for an inactive sub header cell:
 tr
   td id=tabsForm:_id13_headerCell_sub 
 class=myFaces_panelTabbedPane_subHeaderCell 
 myFaces_panelTabbedPane_subHeaderCell_first inactiveSub 
 myFaces_panelTabbedPane_subHeaderCell_inactive#160;/td
   td id=tabsForm:_id15_headerCell_sub 
 class=myFaces_panelTabbedPane_subHeaderCell inactiveSub 
 myFaces_panelTabbedPane_subHeaderCell_inactive#160;/td
   td id=tabsForm:_id17_headerCell_sub 
 class=myFaces_panelTabbedPane_subHeaderCell inactiveSub 
 myFaces_panelTabbedPane_subHeaderCell_active#160;/td
   td id=tabsForm:_id24_headerCell_sub 
 class=myFaces_panelTabbedPane_subHeaderCell inactiveSub 
 myFaces_panelTabbedPane_subHeaderCell_inactive#160;/td
   td class=myFaces_panelTabbedPane_subHeaderCell 
 myFaces_panelTabbedPane_subHeaderCell_last inactiveSub#160;/td
 /tr

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Validator message changes broke facelets backward compatiblity [Was: Re: svn commit: r448673 - [...validator message changes...]]


Yes, that will work, but only if we save the additional attribute :-/

You don't have a summaryMessage in there right now - I don't understand your

summaryMessage + detailMessage, not simply detailMessage. comment.

regards,

Martin


On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:

Also, message = summaryMessage + detailMessage, not simply detailMessage.

At least, I'm pretty sure that's how it currently works.

On 9/21/06, Martin Marinschek [EMAIL PROTECTED] wrote:
 Sorry, yes, I meant validator as well. Well, at least the property
 setting - getting - restoreState and saveState parts are generated. So
 where would you incorporate the check?

 Maybe we should just get rid of the detailMessage at all, and use
 message instead.

 regards,

 Martin

 On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
  In case it's not clear, by component I really mean validator in this 
context.
 
  On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
   On 9/21/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Hmmm... Why not provide a custom Facelets-Tag for this?
  
   Because that's the wrong approach to fixing the problem.
  
The thing is that also the component will be generated - so we can't
really have much custom code there, right?
  
   Why would the component be generated?  That's where all of the
   component-specific logic is.
  
 


 --

 http://www.irian.at

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

 Professional Support for Apache MyFaces





--

http://www.irian.at

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

Professional Support for Apache MyFaces

[jira] Commented: (TOMAHAWK-606) t:commandLink does not work - gives javascript error

[ 
http://issues.apache.org/jira/browse/TOMAHAWK-606?page=comments#action_12436654 
] 

Martin Marinschek commented on TOMAHAWK-606:


I've just seen that I had used square brackets for createElement. Hrmmpf. I've 
fixed it right now, can you try again?

regards,

Martin

 t:commandLink does not work - gives javascript error
 

 Key: TOMAHAWK-606
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-606
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Extended CommandLink/CommandButton
Affects Versions: 1.1.5-SNAPSHOT
 Environment: Tomcat tomcat-4.1.31 / WebLogic 8.1 sp 4, 
 myfaces-core-1.1.4-SNAPSHOT, tomahawk-1.1.5-SNAPSHOT
Reporter: Mahbub Rahman
 Assigned To: Martin Marinschek
Priority: Blocker
 Fix For: 1.1.5-SNAPSHOT


 t:commandLink and t:commandSortHeader does not work with 
 tomahawk-1.1.5-SNAPSHOT + jsp.
 h:commandLink works fine where ever t:commandLink fails with javascript error.
 jsp fragment
 f:view
   h:form id=testForm
 h:panelGrid columns=2 
  h:outputLabel value=First Number for=firstNumber/
  h:inputText id=firstNumber 
 value=#{testBean.firstNumber} required=true/
  h:outputLabel value=Second Number for=secondNumber /
  h:inputText id=secondNumber 
 value=#{testBean.secondNumber} required=true/
   /h:panelGrid
   h:panelGroup
   t:commandLink id=submitTest action=#{testBean.add} 
 value=Add/
 /h:panelGroup
   /h:form
 /f:view
 gives following javascript error:
 ie6:  Error: 
 'document.forms.testForm.elements.testForm:_idcl' is null or not an object
 Firefox 1.0: Error: document.forms.testForm.elements['testForm:_idcl'] 
 has no properties

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Validator message changes broke facelets backward compatiblity [Was: Re: svn commit: r448673 - [...validator message changes...]]


Old value

msg = MessageUtils.getMessage(FacesMessage.SEVERITY_ERROR, message, args);

New Value:

Locale locale = MessageUtils.getCurrentLocale();
String summaryText = MessageUtils.substituteParams(locale,
getSummaryMessage(), args);
String detailText = MessageUtils.substituteParams(locale, message, args);
msg = new FacesMessage(FacesMessage.SEVERITY_ERROR, summaryText, detailText);

I might be misreading either the original code or the new code, but it
looks like Old Value != New value.   Maybe I'm wrong, and in the case
where getSummaryMessage() == null, it's the same thing, though.



On 9/21/06, Martin Marinschek [EMAIL PROTECTED] wrote:

Yes, that will work, but only if we save the additional attribute :-/

You don't have a summaryMessage in there right now - I don't understand your

summaryMessage + detailMessage, not simply detailMessage. comment.

regards,

Martin


On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
 Also, message = summaryMessage + detailMessage, not simply detailMessage.

 At least, I'm pretty sure that's how it currently works.

 On 9/21/06, Martin Marinschek [EMAIL PROTECTED] wrote:
  Sorry, yes, I meant validator as well. Well, at least the property
  setting - getting - restoreState and saveState parts are generated. So
  where would you incorporate the check?
 
  Maybe we should just get rid of the detailMessage at all, and use
  message instead.
 
  regards,
 
  Martin
 
  On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
   In case it's not clear, by component I really mean validator in this 
context.
  
   On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
On 9/21/06, Martin Marinschek [EMAIL PROTECTED] wrote:
 Hmmm... Why not provide a custom Facelets-Tag for this?
   
Because that's the wrong approach to fixing the problem.
   
 The thing is that also the component will be generated - so we can't
 really have much custom code there, right?
   
Why would the component be generated?  That's where all of the
component-specific logic is.
   
  
 
 
  --
 
  http://www.irian.at
 
  Your JSF powerhouse -
  JSF Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 



--

http://www.irian.at

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

Professional Support for Apache MyFaces

Re: Validator message changes broke facelets backward compatiblity [Was: Re: svn commit: r448673 - [...validator message changes...]]


Hey Martin,  I just want to apologize in advance for slowing down your
attempt to single-handedly close out every JIRA issue.  :-)

On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:

Old value

msg = MessageUtils.getMessage(FacesMessage.SEVERITY_ERROR, message, args);

New Value:

Locale locale = MessageUtils.getCurrentLocale();
String summaryText = MessageUtils.substituteParams(locale,
getSummaryMessage(), args);
String detailText = MessageUtils.substituteParams(locale, message, args);
msg = new FacesMessage(FacesMessage.SEVERITY_ERROR, summaryText, detailText);

I might be misreading either the original code or the new code, but it
looks like Old Value != New value.   Maybe I'm wrong, and in the case
where getSummaryMessage() == null, it's the same thing, though.



On 9/21/06, Martin Marinschek [EMAIL PROTECTED] wrote:
 Yes, that will work, but only if we save the additional attribute :-/

 You don't have a summaryMessage in there right now - I don't understand your

 summaryMessage + detailMessage, not simply detailMessage. comment.

 regards,

 Martin


 On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
  Also, message = summaryMessage + detailMessage, not simply detailMessage.
 
  At least, I'm pretty sure that's how it currently works.
 
  On 9/21/06, Martin Marinschek [EMAIL PROTECTED] wrote:
   Sorry, yes, I meant validator as well. Well, at least the property
   setting - getting - restoreState and saveState parts are generated. So
   where would you incorporate the check?
  
   Maybe we should just get rid of the detailMessage at all, and use
   message instead.
  
   regards,
  
   Martin
  
   On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
In case it's not clear, by component I really mean validator in this 
context.
   
On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
 On 9/21/06, Martin Marinschek [EMAIL PROTECTED] wrote:
  Hmmm... Why not provide a custom Facelets-Tag for this?

 Because that's the wrong approach to fixing the problem.

  The thing is that also the component will be generated - so we can't
  really have much custom code there, right?

 Why would the component be generated?  That's where all of the
 component-specific logic is.

   
  
  
   --
  
   http://www.irian.at
  
   Your JSF powerhouse -
   JSF Consulting, Development and
   Courses in English and German
  
   Professional Support for Apache MyFaces
  
 


 --

 http://www.irian.at

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

 Professional Support for Apache MyFaces

[jira] Updated: (TOMAHAWK-261) Do not use document.write in popup calendars

 [ http://issues.apache.org/jira/browse/TOMAHAWK-261?page=all ]

Martin Marinschek updated TOMAHAWK-261:
---

   Status: Resolved  (was: Patch Available)
Fix Version/s: 1.1.4-SNAPSHOT
   Resolution: Fixed

Thanks to Andrew Robinson for this fix.

regards,

Martin

 Do not use document.write in popup calendars
 

 Key: TOMAHAWK-261
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-261
 Project: MyFaces Tomahawk
  Issue Type: Improvement
  Components: Calendar, Date
Affects Versions: 1.1.1, 1.1.2-SNAPSHOT, 1.1.3-SNAPSHOT
Reporter: Andrew Robinson
 Assigned To: Martin Marinschek
Priority: Blocker
 Fix For: 1.1.4-SNAPSHOT

 Attachments: HtmlCalendarRenderer.patch


 The popup calednar for the date control (and I think the calendar control) 
 uses javascript document.write methods. Unfortunately this is not very 
 compatible with AJAX as it is hard to write content to the document after the 
 document is closed.
 Instead, can this be changed to have: 
 A) printed hidden component  (visibility: hidden; display: none) and just 
 shown when the user clicks the popup button.
 or 
 B) Use the DOM JavaScript API to add new elements to the DOM instead of 
 document.write.
 Unless this is changed, these controls cannot be used with AjaxAnywhere and 
 probably not with other AJAX solutions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Validator message changes broke facelets backward compatiblity [Was: Re: svn commit: r448673 - [...validator message changes...]]


As I see it, when getSummaryMessage() returns null, the results should
be the same.

regards,

Martin

On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:

Old value

msg = MessageUtils.getMessage(FacesMessage.SEVERITY_ERROR, message, args);

New Value:

Locale locale = MessageUtils.getCurrentLocale();
String summaryText = MessageUtils.substituteParams(locale,
getSummaryMessage(), args);
String detailText = MessageUtils.substituteParams(locale, message, args);
msg = new FacesMessage(FacesMessage.SEVERITY_ERROR, summaryText, detailText);

I might be misreading either the original code or the new code, but it
looks like Old Value != New value.   Maybe I'm wrong, and in the case
where getSummaryMessage() == null, it's the same thing, though.



On 9/21/06, Martin Marinschek [EMAIL PROTECTED] wrote:
 Yes, that will work, but only if we save the additional attribute :-/

 You don't have a summaryMessage in there right now - I don't understand your

 summaryMessage + detailMessage, not simply detailMessage. comment.

 regards,

 Martin


 On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
  Also, message = summaryMessage + detailMessage, not simply detailMessage.
 
  At least, I'm pretty sure that's how it currently works.
 
  On 9/21/06, Martin Marinschek [EMAIL PROTECTED] wrote:
   Sorry, yes, I meant validator as well. Well, at least the property
   setting - getting - restoreState and saveState parts are generated. So
   where would you incorporate the check?
  
   Maybe we should just get rid of the detailMessage at all, and use
   message instead.
  
   regards,
  
   Martin
  
   On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
In case it's not clear, by component I really mean validator in this 
context.
   
On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
 On 9/21/06, Martin Marinschek [EMAIL PROTECTED] wrote:
  Hmmm... Why not provide a custom Facelets-Tag for this?

 Because that's the wrong approach to fixing the problem.

  The thing is that also the component will be generated - so we can't
  really have much custom code there, right?

 Why would the component be generated?  That's where all of the
 component-specific logic is.

   
  
  
   --
  
   http://www.irian.at
  
   Your JSF powerhouse -
   JSF Consulting, Development and
   Courses in English and German
  
   Professional Support for Apache MyFaces
  
 


 --

 http://www.irian.at

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

 Professional Support for Apache MyFaces





--

http://www.irian.at

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

Professional Support for Apache MyFaces

Re: Validator message changes broke facelets backward compatiblity [Was: Re: svn commit: r448673 - [...validator message changes...]]


I won't be closing out every single one. There will be a lot more to go ;)

regards,

Martin

On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:

Hey Martin,  I just want to apologize in advance for slowing down your
attempt to single-handedly close out every JIRA issue.  :-)

On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
 Old value

 msg = MessageUtils.getMessage(FacesMessage.SEVERITY_ERROR, message, args);

 New Value:

 Locale locale = MessageUtils.getCurrentLocale();
 String summaryText = MessageUtils.substituteParams(locale,
 getSummaryMessage(), args);
 String detailText = MessageUtils.substituteParams(locale, message, args);
 msg = new FacesMessage(FacesMessage.SEVERITY_ERROR, summaryText, detailText);

 I might be misreading either the original code or the new code, but it
 looks like Old Value != New value.   Maybe I'm wrong, and in the case
 where getSummaryMessage() == null, it's the same thing, though.



 On 9/21/06, Martin Marinschek [EMAIL PROTECTED] wrote:
  Yes, that will work, but only if we save the additional attribute :-/
 
  You don't have a summaryMessage in there right now - I don't understand your
 
  summaryMessage + detailMessage, not simply detailMessage. comment.
 
  regards,
 
  Martin
 
 
  On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
   Also, message = summaryMessage + detailMessage, not simply detailMessage.
  
   At least, I'm pretty sure that's how it currently works.
  
   On 9/21/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Sorry, yes, I meant validator as well. Well, at least the property
setting - getting - restoreState and saveState parts are generated. So
where would you incorporate the check?
   
Maybe we should just get rid of the detailMessage at all, and use
message instead.
   
regards,
   
Martin
   
On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
 In case it's not clear, by component I really mean validator in 
this context.

 On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
  On 9/21/06, Martin Marinschek [EMAIL PROTECTED] wrote:
   Hmmm... Why not provide a custom Facelets-Tag for this?
 
  Because that's the wrong approach to fixing the problem.
 
   The thing is that also the component will be generated - so we 
can't
   really have much custom code there, right?
 
  Why would the component be generated?  That's where all of the
  component-specific logic is.
 

   
   
--
   
http://www.irian.at
   
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
   
Professional Support for Apache MyFaces
   
  
 
 
  --
 
  http://www.irian.at
 
  Your JSF powerhouse -
  JSF Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 





--

http://www.irian.at

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

Professional Support for Apache MyFaces

Re: Validator message changes broke facelets backward compatiblity [Was: Re: svn commit: r448673 - [...validator message changes...]]


Shall I open a Jira issue on this and solve it later, or were you
planning on reworking it now?   Quite honestly, I'm fine with fixing
it on Monday (or whenver I next have time) and letting you close
another 100 issues :-)

On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:

I'd put the check inside the validate method itself.

This is what I've done in my own custom validators that have
interdependent attributes.

On 9/21/06, Martin Marinschek [EMAIL PROTECTED] wrote:
 Sorry, yes, I meant validator as well. Well, at least the property
 setting - getting - restoreState and saveState parts are generated. So
 where would you incorporate the check?

 Maybe we should just get rid of the detailMessage at all, and use
 message instead.

 regards,

 Martin

 On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
  In case it's not clear, by component I really mean validator in this 
context.
 
  On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
   On 9/21/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Hmmm... Why not provide a custom Facelets-Tag for this?
  
   Because that's the wrong approach to fixing the problem.
  
The thing is that also the component will be generated - so we can't
really have much custom code there, right?
  
   Why would the component be generated?  That's where all of the
   component-specific logic is.
  
 


 --

 http://www.irian.at

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

 Professional Support for Apache MyFaces

Re: Validator message changes broke facelets backward compatiblity [Was: Re: svn commit: r448673 - [...validator message changes...]]


Yeah, open an issue, and I'll carry on for now ;)

regards,

Martin

On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:

Shall I open a Jira issue on this and solve it later, or were you
planning on reworking it now?   Quite honestly, I'm fine with fixing
it on Monday (or whenver I next have time) and letting you close
another 100 issues :-)

On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
 I'd put the check inside the validate method itself.

 This is what I've done in my own custom validators that have
 interdependent attributes.

 On 9/21/06, Martin Marinschek [EMAIL PROTECTED] wrote:
  Sorry, yes, I meant validator as well. Well, at least the property
  setting - getting - restoreState and saveState parts are generated. So
  where would you incorporate the check?
 
  Maybe we should just get rid of the detailMessage at all, and use
  message instead.
 
  regards,
 
  Martin
 
  On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
   In case it's not clear, by component I really mean validator in this 
context.
  
   On 9/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
On 9/21/06, Martin Marinschek [EMAIL PROTECTED] wrote:
 Hmmm... Why not provide a custom Facelets-Tag for this?
   
Because that's the wrong approach to fixing the problem.
   
 The thing is that also the component will be generated - so we can't
 really have much custom code there, right?
   
Why would the component be generated?  That's where all of the
component-specific logic is.
   
  
 
 
  --
 
  http://www.irian.at
 
  Your JSF powerhouse -
  JSF Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 





--

http://www.irian.at

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

Professional Support for Apache MyFaces

[jira] Commented: (TOMAHAWK-261) Do not use document.write in popup calendars

[ 
http://issues.apache.org/jira/browse/TOMAHAWK-261?page=comments#action_12436665 
] 

Martin Marinschek commented on TOMAHAWK-261:


And by the way: I don't suppose that Netscape 4 is a browser we still support. 
If anybody has problems though, please reopen this issue.

regards,

Martin

 Do not use document.write in popup calendars
 

 Key: TOMAHAWK-261
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-261
 Project: MyFaces Tomahawk
  Issue Type: Improvement
  Components: Calendar, Date
Affects Versions: 1.1.1, 1.1.2-SNAPSHOT, 1.1.3-SNAPSHOT
Reporter: Andrew Robinson
 Assigned To: Martin Marinschek
Priority: Blocker
 Fix For: 1.1.4-SNAPSHOT

 Attachments: HtmlCalendarRenderer.patch


 The popup calednar for the date control (and I think the calendar control) 
 uses javascript document.write methods. Unfortunately this is not very 
 compatible with AJAX as it is hard to write content to the document after the 
 document is closed.
 Instead, can this be changed to have: 
 A) printed hidden component  (visibility: hidden; display: none) and just 
 shown when the user clicks the popup button.
 or 
 B) Use the DOM JavaScript API to add new elements to the DOM instead of 
 document.write.
 Unless this is changed, these controls cannot be used with AjaxAnywhere and 
 probably not with other AJAX solutions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (TOMAHAWK-683) r448673 broke message validator attribute -- needs to be moved from JSP Tag to Component.

2006-09-21 Thread Mike Kienenberger (JIRA)

r448673 broke message validator attribute -- needs to be moved from JSP Tag 
to Component.
---

 Key: TOMAHAWK-683
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-683
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Validators
Affects Versions: 1.1.5-SNAPSHOT
 Environment: facelets
Reporter: Mike Kienenberger
Priority: Critical


Too much logic got put into the ValidatorTag that needs to be in the validator 
class directly.
Can no longer set the message attribute.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (TOMAHAWK-127) Some components do not render valid html

[ 
http://issues.apache.org/jira/browse/TOMAHAWK-127?page=comments#action_12436670 
] 

Martin Marinschek commented on TOMAHAWK-127:


The patch is not valid anymore, and can't be applied automatically (it's in a 
strange format). I'm not sure about the correct position where to apply the 
changes manually. Can you do this patch again?

thanks,

regards,

Martin

 Some components do not render valid html
 

 Key: TOMAHAWK-127
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-127
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Panel Navigation2
 Environment: tested on jboss4.0.3/sun jdk 1.5.0_r05/linux with 
 myFaces 1.1.1 and nightly build 20051230
Reporter: Carsten Stiller
 Assigned To: Martin Marinschek
Priority: Minor
 Attachments: HtmlNavigationMenuRendererUtils.java.diff


 Some components do not render valid html (checked with w3c-validator against 
 HTML4.01strict and XHTML1.0)
 h:form /: The hidden input /-Tag has to be inside a block-element (a  
 div / or whatever)
 rendered code:
 form
 ...
   input name=form_SUBMIT value=1 type=hidden /
 /form
 w3c-validator message: document type does not allow element INPUT here; 
 missing one of P, H1, H2, H3, H4, H5, H6, PRE, DIV, 
 ADDRESS start-tag.
 h:selectManyListbox /: Attribute is rendered as 'multiple=true'  instead 
 of 'multiple=multiple'
 rendered code: 
 select id=... name=... multiple=true
 ...
 /select
 w3c-validator message: value of attribute MULTIPLE cannot be TRUE; must 
 be one of MULTIPLE.
 t:panelNavigation2 /: When layout=list is selected and nested menus  are 
 used, non-active parts of the menu-trees include empty ul /-tags.  (At 
 least one li / is required inside of ul/ul).
 jsf-code:
 t:panelNavigation2 id=... layout=...
   t:commandNavigation2 id=... action=... value=...
   t:commandNavigation2 id=... value=... action=... /
   t:commandNavigation2 id=... value=... action=... /  
 
   /t:commandNavigation2 
   t:commandNavigation2 id=... action=... value=... /
 /t:panelNavigation2
 rendered code, when menu-tree is closed:
 ul
 lia href=... id=.. /aul/ul/li
 lia href=... id=../a/li
 /ul
 w3c-validator message: end tag for UL which is not finished.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (TOMAHAWK-128) Incorrect inputCalendar position when placed in DIV tag with position: absolute;

 [ http://issues.apache.org/jira/browse/TOMAHAWK-128?page=all ]

Martin Marinschek updated TOMAHAWK-128:
---

   Status: Resolved  (was: Patch Available)
Fix Version/s: 1.1.4-SNAPSHOT
   Resolution: Fixed
 Assignee: Martin Marinschek

Thanks to Pawel Koloszko for this fix.

regards,

Martin

 Incorrect inputCalendar position when placed in DIV tag with position: 
 absolute;
 

 Key: TOMAHAWK-128
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-128
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Calendar
Reporter: Pawel Koloszko
 Assigned To: Martin Marinschek
 Fix For: 1.1.4-SNAPSHOT

 Attachments: popcalendar.js.diff


 On my page I have something like that
 t:div id=pageBody styleClass=pageBody
   t:inputCalendar id=dataUrodzenia renderAsPopup=true/
 /t:div
 pageBodyClass is:
 div.pageBody {
   position: absolute;
   top: 80px;
   left: 165px;
   bottom: 25px;
   width: 635px;   
 height: 400px;
 }
 With such layuot popupCalendar is not rendered next to inputCalendar button 
 as it should.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (TOMAHAWK-176) forceId not working on inputCalendar

 [ http://issues.apache.org/jira/browse/TOMAHAWK-176?page=all ]

Martin Marinschek updated TOMAHAWK-176:
---

Status: Resolved  (was: Patch Available)
Resolution: Fixed

 forceId not working on inputCalendar
 

 Key: TOMAHAWK-176
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-176
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Calendar
Affects Versions: 1.1.2-SNAPSHOT
 Environment: Facelets
Reporter: Geoffrey Longo
 Assigned To: Mario Ivankovits
 Fix For: 1.1.4-SNAPSHOT


 inputCalendar is still generating an id even though forceId attribute is set 
 to true.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [continuum] BUILD FAILURE: Tomahawk Core

2006-09-21 Thread Grant Smith

Martin,you wanna get this one ?:)On 9/21/06, [EMAIL PROTECTED]
 [EMAIL PROTECTED] wrote:
Online report : http://myfaces.zones.apache.org:8080/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/16/buildId/4474
Build statistics:State: FailedPrevious State: OkStarted at: Thu, 21 Sep 2006 22:12:05 +Finished at: Thu, 21 Sep 2006 22:12:30 +Total time: 24sBuild Trigger: Schedule
Exit code: 1Building machine hostname: myfaces.zones.apache.orgOperating system : SunOS(unknown)Java version : 1.5.0_07(Sun Microsystems Inc.)Changes
 mmarinschekfix for TOMAHAWK-197 : More CSS for TabbedPane (incl. patch with solution). Thanks to Wolfgang Engelhard for this patch /myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlTabbedPaneRenderer.java
 mmarinschekfix for TOMAHAWK-97:TabbedPane active sub header uses wrong user defined styleClass. Thanks to Jim Wright for this patch. /myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlTabbedPaneRenderer.java
 mmarinschekfix for TOMAHAWK-261 : Do not use document.write in popup calendars. Thanks to Andrew Robinson for supplying this patch. /myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/calendar/HtmlCalendarRenderer.java
 mmarinschekfix for TOMAHAWK-115 : Thanks to Steve Peterson for better documentation. /myfaces/tomahawk/trunk/core/src/main/tld/tomahawk-entities/tomahawk_radio_attributes.xml/myfaces/tomahawk/trunk/core/src/main/tld/tomahawk.tld
 mmarinschekfix for TOMAHAWK-128 : Incorrect inputCalendar position when placed in DIV tag with position: absolute. Thanks to Mirco Attocchi for providing this patch. /myfaces/tomahawk/trunk/core/src/main/resources/org/apache/myfaces/custom/calendar/resource/popcalendar.js
Output:[INFO] Scanning for projects...[INFO] Searching repository for plugin with prefix: 'source'.
[INFO] [INFO] Building Tomahawk Core[INFO]task-segment: [clean, install, source:jar, deploy, site-deploy][INFO] 
[INFO] [clean:clean][INFO] Deleting directory /local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/16/target[INFO] Deleting directory /local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/16/target/classes
[INFO] Deleting directory /local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/16/target/test-classes[INFO] [dependency:unpack {execution: unpack-shared-impl-sources}][INFO] Configured Artifact: org.apache.myfaces.shared:myfaces-shared-tomahawk:sources:2.0.4-SNAPSHOT:jar
[INFO] Expanding: /export/home/mrmaven/.m2/repository/org/apache/myfaces/shared/myfaces-shared-tomahawk/2.0.4-SNAPSHOT/myfaces-shared-tomahawk-2.0.4-SNAPSHOT-sources.jar into /local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/16/target/shared_sources
[INFO] [xslt:transform {execution: default}][INFO] # of XML files: 1[INFO] transform, srcFile: /local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/16/src/main/tld/tomahawk.tld, destFile: /local/continuum-
1.0.3-SNAPSHOT/apps/continuum/working-directory/16/target/classes/META-INF/tomahawk.tld[INFO] [xslt:transform {execution: generate-tld-for-jar}][INFO] # of XML files: 1[INFO] file up-to-date: /local/continuum-
1.0.3-SNAPSHOT/apps/continuum/working-directory/16/target/classes/META-INF/tomahawk.tld[INFO] [xslt:transform {execution: generate-tld-for-tlddoc}][INFO] # of XML files: 1[INFO] transform, srcFile: /local/continuum-
1.0.3-SNAPSHOT/apps/continuum/working-directory/16/src/main/tld/tomahawk.tld, destFile: /local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/16/target/tlddoc-site/tomahawk.tld[INFO] [build-helper:add-source {execution: add-source}]
[INFO] Source directory: /local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/16/target/shared_sources added.[INFO] [resources:resources][INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]Compiling 410 source files to /local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/16/target/classes[INFO] 
[ERROR] BUILD FAILURE[INFO] [INFO] Compilation failure/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/16/src/main/java/org/apache/myfaces/custom/date/HtmlDateRenderer.java:[300,45] getScriptBtn(
javax.faces.context.ResponseWriter,javax.faces.context.FacesContext,javax.faces.component.UIComponent,java.lang.String,java.lang.String,org.apache.myfaces.custom.calendar.FunctionCallProvider) in org.apache.myfaces.custom.calendar.HtmlCalendarRenderer
 cannot be applied to

[jira] Updated: (TOMAHAWK-409) Sandbox 'form' code not working

 [ http://issues.apache.org/jira/browse/TOMAHAWK-409?page=all ]

Martin Marinschek updated TOMAHAWK-409:
---

   Status: Resolved  (was: Patch Available)
Fix Version/s: 1.1.4-SNAPSHOT
   Resolution: Fixed
 Assignee: Martin Marinschek

This had already been fixed on the HEAD. Thanks to Peter Muir for this patch 
still.

regards,

Martin

 Sandbox 'form' code not working
 ---

 Key: TOMAHAWK-409
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-409
 Project: MyFaces Tomahawk
  Issue Type: Bug
Affects Versions: 1.1.3-SNAPSHOT
 Environment: MyFaces 1.1.2, Tomahawk 1.1.3-SNAPSHOT (CVS as of 
 02/05/2006),Tomahawk-Sandbox 1.1.3-SNAPSHOT (CVS as of 02/05/2006)
Reporter: Peter Muir
 Assigned To: Martin Marinschek
 Fix For: 1.1.4-SNAPSHOT

 Attachments: Sandbox-form.patch


 The Sandbox form component allows the action attribute to be manually 
 specified by overriding the getActionUrl(FacesContext facesContext, UIForm 
 form) method. However the HtmlFormRendererBase class's encodeBegin method 
 calls getActionUrl(facesContext) meaning that, in fact the 
 getActionUrl(FacesContext facesContext, UIForm form) in the subclass isn't 
 called.
 I can't see any way using getActionUrl(facesContext) to alter the forms 
 action attribute so, as a work around I've written my own custom form 
 component which overrides encodeBegin.  Is it possible that 
 HtmlFormRendererBase can be altered so it uses getActionUrl(FacesContext 
 facesContext, UIForm form) ?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (TOMAHAWK-442) onclick attribute needed

 [ http://issues.apache.org/jira/browse/TOMAHAWK-442?page=all ]

Martin Marinschek updated TOMAHAWK-442:
---

   Status: Resolved  (was: Patch Available)
Fix Version/s: 1.1.4-SNAPSHOT
   Resolution: Fixed
 Assignee: Martin Marinschek

Thanks to Michael Heinen for providing this patch.

regards,

Martin

 onclick attribute needed
 

 Key: TOMAHAWK-442
 URL: http://issues.apache.org/jira/browse/TOMAHAWK-442
 Project: MyFaces Tomahawk
  Issue Type: Improvement
  Components: Data Scroller
Affects Versions: 1.1.1, 1.1.3-SNAPSHOT, 1.1.2
 Environment: all
Reporter: Michael Heinen
 Assigned To: Martin Marinschek
Priority: Minor
 Fix For: 1.1.4-SNAPSHOT

 Attachments: Datascroller.patch


 DataScroller does not provide an onclick attribute / javascript event handler.
 I have to execute some javascript in order to show a confirmation dialogue if 
 data has been changed on my form but not saved.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (TOMAHAWK-519) component not fully stylable, missing styleClass parameters