[jira] Commented: (TOMAHAWK-638) Tomahawk Schedule style class attributes are ignored under facelets. (Ex: dayClass, entryClass, etc)
[ http://issues.apache.org/jira/browse/TOMAHAWK-638?page=comments#action_12436751 ] Mike Kienenberger commented on TOMAHAWK-638: Are you sure these are ignored? Facelets will also report this warning if the attributes are generic (ie, there's no setHeaderClass() attribute, instead a generic UIComponent attribute is used). The thing to do is to test it first and see if they're still working in spite of the warning. If so, then we'll change this issue to "change generic attributes to concrete attributes" so it works better with alternate view handlers. If not, then we'll have to figure out why these attributes aren't working (perhaps the jsp ScheduleTag passes the attribute with a different name to the Schedule component -- that's a bug for non-jsp component handlers). > Tomahawk Schedule style class attributes are ignored under facelets. (Ex: > dayClass, entryClass, etc) > > > Key: TOMAHAWK-638 > URL: http://issues.apache.org/jira/browse/TOMAHAWK-638 > Project: MyFaces Tomahawk > Issue Type: Bug > Components: Schedule >Reporter: Mikhail Grushinskiy > Assigned To: Jurgen Lust >Priority: Minor > Fix For: 1.1.4-SNAPSHOT, 1.1.5-SNAPSHOT > > > Tomahawk Schedule style class attributes are ignored under facelets. (Ex: > dayClass, entryClass, etc) > The following are warnings from facelets > Property 'headerClass' is not on type: > org.apache.myfaces.custom.schedule.HtmlSchedule > Property 'dayClass' is not on type: > org.apache.myfaces.custom.schedule.HtmlSchedule > facelets 1.1.11 > --MG -- 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-1414) Invalid resource link on Getting Started page
[ http://issues.apache.org/jira/browse/MYFACES-1414?page=comments#action_12436744 ] Mike Kienenberger commented on MYFACES-1414: Bruno, it looks broken to me. Not sure why you think it's fixed. > Invalid resource link on Getting Started page > - > > Key: MYFACES-1414 > URL: http://issues.apache.org/jira/browse/MYFACES-1414 > Project: MyFaces Core > Issue Type: Bug > Components: website >Reporter: Popcorn > > On the Getting started page (http://myfaces.apache.org/gettingstarted.html), > the URL referred to by "here" does not have the MyFaces examples webapp > archive. It is nowhere to be found! > MyFaces examples. Latest milestone webapp archive (myfaces-X.X.X-examples.zip > or myfaces-X.X.X-examples.tgz) is here > The here link points to the download page -> > http://myfaces.apache.org/download.html > This needs to be fixed ASAP. It is a big problem for newbies! -- 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-261) Do not use document.write in popup calendars
[ http://issues.apache.org/jira/browse/TOMAHAWK-261?page=comments#action_12436695 ] Jeremy Grelle commented on TOMAHAWK-261: I don't mean to nitpick or anything, but it was actually me that provided the working patch. ;) Thank you for checking it out and applying it, Martin. Thanks, Jeremy > 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] Commented: (TOMAHAWK-519) component not fully stylable, missing styleClass parameters
[ http://issues.apache.org/jira/browse/TOMAHAWK-519?page=comments#action_12436684 ] Martin Marinschek commented on TOMAHAWK-519: You're supposed to further style the component by changing the CSS-file itself. regards, Martin > component not fully stylable, missing styleClass parameters > --- > > Key: TOMAHAWK-519 > URL: http://issues.apache.org/jira/browse/TOMAHAWK-519 > Project: MyFaces Tomahawk > Issue Type: Bug > Components: Tabbed Pane >Affects Versions: 1.1.3 >Reporter: Mathias Werlitz >Priority: Minor > > Component ist not fully stylable. There are missing tag parameters etc. for > extending/overwriting the style classes: > "myFaces_panelTabbedPane_subHeaderCell_first" > "myFaces_panelTabbedPane_subHeaderCell_last" > This makes it impossible for example to style the component with a 1px border. -- 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
Out of Office AutoReply: [jira] Updated: (TOMAHAWK-409) Sandbox 'form' code not working
Title: Out of Office AutoReply: [jira] Updated: (TOMAHAWK-409) Sandbox 'form' code not working I am away until 25th September. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
[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] 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
Re: [continuum] BUILD FAILURE: Tomahawk Core
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: Failed Previous State: Ok Started at: Thu, 21 Sep 2006 22:12:05 + Finished at: Thu, 21 Sep 2006 22:12:30 + Total time: 24s Build Trigger: Schedule
Exit code: 1 Building machine hostname: myfaces.zones.apache.org Operating system : SunOS(unknown) Java version : 1.5.0_07(Sun Microsystems Inc.)Changes
mmarinschek fix 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
mmarinschek fix 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
mmarinschek fix 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
mmarinschek fix 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
mmarinschek fix 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
[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
[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
>
>
>
> 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] 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) > : The hidden -Tag has to be inside a block-element (a > or whatever) > rendered code: > > ... > > > 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. > : Attribute is rendered as 'multiple="true"' instead > of 'multiple="multiple"' > rendered code: > > ... > > w3c-validator message: value of attribute "MULTIPLE" cannot be "TRUE"; must > be one of "MULTIPLE". > : When layout="list" is selected and nested menus are > used, non-active parts of the menu-trees include empty -tags. (At > least one is required inside of ). > jsf-code: > > > > > > > > > rendered code, when menu-tree is closed: > > ... > ... > > 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] Created: (TOMAHAWK-683) r448673 broke "message" validator attribute -- needs to be moved from JSP Tag to Component.
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-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
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
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...]]
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...]]
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
[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...]]
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 >
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
[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
>
>
>
>
> value="#{testBean.firstNumber}" required="true"/>
>
> value="#{testBean.secondNumber}" required="true"/>
>
>
>value="Add"/>
>
>
>
> 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...]]
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-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 : >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: > >class="myFaces_panelTabbedPane_subHeaderCell > myFaces_panelTabbedPane_subHeaderCell_first inactiveSub > myFaces_panelTabbedPane_subHeaderCell_inactive"> >class="myFaces_panelTabbedPane_subHeaderCell inactiveSub > myFaces_panelTabbedPane_subHeaderCell_inactive"> >class="myFaces_panelTabbedPane_subHeaderCell inactiveSub > myFaces_panelTabbedPane_subHeaderCell_active"> >class="myFaces_panelTabbedPane_subHeaderCell inactiveSub > myFaces_panelTabbedPane_subHeaderCell_inactive"> > > -- 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] Commented: (TOMAHAWK-214) t:outputText attribute \n ->
[ 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 -> > -- > > 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 ''. -- 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] Updated: (TOMAHAWK-214) t:outputText attribute \n ->
[ http://issues.apache.org/jira/browse/TOMAHAWK-214?page=all ] Martin Marinschek updated TOMAHAWK-214: --- Status: Open (was: Patch Available) > t:outputText attribute \n -> > -- > > 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 ''. -- 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 .
> 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 admin
[jira] Commented: (TOMAHAWK-606) t:commandLink does not work - gives javascript error
[
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
>
>
>
>
> value="#{testBean.firstNumber}" required="true"/>
>
> value="#{testBean.secondNumber}" required="true"/>
>
>
>value="Add"/>
>
>
>
> 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...]]
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-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...]]
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.
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...]]
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=rev&rev=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=diff&rev=448673&r1=448672&r2=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 || messageI
[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
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=rev&rev=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=diff&rev=448673&r1=448672&r2=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)
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.
Re: [jira] Updated: (TOMAHAWK-50) equals validator shows text (nit nice by validating passwords...)
On 9/21/06, Martin Marinschek (JIRA) 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.
[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 > > > > 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? > -- 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
[ 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: (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 ] 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] Updated: (TOMAHAWK-46) Duplicate component ID '_id0:scheduleNavigator_1141102800000_link'
[ http://issues.apache.org/jira/browse/TOMAHAWK-46?page=all ] Martin Marinschek updated TOMAHAWK-46: -- Status: Resolved (was: Patch Available) Fix Version/s: 1.1.4-SNAPSHOT Resolution: Fixed Assignee: Martin Marinschek Thanks to Tomonori Iwata for this fix. > Duplicate component ID > '_id0:scheduleNavigator_114110280_link' > > > Key: TOMAHAWK-46 > URL: http://issues.apache.org/jira/browse/TOMAHAWK-46 > Project: MyFaces Tomahawk > Issue Type: Bug > Components: Calendar > Environment: Windows 2003 Server, Tomcata 5.x, Pentum IV 1gb RAM. >Reporter: Adrián Villegas > Assigned To: Martin Marinschek > Fix For: 1.1.4-SNAPSHOT > > Attachments: HtmlCalendarRenderer.patch, My faces error.doc, schedule > fail.doc > > > I run the examples of Myfaces > On January 31st , when i click on month's navigator links, the following > error happend: > Duplicate component ID '_id0:scheduleNavigator_114110280_link' > Previously on forward click from January go to March and another click more > the error page. > This error don't happend on february 1st. > ¿? -- 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
Thanks, the build worked again. I'll add this to the wikiOn 9/21/06, Bernd Bohmann <[EMAIL PROTECTED] > wrote:Hello,in /usr/local/continuum/apps/continuum/working-directory/ you will find the working directorythe projectId for Apache Incubator Trinidad Podling is 146.Already invoke svn cleanup on this dir :-)BerndGrant 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> -- Grant Smith
[jira] Reopened: (TOMAHAWK-606) t:commandLink does not work - gives javascript error
[ http://issues.apache.org/jira/browse/TOMAHAWK-606?page=all ]
Martin Marinschek reopened TOMAHAWK-606:
> 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
>
>
>
>
> value="#{testBean.firstNumber}" required="true"/>
>
> value="#{testBean.secondNumber}" required="true"/>
>
>
>value="Add"/>
>
>
>
> 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] 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\)"
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
>
>
>
>
> value="#{testBean.firstNumber}" required="true"/>
>
> value="#{testBean.secondNumber}" required="true"/>
>
>
>value="Add"/>
>
>
>
> 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: [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 objectThanks,Mahbub"Martin Marinschek (JIRA)" wrote: [ http://issues.apache.org/jira/browse/TOMAHAWK-606?page=all ]Martin Marinschek resolved TOMAHAWK-606.Fix Version/s: 1.1.5-SNAPSHOT Resolution: Fixed> 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> > > > > > > >>> > > > > 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 Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min.
Re: [continuum] BUILD ERROR: Apache Incubator Trinidad Podling
Hello, in /usr/local/continuum/apps/continuum/working-directory/ 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
Re: [continuum] BUILD ERROR: Apache Incubator Trinidad Podling
As far as I know, the working directory is purged each build. I'll check it outp.s. sorry I missed your #myfaces message in irc yesterdayOn 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. Isthis 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 -- Grant Smith
Re: [continuum] BUILD ERROR: Apache Incubator Trinidad Podling
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: (MYFACES-1416) MyFaces doesnt work with Tomcat 5.0.28 and 5.5
[ 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 -
[jira] Resolved: (TOBAGO-135) Changed MyFaces Core dependency to provided
[ 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] Created: (TOBAGO-135) Changed MyFaces Core dependency to provided
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-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
[OT] Job offer
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] 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
Re: JScookMenu is not rendered with Facelets
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] Commented: (TOMAHAWK-682) Editor does not work anymore in Firefox
[ 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
[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] 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
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: (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
[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: (TOMAHAWK-682) Editor does not work anymore in Firefox
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
[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-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
Re: JScookMenu is not rendered with Facelets
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] 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): > styleClass="tree" > nodeClass="treenode" > selectedNodeClass="treenodeSelected" > expandRoot="true"> > > > 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
[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] 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] 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
Re: Outcome of the Google Sommer of Code project Partial State Saving
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 were>a) Create an partial State Saving Tree>b) 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.savestate>>6.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 fluctuate a 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>>
Re: JScookMenu is not rendered with Facelets
So now we got it. The rederer-type is missing in your /WEB-INF/tomahawk.taglib.xml jscookMenu org.apache.myfaces.JSCookMenu org.apache.myfaces.JSCookMenu -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: 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 jscookMenu org.apache.myfaces.JSCookMenu faces-config definse JSCookMenu as org.apache.myfaces.JSCookMenu org.apache.myfaces.custom.navmenu.jscookmenu.HtmlCommandJSCookMenu 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: JScookMenu is not rendered with Facelets
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: 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 jscookMenu org.apache.myfaces.JSCookMenu faces-config definse JSCookMenu as org.apache.myfaces.JSCookMenu org.apache.myfaces.custom.navmenu.jscookmenu.HtmlCommandJSCookMenu 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.
[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
[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: 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-1414) Invalid resource link on Getting Started page
[ http://issues.apache.org/jira/browse/MYFACES-1414?page=all ] Popcorn reopened MYFACES-1414: -- I cannot find myfaces-1.1.4-examples.zip (or myfaces-1.1.4-examples.tgz) on the download page http://myfaces.apache.org/download.html. Where can u see those? Thanks. > Invalid resource link on Getting Started page > - > > Key: MYFACES-1414 > URL: http://issues.apache.org/jira/browse/MYFACES-1414 > Project: MyFaces Core > Issue Type: Bug > Components: website >Reporter: Popcorn > > On the Getting started page (http://myfaces.apache.org/gettingstarted.html), > the URL referred to by "here" does not have the MyFaces examples webapp > archive. It is nowhere to be found! > MyFaces examples. Latest milestone webapp archive (myfaces-X.X.X-examples.zip > or myfaces-X.X.X-examples.tgz) is here > The here link points to the download page -> > http://myfaces.apache.org/download.html > This needs to be fixed ASAP. It is a big problem for newbies! -- 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: Thanks to Sean and Wendy for 1.1.4 Core!
Hey! I would also like to thank Matthias, who also put a fair amount of time into getting this release out of the door. > I don't normally like to waste bandwidth thanking people, but Sean and > Wendy put in a tremendous amount of work getting 1.1.4 out the door > over the course of several months. I know Dennis also made himself > available frequently to retest. Thanks to you all! > Ciao, Mario
[jira] Commented: (MYFACES-1389) Impossible to escape "{", "}" characters in parameterized messages.
[
http://issues.apache.org/jira/browse/MYFACES-1389?page=comments#action_12436462
]
Guy Bashan commented on MYFACES-1389:
-
I had to escape: "{" character. I did "'{'" and it is working great. thanks.
> 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
>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-1414) Invalid resource link on Getting Started page
[ http://issues.apache.org/jira/browse/MYFACES-1414?page=all ] Bruno Aranda resolved MYFACES-1414. --- Resolution: Cannot Reproduce Hi, I cannot reproduce the issue, so I guess it is already fixed. Thanks! Bruno > Invalid resource link on Getting Started page > - > > Key: MYFACES-1414 > URL: http://issues.apache.org/jira/browse/MYFACES-1414 > Project: MyFaces Core > Issue Type: Bug > Components: website >Reporter: Popcorn > > On the Getting started page (http://myfaces.apache.org/gettingstarted.html), > the URL referred to by "here" does not have the MyFaces examples webapp > archive. It is nowhere to be found! > MyFaces examples. Latest milestone webapp archive (myfaces-X.X.X-examples.zip > or myfaces-X.X.X-examples.tgz) is here > The here link points to the download page -> > http://myfaces.apache.org/download.html > This needs to be fixed ASAP. It is a big problem for newbies! -- 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-434) MyFaces's Portlet enhancement
[ http://issues.apache.org/jira/browse/MYFACES-434?page=comments#action_12436457 ] Stephan Strittmatter commented on MYFACES-434: -- Having this integration for Tomahawk 1.1.4 would be very helpful for us! I will already say thank you for your work on this issue! Probably I can suport you on testing on Liferay portlets having fileupload features. > MyFaces's Portlet enhancement > - > > Key: MYFACES-434 > URL: http://issues.apache.org/jira/browse/MYFACES-434 > Project: MyFaces Core > Issue Type: Improvement > Components: Portlet_Support >Affects Versions: 1.1.0 > Environment: LInux, J2SE 1.4.2 >Reporter: Shinsuke SUGAYA > Assigned To: Martin Marinschek > Attachments: filter051230.patch, filter051230.tar.gz, > filterportlet.patch, filterportlet.tar.gz, headerresource_for_j2.tar.gz, > impl-filter-noAddResources-060315.patch, newfile_for_portlet.tar.gz, > patch_for_portlet.patch, tomahawk-filter-noAddResources-060315.patch, > Tomahawk_FileUpload_IBMPortal.zip > > > MyFacesGenericPortlet does not fully support the feature of tomahawk > component, such as inputHtml and fileUpload. So, I request the following > feature to run it on portlet: > - support tags in (ex. inputHtml component) > - support upload (fileUpload component) -- 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
