Re: tomahawk-sandbox-1.1.6-SNAPSHOT-- DOJO error...Thanks Zdenek
This question is more appropriate for the user list.
Prashant Gaikwad wrote:
Hi Zdenek,
Thanks for the response. DOJO error is gone. But another problem is my t:dataTable in the JSP is not refreshing with the latest updates in corresponding database.
Below is the snippet. Please suggest how the view would be partially grgenreated.
Thanks
Prashant
t:panelGrid
s:pprPanelGroup id=periodicalUpdatedArea styleClass=general_font_datagrid
periodicalUpdate=1000
t:dataTableid=data
styleClass=scrollerTable,standardTable
headerClass=standardTable_Header
footerClass=standardTable_Header
rowClasses=standardTable_Row1,standardTable_Row2
columnClasses=standardTable_Column,standardTable_ColumnCentered
var=student
preserveDataModel=false
binding=#{Student.data}
value=#{Student.dataModel.value}
rows=#{Student.dataModel.rows}
rowId=#{student.id}
sortColumn=#{Student.dataModel.sortColumn}
sortAscending=#{Student.dataModel.sortAscending}
preserveSort=true
h:column
f:facet name=header
t:commandSortHeader columnName=studentid immediate=false arrow=true actionListener=#{Student.actionListener}
onclick=if (!confirm(' Sort by Student Id?')) return false styleClass=standardTable_SortHeader
h:outputText value=#{bundles.Student_id}/
/t:commandSortHeader
/f:facet
h:outputText value=#{student.id}/
/h:column
h:column
f:facet name=header
t:commandSortHeader columnName=name immediate=false arrow=true
actionListener=#{Student.actionListener}
onclick=if (!confirm(' Sort by Student Name ?')) return false
styleClass=standardTable_SortHeader
h:outputText value=#{bundles.Name}/
/t:commandSortHeader
/f:facet
h:outputText value=#{student.name}/
/h:column
h:column
f:facet name=header
t:commandSortHeader columnName=grade immediate=false arrow=true
actionListener=#{Student.actionListener}
onclick=if (!confirm(' Sort by Grade ?')) return false
styleClass=standardTable_SortHeader
h:outputText value=#{bundles.Grade}/
/t:commandSortHeader
/f:facet
h:outputText value=#{student.grade}/
/h:column
h:column
f:facet name=header
t:commandSortHeader columnName=topic_news immediate=false arrow=true
actionListener=#{Student.actionListener}
onclick=if (!confirm(' Sort by Topic ?')) return false
styleClass=standardTable_SortHeader
h:outputText value=#{bundles.topic}/
/t:commandSortHeader
/f:facet
h:outputText value=#{student.topic}/
/h:column
h:column
f:facet name=header
h:outputText value=#{bundles.Priority}/
/f:facet
h:outputText value=#{student.priority}/
/h:column
h:column
f:facet name=header
h:outputText
value=#{bundles.Comment_Can_update_only_your_own_comment}/
/f:facet
t:inputTextarea cols=50 value=#{student.comments}
/t:inputTextarea
f:verbatimbr/br/f:verbatim
/h:column
/t:dataTable
/s:pprPanelGroup
/t:panelGrid
-Original Message-
From: Zdeněk Sochor [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 05, 2007 1:50 PM
To: MyFaces Development
Subject: Re: tomahawk-sandbox-1.1.6-SNAPSHOT-- DOJO error...
Hi Prashant,
Dojo is present in Tomahawk CORE 1.1.5 (and snapshot 1.1.6), NOT in 1.1.3.
Download BOTH snapshots - Tomahawk CORE and sandbox to make it work.
Regards,
Zdenek
Prashant Gaikwad napsal(a):
Dear Developer friends,
Need small help to resolve problem I
am facing with tomahawk-sandbox-1.1.6-SNAPSHOT.jar.
I downloaded above jar file from nightly build link. I want to
implement s:pprPanelGroup for asynchronous (AJAX) refresh of
t:dataTable. On implementing sample application from
http://www.irian.at/myfaces.jsf. I am getting following
[jira] Commented: (MYFACES-1414) Invalid resource link on Getting Started page
[ https://issues.apache.org/jira/browse/MYFACES-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486962 ] Jeff Bischoff commented on MYFACES-1414: The language on this website page is still confusing new users into erroneously downloading the old MyFaces examples from 1.1.1. Once the next Tomahawk is released, and official examples are on the download page, we should update this getting started page to reference the correct file names, i.e. tomahawk-examples, not myfaces-examples. The current language is misleading: MyFaces examples. Latest milestone webapp archive (myfaces-X.X.X-examples.zip or myfaces-X.X.X-examples.tgz) is here. We should update the language to be less confusing, something like: MyFaces examples. Latest milestone webapp archive (tomahawk-examples-X.X.X-bin.zip or tomahawk-examples-X.X.X-bin.tar.gz ) is here. Invalid resource link on Getting Started page - Key: MYFACES-1414 URL: https://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. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1414) Invalid resource link on Getting Started page
[ https://issues.apache.org/jira/browse/MYFACES-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486980 ] Jeff Bischoff commented on MYFACES-1414: Unfortunately, I have a tight deadline to meet today. If I can, I'll come back to this another day. Invalid resource link on Getting Started page - Key: MYFACES-1414 URL: https://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. - You can reply to this email to add a comment to the issue online.
Re: [ApacheCon] BOFs
not if it's in London, like the JAVAWUG ;P Matthias Wessendorf wrote: Hey, anyone interested in a MyFaces BOF ? http://wiki.apache.org/apachecon/BirdsOfaFeatherEu07 -M
Re: [VOTE] MyFaces Tomahawk 1.1.5
+1 Tested against MyFaces Core 1.1.5 inside my web application. Thanks Manfred for all the hard work to finally get this release done! Regards, Jeff Bischoff Kenneth L Kurz Associates, Inc. Manfred Geiler wrote: Hi all, This is the official vote for MyFaces Tomahawk 1.1.5. (aka The Tomahawk Easter Release 2007 - can you find the egg?) Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.tomahawk v1.1.5 [1] 2. MyFaces Tomahawk Assembly [2] 3. MyFaces Tomahawk Examples Assembly [2] 4. MyFaces Tomahawk Sandbox Assembly [2] 5. MyFaces Tomahawk Sandbox Examples Assembly [2] 6. Proposed Release Announcement [3] Please note: This vote is majority approval with a minimum of three +1 votes (see [4]). I know this release is overdue but please do only cast a +1 if you really have tested the artifacts and assemblies and not only because you have waited so long... ;-) Please cast your votes: [ ] +1 (I confirm that I tested this release and therefore approve it) [ ] +0 (I have no time to test now but I look forward to this new release) [ ] -1 (Serious concerns because...) --Manfred [1] http://people.apache.org/builds/myfaces/m2-staging-repository/ [2] http://people.apache.org/builds/myfaces/tomahawk-1.1.5/ [3] http://wiki.apache.org/myfaces/TomahawkRelease115#releasenotes [4] http://www.apache.org/foundation/voting.html#ReleaseVotes
Re: JSP viewhandler: automatic id warning when using masterDetail.jsf
Mike, I get that warning message if I use a h:form with no id attribute. In fact, I see this warning on almost every page in the simple Tomahawk example app (and they don't have an id set on the form). Perhaps the warning message could be more clear? To put it another way, if I add an id to the simple example pages, then the warning goes away. Regards, Jeff Bischoff Kenneth L Kurz Associates, Inc. Mike Kienenberger wrote: I'm not going to try to track this one down since I don't do jsp. But here's a strange warning -- UIViewRoot got assigned an automatic id in masterDetail.jsf. INFO: WARNING: Component _id0 just got an automatic id, because there was no id assigned yet. If this component was created dynamically (i.e. not by a JSP tag) you should assign it an explicit static id or assign it the id you get from the createUniqueId from the current UIViewRoot component right after creation! clientID = parent.getClientId(getFacesContext()); parent= UIViewRoot (id=44) _attributesMap= null _childrenList= _ComponentChildrenList (id=100) _clientId= _id0 _events= null _facesListeners= null _facetMap= null _id= _id0 _locale= Locale (id=106) _parent= null _rendered= null _rendererType= null _renderKitId= HTML_BASIC _transient= false _uniqueIdCounter= 1 _valueBindingMap= null _viewId= /masterDetail.jsp
Re: JSP viewhandler: automatic id warning when using masterDetail.jsf
According the the Sun docs [1], it is not a required attribute. Is that official enough? (There is nothing in the spec itself about attributes of core tags, is there?) So should we remove this warning altogether, or just change it? I would be happy to open the JIRA for it, after lunch. :) Mike Kienenberger wrote: Jeff, Mind opening an issue on this? I don't remember if h:form requires an id, but I don't think it is supposed to. On 3/30/07, Jeff Bischoff [EMAIL PROTECTED] wrote: Mike, I get that warning message if I use a h:form with no id attribute. In fact, I see this warning on almost every page in the simple Tomahawk example app (and they don't have an id set on the form). Perhaps the warning message could be more clear? To put it another way, if I add an id to the simple example pages, then the warning goes away. Regards, Jeff Bischoff Kenneth L Kurz Associates, Inc. Mike Kienenberger wrote: I'm not going to try to track this one down since I don't do jsp. But here's a strange warning -- UIViewRoot got assigned an automatic id in masterDetail.jsf. INFO: WARNING: Component _id0 just got an automatic id, because there was no id assigned yet. If this component was created dynamically (i.e. not by a JSP tag) you should assign it an explicit static id or assign it the id you get from the createUniqueId from the current UIViewRoot component right after creation! clientID = parent.getClientId(getFacesContext()); parent= UIViewRoot (id=44) _attributesMap= null _childrenList= _ComponentChildrenList (id=100) _clientId= _id0 _events= null _facesListeners= null _facetMap= null _id= _id0 _locale= Locale (id=106) _parent= null _rendered= null _rendererType= null _renderKitId= HTML_BASIC _transient= false _uniqueIdCounter= 1 _valueBindingMap= null _viewId= /masterDetail.jsp
Re: [sandbox] autoUpdateDataTable
+1 on fully removing it. Anyone not willing to migrate can stick with an older sandbox. Martin Marinschek wrote: Hi *, there is one more reason, why the component should be removed - it is using prototype under the covers, and we moved to dojo a while ago. regards, Martin On 3/29/07, Glauco Pimentel Gomes [EMAIL PROTECTED] wrote: And if you move the autoUpdateDataTable to jsf-comp in Source Forge? Glauco P. Gomes Gerald Müllan escreveu: The periodicalUpdate mechanism of ppr-group goes beyond AutoUpdateDataTable, means it fulfills all its requirements and does little bit more (like updating not only the table, but the whole area inside the ppr-goup). I will furthermore support this addition to ppr. Well, waiting for promotion..this may take it`s time.. cheers, Gerald On 3/29/07, Glauco Pimentel Gomes [EMAIL PROTECTED] wrote: Why not wait PPR promotion to delete it? Glauco P. Gomes Mike Kienenberger escreveu: That's what I was asking -- is there an equivalent replacement? Maybe pprPeriodicalUpdate? I haven't used either, so I wouldn't know. On 3/29/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Ok, but the demo says use pprPeriodicalUpdate http://example.irian.at/example-sandbox-20070329/pprPanelGroupPeriodicalUpdate.jsf So, when that is maintained by a committer and the other not, we shoudl get rid of it -M On 3/29/07, Mike Kienenberger [EMAIL PROTECTED] wrote: Actually, I'm not so sure now. It looks like we have at least one person submitting patches for this component. Should it really be deprecated? Is there an equivalent replacement? If not, and someone is providing patches, I think we should consider keeping it. http://issues.apache.org/jira/browse/TOMAHAWK-935 On 3/29/07, Mike Kienenberger [EMAIL PROTECTED] wrote: Sounds good to me. On 3/29/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: If I don't hear comments against it, I'll do it in some days (to give feedback a chance ;-)) -M On 3/29/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Yeah, deprecated is a nice condition ... It is more a pain to have an unmaintained component in a *sandbox* than simple remove it. On 3/29/07, Bruno Aranda [EMAIL PROTECTED] wrote: I am with Mathias that we should remove completely those components in the API that fail and are not maintained. I see no need to keep them in the API if they are not supported now already. Maybe we could define the set of conditions to remove a component from the sandbox (we already have the conditions to graduate a component)... Cheers, Bruno On 29/03/07, Gerald Müllan [EMAIL PROTECTED] wrote: Ok, let`s remove the demo and leave the component as deprecated. On 3/29/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: I mean, it's sandbox and since there was a reason for setting it to deprecated, it seems reasonable to remove; sandbox I'd not consider as a stable API... At least we should remove the demo... -M On 3/29/07, Gerald Müllan [EMAIL PROTECTED] wrote: Well, the same outcome can be performed by using ppr in combination with the automatically refreshing mechanism. This is the more generic way, so a special component which achieves the same should be dropped. The only thing is, that some user may use AutoUpdateDataTable, but these are definitely not that much :) cheers, Gerald On 3/29/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, I just saw that autoUpdateDataTable is deprecated, why not deleting it? It's the sandbox... -M -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache
[jira] Commented: (TOMAHAWK-945) Split the PPR Example into smaller easy to understand Examples with explanations
[ https://issues.apache.org/jira/browse/TOMAHAWK-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485541 ] Jeff Bischoff commented on TOMAHAWK-945: Okay Ernst, sorry for asking. I just didn't want somebody else to start working on it, if you already were! : ) Great that you are working on this! Split the PPR Example into smaller easy to understand Examples with explanations Key: TOMAHAWK-945 URL: https://issues.apache.org/jira/browse/TOMAHAWK-945 Project: MyFaces Tomahawk Issue Type: Improvement Components: PPRPanelGroup Affects Versions: 1.1.6-SNAPSHOT Reporter: Ernst Fastl Assigned To: Gerald Müllan Fix For: 1.1.6-SNAPSHOT Attachments: tomahawk-945- ppr examples.patch A lot of users have been complaining, that the sandbox PPR example is difficult to understand and they did't get it working. Therefore it would be good to split this example into a number of different examples for the different features similar to the datatable examples -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1527) Problem with the jsp files in myface-examples simple.war
[ https://issues.apache.org/jira/browse/MYFACES-1527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485550 ] Jeff Bischoff commented on MYFACES-1527: Can we close this issue? It looks to be fixed already in the trunk, for all pages referenced in the patch - except for panel stack, which isn't working at all. Seems to be an id conflict introduced by whoever made the changes. That will need a new JIRA issue, I think. This one can be marked fixed. Problem with the jsp files in myface-examples simple.war Key: MYFACES-1527 URL: https://issues.apache.org/jira/browse/MYFACES-1527 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.1.4 Environment: Windows XP with JBoss 4.0.5 Reporter: Oded Nissan Priority: Minor Attachments: fixed_pages.jar Some of the jsp files in the simple.war web application that comes with the myfaces-examples contain a form tag with a name attribute instead of an id attribute. This causes an error in the current myfaces core release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-728) newspaperColumns attribute ignores EL expression
[ https://issues.apache.org/jira/browse/TOMAHAWK-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485554 ] Jeff Bischoff commented on TOMAHAWK-728: You can also take a look at the Wiki page for contributing patches. We've added an example of making a patch from the command line as well, if that's easier for you. [1] http://wiki.apache.org/myfaces/Contributing_Patches newspaperColumns attribute ignores EL expression Key: TOMAHAWK-728 URL: https://issues.apache.org/jira/browse/TOMAHAWK-728 Project: MyFaces Tomahawk Issue Type: Bug Components: Extended Datatable, Newspaper Table Affects Versions: 1.1.4-SNAPSHOT Reporter: Michael Matz Attachments: HtmlDataTable.java, HtmlNewspaperTable.java If you use an EL expression for the newspaperColumns attribute it is ignored and the default value of 1 is used instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-953) Panel Stack example fails with Message: There is more than one JSF tag with id : treePanel for parent component with id : 'stack'
Panel Stack example fails with Message: There is more than one JSF tag with id
: treePanel for parent component with id : 'stack'
-
Key: TOMAHAWK-953
URL: https://issues.apache.org/jira/browse/TOMAHAWK-953
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Examples, Panel Stack
Affects Versions: 1.1.5, 1.1.6-SNAPSHOT
Environment: JSP
Reporter: Jeff Bischoff
The current example page for Panel Stack component, panelstack.jsf, blows up
immediately with message:
There is more than one JSF tag with id : treePanel for parent component with id
: 'stack'
Viewing the source, the problem comes from the following panelGroup code having
been copied-and-pasted, without either id being changed:
t:panelStack id=stack selectedPanel=#{stackState.selected}
h:panelGroup id=treePanel
h:form
t:tree id=tree value=#{treeModel}
styleClass=tree
nodeClass=treenode
selectedNodeClass=treenodeSelected
expandRoot=true
/t:tree
/h:form
f:verbatimbr/f:verbatim
/h:panelGroup
h:panelGroup id=treePanel
h:form
t:tree id=tree value=#{treeModel}
styleClass=tree
nodeClass=treenode
selectedNodeClass=treenodeSelected
expandRoot=true
/t:tree
/h:form
f:verbatimbr/f:verbatim
/h:panelGroup
Suggested solutions: either delete the second panelGroup or replace their ids
with treePanel1 and treePanel2, respectively. If I have time, I'll post a
patch with the latter solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [VOTE] MyFaces Tomahawk 1.1.5
FYI I have filed a new JIRA issue, TOMAHAWK-953, dealing with a broken examples page. Unforunately, it affects both the release artifacts and the current trunk. :( [5] https://issues.apache.org/jira/browse/TOMAHAWK-953 Manfred Geiler wrote: Hi all, This is the official vote for MyFaces Tomahawk 1.1.5. (aka The Tomahawk Easter Release 2007 - can you find the egg?) Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.tomahawk v1.1.5 [1] 2. MyFaces Tomahawk Assembly [2] 3. MyFaces Tomahawk Examples Assembly [2] 4. MyFaces Tomahawk Sandbox Assembly [2] 5. MyFaces Tomahawk Sandbox Examples Assembly [2] 6. Proposed Release Announcement [3] Please note: This vote is majority approval with a minimum of three +1 votes (see [4]). I know this release is overdue but please do only cast a +1 if you really have tested the artifacts and assemblies and not only because you have waited so long... ;-) Please cast your votes: [ ] +1 (I confirm that I tested this release and therefore approve it) [ ] +0 (I have no time to test now but I look forward to this new release) [ ] -1 (Serious concerns because...) --Manfred [1] http://people.apache.org/builds/myfaces/m2-staging-repository/ [2] http://people.apache.org/builds/myfaces/tomahawk-1.1.5/ [3] http://wiki.apache.org/myfaces/TomahawkRelease115#releasenotes [4] http://www.apache.org/foundation/voting.html#ReleaseVotes
[jira] Commented: (TOMAHAWK-953) Panel Stack example fails with Message: There is more than one JSF tag with id : treePanel for parent component with id : 'stack'
[
https://issues.apache.org/jira/browse/TOMAHAWK-953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485628
]
Jeff Bischoff commented on TOMAHAWK-953:
I made the change for suggested solution #2 locally. This appeared to help, as
now the page comes up fine initially, and I can manipulate the tree
successfully.
However, if I use the drop-down box to switch from Tree Panel to SelectBox
Panel, it blows up with the error:
Message: Value is no String
(class=org.apache.myfaces.examples.common.CarConfigurator$Color, [EMAIL
PROTECTED]) and component _idJsp6:selone_menu_colorswith path: {Component-Path
: [Class: javax.faces.component.UIViewRoot,ViewId: /panelstack.jsp][Class:
javax.faces.component.html.HtmlPanelGroup,Id: body][Class:
org.apache.myfaces.custom.panelstack.HtmlPanelStack,Id: stack][Class:
javax.faces.component.html.HtmlPanelGroup,Id: selectBoxPanel][Class:
javax.faces.component.html.HtmlForm,Id: _idJsp6][Class:
javax.faces.component.html.HtmlPanelGrid,Id: _idJsp7][Class:
javax.faces.component.html.HtmlSelectOneMenu,Id: selone_menu_colors]} does not
have a Converter
I don't have time to dig any deeper into this right now. If anyone else would
like to give a crack at fixing this example, that'd be great. I guess the
question becomes: when did it last work, and who touched it last? :)
-JB
Panel Stack example fails with Message: There is more than one JSF tag with
id : treePanel for parent component with id : 'stack'
-
Key: TOMAHAWK-953
URL: https://issues.apache.org/jira/browse/TOMAHAWK-953
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Examples, Panel Stack
Affects Versions: 1.1.5, 1.1.6-SNAPSHOT
Environment: JSP
Reporter: Jeff Bischoff
The current example page for Panel Stack component, panelstack.jsf, blows up
immediately with message:
There is more than one JSF tag with id : treePanel for parent component with
id : 'stack'
Viewing the source, the problem comes from the following panelGroup code
having been copied-and-pasted, without either id being changed:
t:panelStack id=stack selectedPanel=#{stackState.selected}
h:panelGroup id=treePanel
h:form
t:tree id=tree value=#{treeModel}
styleClass=tree
nodeClass=treenode
selectedNodeClass=treenodeSelected
expandRoot=true
/t:tree
/h:form
f:verbatimbr/f:verbatim
/h:panelGroup
h:panelGroup id=treePanel
h:form
t:tree id=tree value=#{treeModel}
styleClass=tree
nodeClass=treenode
selectedNodeClass=treenodeSelected
expandRoot=true
/t:tree
/h:form
f:verbatimbr/f:verbatim
/h:panelGroup
Suggested solutions: either delete the second panelGroup or replace their ids
with treePanel1 and treePanel2, respectively. If I have time, I'll post a
patch with the latter solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: JSP viewhandler: automatic id warning when using masterDetail.jsf
Upon further testing, my initial response may have been misleading. Back when I had JSP in my application, assigning explicit form ids is what got rid of this warning message. However in further testing today with the tomahawk examples from the release candidate files, I found this is no longer sufficient to remove the warning. Something slightly more sinister may have crept in? I have since switched to Facelets, and I don't run into this warning at all in my application. Since this warning message seems to pop up on every simple example page that I have tried, would someone like to look deeper into this in case a new bug has crept in? I'm about to leave for the weekend. Good luck! Jeff Bischoff wrote: According the the Sun docs [1], it is not a required attribute. Is that official enough? (There is nothing in the spec itself about attributes of core tags, is there?) So should we remove this warning altogether, or just change it? I would be happy to open the JIRA for it, after lunch. :) Mike Kienenberger wrote: Jeff, Mind opening an issue on this? I don't remember if h:form requires an id, but I don't think it is supposed to. On 3/30/07, Jeff Bischoff [EMAIL PROTECTED] wrote: Mike, I get that warning message if I use a h:form with no id attribute. In fact, I see this warning on almost every page in the simple Tomahawk example app (and they don't have an id set on the form). Perhaps the warning message could be more clear? To put it another way, if I add an id to the simple example pages, then the warning goes away. Regards, Jeff Bischoff Kenneth L Kurz Associates, Inc. Mike Kienenberger wrote: I'm not going to try to track this one down since I don't do jsp. But here's a strange warning -- UIViewRoot got assigned an automatic id in masterDetail.jsf. INFO: WARNING: Component _id0 just got an automatic id, because there was no id assigned yet. If this component was created dynamically (i.e. not by a JSP tag) you should assign it an explicit static id or assign it the id you get from the createUniqueId from the current UIViewRoot component right after creation! clientID = parent.getClientId(getFacesContext()); parent= UIViewRoot (id=44) _attributesMap= null _childrenList= _ComponentChildrenList (id=100) _clientId= _id0 _events= null _facesListeners= null _facetMap= null _id= _id0 _locale= Locale (id=106) _parent= null _rendered= null _rendererType= null _renderKitId= HTML_BASIC _transient= false _uniqueIdCounter= 1 _valueBindingMap= null _viewId= /masterDetail.jsp
[jira] Commented: (TOMAHAWK-945) Split the PPR Example into smaller easy to understand Examples with explanations
[ https://issues.apache.org/jira/browse/TOMAHAWK-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485204 ] Jeff Bischoff commented on TOMAHAWK-945: Are you volunteering, Ernst? :) Split the PPR Example into smaller easy to understand Examples with explanations Key: TOMAHAWK-945 URL: https://issues.apache.org/jira/browse/TOMAHAWK-945 Project: MyFaces Tomahawk Issue Type: Improvement Components: PPRPanelGroup Affects Versions: 1.1.6-SNAPSHOT Reporter: Ernst Fastl Fix For: 1.1.6-SNAPSHOT A lot of users have been complaining, that the sandbox PPR example is difficult to understand and they did't get it working. Therefore it would be good to split this example into a number of different examples for the different features similar to the datatable examples -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Rewording There should always be a submitted value for an input if it is rendered, its form is submitted, and it is not disabled or read-only.
Mike, It's great that you're working on this. I was definately a bit confused the first time I ever ran into that error message. I think your revisions are a big improvement. I see only one bit of ambiguity in the new message, the line: + You cannot submit a form after disabling an input element via javascript. From the seat of a naive user, it is unclear from this wording whether disabling an input will prevent the entire form submit from succeeding. At the risk of making the message even longer, it would be good to point out the consequences of this mistake, e.g. + You cannot submit a form after disabling an input element via javascript - doing so will cause the entire submit to fail or + You cannot submit a form after disabling an input element via javascript - doing so may have unexpected results I don't know. I don't remember exactly what the effects of this are, it's been a while since I've had the problem. If we know what damage this does though, we should state it. In any case, the changes are definately for the better. You get my +1, even with no further revisions. Regards, Jeff Bischoff Kenneth L Kurz Associates, Inc. Mike Kienenberger wrote: After reading the source code again, here's my revised message: = There should always be a submitted value for an input if it is rendered, + its form is submitted, and it was not originally rendered disabled or read-only.; + You cannot submit a form after disabling an input element via javascript. + Consider setting read-only to true instead + or resetting the disabled value back to false prior to form submission.; On 3/29/07, Mike Kienenberger [EMAIL PROTECTED] wrote: If the input for a component is set to disabled via javascript, the following warning occurs. There should always be a submitted value for an input if it is rendered, its form is submitted, and it is not disabled or read-only. This is not true if the component is set to read-only via javascript. I don't think the error above is clear. Explanation of what's happening underneath here: http://webdesign.about.com/od/forms/a/aa071805.htm Perhaps it should be rewritten as: There should always be a submitted value for an input if it is rendered and its form is submitted. You cannot submit a form after disabling an input element via javascript. Consider using read-only instead or resetting the disabled value back to false prior to form submission. I'm going to start with this, but I'd like to have someone else confirm that this is a better solution. https://issues.apache.org/jira/browse/MYFACES-1569
Re: http://www.irian.at/myfaces/swapimage.jsf
Looks broken to me, Dennis. It is supposed to be a mouseover, but not working in anything I've tested (firefox or IE7). Dennis Byrne wrote: This page doesn't do much. Am I missing something or is the example broken?
Re: Tomahawk Component in Netbeans 5.5 Visual Web Pack
Valeria, This question is more appropriate for the user mailing list. Try asking there and you might get some help. Porru Valeria wrote: I'm a beginner and I'm trying to use the MyFaces component with NetBeans 5.5 Visual Web Pack. I'd like to insert a JSCookMenu into my jsf page and I'd like do it by in Visual mode, by drag and drop component from the Visual Palette of Netbeans. First question: is it possible to do? The Tomahawk Component are importable into a Visual Palette? I read that is necessary to create a complib file, I'm try to create it but the component doesn't appear on the JSP code. What I was wrong? Thanks for Reply Valeria Internet Email Confidentiality Footer - La presente comunicazione, con le informazioni in essa contenute e ogni documento o file allegato, e' rivolta unicamente alla/e persona/e cui e' indirizzata ed alle altre da questa autorizzata/e a riceverla. Se non siete i destinatari/autorizzati siete avvisati che qualsiasi azione, copia, comunicazione, divulgazione o simili basate sul contenuto di tali informazioni e' vietata e potrebbe essere contro la legge (art. 616 C.P., D.Lgs n. 196/2003 Codice in materia di protezione dei dati personali). Se avete ricevuto questa comunicazione per errore, vi preghiamo di darne immediata notizia al mittente e di distruggere il messaggio originale e ogni file allegato senza farne copia alcuna o riprodurne in alcun modo il contenuto. This e-mail and its attachments are intended for the addressee(s) only and are confidential and/or may contain legally privileged information. If you have received this message by mistake or are not one of the addressees above, you may take no action based on it, and you may not copy or show it to anyone; please reply to this e-mail and point out the error which has occurred. -
Re: [jira] Commented: (TOMAHAWK-914) t:dataTable style attributes don't work with Facelets
Mike Kienenberger wrote: Unfortunately, I haven't. I'm likely to be pulling down the latest MyFaces code in the next week or two and implementing a few things. If no one else has gotten to it by then, I'll try to do it at that point. Great, thanks. On the bright side, your issue has helped me dodge a number of potential issues by reminding me that I needed to use some fully-qualified attribute names :-) org.apache.myfaces.dataTable.ROW_STYLECLASS=... org.apache.myfaces.dataTable.ROW_ID=... Haha, at least it has done something. ;) Good, then you will be able to also test if the old workaround still works after the patch. It should of course also generate the log message about deprecation of that workaround... On 3/14/07, Jeff Bischoff (JIRA) dev@myfaces.apache.org wrote: https://issues.apache.org/jira/browse/TOMAHAWK-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480834 Has anyone gotten a chance to give this patch a whirl?
Re: [VOTE] New Apache MyFaces Fusion Name
matze, you're such a rebel. ;) Matthias Wessendorf wrote: [x] Apache MyFaces Kleber On 3/8/07, Jeff Bischoff [EMAIL PROTECTED] wrote: [x] Apache MyFaces Orchestra [ ] Apache MyFaces Aurora [ ] Apache MyFaces Connections
Re: Tomahawk 1.1.5 branch created to eartly?
Depends whether we want the Tomahawk code to be pre-Fusion or not. Of course Fusion is a separate subproject, so it really only affects the (deleted) Sandbox components, right? Wendy Smoak wrote: On 3/5/07, Wendy Smoak [EMAIL PROTECTED] wrote: Not necessarily. There was no 1.1.6-SNAPSHOT in JIRA to choose when closing the issue. I added one and edited the issue. Now it's up to the releae manager whether to merge that change to the branch. Hold on... the trunk *is* at 1.1.5-SNAPSHOT: http://svn.apache.org/repos/asf/myfaces/tomahawk/trunk/pom.xml And so is the branch: http://svn.apache.org/repos/asf/myfaces/tomahawk/branches/1_1_5/pom.xml ) That's not allowed. :) What to do depends on how soon someone has plans to do the Tomahawk 1.1.5 release. Either we 1. update trunk to 1.1.6-SNAPSHOT or 2. delete the branch and re-copy it at some later point
Re: Status of subForm: time for promotion?
Does that bug even still exist? I'm using subForm successfully in app that is nearing production. :D Mike Kienenberger wrote: Other than a volunteer, is there anything holding up the promotion of subForm? I went through the issue tracker and created a subForm component category and moved relevent issues into it. I only see one open issue for subForm, and I don't consider it a blocker to promotion: http://issues.apache.org/jira/browse/TOMAHAWK-445 It has documentation: http://issues.apache.org/jira/browse/TOMAHAWK-445 It has an example: http://example.irian.at/example-sandbox-20070301/subForm.jsf
[jira] Commented: (TOMAHAWK-914) t:dataTable style attributes don't work with Facelets
[ https://issues.apache.org/jira/browse/TOMAHAWK-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477427 ] Jeff Bischoff commented on TOMAHAWK-914: I have attached all-in-one.patch, which implements both of the previous changes but in one single diff file. This is more similar to patches that I have seen applied from other JIRA issues. Hopefully it will be easier to apply. If this is the correct procedure to submit one single diff file with all changes, I should update the wiki [4] with that information. [4] http://wiki.apache.org/myfaces/Contributing_Patches Regards, Jeff Bischoff P.S. Any chance we can also merge this fix into the Tomahawk 1.1.5 release branch? :) t:dataTable style attributes don't work with Facelets - Key: TOMAHAWK-914 URL: https://issues.apache.org/jira/browse/TOMAHAWK-914 Project: MyFaces Tomahawk Issue Type: Bug Components: Extended Datatable Affects Versions: 1.1.4-SNAPSHOT, 1.1.5-SNAPSHOT Environment: MyFaces Core 1.1.5, Facelets 1.1.11 Reporter: Jeff Bischoff Attachments: all-in-one.patch, HtmlDataTable.java.diff, JSFAttr.java.diff Problem: style and styleClass attributes on t:dataTable do not work in Facelets due to use of fully-qualified names in the map. Fix: Patch attached to resolve this by changing the names as stored in the map. Includes code to accept hacks based on the old behaviour, but warns that it is now deprecated. Bonus: Also includes fix for problem in Facelets where the EL can not return a null style. This is due to changes in the EL spec, and prevents the former (very useful) style rollover behaviour. Fix works by converting any empty String returned by the EL in these Style attributes into null. (Reverse Coercion) Background: After converting my application from JSP to Facelets, I set out to make my rowStyleClass attribute on t:dataTable work like it used to. First, I had to get the attribute working in Facelets. With considerable discussion on the user list (see [1] and [2]) and a lot of help from Mike, I think we've identified some pretty simple code changes to enable this and other similar attributes. I plan to introduce a patch for this, probably tomorrow. What happened next was that during testing of this change, I could confirm that the attribute did indeed now work, but I was baffled by unexpected behaviour. My EL expression which had previously returned null in certain situations was now returning the empty String. I went to Facelets list for some clarification on this (see [3]) and it turned out to be a requirement of the new EL spec to coerce the nulls into empty string. Getting an empty String instead of null for this ValueBinding lookup creates a problem because the extended dataTable treats a null value differently and goes looking at the more standard style attributes like rowClasses. With an empty string returned, it assumes it needs to look no further. As a user, there is no way for me to specify that under certain conditions, it should fallback to the other style attributes, e.g. rowClasses. The best fix we have collectively come up with so far is to coerce the empty string back into a null in the dataTable, so that the renderer does the right thing. I don't see too much downside to this approach, as an empty style string has no relevance in CSS. However, I feel a proposed change like this requires extra discussion before making a decision on it. It's another one of those situation where we have to decide how we want to handle unexpected results due to changes in the newer specs. [1] https://facelets.dev.java.net/servlets/ReadMsg?list=usersmsgNo=6875 [2] http://www.nabble.com/Re%3A-Facelets-support-for-a-Tomahawk-dataTable-trick--tf3236491.html [3] https://facelets.dev.java.net/servlets/ReadMsg?list=usersmsgNo=6941 Regards, Jeff Bischoff Kenneth L Kurz Associates, Inc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (TOMAHAWK-914) t:dataTable style attributes don't work with Facelets
Done. :D Mike Kienenberger wrote: Jeff, I think a single diff file is easier, so go ahead and update the documentation. On 3/2/07, Jeff Bischoff (JIRA) dev@myfaces.apache.org wrote: [ https://issues.apache.org/jira/browse/TOMAHAWK-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477427 ] Jeff Bischoff commented on TOMAHAWK-914: I have attached all-in-one.patch, which implements both of the previous changes but in one single diff file. This is more similar to patches that I have seen applied from other JIRA issues. Hopefully it will be easier to apply. If this is the correct procedure to submit one single diff file with all changes, I should update the wiki [4] with that information. [4] http://wiki.apache.org/myfaces/Contributing_Patches Regards, Jeff Bischoff
Re: MyFaces Fusion Naming
Manfred Geiler wrote: Apache MyFaces Orchestra? --Manfred I like the sound of this for a product. I agree though, that something along the lines of glue would be very intuitive for this particular subproject. btw, Kleber will draw blank stares from us english native-speakers. :D
[jira] Commented: (MYFACES-1546) Find a new name for Apache MyFaces Fusion
[ https://issues.apache.org/jira/browse/MYFACES-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476617 ] Jeff Bischoff commented on MYFACES-1546: Transit is not bad... How about: Apache MyFaces Bistro? Find a new name for Apache MyFaces Fusion - Key: MYFACES-1546 URL: https://issues.apache.org/jira/browse/MYFACES-1546 Project: MyFaces Core Issue Type: Task Components: General Reporter: Mario Ivankovits This jira is to collect new names for Apache MyFaces Fusion so far: Apache MyFaces Connections Apache MyFaces Vista Apache MyFaces Salida Apache MyFaces Defender Apache MyFaces Seamless Apache MyFaces Mergence Apache MyFaces Accretion Apache MyFaces Collective Apache MyFaces Aurora Apache MyFaces Concerto Apache MyFaces Orchestra -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Proposed changes to t:dataTable regarding the new EL specification
JSFAttr class has the following attributes incompatible with Facelets:
// dataTable (extended) attributes
String ROW_ID =
org.apache.myfaces.dataTable.ROW_ID;
String ROW_STYLECLASS_ATTR =
org.apache.myfaces.dataTable.ROW_STYLECLASS;
String ROW_STYLE_ATTR =
org.apache.myfaces.dataTable.ROW_STYLE;
I will definately fix StyleClass and Style in this patch. Not sure what
to do about ROW_ID. I don't use it in my app, and not sure what it's
supposed to do or how to test it. Documentation on the attribute is
incomplete (literally, half a sentence in the TLD). I see the attribute
being set in the JSP tag handler, but I don't see this attribute used in
the extended dataTable class anywhere. Therefore, my feeling is to just
leave it and fix the other two. Thoughts?
Regards,
Jeff Bischoff
Kenneth L Kurz Associates, Inc.
Jeff Bischoff wrote:
If there's no objections, I'll open a JIRA and submit a patch. :)
Mike Kienenberger wrote:
This change looks good to me. It's probably more important that the
value binding be able to default to null than to output an empty
string css style.
On 2/22/07, Jeff Bischoff [EMAIL PROTECTED] wrote:
Greets,
After converting my application from JSP to Facelets, I set out to make
my rowStyleClass attribute on t:dataTable work like it used to.
First, I had to get the attribute working in Facelets. With considerable
discussion on the user list (see [1] and [2]) and a lot of help from
Mike, I think we've identified some pretty simple code changes to enable
this and other similar attributes. I plan to introduce a patch for this,
probably tomorrow.
What happened next was that during testing of this change, I could
confirm that the attribute did indeed now work, but I was baffled by
unexpected behaviour. My EL expression which had previously returned
null in certain situations was now returning the empty String. I went to
Facelets list for some clarification on this (see [3]) and it turned out
to be a requirement of the new EL spec to coerce the nulls into empty
string.
Getting an empty String instead of null for this ValueBinding lookup
creates a problem because the extended dataTable treats a null value
differently and goes looking at the more standard style attributes like
rowClasses. With an empty string returned, it assumes it needs to look
no further. As a user, there is no way for me to specify that under
certain conditions, it should fallback to the other style attributes,
e.g. rowClasses.
The best fix we have collectively come up with so far is to coerce the
empty string back into a null in the dataTable, so that the renderer
does the right thing. I don't see too much downside to this approach, as
an empty style string has no relevance in CSS. However, I feel a
proposed change like this requires extra discussion before making a
decision on it. It's another one of those situation where we have to
decide how we want to handle unexpected results due to changes in the
newer specs.
If you review the threads a bit, you can see more of the details of the
issues. I'll post my preliminary proposed code changes at the bottom.
[1] https://facelets.dev.java.net/servlets/ReadMsg?list=usersmsgNo=6875
[2]
http://www.nabble.com/Re%3A-Facelets-support-for-a-Tomahawk-dataTable-trick--tf3236491.html
[3] https://facelets.dev.java.net/servlets/ReadMsg?list=usersmsgNo=6941
Regards,
Jeff Bischoff
Kenneth L Kurz Associates, Inc.
Okay proposed code change in
org.apache.myfaces.component.html.ext.HtmlDataTable
Original Method:
public String getRowStyleClass()
{
if (_rowStyleClass != null)
return _rowStyleClass;
ValueBinding vb = getValueBinding(JSFAttr.ROW_STYLECLASS_ATTR);
return vb != null ? (String) vb.getValue(getFacesContext())
: null;
}
New Method:
public String getRowStyleClass()
{
if (_rowStyleClass != null)
return _rowStyleClass;
// TODO: temporarily support fully-qualified ext. dataTable
attribute names.
ValueBinding vb =
getValueBinding(org.apache.myfaces.dataTable.ROW_STYLECLASS);
if (vb != null)
log.warn(org.apache.myfaces.dataTable.ROW_STYLECLASS is
deprecated. Please use rowStyleClass instead.);
else
vb = getValueBinding(JSFAttr.ROW_STYLECLASS_ATTR);
if(vb == null)
return null;
String bindingValue = (String) vb.getValue(getFacesContext());
if(bindingValue == )
return null; // Fix for JSF 1.2 EL coercing nulls to empty
string
return bindingValue;
}
That, along with the change to JSFAttr to change the constant value from
org.apache.myfaces.dataTable.ROW_STYLECLASS to rowStyleClass. NOTE:
This change affects the shared code!
[jira] Created: (TOMAHAWK-914) t:dataTable style attributes don't work with Facelets
t:dataTable style attributes don't work with Facelets - Key: TOMAHAWK-914 URL: https://issues.apache.org/jira/browse/TOMAHAWK-914 Project: MyFaces Tomahawk Issue Type: Bug Components: Extended Datatable Affects Versions: 1.1.4-SNAPSHOT, 1.1.5-SNAPSHOT Environment: MyFaces Core 1.1.5, Facelets 1.1.11 Reporter: Jeff Bischoff Attachments: HtmlDataTable.java.diff, JSFAttr.java.diff Problem: style and styleClass attributes on t:dataTable do not work in Facelets due to use of fully-qualified names in the map. Fix: Patch attached to resolve this by changing the names as stored in the map. Includes code to accept hacks based on the old behaviour, but warns that it is now deprecated. Bonus: Also includes fix for problem in Facelets where the EL can not return a null style. This is due to changes in the EL spec, and prevents the former (very useful) style rollover behaviour. Fix works by converting any empty String returned by the EL in these Style attributes into null. (Reverse Coercion) Background: After converting my application from JSP to Facelets, I set out to make my rowStyleClass attribute on t:dataTable work like it used to. First, I had to get the attribute working in Facelets. With considerable discussion on the user list (see [1] and [2]) and a lot of help from Mike, I think we've identified some pretty simple code changes to enable this and other similar attributes. I plan to introduce a patch for this, probably tomorrow. What happened next was that during testing of this change, I could confirm that the attribute did indeed now work, but I was baffled by unexpected behaviour. My EL expression which had previously returned null in certain situations was now returning the empty String. I went to Facelets list for some clarification on this (see [3]) and it turned out to be a requirement of the new EL spec to coerce the nulls into empty string. Getting an empty String instead of null for this ValueBinding lookup creates a problem because the extended dataTable treats a null value differently and goes looking at the more standard style attributes like rowClasses. With an empty string returned, it assumes it needs to look no further. As a user, there is no way for me to specify that under certain conditions, it should fallback to the other style attributes, e.g. rowClasses. The best fix we have collectively come up with so far is to coerce the empty string back into a null in the dataTable, so that the renderer does the right thing. I don't see too much downside to this approach, as an empty style string has no relevance in CSS. However, I feel a proposed change like this requires extra discussion before making a decision on it. It's another one of those situation where we have to decide how we want to handle unexpected results due to changes in the newer specs. [1] https://facelets.dev.java.net/servlets/ReadMsg?list=usersmsgNo=6875 [2] http://www.nabble.com/Re%3A-Facelets-support-for-a-Tomahawk-dataTable-trick--tf3236491.html [3] https://facelets.dev.java.net/servlets/ReadMsg?list=usersmsgNo=6941 Regards, Jeff Bischoff Kenneth L Kurz Associates, Inc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TOMAHAWK-914) t:dataTable style attributes don't work with Facelets
[ https://issues.apache.org/jira/browse/TOMAHAWK-914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Bischoff updated TOMAHAWK-914: --- Status: Patch Available (was: Open) t:dataTable style attributes don't work with Facelets - Key: TOMAHAWK-914 URL: https://issues.apache.org/jira/browse/TOMAHAWK-914 Project: MyFaces Tomahawk Issue Type: Bug Components: Extended Datatable Affects Versions: 1.1.4-SNAPSHOT, 1.1.5-SNAPSHOT Environment: MyFaces Core 1.1.5, Facelets 1.1.11 Reporter: Jeff Bischoff Attachments: HtmlDataTable.java.diff, JSFAttr.java.diff Problem: style and styleClass attributes on t:dataTable do not work in Facelets due to use of fully-qualified names in the map. Fix: Patch attached to resolve this by changing the names as stored in the map. Includes code to accept hacks based on the old behaviour, but warns that it is now deprecated. Bonus: Also includes fix for problem in Facelets where the EL can not return a null style. This is due to changes in the EL spec, and prevents the former (very useful) style rollover behaviour. Fix works by converting any empty String returned by the EL in these Style attributes into null. (Reverse Coercion) Background: After converting my application from JSP to Facelets, I set out to make my rowStyleClass attribute on t:dataTable work like it used to. First, I had to get the attribute working in Facelets. With considerable discussion on the user list (see [1] and [2]) and a lot of help from Mike, I think we've identified some pretty simple code changes to enable this and other similar attributes. I plan to introduce a patch for this, probably tomorrow. What happened next was that during testing of this change, I could confirm that the attribute did indeed now work, but I was baffled by unexpected behaviour. My EL expression which had previously returned null in certain situations was now returning the empty String. I went to Facelets list for some clarification on this (see [3]) and it turned out to be a requirement of the new EL spec to coerce the nulls into empty string. Getting an empty String instead of null for this ValueBinding lookup creates a problem because the extended dataTable treats a null value differently and goes looking at the more standard style attributes like rowClasses. With an empty string returned, it assumes it needs to look no further. As a user, there is no way for me to specify that under certain conditions, it should fallback to the other style attributes, e.g. rowClasses. The best fix we have collectively come up with so far is to coerce the empty string back into a null in the dataTable, so that the renderer does the right thing. I don't see too much downside to this approach, as an empty style string has no relevance in CSS. However, I feel a proposed change like this requires extra discussion before making a decision on it. It's another one of those situation where we have to decide how we want to handle unexpected results due to changes in the newer specs. [1] https://facelets.dev.java.net/servlets/ReadMsg?list=usersmsgNo=6875 [2] http://www.nabble.com/Re%3A-Facelets-support-for-a-Tomahawk-dataTable-trick--tf3236491.html [3] https://facelets.dev.java.net/servlets/ReadMsg?list=usersmsgNo=6941 Regards, Jeff Bischoff Kenneth L Kurz Associates, Inc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: MyFaces Fusion Naming
I like em :D Thomas Spiegl wrote: 2 more ... Apache MyFaces Cement Apache MyFaces Plaster On 2/28/07, Grant Smith [EMAIL PROTECTED] wrote: OK, nix my previous vote. I just added the following to the JIRA: The United States of MyFaces (joke) Apache MyFaces States Apache MyFaces StateConverse Apache MyFaces Converse Apache MyFaces Talk Apache MyFaces StateOrchestra Apache MyFaces Music Apache MyFaces Debate Apache MyFaces Fellowship --- I Like this one -- Grant Smith
Re: MyFaces Fusion Naming
In that case, how about: Apache Myfaces Spider ...as in Spider Webs... obviously, can't use web itself :P [EMAIL PROTECTED] wrote: I would avoid any nouns associated with 'heavy', I think it's contradictory to what Fusion is attempting to do. Stick to: http://thesaurus.reference.com/browse/fusion 2 more ... Apache MyFaces Cement Apache MyFaces Plaster On 2/28/07, Grant Smith [EMAIL PROTECTED] wrote: OK, nix my previous vote. I just added the following to the JIRA: The United States of MyFaces (joke) Apache MyFaces States Apache MyFaces StateConverse Apache MyFaces Converse Apache MyFaces Talk Apache MyFaces StateOrchestra Apache MyFaces Music Apache MyFaces Debate Apache MyFaces Fellowship --- I Like this one -- Grant Smith -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: MyFaces Fusion Naming
Glad you liked it. Yeah I figured it would be pretty common name, but at least not as bad as Spyder! (taken by both SP ETF fund and major winter sports gear company) Anyway it's a cool name, but probably too common Mario Ivankovits wrote: Hi Jeff! Apache Myfaces Spider I like it, though the first hit in google with software spider results in http://www.spider-software.de/ Ciao, Mario
Re: Proposed changes to t:dataTable regarding the new EL specification
Hi Mike,
Sorry! I forgot about TOMAHAWK-523. I remembered there were the similar
JIRA issues that affected Tree2, but didn't remember this one existed. I
see you already marked it as part of TOMAHAWK-914, thank you!!
Regards,
Jeff Bischoff
Kenneth L Kurz Associates, Inc.
Mike Kienenberger wrote:
Jeff,
In the future, it would be better to add patches to an existing JIRA
issue when one exists rather than opening a new one.
On 2/28/07, Jeff Bischoff [EMAIL PROTECTED] wrote:
JSFAttr class has the following attributes incompatible with Facelets:
// dataTable (extended) attributes
String ROW_ID =
org.apache.myfaces.dataTable.ROW_ID;
String ROW_STYLECLASS_ATTR =
org.apache.myfaces.dataTable.ROW_STYLECLASS;
String ROW_STYLE_ATTR =
org.apache.myfaces.dataTable.ROW_STYLE;
I will definately fix StyleClass and Style in this patch. Not sure what
to do about ROW_ID. I don't use it in my app, and not sure what it's
supposed to do or how to test it. Documentation on the attribute is
incomplete (literally, half a sentence in the TLD). I see the attribute
being set in the JSP tag handler, but I don't see this attribute used in
the extended dataTable class anywhere. Therefore, my feeling is to just
leave it and fix the other two. Thoughts?
Regards,
Jeff Bischoff
Kenneth L Kurz Associates, Inc.
Jeff Bischoff wrote:
If there's no objections, I'll open a JIRA and submit a patch. :)
Mike Kienenberger wrote:
This change looks good to me. It's probably more important that the
value binding be able to default to null than to output an empty
string css style.
On 2/22/07, Jeff Bischoff [EMAIL PROTECTED] wrote:
Greets,
After converting my application from JSP to Facelets, I set out to
make
my rowStyleClass attribute on t:dataTable work like it used to.
First, I had to get the attribute working in Facelets. With
considerable
discussion on the user list (see [1] and [2]) and a lot of help from
Mike, I think we've identified some pretty simple code changes to
enable
this and other similar attributes. I plan to introduce a patch for
this,
probably tomorrow.
What happened next was that during testing of this change, I could
confirm that the attribute did indeed now work, but I was baffled by
unexpected behaviour. My EL expression which had previously returned
null in certain situations was now returning the empty String. I
went to
Facelets list for some clarification on this (see [3]) and it
turned out
to be a requirement of the new EL spec to coerce the nulls into empty
string.
Getting an empty String instead of null for this ValueBinding lookup
creates a problem because the extended dataTable treats a null value
differently and goes looking at the more standard style attributes
like
rowClasses. With an empty string returned, it assumes it needs to
look
no further. As a user, there is no way for me to specify that under
certain conditions, it should fallback to the other style attributes,
e.g. rowClasses.
The best fix we have collectively come up with so far is to coerce
the
empty string back into a null in the dataTable, so that the renderer
does the right thing. I don't see too much downside to this
approach, as
an empty style string has no relevance in CSS. However, I feel a
proposed change like this requires extra discussion before making a
decision on it. It's another one of those situation where we have to
decide how we want to handle unexpected results due to changes in the
newer specs.
If you review the threads a bit, you can see more of the details
of the
issues. I'll post my preliminary proposed code changes at the bottom.
[1]
https://facelets.dev.java.net/servlets/ReadMsg?list=usersmsgNo=6875
[2]
http://www.nabble.com/Re%3A-Facelets-support-for-a-Tomahawk-dataTable-trick--tf3236491.html
[3]
https://facelets.dev.java.net/servlets/ReadMsg?list=usersmsgNo=6941
Regards,
Jeff Bischoff
Kenneth L Kurz Associates, Inc.
Okay proposed code change in
org.apache.myfaces.component.html.ext.HtmlDataTable
Original Method:
public String getRowStyleClass()
{
if (_rowStyleClass != null)
return _rowStyleClass;
ValueBinding vb =
getValueBinding(JSFAttr.ROW_STYLECLASS_ATTR);
return vb != null ? (String) vb.getValue(getFacesContext())
: null;
}
New Method:
public String getRowStyleClass()
{
if (_rowStyleClass != null)
return _rowStyleClass;
// TODO: temporarily support fully-qualified ext. dataTable
attribute names.
ValueBinding vb =
getValueBinding(org.apache.myfaces.dataTable.ROW_STYLECLASS);
if (vb != null)
log.warn(org.apache.myfaces.dataTable.ROW_STYLECLASS is
deprecated. Please use rowStyleClass instead.);
else
vb = getValueBinding(JSFAttr.ROW_STYLECLASS_ATTR);
if(vb == null)
return null;
String
Re: Tomahawk 1.1.5 release plans?
I saw that post at the time, but figured it was the result of too much doppelbock and wienerschnitzel. ;) Matthias Wessendorf wrote: Well... there was a meeting in munich, during the october fest... and they discussed that... http://wiki.java.net/bin/view/Projects/JSFDaysMunich2006 *snip* Version synchronization. JSF 2.0 renamed JSF 6 to go with Java EE 6. perhaps it was the beer ;))) On 2/23/07, Dennis Byrne [EMAIL PROTECTED] wrote: 6.0? Seriously? Dennis Byrne On 2/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: there was a wiki page which says that they want to have the next version of jsf (2.0) named 6.0 so... I am not really seeing any reason to go from myfaces 1.2 to a 6 ... :-) On 2/23/07, Dennis Byrne [EMAIL PROTECTED] wrote: JSF 1.1 - MyFaces 1.x JSF 1.2 - MyFaces 2.x I'd rather keep the release numbers in sync with the spec numbers. 1.1 - 1.1.x, 1.2 - 1.2.x Paul Spencer Matthias Wessendorf wrote: we sould do the same for core next is 1.5.0 and JSF 1.2 stuff should be changed to 2.0.0 On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: 1.5.0 or 1.6.0. One is as good as the other IMO. You mean 1.6.0 is better because it does not match the 1.1.5 of current core? I think Martin suggested 1.5.0 because it would be in the style of Tomcat 5.0.x vs Tomcat 5.5.x, right? --Manfred On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: If the version of Tomahawk is not tied to the version of MyFaces, then how about the NEXT version of Tomahawk be 1.6? This would allow Tomahawk, like Tobago, to be version independently of MyFaces. Paul Spencer Martin Marinschek wrote: slightly too late, but 1.1.5 would have been my option as well. other option: 1.5 - and let tomahawk and impl version numbers get out of sync. regards, Martin On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: Ok, thanks for your feedback. Branch 1.1.5 created. --Manfred On 2/23/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 +1 for Tomahawk 1.1.5 this time around, which will be compatible with Core 1.1.5. (There is plenty of information in the archives if anyone asks what happened to 1.1.4. As Paul points out, Tomcat skips version numbers in their public release series.) -- Wendy -- Dennis Byrne -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Dennis Byrne
Re: Suggested Version number roadmap (was Re: Tomahawk 1.1.5 release plans?)
Paul Spencer wrote: This is to summarize the version number discussion. MyFaces for JSF 1.1 1.1.5 - Current Release (Announced 19-Feb-2007) 1.1.6 - Next release not currently scheduled MyFaces for JSF 1.2 2.0.0 - Currently being developed as MyFaces 1.2 MyFaces for JSF 2.0 / JSF 6 3.0.0 - ? Tomahawk for JSF 1.1 1.1.3 - Current Release (Announced 14-Jun-2006) 1.1.5 - Next release, currently in process 1.6.0 - Following release Tomahawk for JSF 1.2 2.x - Not started Paul Spencer Wow, that looks pretty good. :)
Re: Proposed changes to t:dataTable regarding the new EL specification
If there's no objections, I'll open a JIRA and submit a patch. :)
Mike Kienenberger wrote:
This change looks good to me. It's probably more important that the
value binding be able to default to null than to output an empty
string css style.
On 2/22/07, Jeff Bischoff [EMAIL PROTECTED] wrote:
Greets,
After converting my application from JSP to Facelets, I set out to make
my rowStyleClass attribute on t:dataTable work like it used to.
First, I had to get the attribute working in Facelets. With considerable
discussion on the user list (see [1] and [2]) and a lot of help from
Mike, I think we've identified some pretty simple code changes to enable
this and other similar attributes. I plan to introduce a patch for this,
probably tomorrow.
What happened next was that during testing of this change, I could
confirm that the attribute did indeed now work, but I was baffled by
unexpected behaviour. My EL expression which had previously returned
null in certain situations was now returning the empty String. I went to
Facelets list for some clarification on this (see [3]) and it turned out
to be a requirement of the new EL spec to coerce the nulls into empty
string.
Getting an empty String instead of null for this ValueBinding lookup
creates a problem because the extended dataTable treats a null value
differently and goes looking at the more standard style attributes like
rowClasses. With an empty string returned, it assumes it needs to look
no further. As a user, there is no way for me to specify that under
certain conditions, it should fallback to the other style attributes,
e.g. rowClasses.
The best fix we have collectively come up with so far is to coerce the
empty string back into a null in the dataTable, so that the renderer
does the right thing. I don't see too much downside to this approach, as
an empty style string has no relevance in CSS. However, I feel a
proposed change like this requires extra discussion before making a
decision on it. It's another one of those situation where we have to
decide how we want to handle unexpected results due to changes in the
newer specs.
If you review the threads a bit, you can see more of the details of the
issues. I'll post my preliminary proposed code changes at the bottom.
[1] https://facelets.dev.java.net/servlets/ReadMsg?list=usersmsgNo=6875
[2]
http://www.nabble.com/Re%3A-Facelets-support-for-a-Tomahawk-dataTable-trick--tf3236491.html
[3] https://facelets.dev.java.net/servlets/ReadMsg?list=usersmsgNo=6941
Regards,
Jeff Bischoff
Kenneth L Kurz Associates, Inc.
Okay proposed code change in
org.apache.myfaces.component.html.ext.HtmlDataTable
Original Method:
public String getRowStyleClass()
{
if (_rowStyleClass != null)
return _rowStyleClass;
ValueBinding vb = getValueBinding(JSFAttr.ROW_STYLECLASS_ATTR);
return vb != null ? (String) vb.getValue(getFacesContext()) :
null;
}
New Method:
public String getRowStyleClass()
{
if (_rowStyleClass != null)
return _rowStyleClass;
// TODO: temporarily support fully-qualified ext. dataTable
attribute names.
ValueBinding vb =
getValueBinding(org.apache.myfaces.dataTable.ROW_STYLECLASS);
if (vb != null)
log.warn(org.apache.myfaces.dataTable.ROW_STYLECLASS is
deprecated. Please use rowStyleClass instead.);
else
vb = getValueBinding(JSFAttr.ROW_STYLECLASS_ATTR);
if(vb == null)
return null;
String bindingValue = (String) vb.getValue(getFacesContext());
if(bindingValue == )
return null; // Fix for JSF 1.2 EL coercing nulls to empty
string
return bindingValue;
}
That, along with the change to JSFAttr to change the constant value from
org.apache.myfaces.dataTable.ROW_STYLECLASS to rowStyleClass. NOTE:
This change affects the shared code!
Re: Next version Tomahawk 1.6 or 1.1.6 (was Re: Suggested Version number roadmap )
It will be set, but not in stone. You've changed the version # of snapshots before. :) +1 for this not being a release blocker Paul Spencer wrote: Mike, As a part of the 1.1.5 release, the next version is set. Based on your comments, the version should be set to 1.1.6. I have no problem with this. The release of 1.1.5 should not be delayed while we determine the next version number. Paul Spencer Mike Kienenberger wrote: I think it's too soon to be making the decision on what to call the next version. Let's wait and see how things go with a Tomahawk 1.1.5 release. We're still encountering dependency issues with current Tomahawk releases. We've promised to deliver implementation-dependent releases twice in the past and failed. Let's wait and see before making that promise again. On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: Mike, As soon as Tomahawk is compatible with the JSF 1.1 spec, then it should be considered implementation independent. If their are known incompatibilities with an implementation, i.e. MyFaces 1.1.4, then those should be noted in Tomahawk's release notes. We can make the testing easer by defining implementation specific profiles for testing Tomahawk against different MyFaces versions, and any other JSF implementations, using profiles. This is currently done in Tomahawk's example pom.xml. See the Deploy with Sun's RI section of the Selenium testing page [1]. Keeping in mind we may want to change the answer in the future, what should the next version be? __ 1.6.0 - JSF 1.1 implementation independent __ 1.1.6 - Dependent on MyFaces 1.1.6 Paul Spencer [1] http://myfaces.apache.org/tomahawk/testing/selenium.html Mike Kienenberger wrote: I don't think Tomahawk has proved yet that it is independent from core versioning. Take the MyFaces Core 1.1.4 incompatiblities between Tomahawk 1.1.5 as an example. I think we should take a wait and see attitude before we decide we're going to start with Tomahawk 1.6 numbering.Remember, we started with Tomahawk 1.1.3 as independent of core and we've still not accomplished the task with releases to date. And if it's truely independent from the core, then it would mean that someone could use Tomahawk 1.1.5 for any version of MyFaces, 1.1.4, 1.1.3, 1.1.2, 1.1.1, 1.0.9, etc., and we know that's not the case. -Mike On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: This is to summarize the version number discussion. MyFaces for JSF 1.1 1.1.5 - Current Release (Announced 19-Feb-2007) 1.1.6 - Next release not currently scheduled MyFaces for JSF 1.2 2.0.0 - Currently being developed as MyFaces 1.2 MyFaces for JSF 2.0 / JSF 6 3.0.0 - ? Tomahawk for JSF 1.1 1.1.3 - Current Release (Announced 14-Jun-2006) 1.1.5 - Next release, currently in process 1.6.0 - Following release Tomahawk for JSF 1.2 2.x - Not started Paul Spencer
Re: Tomahawk 1.1.5 release plans?
+1 on this idea. Tomahawk has settled down since the Dojo move and has been running relatively stable. Best to ensure the next release is branched sometime before any more big changes. (Tomahawk 1.1.4 RC is very good too) :) Paul Spencer wrote: We just completed a MyFaces 1.1.5 release, which resolved blockers related to Tomahawk. Can we get a Tomahawk release done before we start changing things for Fusion? Paul Spencer
Proposed changes to t:dataTable regarding the new EL specification
Greets,
After converting my application from JSP to Facelets, I set out to make
my rowStyleClass attribute on t:dataTable work like it used to.
First, I had to get the attribute working in Facelets. With considerable
discussion on the user list (see [1] and [2]) and a lot of help from
Mike, I think we've identified some pretty simple code changes to enable
this and other similar attributes. I plan to introduce a patch for this,
probably tomorrow.
What happened next was that during testing of this change, I could
confirm that the attribute did indeed now work, but I was baffled by
unexpected behaviour. My EL expression which had previously returned
null in certain situations was now returning the empty String. I went to
Facelets list for some clarification on this (see [3]) and it turned out
to be a requirement of the new EL spec to coerce the nulls into empty
string.
Getting an empty String instead of null for this ValueBinding lookup
creates a problem because the extended dataTable treats a null value
differently and goes looking at the more standard style attributes like
rowClasses. With an empty string returned, it assumes it needs to look
no further. As a user, there is no way for me to specify that under
certain conditions, it should fallback to the other style attributes,
e.g. rowClasses.
The best fix we have collectively come up with so far is to coerce the
empty string back into a null in the dataTable, so that the renderer
does the right thing. I don't see too much downside to this approach, as
an empty style string has no relevance in CSS. However, I feel a
proposed change like this requires extra discussion before making a
decision on it. It's another one of those situation where we have to
decide how we want to handle unexpected results due to changes in the
newer specs.
If you review the threads a bit, you can see more of the details of the
issues. I'll post my preliminary proposed code changes at the bottom.
[1] https://facelets.dev.java.net/servlets/ReadMsg?list=usersmsgNo=6875
[2]
http://www.nabble.com/Re%3A-Facelets-support-for-a-Tomahawk-dataTable-trick--tf3236491.html
[3] https://facelets.dev.java.net/servlets/ReadMsg?list=usersmsgNo=6941
Regards,
Jeff Bischoff
Kenneth L Kurz Associates, Inc.
Okay proposed code change in
org.apache.myfaces.component.html.ext.HtmlDataTable
Original Method:
public String getRowStyleClass()
{
if (_rowStyleClass != null)
return _rowStyleClass;
ValueBinding vb = getValueBinding(JSFAttr.ROW_STYLECLASS_ATTR);
return vb != null ? (String) vb.getValue(getFacesContext()) : null;
}
New Method:
public String getRowStyleClass()
{
if (_rowStyleClass != null)
return _rowStyleClass;
// TODO: temporarily support fully-qualified ext. dataTable
attribute names.
ValueBinding vb =
getValueBinding(org.apache.myfaces.dataTable.ROW_STYLECLASS);
if (vb != null)
log.warn(org.apache.myfaces.dataTable.ROW_STYLECLASS is
deprecated. Please use rowStyleClass instead.);
else
vb = getValueBinding(JSFAttr.ROW_STYLECLASS_ATTR);
if(vb == null)
return null;
String bindingValue = (String) vb.getValue(getFacesContext());
if(bindingValue == )
return null; // Fix for JSF 1.2 EL coercing nulls to empty string
return bindingValue;
}
That, along with the change to JSFAttr to change the constant value from
org.apache.myfaces.dataTable.ROW_STYLECLASS to rowStyleClass. NOTE:
This change affects the shared code!
Re: [VOTE] MyFaces Core 1.1.5
Manfred, The announcement is posted on the website, but the release notes still say Bug. Could you make this change to Bug Fixed? :) Thanks, Jeff Bischoff Kenneth L Kurz Associates, Inc. Manfred Geiler wrote: That's what JIRA automatically generates. But I see your point. Will change Bug to Fixed. Thanks. --Manfred On 2/14/07, Barbalace, Richard [EMAIL PROTECTED] wrote: Hi. Looking at the release notes, I see: Release Notes - MyFaces Core - Version 1.1.5 ** Bug * [long listing of bugs] This phrasing is ambiguous. Are these bugs present in the Release, or bugs fixed in the Release? This might be obvious to developers, but release notes should be more friendly to end users who might otherwise be frightened away. Richard J. Barbalace -Original Message- From: Manfred Geiler [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 14, 2007 7:29 AM To: MyFaces Development Subject: [VOTE] MyFaces Core 1.1.5 Hi all, This is the official vote for MyFaces Core 1.1.5. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.maven v1.0.5 [1] 2. Maven artifact group org.apache.myfaces.shared v2.0.5 [1] 3. Maven artifact group org.apache.myfaces.core v1.1.5 [1] 4. MyFaces Core Assembly [2] 5. Proposed Release Announcement [3] [1] http://people.apache.org/builds/myfaces/m2-staging-repository/ [2] http://people.apache.org/builds/myfaces/core-1.1.5/ [3] http://wiki.apache.org/myfaces/CoreRelease115#releasenotes --Manfred The information transmitted in this electronic communication is intended only for the person or entity to whom it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this information in error, please contact the Compliance HelpLine at 800-856-1983 and properly dispose of this information.
Re: [VOTE] MyFaces Core 1.1.5
Oh okay, thanks for checking. :) Manfred Geiler wrote: You mean the release notes on http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600styleName=Htmlversion=12312310 ? Well, this is a Jira issue. It is generated by Jira on the fly. I have no influence on this. Sorry. --Manfred On 2/16/07, Jeff Bischoff [EMAIL PROTECTED] wrote: Manfred, The announcement is posted on the website, but the release notes still say Bug. Could you make this change to Bug Fixed? :) Thanks, Jeff Bischoff Kenneth L Kurz Associates, Inc. Manfred Geiler wrote: That's what JIRA automatically generates. But I see your point. Will change Bug to Fixed. Thanks. --Manfred On 2/14/07, Barbalace, Richard [EMAIL PROTECTED] wrote: Hi. Looking at the release notes, I see: Release Notes - MyFaces Core - Version 1.1.5 ** Bug * [long listing of bugs] This phrasing is ambiguous. Are these bugs present in the Release, or bugs fixed in the Release? This might be obvious to developers, but release notes should be more friendly to end users who might otherwise be frightened away. Richard J. Barbalace -Original Message- From: Manfred Geiler [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 14, 2007 7:29 AM To: MyFaces Development Subject: [VOTE] MyFaces Core 1.1.5 Hi all, This is the official vote for MyFaces Core 1.1.5. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.maven v1.0.5 [1] 2. Maven artifact group org.apache.myfaces.shared v2.0.5 [1] 3. Maven artifact group org.apache.myfaces.core v1.1.5 [1] 4. MyFaces Core Assembly [2] 5. Proposed Release Announcement [3] [1] http://people.apache.org/builds/myfaces/m2-staging-repository/ [2] http://people.apache.org/builds/myfaces/core-1.1.5/ [3] http://wiki.apache.org/myfaces/CoreRelease115#releasenotes --Manfred The information transmitted in this electronic communication is intended only for the person or entity to whom it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this information in error, please contact the Compliance HelpLine at 800-856-1983 and properly dispose of this information.
Re: [jira] [VOTE] MyFaces Core 1.1.5
Woohoo! Manfred Geiler wrote: Thanks everybody. Seems like there are enough (binding) positive votes. ;-) I hereby close this vote and start the release distribution. --Manfred
Re: svn commit: r507121 - /myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/submitOnEvent/SubmitOnEventRenderer.java
This deep scan seems wrong to me. It could pose both an unnecessary
performance burden and potentially unexpected behaviour. The search
algorithm defined by the UIComponent findComponent method [1] should be
sufficient for specifying a target in any known naming container.
Consider this: A user attempts to reference an object in another naming
container, but makes a mistake in the path portion of the id. This
should cause the search to fail, but thanks to the deep scan, it finds
the desired component by the simple id. Everything appears to work. A
bit later, another user on the team adds a component to another naming
container with the same simple id. All of a sudden, the search is
finding the wrong component to submit - and a JIRA issue probably gets
opened if they can't figure it out.
If we really want to encourage this sort of lazy specification of for
attributes, then it needs to be both documented and consistent
throughout the project. My feeling is that findComponent() is sufficient.
[1 tiny] http://tinyurl.com/2k8yzn
[1 long]
http://java.sun.com/javaee/javaserverfaces/1.1_01/docs/api/javax/faces/component/UIComponent.html#findComponent(java.lang.String)
Regards,
Jeff Bischoff
Kenneth L Kurz Associates, Inc.
Martin Marinschek wrote:
Why does the normal findComponent method fail for you?
regards,
Martin
On 2/13/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: imario
Date: Tue Feb 13 09:58:27 2007
New Revision: 507121
URL: http://svn.apache.org/viewvc?view=revrev=507121
Log:
use an aggressive strategy (traverse the whole tree) to search a
component by id if the normal
uiComponent.findComponent failed. Is there a better way?
Modified:
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/submitOnEvent/SubmitOnEventRenderer.java
Modified:
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/submitOnEvent/SubmitOnEventRenderer.java
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/submitOnEvent/SubmitOnEventRenderer.java?view=diffrev=507121r1=507120r2=507121
==
---
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/submitOnEvent/SubmitOnEventRenderer.java
(original)
+++
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/submitOnEvent/SubmitOnEventRenderer.java
Tue Feb 13 09:58:27 2007
@@ -30,6 +30,7 @@
import javax.faces.component.UIInput;
import javax.faces.component.UICommand;
import java.io.IOException;
+import java.util.Iterator;
/**
* Attach an event handler to an input element or use a global event
handler to
@@ -74,7 +75,11 @@
}
forComponent = uiComponent.findComponent(forComponentId);
-if (forComponent == null)
+ if (forComponent == null)
+ {
+ forComponent =
findComponentAggressive(facesContext.getViewRoot(), forComponentId);
+ }
+ if (forComponent == null)
{
throw new IllegalArgumentException(SubmitOnEvent:
can't find 'for'-component ' + forComponentId + ');
}
@@ -119,4 +124,30 @@
out.writeText(js.toString(), null);
out.endElement(HTML.SCRIPT_ELEM);
}
+
+ /**
+* deep scan the tree and see if ANY naming container has a
component with the
+* given id
+*/
+ private UIComponent findComponentAggressive(UIComponent base,
String id)
+ {
+ if (id.equals(base.getId()))
+ {
+ return base;
+ }
+
+ Iterator iter = base.getFacetsAndChildren();
+ while (iter.hasNext())
+ {
+ UIComponent child = (UIComponent) iter.next();
+
+ UIComponent found =
findComponentAggressive(child, id);
+ if (found != null)
+ {
+ return found;
+ }
+ }
+
+ return null;
+ }
}
Re: [VOTE] MyFaces Core 1.1.5
Well, in that case... +1 (non-binding) This looks to be the best MyFaces Core yet! Great job guys. Jeff Bischoff Kenneth L Kurz Associates, Inc. Manfred Geiler wrote: Every community member vote counts! Who is a MyFaces community member? Everybody interested in MyFaces, not only committers! PMC members have the right to veto (with a binding -1). That's the only difference. --Manfred On 2/14/07, Cagatay Civici [EMAIL PROTECTED] wrote: I don't vote since only pmc votes count but I'd want to thank everyone involved especially Manfred. Cagatay
Re: [VOTE] myfaces maven-project artifact 1.0.5
Manfred Geiler wrote: Please vote for the release of MyFaces artifact maven-project version 1.0.5! You can find the release candidate here: http://svn.apache.org/repos/asf/myfaces/maven/branches/1_0_5 Revision 502632 Please note: The released maven-project artifact is the basis for releasing myfaces-shared 2.0.5 and myfaces-core 1.1.5. --Manfred Hmm in the past several releases, there was one vote thread for the product and its dependencies, i.e. myfaces-core, myfaces-shared, + maven-project all voted as one thread. New policy? I'm just a user, but if I had a vote it would be +1 for all of the above, as I have been testing them with no problems. :)
[jira] Commented: (TOMAHAWK-807) documentBody needs id, style and styleClass attributes
[ https://issues.apache.org/jira/browse/TOMAHAWK-807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469462 ] Jeff Bischoff commented on TOMAHAWK-807: This would be a start, though more is needed. Specifically, t:documentBody also needs the html pass-thru attributes such as bgcolor, etc. What would really be nice is a background attribute that behaves much like the h:graphicImage tag does (at least in terms of path rewriting for you). documentBody needs id, style and styleClass attributes -- Key: TOMAHAWK-807 URL: https://issues.apache.org/jira/browse/TOMAHAWK-807 Project: MyFaces Tomahawk Issue Type: Improvement Components: Html Tag Affects Versions: 1.1.3 Environment: documentBody tag needs to support id, style and styleClass tags Reporter: Anil Kommareddi Attachments: DocumentBody.java, DocumentBodyRenderer.java, DocumentBodyTag.java, tomahawk.tld documentBody tag needs to support id, style and styleClass tags -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Myfaces Wiki] Update of ClearInputComponents by SimonKitching
Simon, I noticed a probable mistake in the following line from your addition: + However when using command components with immediate=false, things become more complex. Here you are actually talking about the scenario immediate=true! You described immediate=false in a previous paragraph. I have made this change already for you on the wiki, but if I am mistaken please revert it. :) Regards, Jeff Bischoff Kenneth L Kurz Associates, Inc. Mike Kienenberger wrote: Simon, Since you're working on this page, can you please remove this part at the bottom of the page? I've successfully used the return non-null navigation outcome to the same page in order to reset form values. Note that this approach has not been tested; if you find it does work, then please update this page. On 1/25/07, Apache Wiki [EMAIL PROTECTED] wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Myfaces Wiki for change notification. The following page has been changed by SimonKitching: http://wiki.apache.org/myfaces/ClearInputComponents -- + === Problem Description === + Sometimes you want to provide a command component (eg a link or button) that performs some server action, and - renders the same page but with completely fresh values for all components. However this doesn't work well + renders the same page but with completely fresh values for all components. - when the component is immediate; in this case input components get their submitted value set during the postback - and re-render that submitted value even when the backing values for those input components have been reset to default values. + When using command components with the normal immediate setting (false), achieving this is just a matter of clearing the beans that the JSF component value attributes access. Any values entered by the user will have been pushed into these beans as part of the Update Model phase, so the components themselves will not be holding any information about submitted data. The action method associated with the command is then run which resets the model, and when the components render themselves they will draw fresh data from the (reset) beans. + + Note that because data is being pushed into the model, the validation phase must run, and therefore any invalid data in the page will cause the action to be skipped, and the page is redisplayed with the validation errors displayed. This is not generally the desired behaviour for a clear type operation! The solution is to set attribute immediate=true on the command so that its associated action is invoked before validation is applied to the input components in the same view (see [How_The_Immediate_Attribute_Works]). + + However when using command components with immediate=false, things become more complex. All components will retrieve the raw submitted values submitted by the user, but the immediate command will then run before they can be pushed into the backing beans; the components therefore remember this data. When the (immediate) action causes navigation to another view then this is no problem; these components will be discarded anyway. However if the action method causes JSF to go directly to the render phase 'of the same view' [by calling facesContext.renderResponse()], then the components will behave as they do for a validation failure - by displaying the value cached in the component rather than fetching data from the backing bean. + - Here are a number of possible solutions + Below are a number of possible solutions. === Force a new View === Call this method from the action method of the immediate command component:
[jira] Commented: (TOMAHAWK-850) displayValueOnly on input elements who are required triggers validation
[ https://issues.apache.org/jira/browse/TOMAHAWK-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467844 ] Jeff Bischoff commented on TOMAHAWK-850: Cagatay, Wait, does that mean we reverted and lost the security patch from MYFACES-1467? I know we are hoping for some spec clarification on that one, but did we decide in the meantime to stick with the security patch or the original behaviour? displayValueOnly on input elements who are required triggers validation --- Key: TOMAHAWK-850 URL: https://issues.apache.org/jira/browse/TOMAHAWK-850 Project: MyFaces Tomahawk Issue Type: Bug Components: Validators Affects Versions: 1.1.5-SNAPSHOT Reporter: Stefan Betermieux Assigned To: Cagatay Civici Fix For: 1.1.5-SNAPSHOT Hi, using the latest SVN snapshot, I get a validation error message when I use an UIInput (for example InputText) with displayValueOnly=true and required=true. It is simple to reproduce: f:view h:form id=form t:inputText id=input value=Test required=true displayValueOnly=true/ h:commandButton id=button value=press me action=success/ h:message id=message for=input/ /h:form /f:view The replacement of my value bean lookups by static strings hasn't affected the outcome, a validation error (input: Value is required.) is always triggered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-865) inputHtml, inputDate, inputCalendar do not work with ajax4jsf
[ https://issues.apache.org/jira/browse/TOMAHAWK-865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466063 ] Jeff Bischoff commented on TOMAHAWK-865: Can we get someone to downgrade this from Blocker please? inputHtml, inputDate, inputCalendar do not work with ajax4jsf - Key: TOMAHAWK-865 URL: https://issues.apache.org/jira/browse/TOMAHAWK-865 Project: MyFaces Tomahawk Issue Type: Bug Components: Calendar, Date, Html Editor Affects Versions: 1.1.5-SNAPSHOT Environment: IE and FireFox Reporter: Dave Priority: Blocker I added ajax to my jsf page using ajax4jsf. inputHtml stop working correctly if the page is ajax4jsf enabled. IE reports Error on Page on status bar, and all text entered become null on the server side. I searched the web, and found that inputDate and inputCalendar do not work ajax4jsf either. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [tobago] f:selectItem with tc:selectOneChoice
Wong, Emmanuel (Sam) wrote: Hi: Could anyone tell me how to display a specified drop down list value? Let say will would like to display 3:Medium instead of other drop down value. Please see below. Thanks. Unbelievable, considering the email that you are responding to. I think Dennis' advice applies equally to you, Sam. :) Dennis Byrne wrote: You will probably be better off directing these questions to users@myfaces.apache.org .
[jira] Commented: (MYFACES-1467) Validation doesn't run for required fields if submitted value is null
[
https://issues.apache.org/jira/browse/MYFACES-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464276
]
Jeff Bischoff commented on MYFACES-1467:
I have also noticed the breakage in my code that Cristi noted. For some fields,
I have disabled bound to a bean property, but required hard-coded to true. In
these cases, the new patch is causing me to get validation errors where I
didn't used to see them.
Of course as a user, this problem can be avoided with something like:
h:inputText disabled=#{bean.disabled} required=#{not bean.disabled} /
However, for those of us with large, existing applications that depend on the
old behaviour, this would need to be changed in a LOT of places. IMHO, the old
behaviour was rather intuitive. However, after reading this thread I think that
perhaps the original way this was implemented was perhaps oversimplified.
Validation should be skipped when the component is disabled or read-only, but
not *whenever* the value is null. Is there a way we can keep the patch to fix
the security hole, but yet restore the old behaviour specifically for disabled
and read-only use cases?
Jeff Bischoff
Validation doesn't run for required fields if submitted value is null
-
Key: MYFACES-1467
URL: https://issues.apache.org/jira/browse/MYFACES-1467
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 1.1.5-SNAPSHOT, 1.2.0-SNAPSHOT
Reporter: David Chandler
Assigned To: Matthias Weßendorf
Fix For: 1.1.5-SNAPSHOT
Attachments: patch.txt
A component with a required value will not fail validation as expected if the
submitted value is null. This issue is not seen normally because browsers
send the value for an empty text field as an empty string. That is, the POST
data for an empty field1 will contain the field name but no value, like
field1=field2=something. However, if you use a man-in-the-middle proxy such
as Paros to remove fieldname= from the POST data, the submitted value will
be null. UIInput.validate() skips validation for null submitted values, but
since requiredness is also part of validation, the requiredness check gets
skipped, too.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Patch Branch?
Awesome. What will be the compatibility situation between Myfaces Core 1.1.4.1 and Tomahawk 1.1.4/1.1.5? Any trivial fixes we can backport to improve this? Regards, Jeff Bischoff Kenneth L Kurz Associates, Inc. Wendy Smoak wrote: On 1/5/07, Stan Silvert [EMAIL PROTECTED] wrote: Stan, do you have the JIRA issue and svn revision(s) for the portlet bug fix? I need to know if it affects Shared or just Core. It's just core. http://issues.apache.org/jira/browse/MYFACES-1481 OK, then we can use the released Shared 2.0.3 with it. There having been no objections voiced so far... here's the branch: http://svn.apache.org/repos/asf/myfaces/core/branches/1_1_4_1/ And the release plan: http://wiki.apache.org/myfaces/CoreRelease1141 I added a JIRA version for 1.1.4.1-SNAPSHOT and moved MYFACES-1481 to it. It's ready for someone to apply the fix to the branch, and update the license headers. I'm not sure what in what order those would go best; I'm hoping the relevant commits can be merged to the branch, but I'm not familiar enough with the code to attempt it. Instructions for publishing snapshots (and fixing permissions afterwards) are at the bottom of the release plan. I'll keep an eye on this, but starting next week I won't be available as much during the day.
Re: Reason behind jsf_sequence?
lightbulb, It doesn't sound like you are discussing JSF navigation here at all. Key point to note: by default, JSF navigates with server-side forwards. These *do not* result in the browser URL being updated. :) regards, Jeff Bischoff Kenneth L Kurz Associates, Inc. lightbulb432 wrote: Regarding the back button problem, I have a question: So the issue is that you have an original page with a form on it (page1.html) that was obtained through a GET; the browser bar shows page1.html. You POST that form to a destination of page2.html (as defined in form) and a response is generated in whatever way and the browser bar now shows page2.html. First question: is this a postback? (Is a regular POST the same as a postback?) From page2.html, the user hits the back button...doesn't it just do a GET on page1.html and all is fine? What's the issue? I'd guess that hitting the Refresh button would cause another POST to page2.html with the same parameters, but hitting the Back button would cause a GET to page1.html...am I totally off here? Jacob Hookom wrote: If it's like the RI, the reasoning is to accommodate the back button issue with server-side state saving. It would be wrong to assume/associate a single state with a page given multiple windows and back button use. Using a sequence adds a level of uniqueness to state which is equal to 'page + sequence id'. I've been noticing in my output a jsf_sequence hidden form field that increments on what seems to be each request. What's the reason for such an incrementing hidden field? Does it have something to do with this back button issue? If so, how? I tried using a debugger but quickly got overwhelmed... :( -- View this message in context: http://www.nabble.com/Reason-behind-jsf_sequence--tf2860440.html#a7992103 Sent from the My Faces - Dev mailing list archive at Nabble.com.
[jira] Commented: (TOMAHAWK-830) s:selectManyPicklist doesn't show preselected values
[
http://issues.apache.org/jira/browse/TOMAHAWK-830?page=comments#action_12460493
]
Jeff Bischoff commented on TOMAHAWK-830:
Chintan,
When using selectManyPicklist, the selectItems needs to contain *ALL* the
possible selections. Then selected items should be a subset of this list. The
unselected items list will be automatically generated by the component with the
remainder.
Can you please verify that all your selected values are also in the selectItems?
s:selectManyPicklist doesn't show preselected values
--
Key: TOMAHAWK-830
URL: http://issues.apache.org/jira/browse/TOMAHAWK-830
Project: MyFaces Tomahawk
Issue Type: Bug
Components: New Component
Affects Versions: 1.1.5-SNAPSHOT
Environment: Os: Windows XP Browser: IE,Firefox
Reporter: chintan parekh
Priority: Blocker
am facing one issues with selectManyPickList. I am putting my code here.
JSP code:
t:panelGroup
t:panelGrid columns=3
t:outputLabel value=ABC/
t:outputLabel value=:/
%-- Sandbox component --%
s:selectManyPicklist size=10 style=width:175px;
valueChangeListener=#{accessDelegationController.selectionChangedForOperations
}
value=#{accessDelegationController.selectedOperationsList}
immediate=true
f:selectItems
value=#{accessDelegationController.operationsList } /
/s:selectManyPicklist
/t:panelGrid
/t:panelGroup
Java Code:
Creating 2 Lists. one for SelectedValues and other for default values.
private List selectedOperationsList = new ArrayList();
private List operationsList = new ArrayList();
//here both lists have getter and setter method(which i have not mentioned
here)
//logic to add values in above lists. (Note: I am iterating the values which
i am getting from backend. and adding to selectedOperationList list)
List OperationList1 = (List)Service1.getCreatedOperationRulesList();
//Iterator for selected operation
Iterator iter = OperationList1.iterator();
int i = 0;
while( iter.hasNext()){
Operation operation = (Operation)OperationList1.get(i);
selectedOperationsList.add(new
SelectItem(Integer.toString(operation.getId()),operation.getName()));
i++;
iter.next();
}
//same for default operation lists
List operationList2=(List)Service2.getOperationsList();
Iterator iter1 = operationList2.iterator ();
int j = 0;
while(iter1.hasNext()){
Operation operation1 =
(Operation)operationList2.get(j);
operationsList.add (new
SelectItem(Integer.toString(operation1.getId()),operation1.getName()));
j++;
iter1.next();
}
While rendering only left-hand side value comes.( i mean operationsList).
Right-hand side box(selecteOperationsList) contains no values. though both
the lists are having values in it.
I dont know what is the problem? can you please help me?
Thanks
Chintan
--
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: MyFaces 1.1.5 Release Status?
Aneesha Govil wrote: I would second that. There is no way to apply bug-fix patches without upgrading to a newer, not-stable-yet snapshot nightly build. Well yes, unless you are comfortable applying the patches yourself and maintaining/building the source locally. While this will always be the preferred solution for a select few of the users, the broad majority of us would be much better served by official maintenance releases. Regards, Jeff Bischoff Kenneth L Kurz Associates, Inc. Aneesha Govil wrote: On 12/21/06, Jeff Bischoff [EMAIL PROTECTED] wrote: [...] The problem with this is that, despite lengthening your release cycle, you are still having trouble with release stability. In order to achieve this stability, you either need to be willing to branch for extensive testing before a release (even though it is meanwhile getting out of date). Or, you can take a look at ideas like Paul Spencer's idea for following a Tomcat style of release. If you're going to be releasing code that is only a few days or a week fresh from the trunk, then you're going to need to start releasing maintenance updates to gradually add to their stability. I'm just a humble user, but this is my 2 cents... I would second that. There is no way to apply bug-fix patches without upgrading to a newer, not-stable-yet snapshot nightly build. Regards, Aneesha Regards, Jeff Bischoff Kenneth L Kurz Associates, Inc. Thomas Spiegl wrote: tomahawk 1.1.4 branch is quite out of date by now. I'd like to skip this one, and start releasing core and tomahawk 1.1.5 asap. On 12/18/06, Paul Spencer [EMAIL PROTECTED] wrote: This is yet another release status request. Current open issue with a Fix Version = 1.1.5-SNAPSHOT MYFACES-1372h:messages not shown (- not working) ** Per an 8-Dec-2006 Posting from Mike Kienenberger: MYFACES-1372h:messages not shown (- not working) is important, but it's been broken for 18 months. It's not a regression as far as I know. MYFACES-1409incorrect behavior after RESTORE_VIEW responseComplete MYFACES-1411Lifecycle phase executions repetitions ** Per an 8-Dec-2006 Posting from Mike Kienenberger: MYFACES-1411 has I.P. issues. MYFACES-1506Translated messages in Messages.properties files ** Per an 8-Dec-2006 Posting from Mike Kienenberger: MYFACES-1506 is an improvement. It can be moved to 1.1.6. Actually, this is a Tomahawk issue, not a MyFaces one. Should be moved. Not sure how Messages.properties interacts with Tomahawk, though. None of the above issue are marked as blockers. Are any of the actually blockers to the 1.1.5 release? What is holding up this release? Paul Spencer
Re: Reason behind jsf_sequence?
Lightbulb, Take a look at the context-param: context-param description Only applicable if state saving method is server (= default). Defines the amount (default = 20) of the latest views are stored in session. /description param-nameorg.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION/param-name param-value20/param-value /context-param This is a myfaces thing. Basically it will store the last X number of component trees, and when a new sumbit occurs it uses the sequence number to look up the right component tree. It has no idea whether they are coming from the same or different windows. It does not overwrite the old ones until it runs out of room (that's the whole point of the sequence numbers, so you can have several copies of the same view with different component trees). I agree with Craig though, you can learn a lot from the source - much more than just looking naively at the generated output. :) Regards, Jeff Bischoff Kenneth L Kurz Associates, Inc. Craig McClanahan wrote: On 12/21/06, lightbulb432 [EMAIL PROTECTED] wrote: Thanks for the detailed response. How would the server generally tell which came from which window using jsf_sequence? Because each window would postback the id rendered in that page, telling the server which ViewState to associate to process update/action logic. Does the server actually store the ViewState associated with EVERY single jsf_sequence number? I'd imagine that it'd only store it for what it deems to be each separate sequence of tasks (e.g. in a given window), then overwrite/update that ViewState associated with one window, but keep the other ViewState around for when that one comes in. That's why I'm wondering how the server knows which jsf_sequence number is associated with which other jsf_sequence number as part of the same window... (I wonder if any of what I said was coherent...?) I'll try to explain my question: You open one window and go to the page and get a jsf_sequence of 332 - the server creates a component tree on the server in reponse and associates it with jsf_sequence 332. You open another window and get a jsf_sequence of 154 and similar things occur. In the first window you submit a form and get a jsf_sequence of 778. Now does the server have 3 component trees in its memory? (One per sequence number?) Or just 2? (One per window?) I'd imagine it'd be the latter. But if so, how does it know that the component tree of 332 should be overridden by component tree associated with 778? Wow, I'm so confused...I'm pretty sure I'm not even thinking about this in anywhere near the right way! The best way to address your confusion would be to look at the actual source code, and see what actually happens for yourself. The source code for both MyFaces and the JSF RI is open source ... you'd answer your questions a lot faster by just taking a look at what actually *does* happen. Craig Jacob Hookom wrote: When a postback occurs, the ViewState is restored from the previous request-- in the case of: Client: The ViewState is serialized and posted back to the server-- so you could render a page, come back 5 hours later and click a button, sending the state you have stored in the page back to the server for use. Server: The ViewState is stored on the server, so the page only has a sequence number to identify, on postback, which rendered state we should use. lightbulb432 wrote: That's a good point. Few follow ups below: 1) Could you please explain what, on a high level, the general algorithm used by the server would be to see whether the state is part of the same sequence of activities? e.g. if I open up two windows and am doing two different things at the same time, couldn't potentially the jsf_sequences in the first window be 1,3,5,7,9... and for the second window be 2,4,6,8,10...? There is no continuity with ViewState-- nor is there an expectation on the 'sequence' of identifiers, it could be any unique number. Theoretically, you could store ViewState globally in the application scope, handing out identifiers from one, shared sequence number. So I think there's some confusion with the term 'sequence' here, since it should just be 'unique id' or 'primary key' How would the server generally tell which came from which window using jsf_sequence? Because each window would postback the id rendered in that page, telling the server which ViewState to associate to process update/action logic. 2) A somewhat related question I have is what is the difference between the back button problem for client-side and server-side state saving? From what I've read in articles/posts/books, I get the impression that it's a bigger problem with server-side than client-side state saving (e.g. even your post singled out server-side). I know that the state is stored in the actual page as a hidden field with client-side, but I can't conceptualize how
[jira] Commented: (TOMAHAWK-826) Improve outputLabel component to have a different CSS class in case of an error
[ http://issues.apache.org/jira/browse/TOMAHAWK-826?page=comments#action_12460284 ] Jeff Bischoff commented on TOMAHAWK-826: Alex, I can't speak to the specifics of using this particular component. However, normally you don't need to use forceId when using the for attributes of components from Tomahawk (and other component libraries). Such fields typically use the UIComponent.findComponent() method. [1] A quick look at the source [2] confirms the use of this findComponent method in this component. And yes,as you can see it is in sandbox. Basically, if both components are in the same naming container, than you can just use their simple ids in the for field. Else, you can use a syntax like :MyForm:MySubView:simpleId [1] http://java.sun.com/javaee/javaserverfaces/1.1_01/docs/api/javax/faces/component/UIComponent.html#findComponent(java.lang.String) [2] http://svn.apache.org/repos/asf/myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/ifmessage/ Improve outputLabel component to have a different CSS class in case of an error --- Key: TOMAHAWK-826 URL: http://issues.apache.org/jira/browse/TOMAHAWK-826 Project: MyFaces Tomahawk Issue Type: Improvement Reporter: Alex Savitsky Priority: Minor Attachments: HtmlFlaggableLabelRenderer.java Currently, the only visual cue for validation errors is to display validation messages using t:messages /. However, quite often there's a different requirement for error flagging, namely to identify the field labels (e.g., make them red) if the field has an error. This behavior cannot be achieved using available controls, and therefore I propose to enhance an existing Label control with this functionality. All it would have to do is to set a specified CSS class (and/or CSS style) on a label component, if the field referenced with the for attribute has an error. -- 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-826) Improve outputLabel component to have a different CSS class in case of an error
[ http://issues.apache.org/jira/browse/TOMAHAWK-826?page=comments#action_12460300 ] Jeff Bischoff commented on TOMAHAWK-826: Yes it would require an extra outputLabel for each one, which is why I do think that your suggestion would be a more elegant solution for this use-case. As for it being up to me, I'm just a fellow user trying to be helpful and participate in the discussion with you. :) The best I can do is vote for the issue, and give you some tips on getting your idea accepted. One thing you will want to look at are the guidelines [3] for contributing patches. The more of the work we users do ourselves, the greater the chances of the component being given a shot. Plus, the devs are usually much more willing to apply patches when they are in the proper format (i.e. include a diff). As for sandbox components, basically they remain in the sandbox for testing and further development until they are stable enough and accepted to be promoted into Tomahawk. You can see the guidelines for these promotions here [4]. [3] http://wiki.apache.org/myfaces/Contributing_Patches [4] http://wiki.apache.org/myfaces/promotion Improve outputLabel component to have a different CSS class in case of an error --- Key: TOMAHAWK-826 URL: http://issues.apache.org/jira/browse/TOMAHAWK-826 Project: MyFaces Tomahawk Issue Type: Improvement Reporter: Alex Savitsky Priority: Minor Attachments: HtmlFlaggableLabelRenderer.java Currently, the only visual cue for validation errors is to display validation messages using t:messages /. However, quite often there's a different requirement for error flagging, namely to identify the field labels (e.g., make them red) if the field has an error. This behavior cannot be achieved using available controls, and therefore I propose to enhance an existing Label control with this functionality. All it would have to do is to set a specified CSS class (and/or CSS style) on a label component, if the field referenced with the for attribute has an error. -- 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: MyFaces 1.1.5 Release Status?
Thomas Spiegl wrote: tomahawk 1.1.4 branch is quite out of date by now. Yes, if it were current (i.e. the trunk) it wouldn't be stable. It was branched ~2 months ago. I'd like to skip this one, and start releasing core and tomahawk 1.1.5 asap. This seems such a common tendency of the myfaces team, to be eager to get the new functionality out and released. The problem with this is that, despite lengthening your release cycle, you are still having trouble with release stability. In order to achieve this stability, you either need to be willing to branch for extensive testing before a release (even though it is meanwhile getting out of date). Or, you can take a look at ideas like Paul Spencer's idea for following a Tomcat style of release. If you're going to be releasing code that is only a few days or a week fresh from the trunk, then you're going to need to start releasing maintenance updates to gradually add to their stability. I'm just a humble user, but this is my 2 cents... Regards, Jeff Bischoff Kenneth L Kurz Associates, Inc. Thomas Spiegl wrote: tomahawk 1.1.4 branch is quite out of date by now. I'd like to skip this one, and start releasing core and tomahawk 1.1.5 asap. On 12/18/06, Paul Spencer [EMAIL PROTECTED] wrote: This is yet another release status request. Current open issue with a Fix Version = 1.1.5-SNAPSHOT MYFACES-1372h:messages not shown (- not working) ** Per an 8-Dec-2006 Posting from Mike Kienenberger: MYFACES-1372h:messages not shown (- not working) is important, but it's been broken for 18 months. It's not a regression as far as I know. MYFACES-1409incorrect behavior after RESTORE_VIEW responseComplete MYFACES-1411Lifecycle phase executions repetitions ** Per an 8-Dec-2006 Posting from Mike Kienenberger: MYFACES-1411 has I.P. issues. MYFACES-1506Translated messages in Messages.properties files ** Per an 8-Dec-2006 Posting from Mike Kienenberger: MYFACES-1506 is an improvement. It can be moved to 1.1.6. Actually, this is a Tomahawk issue, not a MyFaces one. Should be moved. Not sure how Messages.properties interacts with Tomahawk, though. None of the above issue are marked as blockers. Are any of the actually blockers to the 1.1.5 release? What is holding up this release? Paul Spencer
[jira] Commented: (TOMAHAWK-826) Improve outputLabel component to have a different CSS class in case of an error
[ http://issues.apache.org/jira/browse/TOMAHAWK-826?page=comments#action_12460068 ] Jeff Bischoff commented on TOMAHAWK-826: Not to say that I wouldn't support adding such a feature (I think it might be neat), but when you say This behavior cannot be achieved using available controls..., are you sure you can not achieve this effect using the component added in TOMAHAWK-165? Of course this and similar approaches would require multiple outputLabels for each component, making your proposed solution still preferable. :) [1] http://issues.apache.org/jira/browse/TOMAHAWK-165 Improve outputLabel component to have a different CSS class in case of an error --- Key: TOMAHAWK-826 URL: http://issues.apache.org/jira/browse/TOMAHAWK-826 Project: MyFaces Tomahawk Issue Type: Improvement Reporter: Alex Savitsky Priority: Minor Attachments: HtmlFlaggableLabelRenderer.java Currently, the only visual cue for validation errors is to display validation messages using t:messages /. However, quite often there's a different requirement for error flagging, namely to identify the field labels (e.g., make them red) if the field has an error. This behavior cannot be achieved using available controls, and therefore I propose to enhance an existing Label control with this functionality. All it would have to do is to set a specified CSS class (and/or CSS style) on a label component, if the field referenced with the for attribute has an error. -- 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: how to use visibleOnUserRole
Hi Sytl, Questions such as this are more appropriate on the users@myfaces.apache.org mailing list. styl9090 wrote: Hello All, I am new to myfaces and JSF.. I am using Tomahawk to display tabs on my page. would like to set role based tabs using visibleOnUserRole. I will know the role of the user once the user logs in. But how to use these roles here in tabs or commandbuttons of JSF..? How can I send those roles to JSF? Thanks in advance. Shekar.
[jira] Commented: (MYFACES-1414) Invalid resource link on Getting Started page
[ http://issues.apache.org/jira/browse/MYFACES-1414?page=comments#action_12457799 ] Jeff Bischoff commented on MYFACES-1414: Mike, You are right, that would be nice. Maybe we can have those added someday. (Maybe people would like to create examples and submit them to JIRA as improvements?) Here's where I think the confusion comes from: Originally, Tomahawk was *not* a separate add-on. Myfaces Core and Tomahawk were one tightly knit product that included both a JSF implementation and the extensions. They have since been decoupled into separate products with their own (semi) independant release schedules. So those 1.1.1-examples that you are seeing? These are the same 4 sample projects (which have since been updated of course) that are now called the Tomahawk examples. It's just that at the time, Tomahawk wasn't released separatedly. I don't think we have ever had an examples artifact that was devoid of any references to Tomahawk components. (Someone please correct me if I am wrong) I hope this explanation helps? 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-749) t:stylesheet example renders two head elements (patch included)
[ http://issues.apache.org/jira/browse/TOMAHAWK-749?page=comments#action_12457377 ] Jeff Bischoff commented on TOMAHAWK-749: Thanks Cagatay! Next time I will submit a svn diff. t:stylesheet example renders two head elements (patch included) --- Key: TOMAHAWK-749 URL: http://issues.apache.org/jira/browse/TOMAHAWK-749 Project: MyFaces Tomahawk Issue Type: Bug Components: Examples, Stylesheet Affects Versions: 1.1.5-SNAPSHOT Environment: Any Reporter: Jeff Bischoff Assigned To: Cagatay Civici Priority: Trivial Fix For: 1.1.5-SNAPSHOT Attachments: css.jsp The t:stylesheet example page (css.jsp) in the Tomahawk examples incorrectly renders two head elements for the generated html page. This is because the page both explicitly defines a head element and includes the standard tomahawk examples head element. -- 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_12457490 ] Jeff Bischoff commented on MYFACES-1414: Examples are a part of Tomahawk distribution. The 1.1.3 release was missing them, but the next release will have them. For now, you can grab them from the nightlies [1]. [1] http://people.apache.org/builds/myfaces/nightly/ 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-816) Tomahawk 1.1.3 is not in the Maven repository
[ http://issues.apache.org/jira/browse/TOMAHAWK-816?page=comments#action_12455654 ] Jeff Bischoff commented on TOMAHAWK-816: Staging Repository: http://myfaces.zones.apache.org/dist/maven-repository I believe this is a known issue David (see [1]) , and I'm not sure there is anything that can be done for this. Hopefully the next release will be signed by the release manager, and it can be propagated to all the maven repos. More instructions for using the staging area can be found here [2]. [1] http://www.nabble.com/tomahawk-on-ibiblio--tf2435027.html#a6908688 [2] http://wiki.apache.org/myfaces/Using_MyFaces_in_a_Project_built_with_Maven Regards, Jeff Bischoff Kenneth L Kurz Associates, Inc. Tomahawk 1.1.3 is not in the Maven repository - Key: TOMAHAWK-816 URL: http://issues.apache.org/jira/browse/TOMAHAWK-816 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.3 Environment: all Reporter: David Rabinowitz The tomahwk artifacts are not deployed to the main maven repository (repo1.apache.org), neither the private repository on people.apache.org is 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] Commented: (TOMAHAWK-749) t:stylesheet example renders two head elements (patch included)
[ http://issues.apache.org/jira/browse/TOMAHAWK-749?page=comments#action_12450207 ] Jeff Bischoff commented on TOMAHAWK-749: What steps can I take to help get these little fixes into the source code? Do I need to provide some sort of diff file, like CVS has? I assume SVN has something like this... t:stylesheet example renders two head elements (patch included) --- Key: TOMAHAWK-749 URL: http://issues.apache.org/jira/browse/TOMAHAWK-749 Project: MyFaces Tomahawk Issue Type: Bug Components: Examples, Stylesheet Affects Versions: 1.1.5-SNAPSHOT Environment: Any Reporter: Jeff Bischoff Priority: Trivial Fix For: 1.1.5-SNAPSHOT Attachments: css.jsp The t:stylesheet example page (css.jsp) in the Tomahawk examples incorrectly renders two head elements for the generated html page. This is because the page both explicitly defines a head element and includes the standard tomahawk examples head element. -- 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: Tomahawk status?
I hope Jeff will investigate some more. Nuts. I didn't realize you guys were waiting for more testing. Now it's been a month, but the situation is still the same. Martin's comments helped narrow it down, and that last stretch of testing that I did pretty much confirmed that the new javascript is working just fine. My original suspicions about that aren't supported by the evidence, so I think Martin's hands might just be clean after all. :D I was waiting for a Dev to comment again, because I felt that I pretty well determined what was breaking the auto scroll behaviour. I can't be certain, without an intimate knowledge of the autoscroll implemenation, but I'm fairly sure this is the cause: input type=hidden name=autoScroll / That input is generated in a different part of the page in Tomahawk 1.1.5 than it was in Tomahawk 1.1.3. When you combine Tomahawk 1.1.5 with MyFaces Core 1.1.4 you get two input boxes (in different spots). If you take a working combination of the two, and manually add an extra input like this to the page - that also breaks autoscrolling. That's why I really think/thought I have found the cause. Perhaps my comments misled you into thinking I was still suspecting the javascript? My fault for not being more clear. [1] https://issues.apache.org/jira/browse/TOMAHAWK-713 Regards, Jeff Bischoff Kenneth L Kurz Associates, Inc. Martin Marinschek wrote: @Wendy: I've commented on TOMAHAWK-713 - I currently don't see why this is failing, I hope Jeff will investigate some more. Apart from that, I've tried to fix whatever I saw possible of whatever compatibility problems with former MyFaces-versions remained. Of course, with the recent changes of Thomas, we still have the problems as pointed out above. The problem is that currently a lot of stuff is moving around, and this for compatibility reasons. I believe this will be for the best of everyone in the end, but currently it's all a major mess. -- View this message in context: http://www.nabble.com/Tomahawk-status--tf2340567.html#a7241793 Sent from the My Faces - Dev mailing list archive at Nabble.com.
[jira] Created: (TOMAHAWK-749) t:stylesheet example renders two head elements (patch included)
t:stylesheet example renders two head elements (patch included) --- Key: TOMAHAWK-749 URL: http://issues.apache.org/jira/browse/TOMAHAWK-749 Project: MyFaces Tomahawk Issue Type: Bug Components: Examples, Stylesheet Affects Versions: 1.1.5-SNAPSHOT Environment: Any Reporter: Jeff Bischoff Priority: Trivial Fix For: 1.1.5-SNAPSHOT The t:stylesheet example page (css.jsp) in the Tomahawk examples incorrectly renders two head elements for the generated html page. This is because the page both explicitly defines a head element and includes the standard tomahawk examples head element. -- 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-749) t:stylesheet example renders two head elements (patch included)
[ http://issues.apache.org/jira/browse/TOMAHAWK-749?page=all ] Jeff Bischoff updated TOMAHAWK-749: --- Status: Patch Available (was: Open) t:stylesheet example renders two head elements (patch included) --- Key: TOMAHAWK-749 URL: http://issues.apache.org/jira/browse/TOMAHAWK-749 Project: MyFaces Tomahawk Issue Type: Bug Components: Stylesheet, Examples Affects Versions: 1.1.5-SNAPSHOT Environment: Any Reporter: Jeff Bischoff Priority: Trivial Fix For: 1.1.5-SNAPSHOT The t:stylesheet example page (css.jsp) in the Tomahawk examples incorrectly renders two head elements for the generated html page. This is because the page both explicitly defines a head element and includes the standard tomahawk examples head element. -- 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-749) t:stylesheet example renders two head elements (patch included)
[ http://issues.apache.org/jira/browse/TOMAHAWK-749?page=comments#action_12443852 ] Jeff Bischoff commented on TOMAHAWK-749: I have attached a patch of css.jsp, from the Tomahawk examples webapp (simple). The changes are: * Commented out the incorrect inclusion of head.inc * Added a comment explaining the change I would not recommend simply removing the line altogether, as a well-meaning person might think it missing and add it back in again, in the future. t:stylesheet example renders two head elements (patch included) --- Key: TOMAHAWK-749 URL: http://issues.apache.org/jira/browse/TOMAHAWK-749 Project: MyFaces Tomahawk Issue Type: Bug Components: Stylesheet, Examples Affects Versions: 1.1.5-SNAPSHOT Environment: Any Reporter: Jeff Bischoff Priority: Trivial Fix For: 1.1.5-SNAPSHOT Attachments: css.jsp The t:stylesheet example page (css.jsp) in the Tomahawk examples incorrectly renders two head elements for the generated html page. This is because the page both explicitly defines a head element and includes the standard tomahawk examples head element. -- 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-713) Auto Scroll silently fails on Core 1.1.4 and Tomahawk nightly
[ http://issues.apache.org/jira/browse/TOMAHAWK-713?page=comments#action_12441217 ] Jeff Bischoff commented on TOMAHAWK-713: I am doing all testing for this bug using the Tomahawk examples application (both modified and unmodified versions). There is no sign of any dummyForm code on the generated page. There is one form around everything inside the f:view. In the unmodified example, the form has no id which generates a warning when viewed. I have modified versions where I gave the form an id - there is no error then, but the broken behaviour remains. In both cases, all commandLinks are nested within the form. You're not able to reproduce this problem? Auto Scroll silently fails on Core 1.1.4 and Tomahawk nightly - Key: TOMAHAWK-713 URL: http://issues.apache.org/jira/browse/TOMAHAWK-713 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.5-SNAPSHOT Environment: MyFaces Core 1.1.4 and Tomahawk nightlies (dated 2006-09-26 or 2006-09-27) Tested in Firefox and Internet Explorer browsers Reporter: Jeff Bischoff Attachments: simple.war, simple2.war When using MyFaces Core 1.1.4 and the latest Tomahawk nightlies (dated 2006-09-26 or 2006-09-27), the Auto Scroll functionality fails. There is no error message in the application logs nor in javascript console. This is presumably related to the javascript changes made to ensure compatibility with the RI. This is a major bug, since latest Tomahawk should be compatible with the Core 1.1.4 release. This breakage can be observed simply by taking the latest tomahawk-examples nightly download, and substituting in the Core 1.1.4 jars. I will attach such an example. -- 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-713) Auto Scroll silently fails on Core 1.1.4 and Tomahawk nightly
[
http://issues.apache.org/jira/browse/TOMAHAWK-713?page=comments#action_12441271
]
Jeff Bischoff commented on TOMAHAWK-713:
If the rendering of the form input is supposed to be at the end of the form,
why is it showing up early? Even in the latest build it shows up in the wrong
place.
http://example.irian.at/example-simple-20061010/autoscroll.jsf
View the generated source on that. You get the oam submit javascripts just
before the first commandLInk, and the autoscroll just after:
trtdscript type=text/javascript!--
function oamSetHiddenInput(formname, name, value)
{
...
}
function oamSubmitForm(formName, linkId, target, params)
{
...
}
//--/scripta href=# onclick=return
oamSubmitForm('_idJsp0','_idJsp0:_idJsp5:0:_idJsp7');
id=_idJsp0:_idJsp5:0:_idJsp70. Click me!/a
input type=hidden name=autoScroll /
/td/tr
Auto Scroll silently fails on Core 1.1.4 and Tomahawk nightly
-
Key: TOMAHAWK-713
URL: http://issues.apache.org/jira/browse/TOMAHAWK-713
Project: MyFaces Tomahawk
Issue Type: Bug
Affects Versions: 1.1.5-SNAPSHOT
Environment: MyFaces Core 1.1.4 and Tomahawk nightlies (dated
2006-09-26 or 2006-09-27)
Tested in Firefox and Internet Explorer browsers
Reporter: Jeff Bischoff
Attachments: simple.war, simple2.war
When using MyFaces Core 1.1.4 and the latest Tomahawk nightlies (dated
2006-09-26 or 2006-09-27), the Auto Scroll functionality fails. There is no
error message in the application logs nor in javascript console. This is
presumably related to the javascript changes made to ensure compatibility
with the RI. This is a major bug, since latest Tomahawk should be compatible
with the Core 1.1.4 release.
This breakage can be observed simply by taking the latest tomahawk-examples
nightly download, and substituting in the Core 1.1.4 jars. I will attach such
an example.
--
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-713) Auto Scroll silently fails on Core 1.1.4 and Tomahawk nightly
[ http://issues.apache.org/jira/browse/TOMAHAWK-713?page=comments#action_12441272 ] Jeff Bischoff commented on TOMAHAWK-713: Oh, and I got a chance to debug the javascript with FireBug (against MyFaces Core 1.1.4 and Tomahawk 1.1.5). Looks like the javascript runs correctly: getScrolling() gets called, and returns the right value. It's just that there are two autoscroll hidden input components on that page, and I don't think it is setting/retrieving from the right one. If we can figure out why this hidden input is showing up in the wrong place and prevent it, I think the javascript will work just fine. Auto Scroll silently fails on Core 1.1.4 and Tomahawk nightly - Key: TOMAHAWK-713 URL: http://issues.apache.org/jira/browse/TOMAHAWK-713 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.5-SNAPSHOT Environment: MyFaces Core 1.1.4 and Tomahawk nightlies (dated 2006-09-26 or 2006-09-27) Tested in Firefox and Internet Explorer browsers Reporter: Jeff Bischoff Attachments: simple.war, simple2.war When using MyFaces Core 1.1.4 and the latest Tomahawk nightlies (dated 2006-09-26 or 2006-09-27), the Auto Scroll functionality fails. There is no error message in the application logs nor in javascript console. This is presumably related to the javascript changes made to ensure compatibility with the RI. This is a major bug, since latest Tomahawk should be compatible with the Core 1.1.4 release. This breakage can be observed simply by taking the latest tomahawk-examples nightly download, and substituting in the Core 1.1.4 jars. I will attach such an example. -- 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-713) Auto Scroll silently fails on Core 1.1.4 and Tomahawk nightly
[
http://issues.apache.org/jira/browse/TOMAHAWK-713?page=comments#action_12440546
]
Jeff Bischoff commented on TOMAHAWK-713:
Well, I spent the last few hours looking at this bug. I think I've identified
two issues which are preventing the 1.1.5 tomahawk components from using
AUTO_SCROLL on myfaces 1.1.4, and one of those issues also breaks AUTO_SCROLL
for any core commandlinks *that are in the same form*.
Issue #1
This probably only affects the tomahawk components. Most of the onclick
javascript has been moved to functions which are declared just before the first
commandlink. The following code was moved into this function:
if(window.getScrolling!=undefined)
{
document.forms[formName].elements['autoScroll'].value=getScrolling();
}
This code looks intended to maintain backwards compatibility for auto
scrolling. It works fine for the core components, who use it in the onclick.
Unfortunately, when it is used inside this function, the if statement will
always return false. The getScrolling() function will never be defined for this
javascript block, as it is defined in a separate javascript block at the end of
the form.
To verify this, I inserted some custom javascript into the page, containing
this code without the if statement. The result when I used the line in a
function in the same part of the page was a javascript error in the console
getScrolling() is not defined. But when I used it in an onclick, there was no
error.
Issue #2
I think this issue breaks auto scrolling for all components in the same form as
a tomahawk commandLink, regardless of whether they are core or tomahawk
components.
input type=hidden name=autoScroll /
This hidden input is generated to support auto scrolling. In Myfaces 1.1.4, it
is generated at the end of the form. In Myfaces/Tomahawk 1.1.5, it is generated
just after the first commandLink. When you mix Myfaces 1.1.4 with Tomahawk
1.1.5, you get two of these inputs per form in any form containing a
t:commandLink. Such forms have autoscroll broken for *both* core components and
tomahawk components.
Auto Scroll silently fails on Core 1.1.4 and Tomahawk nightly
-
Key: TOMAHAWK-713
URL: http://issues.apache.org/jira/browse/TOMAHAWK-713
Project: MyFaces Tomahawk
Issue Type: Bug
Affects Versions: 1.1.5-SNAPSHOT
Environment: MyFaces Core 1.1.4 and Tomahawk nightlies (dated
2006-09-26 or 2006-09-27)
Tested in Firefox and Internet Explorer browsers
Reporter: Jeff Bischoff
Attachments: simple.war, simple2.war
When using MyFaces Core 1.1.4 and the latest Tomahawk nightlies (dated
2006-09-26 or 2006-09-27), the Auto Scroll functionality fails. There is no
error message in the application logs nor in javascript console. This is
presumably related to the javascript changes made to ensure compatibility
with the RI. This is a major bug, since latest Tomahawk should be compatible
with the Core 1.1.4 release.
This breakage can be observed simply by taking the latest tomahawk-examples
nightly download, and substituting in the Core 1.1.4 jars. I will attach such
an example.
--
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-713) Auto Scroll silently fails on Core 1.1.4 and Tomahawk nightly
[ http://issues.apache.org/jira/browse/TOMAHAWK-713?page=comments#action_12439948 ] Jeff Bischoff commented on TOMAHAWK-713: Just tested the Tomahawk 2006-10-04 nightly build against Core 1.1.4, and the problem persists. Auto Scroll silently fails on Core 1.1.4 and Tomahawk nightly - Key: TOMAHAWK-713 URL: http://issues.apache.org/jira/browse/TOMAHAWK-713 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.5-SNAPSHOT Environment: MyFaces Core 1.1.4 and Tomahawk nightlies (dated 2006-09-26 or 2006-09-27) Tested in Firefox and Internet Explorer browsers Reporter: Jeff Bischoff Attachments: simple.war When using MyFaces Core 1.1.4 and the latest Tomahawk nightlies (dated 2006-09-26 or 2006-09-27), the Auto Scroll functionality fails. There is no error message in the application logs nor in javascript console. This is presumably related to the javascript changes made to ensure compatibility with the RI. This is a major bug, since latest Tomahawk should be compatible with the Core 1.1.4 release. This breakage can be observed simply by taking the latest tomahawk-examples nightly download, and substituting in the Core 1.1.4 jars. I will attach such an example. -- 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-713) Auto Scroll silently fails on Core 1.1.4 and Tomahawk nightly
[ http://issues.apache.org/jira/browse/TOMAHAWK-713?page=comments#action_12439958 ] Jeff Bischoff commented on TOMAHAWK-713: Wendy, I'm not entirely sure. Perhaps I'm mistaken about the reason for the javascript changes. Regardless, a quick look at the generated source for just about any example page reveals dramatically different javascript between Tomahawk 1.1.3 and Tomahawk 1.1.5 (nightly). There are new functions, like oamSetHiddenInput and oamSubmitForm. These were not present in earlier versions. There seems to be some sort of javascript disconnect between Tomahawk 1.1.5 and Core 1.1.4 that affects autoscrolling. I think Martin would know about this stuff? Auto Scroll silently fails on Core 1.1.4 and Tomahawk nightly - Key: TOMAHAWK-713 URL: http://issues.apache.org/jira/browse/TOMAHAWK-713 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.5-SNAPSHOT Environment: MyFaces Core 1.1.4 and Tomahawk nightlies (dated 2006-09-26 or 2006-09-27) Tested in Firefox and Internet Explorer browsers Reporter: Jeff Bischoff Attachments: simple.war When using MyFaces Core 1.1.4 and the latest Tomahawk nightlies (dated 2006-09-26 or 2006-09-27), the Auto Scroll functionality fails. There is no error message in the application logs nor in javascript console. This is presumably related to the javascript changes made to ensure compatibility with the RI. This is a major bug, since latest Tomahawk should be compatible with the Core 1.1.4 release. This breakage can be observed simply by taking the latest tomahawk-examples nightly download, and substituting in the Core 1.1.4 jars. I will attach such an example. -- 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-713) Auto Scroll silently fails on Core 1.1.4 and Tomahawk nightly
[ http://issues.apache.org/jira/browse/TOMAHAWK-713?page=comments#action_12439970 ] Jeff Bischoff commented on TOMAHAWK-713: Wendy, thanks for looking into this. Can't believe I didn't notice that autoscroll.jsf page! I was just randomly testing on the other pages. The problem is still there, but you've narrowed it down a bit. When I go to autoscroll.jsf, it behaves as expected (it down not scroll back to the top). *However*, those are all h:commandLink. If I change the source to contain a t:commandLink instead, autoscroll breaks on that page (The browser scrolls to the top of the page, when I click on any link). I tried it also with t:commandButton, and this fails to autoscroll also. This leads to two conclusions: * The mere presence of tomahawk 1.1.5 jar does not interfere with the correct autoscrolling of Core components. * When tomahawk 1.1.5 is used on top of Core 1.1.4, autoscrolling is broken for t:commandButton, t:commandLink, and any components that rely on t:commandLink (e.g. datascroller). From looking at the generated javascript, there is definately a new submission mechanism being used by these components. That's where the new oam javascript functions come into play... Auto Scroll silently fails on Core 1.1.4 and Tomahawk nightly - Key: TOMAHAWK-713 URL: http://issues.apache.org/jira/browse/TOMAHAWK-713 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.5-SNAPSHOT Environment: MyFaces Core 1.1.4 and Tomahawk nightlies (dated 2006-09-26 or 2006-09-27) Tested in Firefox and Internet Explorer browsers Reporter: Jeff Bischoff Attachments: simple.war When using MyFaces Core 1.1.4 and the latest Tomahawk nightlies (dated 2006-09-26 or 2006-09-27), the Auto Scroll functionality fails. There is no error message in the application logs nor in javascript console. This is presumably related to the javascript changes made to ensure compatibility with the RI. This is a major bug, since latest Tomahawk should be compatible with the Core 1.1.4 release. This breakage can be observed simply by taking the latest tomahawk-examples nightly download, and substituting in the Core 1.1.4 jars. I will attach such an example. -- 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-713) Auto Scroll silently fails on Core 1.1.4 and Tomahawk nightly
Auto Scroll silently fails on Core 1.1.4 and Tomahawk nightly - Key: TOMAHAWK-713 URL: http://issues.apache.org/jira/browse/TOMAHAWK-713 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.5-SNAPSHOT Environment: MyFaces Core 1.1.4 and Tomahawk nightlies (dated 2006-09-26 or 2006-09-27) Tested in Firefox and Internet Explorer browsers Reporter: Jeff Bischoff When using MyFaces Core 1.1.4 and the latest Tomahawk nightlies (dated 2006-09-26 or 2006-09-27), the Auto Scroll functionality fails. There is no error message in the application logs nor in javascript console. This is presumably related to the javascript changes made to ensure compatibility with the RI. This is a major bug, since latest Tomahawk should be compatible with the Core 1.1.4 release. This breakage can be observed simply by taking the latest tomahawk-examples nightly download, and substituting in the Core 1.1.4 jars. I will attach such an example. -- 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-1346) exception when using a custom error page and a 404 occurs with an address that matches pattern for FasesServlet
[ http://issues.apache.org/jira/browse/MYFACES-1346?page=comments#action_12430511 ] Jeff Bischoff commented on MYFACES-1346: It says status is patch available... but what patch? There are no files attached, nor Fix Version. exception when using a custom error page and a 404 occurs with an address that matches pattern for FasesServlet --- Key: MYFACES-1346 URL: http://issues.apache.org/jira/browse/MYFACES-1346 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.1.1, 1.1.3 Environment: JBoss-3.2.7 Reporter: Michal Borowiecki I have defined a custom error page and mapped it (among others) to 404 errors in web.xml: error-page error-code400/error-code location/error.jspx/location /error-page It works for all addresses except those that match the mapping for the FacesServlet (*.jsf). When a page that doesn't exist is requested, a standard Tomcat error page is shown instead of the custom error page and the following exception is logged: 2006-06-29 12:50:32,655 ERROR TP-Processor6 [Engine] ApplicationDispatcher[] Servlet.service() for servlet jsp threw exception java.lang.IllegalStateException: getOutputStream() has already been called for this response at org.apache.coyote.tomcat5.CoyoteResponse.getWriter(CoyoteResponse.java:600) at org.apache.coyote.tomcat5.CoyoteResponseFacade.getWriter(CoyoteResponseFacade.java:164) at org.apache.jasper.runtime.JspWriterImpl.initOut(JspWriterImpl.java:124) at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:117) at org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:191) at org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:115) at org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:75) at org.apache.jsp.error_jspx._jspService(error_jspx.java:185) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:696) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:476) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:409) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:312) at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:396) at org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:301) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:147) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:535) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:300) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:374) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:743) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:675
