[jira] Updated: (TOMAHAWK-36) t:div, t:span, s:fieldset should render children
[ http://issues.apache.org/jira/browse/TOMAHAWK-36?page=all ] Gert Vanthienen updated TOMAHAWK-36: Status: Patch Available (was: Reopened) t:div, t:span, s:fieldset should render children Key: TOMAHAWK-36 URL: http://issues.apache.org/jira/browse/TOMAHAWK-36 Project: MyFaces Tomahawk Type: Bug Environment: tomcat 5.5.9 Reporter: Dennis Byrne Priority: Minor Attachments: TOMAHAWK-36.patch, fieldset.diff In the following JSP, the test method of the test bean creates a HtmlOutputText, sets a unique id, sets a value, and adds it to the children collection of the UIComponent of the div tag. However the new child component is never rendered. The only child rendered is the first one (w/ @value = foo ). f:view h:commandLink value=action action=#{test.test} / t:div binding=#{test.tag} h:outputText value=foo / /t:div /f:view The reason why the first child (@value=foo) is always rendered has to do w/ the fact that UIComponentTag.doEndTag ends up triggerring HtmlTextRendererBase.renderOutputText during the render response phase. This also explains why the programmatically added sibling is not rendered - there is no UIComponentTag.doEndTag() . The programmatically added UIComponent will be rendered if you wrap t:div w/ a panelGrid or panelGroup. This is because the UIComponents for these two tags render their own children, and MyFaces uses recursion in order to make sure the proper encoding methods are called on *all* children. -- 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: (TOBAGO-54) visual text decoration component
[ http://issues.apache.org/jira/browse/TOBAGO-54?page=all ] updated TOBAGO-54: --- Status: Patch Available (was: Open) visual text decoration component Key: TOBAGO-54 URL: http://issues.apache.org/jira/browse/TOBAGO-54 Project: MyFaces Tobago Type: New Feature Versions: 1.0.7 Reporter: Nazar Stasiv Fix For: 1.0.8 I need to manage t:link component text decoration. I have sheet component with items t:link. First column displays t:link elements with underlined font, but the rest of columns should be links without underlining. Since it is not possible to apply font styles to t:link directly I propose to introduce new t:font component which will add bold,italic,underline attributes to manage font display in a flexible way. This wont break concept of view layer. What do you think ? -- 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] Closed: (TOMAHAWK-249) ExtensionFilter does not play nice with other filters performing file uploads
[ http://issues.apache.org/jira/browse/TOMAHAWK-249?page=all ] Matthias Weßendorf closed TOMAHAWK-249: --- Resolution: Fixed patch applied, thanks Adam ExtensionFilter does not play nice with other filters performing file uploads - Key: TOMAHAWK-249 URL: http://issues.apache.org/jira/browse/TOMAHAWK-249 Project: MyFaces Tomahawk Type: Bug Components: File Upload Versions: 1.1.2-SNAPSHOT Environment: Generic issue. Reporter: Adam Winer Assignee: Matthias Weßendorf If you have both the ExtensionsFilter and the AdfFacesFilter installed (both are required by the respective libraries), and the ExtensionsFilter goes first, any page containing a file upload will fail (non-upload fields, everything). This is because both filters are attempting to process the upload. If you flip the order, things (should) work. In theory, you might say don't have two filters trying to do file upload, but in practice, a lot of filters serve multiple purposes, so it's not nearly that simple. Simple fix, though: MultipartRequestWrapper needs to override getContentType() to indicate to the system that it has processed the file upload (and prevent any other filters from doing so); just add: public String getContentType() { return application/x-www-form-urlencoded; } -- 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: Puzzled about generated code
Manfred Geiler schrieb: Ok, I just spent a few minutes and found the old codegenerator on the attic. Will try to integrate it into current maven structure. Please stay tuned! Thanks, Manfred Manfred, just a question, what was the scope of the old codegenerator, does it generated boilerplate code for the components?
Re: Puzzled about generated code
Werner,Look at the component classes. Everything between the BEGIN and END GENERATED CODE markers was generated by a Velocity template from the according component xml files.In a few minutes I will checkin the reborn codegenerator - stay tuned. ManfredOn 4/13/06, Werner Punz [EMAIL PROTECTED] wrote: Manfred Geiler schrieb: Ok, I just spent a few minutes and found the old codegenerator on the attic. Will try to integrate it into current maven structure. Please stay tuned! Thanks, ManfredManfred, just a question, what was the scope of the old codegenerator,does it generated boilerplate code for the components?
Re: Puzzled about generated code
Manfred Geiler schrieb: Werner, Look at the component classes. Everything between the BEGIN and END GENERATED CODE markers was generated by a Velocity template from the according component xml files. In a few minutes I will checkin the reborn codegenerator - stay tuned. Ah superb, I was looking for such a thing for a long time. I knew something was done back then for the wml stuff, but I never had time to dig into it. Lovely stuff, will save a lot of time.
Re: Provide Patch / Cancel Patch
Hi Sean, are you sure? It looks like just a anonymous user triggers this, see http://issues.apache.org/jira/browse/TOBAGO-54?page=all Regards, Volker Sean Schofield wrote: Done. Users must have the same permissions as for Create Issue (which is to say they must be logged in.) Sean On 3/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote: I'm wondering if it'd be possible to restrict Provide Patch to logged-in users. It's annoying when an anonymous user triggers this with a patch because there's no way to identify them in order to educate them as to why it was the wrong thing to do. On 3/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote: Is there any way to have the JIRA notification mail state when one of these buttons was pushed? Right now we only get the following (Anon said there was a patch; I cancelled the process because there wasn't one). Anonymous (JIRA) [ http://issues.apache.org/jira/browse/TOMAHAWK-134?page=all ] updated TOMAHAWK-134: Mike Kienenberger (JIRA) [ http://issues.apache.org/jira/browse/TOMAHAWK-134?page=all ] Mike Kienenberger updated TOMAHAWK-134: -- Don't answer to From: address! Mail to this account are droped if not recieved via mailinglist. To contact me direct create the mail address by concatenating my forename to my senders domain.
Code generator is back! (was: Puzzled about generated code)
Hi all,After finding some spare time yesterday and rummaging in the myfaces attic, I was able to re-add the long missed code generation feature. Hooray.Gert Vanthienen was kind enough to offer his help on re-installing the full code gen feature. Gert,I just checked in the code generator. It is already adapted to the new maven build structure.You can find the generator code (with the Velocity template) in the /maven/build-tools module.I tested the codegen with the core/api module where I already added it to the pom.xmlBy default code generation is turned off during a normal build. You can try it out with mvn compile -P regenerate-component-codePlease look at these open tasks:1. add code generation feature to tomahawk module 2. look for manually changed code parts that are now incompatible to regeneration i.e. generate code and do some svn diffing to find dangerous generated code part modifications3. revert and check in trivial (whitespace) changes that happened manually some time ago. The goal is to have a state where code (re)generation does not change anything with current code state. 4. Write a Wiki page HowToGenerateComponentCodePartsFor 2. and 3. we should wait for the 1.1.2 release to be out - which hopefully can happen during the next days.Thanks,Manfred On 4/13/06, Manfred Geiler [EMAIL PROTECTED] wrote: Werner,Look at the component classes. Everything between the BEGIN and END GENERATED CODE markers was generated by a Velocity template from the according component xml files.In a few minutes I will checkin the reborn codegenerator - stay tuned. ManfredOn 4/13/06, Werner Punz [EMAIL PROTECTED] wrote: Manfred Geiler schrieb: Ok, I just spent a few minutes and found the old codegenerator on the attic. Will try to integrate it into current maven structure. Please stay tuned! Thanks, ManfredManfred, just a question, what was the scope of the old codegenerator,does it generated boilerplate code for the components?
Re: Puzzled about generated code
On 4/13/06, Werner Punz [EMAIL PROTECTED] wrote: Manfred Geiler schrieb: Werner, Look at the component classes. Everything between the BEGIN and END GENERATED CODE markers was generated by a Velocity template from the according component xml files. In a few minutes I will checkin the reborn codegenerator - stay tuned.Ah superb, I was looking for such a thing for a long time.I knew something was done back then for the wml stuff, but I never had time to dig into it.Lovely stuff, will save a lot of timeand beware us of dangerous copy and paste errors that are very likely to happen when writing boring trivial code parts.Manfred
[jira] Created: (MYFACES-1282) sandbox inputSuggestAjax ignores onkeydown event
sandbox inputSuggestAjax ignores onkeydown event Key: MYFACES-1282 URL: http://issues.apache.org/jira/browse/MYFACES-1282 Project: MyFaces Core Type: Bug Components: General Versions: 1.1.2-SNAPSHOT Reporter: Juergen Melzer Fix For: 1.1.2-SNAPSHOT I created a field like: s:inputSuggestAjax suggestedItemsMethod=#{editUser.getUserNames} id=stellvertreterUserID value=#{editUser.activeSubstitute} onkeydown=alert('Hallo') onclick=alert('Hallo')/ But no javascript event are generated... -- 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-250) New 'Outlook Menu' type component for Sandbox
New 'Outlook Menu' type component for Sandbox -- Key: TOMAHAWK-250 URL: http://issues.apache.org/jira/browse/TOMAHAWK-250 Project: MyFaces Tomahawk Type: New Feature Reporter: Sharath Reddy This component provides 'Outlook menu' type of component for MyFaces. Features include: 1. Action and action listener can be specified for each menu option 2. Menu can be constructed dynamically from a backing bean as demonstrated in the 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-250) New 'Outlook Menu' type component for Sandbox
[ http://issues.apache.org/jira/browse/TOMAHAWK-250?page=comments#action_12374327 ] Mario Ivankovits commented on TOMAHAWK-250: --- Adapted from the original component developed by Kevin Le (http://pragmaticobjects.com) does this mean you copied some source from there? If so, what license was/is it? Where did you have the icons from? Whats their license? Would it be possible to use org.apache.myfaces.custom.navmenu.NavigationMenuItem to configure the component. That way it could be an easy replacement and we should try to keep our configurations slick. New 'Outlook Menu' type component for Sandbox -- Key: TOMAHAWK-250 URL: http://issues.apache.org/jira/browse/TOMAHAWK-250 Project: MyFaces Tomahawk Type: New Feature Reporter: Sharath Reddy Attachments: patch.zip This component provides 'Outlook menu' type of component for MyFaces. Features include: 1. Action and action listener can be specified for each menu option 2. Menu can be constructed dynamically from a backing bean as demonstrated in the 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] Reopened: (TOBAGO-13) Remove org.apache.myfaces.tobago.el.VariableResolverImpl from faces-config and rename it to UserVariableResolverImpl
[ http://issues.apache.org/jira/browse/TOBAGO-13?page=all ] Bernd Bohmann reopened TOBAGO-13: - Remove org.apache.myfaces.tobago.el.VariableResolverImpl from faces-config and rename it to UserVariableResolverImpl Key: TOBAGO-13 URL: http://issues.apache.org/jira/browse/TOBAGO-13 Project: MyFaces Tobago Type: Bug Reporter: Bernd Bohmann Assignee: Bernd Bohmann Priority: Trivial Fix For: 1.0.7 -- 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] Closed: (TOBAGO-13) Remove org.apache.myfaces.tobago.el.VariableResolverImpl from faces-config and rename it to UserVariableResolverImpl
[ http://issues.apache.org/jira/browse/TOBAGO-13?page=all ] Bernd Bohmann closed TOBAGO-13: --- Resolution: Fixed Remove org.apache.myfaces.tobago.el.VariableResolverImpl from faces-config and rename it to UserVariableResolverImpl Key: TOBAGO-13 URL: http://issues.apache.org/jira/browse/TOBAGO-13 Project: MyFaces Tobago Type: Task Reporter: Bernd Bohmann Assignee: Bernd Bohmann Priority: Trivial Fix For: 1.0.7 -- 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-98) Tabs in panelTabbedPane are shown as buttons on IExplorer
[ http://issues.apache.org/jira/browse/TOMAHAWK-98?page=comments#action_12374329 ] Jan Hoeve commented on TOMAHAWK-98: --- I also have this problem. Specifically: one jsp file had that problem, an other one did not. I compared those file and found one thing: in the 'broken' jsp, the f:form surrounding the panelTabbedPane did not have an id, while the other jsp did have one. I added an id to the form in the first jsp, and bingo: my Internet explorer problem was gone. Maybe you could verify this. Tabs in panelTabbedPane are shown as buttons on IExplorer - Key: TOMAHAWK-98 URL: http://issues.apache.org/jira/browse/TOMAHAWK-98 Project: MyFaces Tomahawk Type: Bug Environment: Windows XP Professional SP2, IE 6.0 SP2, Exadel Studio 3.0.4 Reporter: Javor Petkov Assignee: Thomas Spiegl Hello, The tabs in panelTabbedPane are shown as buttons when using Internet Explorer 6.0 SP2 and the XP theme for the MyFaces 1.1.1 version. Tested with IE 6.0 without updates - same behaviour, tabs shown as buttons - more visible if the default XP theme is used. With Firefox tabs are fine (displayed as tabs). With version 1.0.9 of MyFaces and IE the tabs are also rendered fine so this seems to be a new feature/bug in MyFaces 1.1.1. The problem is reproducible with the Tabbed Pane example of Exadel Studio 3.0.4. Mail me for screenshots if needed. Thanks for having a look :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (TOMAHAWK-250) New 'Outlook Menu' type component for Sandbox
Hi Mario, Kevin wrote the original version as a JSP tag. I converted it into a JSF component. I sought and received permission from Kevin by email to do this. It is an almost complete code rewrite. I dont know where Kevin got the original icons from. I am copying him on the email, so maybe he can reply. I suppose I can use NavigationMenuItem...but it is not a good fit. The atttribute names dont match...Also, every panel has a list of Icons, so I would have to add an arrayList attribute to NavigationMenuItem. I will look into it and get back to you. Regards, Sharath --- Mario Ivankovits (JIRA) dev@myfaces.apache.org wrote: [ http://issues.apache.org/jira/browse/TOMAHAWK-250?page=comments#action_12374327 ] Mario Ivankovits commented on TOMAHAWK-250: --- Adapted from the original component developed by Kevin Le (http://pragmaticobjects.com) does this mean you copied some source from there? If so, what license was/is it? Where did you have the icons from? Whats their license? Would it be possible to use org.apache.myfaces.custom.navmenu.NavigationMenuItem to configure the component. That way it could be an easy replacement and we should try to keep our configurations slick. New 'Outlook Menu' type component for Sandbox -- Key: TOMAHAWK-250 URL: http://issues.apache.org/jira/browse/TOMAHAWK-250 Project: MyFaces Tomahawk Type: New Feature Reporter: Sharath Reddy Attachments: patch.zip This component provides 'Outlook menu' type of component for MyFaces. Features include: 1. Action and action listener can be specified for each menu option 2. Menu can be constructed dynamically from a backing bean as demonstrated in the 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 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [jira] Commented: (TOMAHAWK-250) New 'Outlook Menu' type component for Sandbox
Hi Mario, Ok, I see that NavigationMenuItems already has a List attribute. I could probably use this. I can submit a patch. BTW, below is the license from the original files. I am sorry if I seem to be a bit naive about license issues, I assumed that since I corresponded with Le and obtained his permission, there would not be any issues. /* * Created on Dec 19, 2004 * * Copyright (c) 2005, Pragmatic Objects - Kevin H. Le * All rights reserved. * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions are met: * * 1. Redistributions of source code must retain the above copyright notice, * this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright notice, * this list of conditions and the following disclaimer in the documentation * and/or other materials provided with the distribution. * 3. Neither the name of the Pragmatic Objects nor Kevin H. Le nor the * names of its contributors may be used to endorse or promote products derived * from this software without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS IS * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE * POSSIBILITY OF SUCH DAMAGE. */ --- Mario Ivankovits (JIRA) dev@myfaces.apache.org wrote: [ http://issues.apache.org/jira/browse/TOMAHAWK-250?page=comments#action_12374327 ] Mario Ivankovits commented on TOMAHAWK-250: --- Adapted from the original component developed by Kevin Le (http://pragmaticobjects.com) does this mean you copied some source from there? If so, what license was/is it? Where did you have the icons from? Whats their license? Would it be possible to use org.apache.myfaces.custom.navmenu.NavigationMenuItem to configure the component. That way it could be an easy replacement and we should try to keep our configurations slick. New 'Outlook Menu' type component for Sandbox -- Key: TOMAHAWK-250 URL: http://issues.apache.org/jira/browse/TOMAHAWK-250 Project: MyFaces Tomahawk Type: New Feature Reporter: Sharath Reddy Attachments: patch.zip This component provides 'Outlook menu' type of component for MyFaces. Features include: 1. Action and action listener can be specified for each menu option 2. Menu can be constructed dynamically from a backing bean as demonstrated in the 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 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[al] license question [was [jira] Commented: (TOMAHAWK-250) New 'Outlook Menu' type component for Sandbox]
sharath reddy schrieb: Ok, I see that NavigationMenuItems already has a List attribute. I could probably use this. I can submit a patch. Great! BTW, below is the license from the original files. I am sorry if I seem to be a bit naive about license issues No problem, licensing stuff is odd ;-) , I assumed that since I corresponded with Le and obtained his permission, there would not be any issues. The question is if Le was aware that you would change the license. What to do next? How can we ensure that there is no license problem? Do Le and Sharath have to sign a CLA? /* * Created on Dec 19, 2004 * * Copyright (c) 2005, Pragmatic Objects - Kevin H. Le * All rights reserved. * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions are met: * * 1. Redistributions of source code must retain the above copyright notice, * this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright notice, * this list of conditions and the following disclaimer in the documentation * and/or other materials provided with the distribution. * 3. Neither the name of the Pragmatic Objects nor Kevin H. Le nor the * names of its contributors may be used to endorse or promote products derived * from this software without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS IS * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE * POSSIBILITY OF SUCH DAMAGE. */ Ciao, Mario
JavaScript set values and model update
I have a problem with JavaScript set values. t:selectOneMenu id=moduleSelect forceId=true value=#{search.module} f:selectItems value=#{search.modules} / /t:selectOneMenu Than I add options to this select menu via js. var a = document.getElementById(moduleSelect).options; a[0] = new Option(,, false); and so on... My #{search.modules} also returns a SelectItem list(when appropriate). But the problem is unless #{search.modules} is not empty, whatever i choose update my model with that data. Is there anything that I'm missing here? I use Facelets/MyFaces. smime.p7s Description: S/MIME Cryptographic Signature
dataScroller with newspaperTable?
hello all, Is it possible to apply a dataScroller on a newspaperTable? I tried this with newspaperColumns=2 but got only one column. I asked the people from the user mailing list with no result :( Please help. thanx! Marcus t:newspaperTable id=at newspaperColumns=2 rows=#{articleHandler.numberRowsPerPage} value=#{articleHandler.currentRowSet.wrappedData} var=article f:facet name=spacerf:verbatim#160;/f:verbatim/f:facet h:column id=col h:outputText value=#{article.title} id=title / /h:column /t:newspaperTable t:dataScroller for=at style=margin-top: 1em fastStep=20 pageCountVar=pageCount pageIndexVar=pageIndex paginator=true paginatorMaxPages=20 paginatorTableClass=paginator paginatorActiveColumnClass=paginatorActiveColumn renderFacetsIfSinglePage=false /t:dataScroller
[jira] Created: (TOMAHAWK-251) previousRowDataVar is not saved/restored
previousRowDataVar is not saved/restored Key: TOMAHAWK-251 URL: http://issues.apache.org/jira/browse/TOMAHAWK-251 Project: MyFaces Tomahawk Type: Bug Components: Extended Datatable Versions: 1.1.1 Reporter: Chris Rudd The previousRowDatavar is not managed by the saveState/restoreState methods. This results in the value being null on all subsequent requests that restore the view. Note: if you use value binding it works as UIComponentBase manages the save/restore of all value bindings. -- 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: default AutoScroll setting depends on Tomahawk
Mario, You never got back to me on this. What do you think? I am willing to help add this functionality to the sandbox focus component if that is where you think it should go but I think it should go with the auto-scrolling stuff for accessibility reasons (i.e. no mouse). You are the more experienced Myfaces developer. Let me know. Chad Lyon Application Software Developer Science Applications International Corporation (SAIC) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 12, 2006 11:25 AM To: MyFaces Development Subject: RE: default AutoScroll setting depends on Tomahawk Sorry for being ignorant, but whats the value for the user to have the focus reset on the last action component? Let's say you are tabbing through the controls on a shopping cart page (in a mouse-less world). After changing the number of items in an inputText field you tab to a button that, for example, updates your shopping cart. You hit space bar to press the button (fire the action), the page reloads and your focus is back at the top. In a similar thick client app you would retain focus to the button you just pressed. Chad Lyon Application Software Developer Science Applications International Corporation (SAIC) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mario Ivankovits Sent: Wednesday, April 12, 2006 9:59 AM To: MyFaces Development Subject: Re: default AutoScroll setting depends on Tomahawk Hi You seem like the person to approve the patch I wrote for auto-focus. Sorry for being ignorant, but whats the value for the user to have the focus reset on the last action component? Could you please explain this a little bit for me. If, I would like to have the focus set on the first component caused a validation error, else the focus should be on the first inputable component on the page. For sure, both scenarios can be solved by enhancing the focus component. Ciao, Mario
Re: [al] license question [was [jira] Commented: (TOMAHAWK-250) New 'Outlook Menu' type component for Sandbox]
On 4/13/06, Mario Ivankovits [EMAIL PROTECTED] wrote: * Copyright (c) 2005, Pragmatic Objects - Kevin H. Le It looks like a pretty standard BSD license. Do Le and Sharath have to sign a CLA? Yes, it would be best if Le signed a CLA and agreed to release this under the Apache 2.0 license. Otherwise, we'll have to carry forward the Pragmatic Objects BSD license, which is extra work. Depending on the size of the contribution, it's not necessarily worthwhile. Sharath should also sign a CLA if this is a significant contribution -- it's currently unclear how much of the work is from Sharath and how much is from Le.
Re: [al] license question [was [jira] Commented: (TOMAHAWK-250) New 'Outlook Menu' type component for Sandbox]
What to do next? How can we ensure that there is no license problem? Do Le and Sharath have to sign a CLA? To play it safe, yes ( as well as Pragmatic Objects ). The apache main site has information on corporate intellectual property contributions. Dennis Byrne
Re: default AutoScroll setting depends on Tomahawk
Hi Lyon! You never got back to me on this. Yes, sorry! What do you think? I am willing to help add this functionality to the sandbox focus component if that is where you think it should go but I think it should go with the auto-scrolling stuff for accessibility reasons (i.e. no mouse). I would be more happy if we manage to put it into the focus component. For this to work we have to create a way so components can register additional (global) fields with form/link/button. A more generic way like adding every possible function again and again into the core. The focus component then can register with them and tell them wich javascript/field/wathever to render if e.g. it is configured with t:focus captureActionFocus=true/ We can rename our DummyFormLinkRenderer and DummyFormButtonRenderer in tomahawk to something like ExtendedLinkRenderer and ExtendedButtonRender and also create an ExtendedFormRenderer in tomahawk. The registry could be a request bean where we have to outline its interface and possibilities. What do you think? Ciao, Mario
[jira] Created: (TOMAHAWK-252) tree2 table, td for spacing/navigation inherits CSS styles
tree2 table, td for spacing/navigation inherits CSS styles -- Key: TOMAHAWK-252 URL: http://issues.apache.org/jira/browse/TOMAHAWK-252 Project: MyFaces Tomahawk Type: Improvement Components: Tree2 Versions: 1.1.1 Environment: tree2 uses table and td to implement spacing and placement of the tree branch lines, folder images etc. this is problematic if the t:tree2 is within another table, as the cells may inherit CSS styles from the parent table class= resulting in undesireable borders or padding around the tree navigation components despite table border=0 cellpadding=0 etc. suggested solution is to use img instead for fixed width placeholders instead of a nested table. Reporter: Bill Schneider -- 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: default AutoScroll setting depends on Tomahawk
On 4/13/06, Lyon, Chad S. [EMAIL PROTECTED] wrote: I am willing to help add this functionality to the sandbox focus component if that is where you think it should go but I think it should go with the auto-scrolling stuff for accessibility reasons (i.e. no mouse). I think it's fine for it to work like auto-scrolling does. However, I think it'd also be good if we either added a focus attribute for Tomahawk components, or -- and I think this would be more versatile -- included the focus component as part of this process, so that a page designer could change the focus behavior without writing javascript. I'd also like to see something similar for autoscroll, but with my limited javascript knowledge, I was never able to get autoscrolling to be controllable. On 4/13/06, Mario Ivankovits [EMAIL PROTECTED] wrote: For this to work we have to create a way so components can register additional (global) fields with form/link/button. A more generic way like adding every possible function again and again into the core. Mario, this is a good idea! The Jenia4Faces developers were asking me about this same functionality yesterday.All I could suggest was that they scan the component tree for the form and programmically add a hidden input field to the component tree. I have no idea how practical that process would be.
[jira] Created: (MYFACES-1283) JavaScript error on AccordionPanel
JavaScript error on AccordionPanel -- Key: MYFACES-1283 URL: http://issues.apache.org/jira/browse/MYFACES-1283 Project: MyFaces Core Type: Bug Components: General Versions: 1.1.0, 1.0.9m9, 1.1.1, 1.1.2-SNAPSHOT Reporter: Rogério Pereira Araújo Priority: Blocker Fix For: 1.1.2-SNAPSHOT When i load a page with AccordionPanel i get these errors: Error: {expandedBg:#63699c, hoverBg:#63699c, collapsedBg:#6b79a5, expandedTextColor:#ff, expandedFontWeight:bold, hoverTextColor:#ff, collapsedTextColor:#ced7ef, collapsedFontWeight:normal, hoverTextColor:#ff, borderColor:#1f669b, panelHeight:200, onHideTab:null, onShowTab:null}.extend is not a function source file: http://localhost:8080/myfaces-example-sandbox/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/11449359/accordion.HtmlAccordionPanelRenderer/customRico.js Line: 50 Error: {expandedBg:#63699c, hoverBg:#63699c, collapsedBg:#6b79a5, expandedTextColor:#ff, expandedFontWeight:bold, hoverTextColor:#ff, collapsedTextColor:#ced7ef, collapsedFontWeight:normal, hoverTextColor:#ff, borderColor:#1f669b, panelHeight:200, closedPanelHeight:50, useRealHeight:true, onHideTab:null, onShowTab:null}.extend is not a function source file: http://localhost:8080/myfaces-example-sandbox/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/11449359/accordion.HtmlAccordionPanelRenderer/customRico.js Line: 276 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-1283) JavaScript error on AccordionPanel
[ http://issues.apache.org/jira/browse/MYFACES-1283?page=all ] Rogério Pereira Araújo updated MYFACES-1283: Status: Patch Available (was: Open) JavaScript error on AccordionPanel -- Key: MYFACES-1283 URL: http://issues.apache.org/jira/browse/MYFACES-1283 Project: MyFaces Core Type: Bug Components: General Versions: 1.1.0, 1.0.9m9, 1.1.1, 1.1.2-SNAPSHOT Reporter: Rogério Pereira Araújo Priority: Blocker Fix For: 1.1.2-SNAPSHOT Attachments: customRico.diff When i load a page with AccordionPanel i get these errors: Error: {expandedBg:#63699c, hoverBg:#63699c, collapsedBg:#6b79a5, expandedTextColor:#ff, expandedFontWeight:bold, hoverTextColor:#ff, collapsedTextColor:#ced7ef, collapsedFontWeight:normal, hoverTextColor:#ff, borderColor:#1f669b, panelHeight:200, onHideTab:null, onShowTab:null}.extend is not a function source file: http://localhost:8080/myfaces-example-sandbox/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/11449359/accordion.HtmlAccordionPanelRenderer/customRico.js Line: 50 Error: {expandedBg:#63699c, hoverBg:#63699c, collapsedBg:#6b79a5, expandedTextColor:#ff, expandedFontWeight:bold, hoverTextColor:#ff, collapsedTextColor:#ced7ef, collapsedFontWeight:normal, hoverTextColor:#ff, borderColor:#1f669b, panelHeight:200, closedPanelHeight:50, useRealHeight:true, onHideTab:null, onShowTab:null}.extend is not a function source file: http://localhost:8080/myfaces-example-sandbox/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/11449359/accordion.HtmlAccordionPanelRenderer/customRico.js Line: 276 -- 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-1281) Unable to write and restore serialized views
[ http://issues.apache.org/jira/browse/MYFACES-1281?page=comments#action_12374370 ] sean schofield commented on MYFACES-1281: - My patch still does not fix TCK problem. Without getting into too much of an NDA area here, lets just say the TCK makes two different requests to test this and that its unaware of our view sequence produced during rendering. My proposed solution is to store the sequence of the last view accessed in the session so that if there is a problem obtaining the sequence it can default to this. I don't think this will break existing functionality but I'm hoping to hear more from the serialized view experts out there. Unable to write and restore serialized views Key: MYFACES-1281 URL: http://issues.apache.org/jira/browse/MYFACES-1281 Project: MyFaces Core Type: Bug Components: JSR-127 Versions: 1.1.2-SNAPSHOT Reporter: sean schofield Priority: Blocker Fix For: 1.1.2-SNAPSHOT Attachments: one_line_fix.patch TCK testing turned up an apparent issue with restoring serialized views. Because of the NDA I can't get into the specific details of the test but I have added my own unit test to core-impl that demonstrates the problem. We need to fix this ASAP. -- 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: [IMPORTANT] Major blocker issue: MYFACES-1281
This issue still isn't fixed. Please review my latest JIRA comments on the proposed solution. This issue is our top priority right now. Sean On 4/12/06, Sean Schofield [EMAIL PROTECTED] wrote: BTW, it appears i did not commit the test last night or the fix today. I just committed both to the branch. Sean On 4/12/06, Sean Schofield [EMAIL PROTECTED] wrote: Ok so this is how things work outside of unit tests. I am committing a fix that I think should work for the unit test (and TCK) and still leave the existing functionality the way it is (which is presumably good b/c we've heard no complaints on this.) Sean On 4/12/06, Dennis Byrne [EMAIL PROTECTED] wrote: MyFaces looks for a parameter called jsf_sequence . Do a few post backs on any form page in the example app and you'll see this incremented. This is how the impl keeps track of which view to associate w/ each IF YOU KNOW ANYTHING MORE ON THIS, HELP. Dennis Byrne -Original Message- From: Sean Schofield [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 12, 2006 11:58 AM To: 'MyFaces Development' Subject: Re: [IMPORTANT] Major blocker issue: MYFACES-1281 Still waiting for some help on this issue. Come on MyFaces committers lets get this one figured out. You don't need the TCK to fix this. Just make the unit test work and help explain how it works (if it ever worked) in the standard non-unit test case. Sean On 4/11/06, Sean Schofield [EMAIL PROTECTED] wrote: There is an outstanding issue that is preventing us from passing the TCK. Without this we cannot release a JSF 1.1 certified release. We could use everyone's help in tracking this down and resolving ASAP. We need to get on with the 1.1.2 release. Sean ps. More frequent releases should help reduce the number of suprise TCK failures per release. Also more unit tests will be helpful here.
[jira] Updated: (MYFACES-821) Usage of request attributes for caching
[ http://issues.apache.org/jira/browse/MYFACES-821?page=all ] updated MYFACES-821: - Status: Patch Available (was: Open) Usage of request attributes for caching --- Key: MYFACES-821 URL: http://issues.apache.org/jira/browse/MYFACES-821 Project: MyFaces Core Type: Bug Versions: 1.1.0 Environment: liferay 3.6.1 Reporter: Michael Lipp Assignee: Stan Silvert JspStateManagerImpl (and maybe other classes) uses request attributes for caching state. This causes a wrong view to be used if there is more than one JSF-based portlet on a single page. MyFaces saves the serialized view of the first portlet on the page as a request attribute. To avoid re-serialization, MyFaces subsequently checks if there already is a request attribute with a serialized view. As request attributes are not scoped to a single portlet (the portlet specification does not require this), the serialized view of the first portlet will be found and used by the second portlet. This usage of request attributes may also be the cause of MYFACES-549. As JSF, of course, does not need to know about the portlet environment, it cannot be required that MyFaces saves such information per view, e.g. by prepending the viewId to the key for the request attribute (although this would solve the problem). IMHO any request attributes added during lifecycle.render() should be removed after lifecycle() render by the portlet bridge. (The same applies to request attributes added during lifecycle.execute(), but these should also be re-added before lifecycle.render().) I have implemented this in my portlet bridge as a workaround. -- 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-1281) Unable to write and restore serialized views
[ http://issues.apache.org/jira/browse/MYFACES-1281?page=comments#action_12374380 ] Mario Ivankovits commented on MYFACES-1281: --- I'll have a look at it now - even if I am not a serialized view expert ;-) Unable to write and restore serialized views Key: MYFACES-1281 URL: http://issues.apache.org/jira/browse/MYFACES-1281 Project: MyFaces Core Type: Bug Components: JSR-127 Versions: 1.1.2-SNAPSHOT Reporter: sean schofield Priority: Blocker Fix For: 1.1.2-SNAPSHOT Attachments: one_line_fix.patch TCK testing turned up an apparent issue with restoring serialized views. Because of the NDA I can't get into the specific details of the test but I have added my own unit test to core-impl that demonstrates the problem. We need to fix this ASAP. -- 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: Provide Patch / Cancel Patch
Sorry, I got mixed up while fixing the workflow. There are two separate concepts: 1.) workflow, 2.) workflow scheme. I had only changed the scheme but it was pointing to the wrong workflow. It should be fixed now. Sean On 4/13/06, Volker Weber [EMAIL PROTECTED] wrote: Hi Sean, are you sure? It looks like just a anonymous user triggers this, see http://issues.apache.org/jira/browse/TOBAGO-54?page=all Regards, Volker Sean Schofield wrote: Done. Users must have the same permissions as for Create Issue (which is to say they must be logged in.) Sean On 3/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote: I'm wondering if it'd be possible to restrict Provide Patch to logged-in users. It's annoying when an anonymous user triggers this with a patch because there's no way to identify them in order to educate them as to why it was the wrong thing to do. On 3/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote: Is there any way to have the JIRA notification mail state when one of these buttons was pushed? Right now we only get the following (Anon said there was a patch; I cancelled the process because there wasn't one). Anonymous (JIRA) [ http://issues.apache.org/jira/browse/TOMAHAWK-134?page=all ] updated TOMAHAWK-134: Mike Kienenberger (JIRA) [ http://issues.apache.org/jira/browse/TOMAHAWK-134?page=all ] Mike Kienenberger updated TOMAHAWK-134: -- Don't answer to From: address! Mail to this account are droped if not recieved via mailinglist. To contact me direct create the mail address by concatenating my forename to my senders domain.
[jira] Created: (TOMAHAWK-253) Dummy form code must call StateManager.saveSerializedView() for server-side state saving
Dummy form code must call StateManager.saveSerializedView() for server-side state saving Key: TOMAHAWK-253 URL: http://issues.apache.org/jira/browse/TOMAHAWK-253 Project: MyFaces Tomahawk Type: Bug Versions: 1.1.2-SNAPSHOT Environment: Generic issue. Reporter: Adam Winer The current dummy form code in DummyFormUtils has a block that reads: if (stateManager.isSavingStateInClient(facesContext)) { //render state parameters //TODO: Optimize saveSerializedView call, because serialized view is built twice! StateManager.SerializedView serializedView = stateManager.saveSerializedView(facesContext); stateManager.writeState(facesContext, serializedView); } else { writer.startElement(HTML.INPUT_ELEM, null); writer.writeAttribute(org.apache.myfaces.shared_tomahawk.renderkit.html.HTML.TYPE_ATTR, org.apache.myfaces.shared_tomahawk.renderkit.html.HTML.INPUT_TYPE_HIDDEN, null); writer.writeAttribute(HTML.NAME_ATTR, org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.SEQUENCE_PARAM, null); writer.writeAttribute(org.apache.myfaces.shared_tomahawk.renderkit.html.HTML.VALUE_ATTR, org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.getViewSequence(facesContext), null); writer.endElement(org.apache.myfaces.shared_tomahawk.renderkit.html.HTML.INPUT_ELEM); } Note that stateManager.saveSerializedView() is only called for client-side state saving. This means that the dummy form code never actually gets around to calling stateManager.saveSerializedView(), so unless someone else has called this method, the view never actually gets saved in the session. This is breaking the latest release of Facelets (1.1.5), which has added optimizations that avoid unnecessary calls to the StateManager. Simple fix: haul StateManager.SerializedView serializedView = stateManager.saveSerializedView(facesContext); ... out of the if block. Ideally, this code should be refactored so that the server-side code is also calling StateManager.writeState() too - it's a significant problem that DummyFormUtils has hardcoded knowledge of how the StateManager works. -- 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-253) Dummy form code must call StateManager.saveSerializedView() for server-side state saving
[ http://issues.apache.org/jira/browse/TOMAHAWK-253?page=all ] Adam Winer updated TOMAHAWK-253: Status: Patch Available (was: Open) Dummy form code must call StateManager.saveSerializedView() for server-side state saving Key: TOMAHAWK-253 URL: http://issues.apache.org/jira/browse/TOMAHAWK-253 Project: MyFaces Tomahawk Type: Bug Versions: 1.1.2-SNAPSHOT Environment: Generic issue. Reporter: Adam Winer The current dummy form code in DummyFormUtils has a block that reads: if (stateManager.isSavingStateInClient(facesContext)) { //render state parameters //TODO: Optimize saveSerializedView call, because serialized view is built twice! StateManager.SerializedView serializedView = stateManager.saveSerializedView(facesContext); stateManager.writeState(facesContext, serializedView); } else { writer.startElement(HTML.INPUT_ELEM, null); writer.writeAttribute(org.apache.myfaces.shared_tomahawk.renderkit.html.HTML.TYPE_ATTR, org.apache.myfaces.shared_tomahawk.renderkit.html.HTML.INPUT_TYPE_HIDDEN, null); writer.writeAttribute(HTML.NAME_ATTR, org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.SEQUENCE_PARAM, null); writer.writeAttribute(org.apache.myfaces.shared_tomahawk.renderkit.html.HTML.VALUE_ATTR, org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.getViewSequence(facesContext), null); writer.endElement(org.apache.myfaces.shared_tomahawk.renderkit.html.HTML.INPUT_ELEM); } Note that stateManager.saveSerializedView() is only called for client-side state saving. This means that the dummy form code never actually gets around to calling stateManager.saveSerializedView(), so unless someone else has called this method, the view never actually gets saved in the session. This is breaking the latest release of Facelets (1.1.5), which has added optimizations that avoid unnecessary calls to the StateManager. Simple fix: haul StateManager.SerializedView serializedView = stateManager.saveSerializedView(facesContext); ... out of the if block. Ideally, this code should be refactored so that the server-side code is also calling StateManager.writeState() too - it's a significant problem that DummyFormUtils has hardcoded knowledge of how the StateManager works. -- 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
Any status update on the Subversion repos?
Hi Craig, It is now three weeks since the announcement of the new adffaces-xxx mailing lists. I know you are busy, but do you have a status update on the creation of the Subversion repository for these components? Thanks - Jonas -- Author: Pro JSF and Ajax: Building Rich Internet Components Blog: http://www.orablogs.com/jjacobi
[jira] Commented: (TOMAHAWK-253) Dummy form code must call StateManager.saveSerializedView() for server-side state saving
[ http://issues.apache.org/jira/browse/TOMAHAWK-253?page=comments#action_12374383 ] Adam Winer commented on TOMAHAWK-253: - As with my last issue, no true patch, but a one-line fix provided in the bug text. Dummy form code must call StateManager.saveSerializedView() for server-side state saving Key: TOMAHAWK-253 URL: http://issues.apache.org/jira/browse/TOMAHAWK-253 Project: MyFaces Tomahawk Type: Bug Versions: 1.1.2-SNAPSHOT Environment: Generic issue. Reporter: Adam Winer The current dummy form code in DummyFormUtils has a block that reads: if (stateManager.isSavingStateInClient(facesContext)) { //render state parameters //TODO: Optimize saveSerializedView call, because serialized view is built twice! StateManager.SerializedView serializedView = stateManager.saveSerializedView(facesContext); stateManager.writeState(facesContext, serializedView); } else { writer.startElement(HTML.INPUT_ELEM, null); writer.writeAttribute(org.apache.myfaces.shared_tomahawk.renderkit.html.HTML.TYPE_ATTR, org.apache.myfaces.shared_tomahawk.renderkit.html.HTML.INPUT_TYPE_HIDDEN, null); writer.writeAttribute(HTML.NAME_ATTR, org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.SEQUENCE_PARAM, null); writer.writeAttribute(org.apache.myfaces.shared_tomahawk.renderkit.html.HTML.VALUE_ATTR, org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.getViewSequence(facesContext), null); writer.endElement(org.apache.myfaces.shared_tomahawk.renderkit.html.HTML.INPUT_ELEM); } Note that stateManager.saveSerializedView() is only called for client-side state saving. This means that the dummy form code never actually gets around to calling stateManager.saveSerializedView(), so unless someone else has called this method, the view never actually gets saved in the session. This is breaking the latest release of Facelets (1.1.5), which has added optimizations that avoid unnecessary calls to the StateManager. Simple fix: haul StateManager.SerializedView serializedView = stateManager.saveSerializedView(facesContext); ... out of the if block. Ideally, this code should be refactored so that the server-side code is also calling StateManager.writeState() too - it's a significant problem that DummyFormUtils has hardcoded knowledge of how the StateManager works. -- 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
ADF Faces and JIRA
Is there a reason why we can't use the custom MyFaces JIRA workflow for the ADF Faces project? We have a few little extras that are nice to have and this will ultimately make it easier to assimilate the ADF project when the time comes. Sean ps. I'm happy to change it if this is desired.
Re: ADF Faces and JIRA
I'd definitely want to use the same workflow. -- Adam On 4/13/06, Sean Schofield [EMAIL PROTECTED] wrote: Is there a reason why we can't use the custom MyFaces JIRA workflow for the ADF Faces project? We have a few little extras that are nice to have and this will ultimately make it easier to assimilate the ADF project when the time comes. Sean ps. I'm happy to change it if this is desired.
[jira] Commented: (MYFACES-1281) Unable to write and restore serialized views
[ http://issues.apache.org/jira/browse/MYFACES-1281?page=comments#action_12374388 ] Mario Ivankovits commented on MYFACES-1281: --- Ok, looks like I got it. It already falls back to the sessionmap if the sequence cant be found in the request, the problem ist, that the FIRST sequence isnt stored in the session map (subsequent will - so in fact this IS ab BUG) I dont like the code around the sequence number, but its not the time to rewrite it ;-) , so I made a quick hack which also saves the sequence in the session on the first request. Unable to write and restore serialized views Key: MYFACES-1281 URL: http://issues.apache.org/jira/browse/MYFACES-1281 Project: MyFaces Core Type: Bug Components: JSR-127 Versions: 1.1.2-SNAPSHOT Reporter: sean schofield Priority: Blocker Fix For: 1.1.2-SNAPSHOT Attachments: one_line_fix.patch TCK testing turned up an apparent issue with restoring serialized views. Because of the NDA I can't get into the specific details of the test but I have added my own unit test to core-impl that demonstrates the problem. We need to fix this ASAP. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-821) Usage of request attributes for caching
[ http://issues.apache.org/jira/browse/MYFACES-821?page=all ] Mike Kienenberger updated MYFACES-821: -- Status: Open (was: Patch Available) Usage of request attributes for caching --- Key: MYFACES-821 URL: http://issues.apache.org/jira/browse/MYFACES-821 Project: MyFaces Core Type: Bug Versions: 1.1.0 Environment: liferay 3.6.1 Reporter: Michael Lipp Assignee: Stan Silvert JspStateManagerImpl (and maybe other classes) uses request attributes for caching state. This causes a wrong view to be used if there is more than one JSF-based portlet on a single page. MyFaces saves the serialized view of the first portlet on the page as a request attribute. To avoid re-serialization, MyFaces subsequently checks if there already is a request attribute with a serialized view. As request attributes are not scoped to a single portlet (the portlet specification does not require this), the serialized view of the first portlet will be found and used by the second portlet. This usage of request attributes may also be the cause of MYFACES-549. As JSF, of course, does not need to know about the portlet environment, it cannot be required that MyFaces saves such information per view, e.g. by prepending the viewId to the key for the request attribute (although this would solve the problem). IMHO any request attributes added during lifecycle.render() should be removed after lifecycle() render by the portlet bridge. (The same applies to request attributes added during lifecycle.execute(), but these should also be re-added before lifecycle.render().) I have implemented this in my portlet bridge as a workaround. -- 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-210) Would be recommendable to add to a new attribute to tag t:panelTab that allows to disabled a certain tab
[ http://issues.apache.org/jira/browse/TOMAHAWK-210?page=all ] Mike Kienenberger updated TOMAHAWK-210: --- Status: Open (was: Patch Available) Would be recommendable to add to a new attribute to tag t:panelTab that allows to disabled a certain tab -- Key: TOMAHAWK-210 URL: http://issues.apache.org/jira/browse/TOMAHAWK-210 Project: MyFaces Tomahawk Type: New Feature Components: Tabbed Pane Environment: Windows XP Jboss 4.0.3SP1 Tomahawk 1.1.1 Reporter: Jorge Rodríguez Pedrianes Priority: Minor Hello, I have been working with the component Tabbe Pane and have seen that it has the possibility of disabled a certain tab taking care of role of user. Although this very is limited, this could also be done to with an attribute in tag t:panelTab/, for example with one with the name disabled that you can put to him a boolean or one EL. For Example: t:panelTab . disabled=true / or t:panelTab . disabled=#{backingBean.disabled} / -- 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: Provide Patch / Cancel Patch
On 4/13/06, Sean Schofield [EMAIL PROTECTED] wrote: Sorry, I got mixed up while fixing the workflow. There are two separate concepts: 1.) workflow, 2.) workflow scheme. I had only changed the scheme but it was pointing to the wrong workflow. It should be fixed now. I'm able to cancel patches again. I haven't tested to insure that anonymous users can't provide them, but I'm sure some anonymous user will step forward and let us know if it's still possible :)
Re: ADF Faces and JIRA
Done. I noticed the project has its own permissions and notifications schemes as well. Notification probably makes sense because of the different mailing lists. I'll look at permissions at some future point. Sean On 4/13/06, Adam Winer [EMAIL PROTECTED] wrote: I'd definitely want to use the same workflow. -- Adam On 4/13/06, Sean Schofield [EMAIL PROTECTED] wrote: Is there a reason why we can't use the custom MyFaces JIRA workflow for the ADF Faces project? We have a few little extras that are nice to have and this will ultimately make it easier to assimilate the ADF project when the time comes. Sean ps. I'm happy to change it if this is desired.
Re: [IMPORTANT] Major blocker issue: MYFACES-1281
What about Mario's fix 2 hours ago? (see Jira)ManfredOn 4/13/06, Sean Schofield [EMAIL PROTECTED] wrote:This issue still isn't fixed.Please review my latest JIRA comments on the proposed solution.This issue is our top priority right now.SeanOn 4/12/06, Sean Schofield [EMAIL PROTECTED] wrote: BTW, it appears i did not commit the test last night or the fix today. I just committed both to the branch. Sean On 4/12/06, Sean Schofield [EMAIL PROTECTED] wrote: Ok so this is how things work outside of unit tests.I am committing a fix that I think should work for the unit test (and TCK) and still leave the existing functionality the way it is (which is presumably good b/c we've heard no complaints on this.) Sean On 4/12/06, Dennis Byrne [EMAIL PROTECTED] wrote: MyFaces looks for a parameter called jsf_sequence .Do a few post backs on any form page in the example app and you'll see this incremented.This is how the impl keeps track of which view to associate w/ each IF YOU KNOW ANYTHING MORE ON THIS, HELP. Dennis Byrne -Original Message- From: Sean Schofield [mailto: [EMAIL PROTECTED]] Sent: Wednesday, April 12, 2006 11:58 AM To: 'MyFaces Development' Subject: Re: [IMPORTANT] Major blocker issue: MYFACES-1281 Still waiting for some help on this issue.Come on MyFaces committers lets get this one figured out.You don't need the TCK to fix this. Just make the unit test work and help explain how it works (if it ever worked) in the standard non-unit test case. Sean On 4/11/06, Sean Schofield [EMAIL PROTECTED] wrote:There is an outstanding issue that is preventing us from passing theTCK.Without this we cannot release a JSF 1.1 certified release.We could use everyone's help in tracking this down and resolving ASAP.We need to get on with the 1.1.2 release. Sean ps. More frequent releases should help reduce the number of supriseTCK failures per release.Also more unit tests will be helpful here.
RE: Core 1.1.2 Branch - Incorrect Dependency?
Sean, Thanks, Core looks good now. Are we supposed to be testing the Tomahawk 1.1.2 branch as well, or is the focus just on Shared and Core right now? I ask because as it stands right now in the branch, Tomahawk's core pom.xml is still pointing to myfaces-shared-impl-2.0.0-SNAPSHOT.jar. Jeremy -Original Message- From: Sean Schofield [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 12, 2006 8:03 PM To: MyFaces Development Subject: Re: Core 1.1.2 Branch - Incorrect Dependency? Jeremy, You're correct about the dependency. I had changed it in the dependency section but forgot about Manfred's shared refactoring magic. Good catch. I'm checking in a fixed POM now. Sean On 4/12/06, Jeremy J. Grelle [EMAIL PROTECTED] wrote: Hello everyone. I just started to try and do some testing of the 1.1.2 release and noticed a possible problem when I cleared out my maven repo so that I could do a clean build. When building the core-impl package, maven went and grabbed myfaces-shared-impl-2.0.1-SNAPSHOT.jar for the repackaging bit. Shouldn't it be getting myfaces-shared-impl-2.0.0.jar? Found the following bit in the pom.xml that is triggering this: plugin groupIdorg.codehaus.mojo/groupId artifactIddependency-maven-plugin/artifactId executions execution idunpack-shared-impl/id phaseprocess-classes/phase goalsgoalunpack/goal/goals configuration artifactItems artifactItem groupIdorg.apache.myfaces.shared/groupId artifactIdmyfaces-shared-impl/artifactId version2.0.1-SNAPSHOT/version /artifactItem /artifactItems outputDirectory${project.build.directory}/classes/outputDirectory /configuration /execution /executions /plugin Thanks, Jeremy
Re: Puzzled about generated code
On 4/13/06, Manfred Geiler [EMAIL PROTECTED] wrote: In a few minutes I will checkin the reborn codegenerator - stay tuned. Excellent! We can start working on facelet and shale support now.
Re: Core 1.1.2 Branch - Incorrect Dependency?
On 4/13/06, Jeremy J. Grelle [EMAIL PROTECTED] wrote: Are we supposed to be testing the Tomahawk 1.1.2 branch as well, or is the focus just on Shared and Core right now? Shared and Core right now. I ask because as it stands right now in the branch, Tomahawk's core pom.xml is still pointing to myfaces-shared-impl-2.0.0-SNAPSHOT.jar. That seems wrong. Tomahawk shouldn't have any shared_impl dependencies right now. Try changing it to shared-tomahawk. Sandbox still has a few core dependencies, but those are slowing being removed.
Re: [IMPORTANT] Major blocker issue: MYFACES-1281
Hi! What about Mario's fix 2 hours ago? (see Jira) :-D I dont know which date jira shows, but I patched it for about half an hour ago. I already told Sean about it and he prepares a new TCK test cycle. Ciao, Mario
Re: Any status update on the Subversion repos?
Thanks Craig, I really appreciate this - Jonas Craig McClanahan wrote: Jonas Jacobi wrote: Hi Craig, It is now three weeks since the announcement of the new adffaces-xxx mailing lists. I know you are busy, but do you have a status update on the creation of the Subversion repository for these components? Thanks - Jonas -- *Author*: Pro JSF and Ajax: Building Rich Internet Components http://apress.com/book/bookDisplay.html?bID=10044 *Blog*: http://www.orablogs.com/jjacobi When I looked yesterday, the request to create this subversion repository was 23rd on the list of outstanding infrastructure issues (yes, it takes a long time :-( sometimes). However, in response to some pings from me on Monday, it at least got assigned to someone who promised to look at it "this week." Same thing (but different volunteer) for the new account setups. I'll try again. Craig -- Author: Pro JSF and Ajax: Building Rich Internet Components Blog: http://www.orablogs.com/jjacobi
Re: Any status update on the Subversion repos?
Jonas Jacobi wrote: Hi Craig, It is now three weeks since the announcement of the new adffaces-xxx mailing lists. I know you are busy, but do you have a status update on the creation of the Subversion repository for these components? Thanks - Jonas -- *Author*: Pro JSF and Ajax: Building Rich Internet Components http://apress.com/book/bookDisplay.html?bID=10044 *Blog*: http://www.orablogs.com/jjacobi When I looked yesterday, the request to create this subversion repository was 23rd on the list of outstanding infrastructure issues (yes, it takes a long time :-( sometimes). However, in response to some pings from me on Monday, it at least got assigned to someone who promised to look at it this week. Same thing (but different volunteer) for the new account setups. I'll try again. Craig
Re: Any status update on the Subversion repos?
On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: Jonas Jacobi wrote: Hi Craig, It is now three weeks since the announcement of the new adffaces-xxx mailing lists. I know you are busy, but do you have a status update on the creation of the Subversion repository for these components? Thanks - Jonas -- *Author*: Pro JSF and Ajax: Building Rich Internet Components http://apress.com/book/bookDisplay.html?bID=10044 *Blog*: http://www.orablogs.com/jjacobiWhen I looked yesterday, the request to create this subversionrepository was 23rd on the list of outstanding infrastructure issues (yes, it takes a long time :-( sometimes).However, in response to somepings from me on Monday, it at least got assigned to someone whopromised to look at it this week.Same thing (but different volunteer) for the new account setups.I'll try again.Unless there's more to it than I think there is, I should be able to take care of the SVN repo this evening, if Garrett doesn't beat me to it. I believe all that's involved is adding the directories in SVN and updating the auth and mailer config files. --Martin CooperCraig
[jira] Closed: (MYFACES-821) Usage of request attributes for caching
[ http://issues.apache.org/jira/browse/MYFACES-821?page=all ] Stan Silvert closed MYFACES-821: Resolution: Won't Fix This is a problem in LifeRay. The latest version has a fix. Usage of request attributes for caching --- Key: MYFACES-821 URL: http://issues.apache.org/jira/browse/MYFACES-821 Project: MyFaces Core Type: Bug Versions: 1.1.0 Environment: liferay 3.6.1 Reporter: Michael Lipp Assignee: Stan Silvert JspStateManagerImpl (and maybe other classes) uses request attributes for caching state. This causes a wrong view to be used if there is more than one JSF-based portlet on a single page. MyFaces saves the serialized view of the first portlet on the page as a request attribute. To avoid re-serialization, MyFaces subsequently checks if there already is a request attribute with a serialized view. As request attributes are not scoped to a single portlet (the portlet specification does not require this), the serialized view of the first portlet will be found and used by the second portlet. This usage of request attributes may also be the cause of MYFACES-549. As JSF, of course, does not need to know about the portlet environment, it cannot be required that MyFaces saves such information per view, e.g. by prepending the viewId to the key for the request attribute (although this would solve the problem). IMHO any request attributes added during lifecycle.render() should be removed after lifecycle() render by the portlet bridge. (The same applies to request attributes added during lifecycle.execute(), but these should also be re-added before lifecycle.render().) I have implemented this in my portlet bridge as a workaround. -- 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: [IMPORTANT] Major blocker issue: MYFACES-1281
Yes Mario's checkin will hopefull fix this. I'm preparing a new TCK for testing as we speak. Sean On 4/13/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! What about Mario's fix 2 hours ago? (see Jira) :-D I dont know which date jira shows, but I patched it for about half an hour ago. I already told Sean about it and he prepares a new TCK test cycle. Ciao, Mario
[jira] Created: (TOMAHAWK-254) inputCalendar in datatable - Conversion error occurred.
inputCalendar in datatable - Conversion error occurred. - Key: TOMAHAWK-254 URL: http://issues.apache.org/jira/browse/TOMAHAWK-254 Project: MyFaces Tomahawk Type: Bug Components: Calendar Versions: 1.1.1 Environment: WSAD 5.1.2 with Tomahawk Reporter: Todd Smith When we are using the inputCalendar inside a datatable and binding it to our dataBeans we get conversion errors when we try to save changes or even navigate to another page. Conversion error occurred. This happened for all fields that were either populated or null. example code: h:dataTable width=750 border=1 cellpadding=0 cellspacing=0 value=#{rateTableBB.productsListModel} var=results headerClass=DataText2Bold rowClasses=DataText2,DataText2GrayBG columnClasses=center footerClass=center ... h:column t:inputCalendar id=productEndDate styleClass=InputField10 monthYearRowClass=yearMonthHeader weekRowClass=weekHeader renderPopupButtonAsImage=true popupDateFormat=MM/dd/ renderAsPopup=true currentDayCellClass=currentDayCell size=10 value=#{results.capnProvAgrmtGUIBean.utilDateTrmntnDt} onchange=checkThisRow(this,'productEndDate','row') / /h:column /dataTable I'm not exacly sure why this is happening. We couldn't get the dates to bind at all even outside a datatable unless we used Java.util.Dates and we had to bind to a field directly in our backing bean ie. #{ourBackingBean.someUtilDate}. Then we have to manually get/set our date field from our transfer object. If we try to link to a dataBean by reference, the page won't bind the date and nothing will submit. #{someTransferObject.ourDatabean.someUtilDate}. Thus our page is effectively hung. Has anyone come across these issue and how to fix? We want to bind by reference to the transfer object. Do we need to add all our databeans and transfer objects into our faces.config? -- 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: Core 1.1.2 Branch - Incorrect Dependency?
I believe this branch should be blown away entirely. The 1.1.2 stuff is on the trunk. We created this branch a while ago to sort out the tohawk/shared refactoring. Now that everything has been merged down I think this branch should be killed. Any objections? Sean On 4/13/06, Mike Kienenberger [EMAIL PROTECTED] wrote: On 4/13/06, Jeremy J. Grelle [EMAIL PROTECTED] wrote: Are we supposed to be testing the Tomahawk 1.1.2 branch as well, or is the focus just on Shared and Core right now? Shared and Core right now. I ask because as it stands right now in the branch, Tomahawk's core pom.xml is still pointing to myfaces-shared-impl-2.0.0-SNAPSHOT.jar. That seems wrong. Tomahawk shouldn't have any shared_impl dependencies right now. Try changing it to shared-tomahawk. Sandbox still has a few core dependencies, but those are slowing being removed.
Re: Core 1.1.2 Branch - Incorrect Dependency?
Hi! Now that everything has been merged down I think this branch should be killed. Any objections? My last patch is not merged down, shall I commit it there? Ciao, Mario
Re: Any status update on the Subversion repos?
On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: Jonas Jacobi wrote: Hi Craig, It is now three weeks since the announcement of the new adffaces-xxx mailing lists. I know you are busy, but do you have a status update on the creation of the Subversion repository for these components? Thanks - Jonas -- *Author*: Pro JSF and Ajax: Building Rich Internet Components http://apress.com/book/bookDisplay.html?bID=10044 *Blog*: http://www.orablogs.com/jjacobiWhen I looked yesterday, the request to create this subversion repository was 23rd on the list of outstanding infrastructure issues (yes, it takes a long time :-( sometimes).However, in response to somepings from me on Monday, it at least got assigned to someone whopromised to look at it this week.Same thing (but different volunteer) for the new account setups.I'll try again.Unless there's more to it than I think there is, I should be able to take care of the SVN repo this evening, if Garrett doesn't beat me to it. I believe all that's involved is adding the directories in SVN and updating the auth and mailer config files. That would be awesome. Thanks Martin!! --Martin Cooper Craig Craig
[jira] Closed: (MYFACES-549) faces navigation rules not working for two portlets on portal page
[ http://issues.apache.org/jira/browse/MYFACES-549?page=all ] Stan Silvert closed MYFACES-549: Resolution: Won't Fix The latest version of LifeRay has a fix for this. faces navigation rules not working for two portlets on portal page -- Key: MYFACES-549 URL: http://issues.apache.org/jira/browse/MYFACES-549 Project: MyFaces Core Type: Bug Components: General Versions: 1.1.1 Environment: Linux 2.6.12, Java 1.5.0_04, Liferay Pro 3.6.1 (portla), nightly build (20050909) Reporter: zeroconf Priority: Minor Attachments: cardemo.war.zip I'm trying to write some JSF portlets within one portlet application but encountered some problems concerning navigation rules when I put more than one JSF portlet per portal page. When I put just one portlet on my page everything concerning the navigation rules (with h:commandButton action=p1next value=go on / stuff) works fine and I get to the next view. But when I put a second faces portlet on the page navigation and invoking actions on backing beans in the second portlet just doesn't work at all. If I remove both portlets and put the second portlet on the page again (so that I'm having just one portlet again) this portlet works fine as well. So I assume that navigation settings in faces-config.xml must be correct. It has something to do with the arrangement of two faces portlets on the portal page so that the second one stops working as expected. I also tried to use distinct IDs for all ui-components and also distinct from-output-values but that doesn't help Thanks zeroconf Attached are the important parts of my web.xml, faces-config.xml and portlet.xml web.xml ?xml version=1.0? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app display-namePROJECT_NAME/display-name context-param param-namecompany_id/param-name param-valueliferay.com/param-value /context-param context-param param-namejavax.faces.STATE_SAVING_METHOD/param-name param-valueclient/param-value /context-param context-param param-namejavax.faces.application.CONFIG_FILES/param-name param-value/WEB-INF/faces-config.xml/param-value /context-param listener listener-classcom.liferay.portal.servlet.PortletContextListener/listener-class /listener listener listener-classorg.apache.myfaces.webapp.StartupServletContextListener/listener-class /listener servlet servlet-namePROJECT_NAME/servlet-name servlet-classcom.liferay.portal.servlet.PortletServlet/servlet-class init-param param-nameportlet-class/param-name param-valueorg.apache.myfaces.portlet.MyFacesGenericPortlet/param-value /init-param load-on-startup0/load-on-startup /servlet servlet servlet-nameFacesServlet/servlet-name servlet-classjavax.faces.webapp.FacesServlet/servlet-class load-on-startup1/load-on-startup /servlet servlet-mapping servlet-namePROJECT_NAME/servlet-name url-pattern/PROJECT_NAME/*/url-pattern /servlet-mapping taglib taglib-urihttp://java.sun.com/portlet/taglib-uri taglib-location/WEB-INF/tld/liferay-portlet.tld/taglib-location /taglib /web-app faces-config.xml: == ?xml version=1.0? !DOCTYPE faces-config PUBLIC -//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN http://java.sun.com/dtd/web-facesconfig_1_1.dtd; faces-config xmlns=http://java.sun.com/JSF/Configuration; factory faces-context-factoryorg.apache.myfaces.context.MyFacesContextFactoryImpl/faces-context-factory /factory !-- navigation for JSF portlet 1 -- navigation-rule from-view-id/jsp/jsf1/index.jsp/from-view-id navigation-case from-outcomep1next/from-outcome to-view-id/jsp/jsf1/n1.jsp/to-view-id /navigation-case /navigation-rule navigation-rule from-view-id/jsp/jsf1/n1.jsp/from-view-id navigation-case from-outcomep1back/from-outcome to-view-id/jsp/jsf1/index.jsp/to-view-id /navigation-case /navigation-rule !-- navigation for JSF portlet 2 -- navigation-rule from-view-id/jsp/jsf2/index.jsp/from-view-id navigation-case from-outcomep2next/from-outcome
Re: Core 1.1.2 Branch - Incorrect Dependency?
Oh, you didnt mean shared, sorry, I'll stop computing for today ;-) --- Mario Now that everything has been merged down I think this branch should be killed. Any objections? My last patch is not merged down, shall I commit it there? Ciao, Mario
Re: Core 1.1.2 Branch - Incorrect Dependency?
We should wait and merge down everything (on both branches) once the release is finalized. I guess we make an exception for the one command link thing you fixed earlier where the branch fix is incompatible with the trunk code. Please remind me to do this though when the time comes. Sean On 4/13/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Oh, you didnt mean shared, sorry, I'll stop computing for today ;-) --- Mario Now that everything has been merged down I think this branch should be killed. Any objections? My last patch is not merged down, shall I commit it there? Ciao, Mario
[jira] Updated: (TOBAGO-54) visual text decoration component
[ http://issues.apache.org/jira/browse/TOBAGO-54?page=all ] Volker Weber updated TOBAGO-54: --- Status: Open (was: Patch Available) visual text decoration component Key: TOBAGO-54 URL: http://issues.apache.org/jira/browse/TOBAGO-54 Project: MyFaces Tobago Type: New Feature Versions: 1.0.7 Reporter: Nazar Stasiv Fix For: 1.0.8 I need to manage t:link component text decoration. I have sheet component with items t:link. First column displays t:link elements with underlined font, but the rest of columns should be links without underlining. Since it is not possible to apply font styles to t:link directly I propose to introduce new t:font component which will add bold,italic,underline attributes to manage font display in a flexible way. This wont break concept of view layer. What do you think ? -- 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: (TOBAGO-54) visual text decoration component
[ http://issues.apache.org/jira/browse/TOBAGO-54?page=comments#action_12374410 ] Volker Weber commented on TOBAGO-54: There is already a 'markup' attribute at out tag [1], I think we should add this attribute also to the link tag and discuss which markup types we will have. Currendly possible values are 'none', 'strong' and 'deleted', but they are not realy supported by the themes. [1] http://myfaces.apache.org/tobago/tobago-core/tlddoc/tc/out.html visual text decoration component Key: TOBAGO-54 URL: http://issues.apache.org/jira/browse/TOBAGO-54 Project: MyFaces Tobago Type: New Feature Versions: 1.0.7 Reporter: Nazar Stasiv Fix For: 1.0.8 I need to manage t:link component text decoration. I have sheet component with items t:link. First column displays t:link elements with underlined font, but the rest of columns should be links without underlining. Since it is not possible to apply font styles to t:link directly I propose to introduce new t:font component which will add bold,italic,underline attributes to manage font display in a flexible way. This wont break concept of view layer. What do you think ? -- 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: Any status update on the Subversion repos?
That would be fantastic! Thanks plenty, Jonas Martin Cooper wrote: On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: Jonas Jacobi wrote: Hi Craig, It is now three weeks since the announcement of the new adffaces-xxx mailing lists. I know you are busy, but do you have a status update on the creation of the Subversion repository for these components? Thanks - Jonas -- *Author*: Pro JSF and Ajax: Building Rich Internet Components http://apress.com/book/bookDisplay.html?bID=10044 *Blog*: http://www.orablogs.com/jjacobi When I looked yesterday, the request to create this subversion repository was 23rd on the list of outstanding infrastructure issues (yes, it takes a long time :-( sometimes).However, in response to some pings from me on Monday, it at least got assigned to someone who promised to look at it "this week."Same thing (but different volunteer) for the new account setups.I'll try again. Unless there's more to it than I think there is, I should be able to take care of the SVN repo this evening, if Garrett doesn't beat me to it. I believe all that's involved is adding the directories in SVN and updating the auth and mailer config files. -- Martin Cooper Craig -- Author: Pro JSF and Ajax: Building Rich Internet Components Blog: http://www.orablogs.com/jjacobi
[jira] Created: (TOMAHAWK-255) inputCalendar in a datatable can't submit with null values
inputCalendar in a datatable can't submit with null values -- Key: TOMAHAWK-255 URL: http://issues.apache.org/jira/browse/TOMAHAWK-255 Project: MyFaces Tomahawk Type: Bug Components: Calendar Versions: 1.1.1 Environment: WSAD 5.1.2 - Windows 2000 - ie6 Reporter: Todd Smith When I have an inputCalendar field in a datatable, i get a Conversion error occurred message for each inputcalendar field in my datatable that has a null value when I try to submit anything on the page. This sounds similar to the myfaces 233 bug for the inputDate problem in a datatable. Is there a way to turn off the converter/validator for null values? I also noticed the onchange events don't seem to be working when you select a date from the calendar. I also set required=false, to try to allow nulls, but that didn't work either. Thanks -- 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: Any status update on the Subversion repos?
I believe this is done. Your repo is at:https://svn.apache.org/repos/asf/incubator/adffaces/Note that I have not created the standard trunk / tags / branches directories in there, since incubator podlings appear to be doing things differently - some have them, some don't - so I figured I'd let you decide what you want to do. I've given karma to craigmcc, matzew, mmarinschek and baranda, per INCUBATOR-17.Commits should go to the right place.If someone could verify for me that it's all working, I'll go ahead and close out the JIRA issues. --Martin CooperOn 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: Jonas Jacobi wrote: Hi Craig, It is now three weeks since the announcement of the new adffaces-xxx mailing lists. I know you are busy, but do you have a status update on the creation of the Subversion repository for these components? Thanks - Jonas -- *Author*: Pro JSF and Ajax: Building Rich Internet Components http://apress.com/book/bookDisplay.html?bID=10044*Blog*: http://www.orablogs.com/jjacobi When I looked yesterday, the request to create this subversion repository was 23rd on the list of outstanding infrastructure issues (yes, it takes a long time :-( sometimes).However, in response to some pings from me on Monday, it at least got assigned to someone who promised to look at it this week.Same thing (but different volunteer) for the new account setups.I'll try again. Unless there's more to it than I think there is, I should be able to take care of the SVN repo this evening, if Garrett doesn't beat me to it. I believe all that's involved is adding the directories in SVN and updating the auth and mailer config files.That would be awesome.Thanks Martin!!-- Martin Cooper Craig Craig
Re: Any status update on the Subversion repos?
On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: I believe this is done. Your repo is at:https://svn.apache.org/repos/asf/incubator/adffaces/ Note that I have not created the standard trunk / tags / branches directories in there, since incubator podlings appear to be doing things differently - some have them, some don't - so I figured I'd let you decide what you want to do. I've given karma to craigmcc, matzew, mmarinschek and baranda, per INCUBATOR-17.Commits should go to the right place.If someone could verify for me that it's all working, I'll go ahead and close out the JIRA issues. Works for me (complete with email to the commits list) ... thanks Martin!I assume that granting karma to other authorized committers is just a matter of editing the infrastructure subversion/asf-authorization file, right? I'm on the Incubator PMC, so karma for that shouldn't be a problem. Craig-- Martin CooperOn 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: Jonas Jacobi wrote: Hi Craig, It is now three weeks since the announcement of the new adffaces-xxx mailing lists. I know you are busy, but do you have a status update on the creation of the Subversion repository for these components? Thanks - Jonas -- *Author*: Pro JSF and Ajax: Building Rich Internet Components http://apress.com/book/bookDisplay.html?bID=10044*Blog*: http://www.orablogs.com/jjacobi When I looked yesterday, the request to create this subversion repository was 23rd on the list of outstanding infrastructure issues (yes, it takes a long time :-( sometimes).However, in response to some pings from me on Monday, it at least got assigned to someone who promised to look at it this week.Same thing (but different volunteer) for the new account setups.I'll try again. Unless there's more to it than I think there is, I should be able to take care of the SVN repo this evening, if Garrett doesn't beat me to it. I believe all that's involved is adding the directories in SVN and updating the auth and mailer config files.That would be awesome.Thanks Martin!!-- Martin Cooper Craig Craig
Re: Any status update on the Subversion repos?
On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: I believe this is done. Your repo is at:https://svn.apache.org/repos/asf/incubator/adffaces/ Note that I have not created the standard trunk / tags / branches directories in there, since incubator podlings appear to be doing things differently - some have them, some don't - so I figured I'd let you decide what you want to do. I've given karma to craigmcc, matzew, mmarinschek and baranda, per INCUBATOR-17.Commits should go to the right place.If someone could verify for me that it's all working, I'll go ahead and close out the JIRA issues. Works for me (complete with email to the commits list) ... thanks Martin!No problem. Happy to help. I assume that granting karma to other authorized committers is just a matter of editing the infrastructure subversion/asf-authorization file, right? Right. I'm on the Incubator PMC, so karma for that shouldn't be a problem. Actually, only PMC chairs have explicit rights for that, but I think you'll be OK because you're an ASF member.--Martin Cooper Craig -- Martin CooperOn 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: Jonas Jacobi wrote: Hi Craig, It is now three weeks since the announcement of the new adffaces-xxx mailing lists. I know you are busy, but do you have a status update on the creation of the Subversion repository for these components? Thanks - Jonas -- *Author*: Pro JSF and Ajax: Building Rich Internet Components http://apress.com/book/bookDisplay.html?bID=10044*Blog*: http://www.orablogs.com/jjacobi When I looked yesterday, the request to create this subversion repository was 23rd on the list of outstanding infrastructure issues (yes, it takes a long time :-( sometimes).However, in response to some pings from me on Monday, it at least got assigned to someone who promised to look at it this week.Same thing (but different volunteer) for the new account setups.I'll try again. Unless there's more to it than I think there is, I should be able to take care of the SVN repo this evening, if Garrett doesn't beat me to it. I believe all that's involved is adding the directories in SVN and updating the auth and mailer config files.That would be awesome.Thanks Martin!!-- Martin Cooper Craig Craig
Re: Any status update on the Subversion repos?
On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: I believe this is done. Your repo is at:https://svn.apache.org/repos/asf/incubator/adffaces/ Note that I have not created the standard trunk / tags / branches directories in there, since incubator podlings appear to be doing things differently - some have them, some don't - so I figured I'd let you decide what you want to do. I've given karma to craigmcc, matzew, mmarinschek and baranda, per INCUBATOR-17.Commits should go to the right place.If someone could verify for me that it's all working, I'll go ahead and close out the JIRA issues. Works for me (complete with email to the commits list) ... thanks Martin!No problem. Happy to help. I assume that granting karma to other authorized committers is just a matter of editing the infrastructure subversion/asf-authorization file, right? Right. I'm on the Incubator PMC, so karma for that shouldn't be a problem. Actually, only PMC chairs have explicit rights for that, but I think you'll be OK because you're an ASF member. It's not letting me right now ... i'll go ahead and request karma on the infra list. --Martin CooperCraig Craig -- Martin CooperOn 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: Jonas Jacobi wrote: Hi Craig, It is now three weeks since the announcement of the new adffaces-xxx mailing lists. I know you are busy, but do you have a status update on the creation of the Subversion repository for these components? Thanks - Jonas -- *Author*: Pro JSF and Ajax: Building Rich Internet Components http://apress.com/book/bookDisplay.html?bID=10044*Blog*: http://www.orablogs.com/jjacobi When I looked yesterday, the request to create this subversion repository was 23rd on the list of outstanding infrastructure issues (yes, it takes a long time :-( sometimes).However, in response to some pings from me on Monday, it at least got assigned to someone who promised to look at it this week.Same thing (but different volunteer) for the new account setups.I'll try again. Unless there's more to it than I think there is, I should be able to take care of the SVN repo this evening, if Garrett doesn't beat me to it. I believe all that's involved is adding the directories in SVN and updating the auth and mailer config files.That would be awesome.Thanks Martin!!-- Martin Cooper Craig Craig
Re: Any status update on the Subversion repos?
Excellent, thanks! Once I get an apache account, karma for the SVN, and a bit of free time, I can check this puppy in and we can started for real! -- Adam On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: I believe this is done. Your repo is at: https://svn.apache.org/repos/asf/incubator/adffaces/ Note that I have not created the standard trunk / tags / branches directories in there, since incubator podlings appear to be doing things differently - some have them, some don't - so I figured I'd let you decide what you want to do. I've given karma to craigmcc, matzew, mmarinschek and baranda, per INCUBATOR-17. Commits should go to the right place. If someone could verify for me that it's all working, I'll go ahead and close out the JIRA issues. Works for me (complete with email to the commits list) ... thanks Martin! I assume that granting karma to other authorized committers is just a matter of editing the infrastructure subversion/asf-authorization file, right? I'm on the Incubator PMC, so karma for that shouldn't be a problem. Craig -- Martin Cooper On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: Jonas Jacobi wrote: Hi Craig, It is now three weeks since the announcement of the new adffaces-xxx mailing lists. I know you are busy, but do you have a status update on the creation of the Subversion repository for these components? Thanks - Jonas -- *Author*: Pro JSF and Ajax: Building Rich Internet Components http://apress.com/book/bookDisplay.html?bID=10044 *Blog*: http://www.orablogs.com/jjacobi When I looked yesterday, the request to create this subversion repository was 23rd on the list of outstanding infrastructure issues (yes, it takes a long time :-( sometimes). However, in response to some pings from me on Monday, it at least got assigned to someone who promised to look at it this week. Same thing (but different volunteer) for the new account setups. I'll try again. Unless there's more to it than I think there is, I should be able to take care of the SVN repo this evening, if Garrett doesn't beat me to it. I believe all that's involved is adding the directories in SVN and updating the auth and mailer config files. That would be awesome. Thanks Martin!! -- Martin Cooper Craig Craig
Re: Any status update on the Subversion repos?
Scratch item #1 - just got the e-mail, [EMAIL PROTECTED] now exists. ;) Who can grant me karma for http://svn.apache.org/repos/asf/incubator/adffaces/? -- Adam On 4/13/06, Adam Winer [EMAIL PROTECTED] wrote: Excellent, thanks! Once I get an apache account, karma for the SVN, and a bit of free time, I can check this puppy in and we can started for real! -- Adam On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: I believe this is done. Your repo is at: https://svn.apache.org/repos/asf/incubator/adffaces/ Note that I have not created the standard trunk / tags / branches directories in there, since incubator podlings appear to be doing things differently - some have them, some don't - so I figured I'd let you decide what you want to do. I've given karma to craigmcc, matzew, mmarinschek and baranda, per INCUBATOR-17. Commits should go to the right place. If someone could verify for me that it's all working, I'll go ahead and close out the JIRA issues. Works for me (complete with email to the commits list) ... thanks Martin! I assume that granting karma to other authorized committers is just a matter of editing the infrastructure subversion/asf-authorization file, right? I'm on the Incubator PMC, so karma for that shouldn't be a problem. Craig -- Martin Cooper On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: Jonas Jacobi wrote: Hi Craig, It is now three weeks since the announcement of the new adffaces-xxx mailing lists. I know you are busy, but do you have a status update on the creation of the Subversion repository for these components? Thanks - Jonas -- *Author*: Pro JSF and Ajax: Building Rich Internet Components http://apress.com/book/bookDisplay.html?bID=10044 *Blog*: http://www.orablogs.com/jjacobi When I looked yesterday, the request to create this subversion repository was 23rd on the list of outstanding infrastructure issues (yes, it takes a long time :-( sometimes). However, in response to some pings from me on Monday, it at least got assigned to someone who promised to look at it this week. Same thing (but different volunteer) for the new account setups. I'll try again. Unless there's more to it than I think there is, I should be able to take care of the SVN repo this evening, if Garrett doesn't beat me to it. I believe all that's involved is adding the directories in SVN and updating the auth and mailer config files. That would be awesome. Thanks Martin!! -- Martin Cooper Craig Craig
Re: Any status update on the Subversion repos?
On 4/13/06, Adam Winer [EMAIL PROTECTED] wrote: Scratch item #1 - just got the e-mail, [EMAIL PROTECTED]now exists. ;)Who can grant me karma forhttp://svn.apache.org/repos/asf/incubator/adffaces/ ?Scratch #2 - you now have karma. Now all you need is free time. ;-)John Fallows also now has karma. FYI, we still don't have ICLAs from Jonas Jacobi or Omar Tazi.--Martin Cooper -- AdamOn 4/13/06, Adam Winer [EMAIL PROTECTED] wrote: Excellent, thanks!Once I get an apache account, karma for the SVN, and a bit of free time, I can check this puppy in and we can started for real! -- Adam On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: I believe this is done. Your repo is at: https://svn.apache.org/repos/asf/incubator/adffaces/ Note that I have not created the standard trunk / tags / branches directories in there, since incubator podlings appear to be doing things differently - some have them, some don't - so I figured I'd let you decide what you want to do. I've given karma to craigmcc, matzew, mmarinschek and baranda, per INCUBATOR-17. Commits should go to the right place. If someone could verify for me that it's all working, I'll go ahead and close out the JIRA issues. Works for me (complete with email to the commits list) ... thanks Martin! I assume that granting karma to other authorized committers is just a matter of editing the infrastructure subversion/asf-authorization file, right?I'm on the Incubator PMC, so karma for that shouldn't be a problem. Craig-- Martin Cooper On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: Jonas Jacobi wrote: Hi Craig, It is now three weeks since the announcement of the newadffaces-xxx mailing lists. I know you are busy, but do you have a status update on the creation of the Subversion repository for these components? Thanks - Jonas -- *Author*: Pro JSF and Ajax: Building Rich Internet Components http://apress.com/book/bookDisplay.html?bID=10044*Blog*: http://www.orablogs.com/jjacobi When I looked yesterday, the request to create this subversion repository was 23rd on the list of outstanding infrastructure issues (yes, it takes a long time :-( sometimes).However, in response tosome pings from me on Monday, it at least got assigned to someone who promised to look at it this week.Same thing (but different volunteer) for the new account setups.I'll try again. Unless there's more to it than I think there is, I should be able totake care of the SVN repo this evening, if Garrett doesn't beat me to it. I believe all that's involved is adding the directories in SVN andupdating the auth and mailer config files. That would be awesome.Thanks Martin!! -- Martin Cooper Craig Craig
Re: Any status update on the Subversion repos?
On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: On 4/13/06, Adam Winer [EMAIL PROTECTED] wrote: Scratch item #1 - just got the e-mail, [EMAIL PROTECTED]now exists. ;)Who can grant me karma for http://svn.apache.org/repos/asf/incubator/adffaces/ ?Scratch #2 - you now have karma. Now all you need is free time. ;-)Plus one more detail :-). We need to decide about the organization of the incubator repository. I'll post a separate thread on that in just a minute. John Fallows also now has karma. FYI, we still don't have ICLAs from Jonas Jacobi or Omar Tazi. --Martin Cooper Craig -- AdamOn 4/13/06, Adam Winer [EMAIL PROTECTED] wrote: Excellent, thanks!Once I get an apache account, karma for the SVN, and a bit of free time, I can check this puppy in and we can started for real! -- Adam On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: I believe this is done. Your repo is at: https://svn.apache.org/repos/asf/incubator/adffaces/ Note that I have not created the standard trunk / tags / branches directories in there, since incubator podlings appear to be doing things differently - some have them, some don't - so I figured I'd let you decide what you want to do. I've given karma to craigmcc, matzew, mmarinschek and baranda, per INCUBATOR-17. Commits should go to the right place. If someone could verify for me that it's all working, I'll go ahead and close out the JIRA issues. Works for me (complete with email to the commits list) ... thanks Martin! I assume that granting karma to other authorized committers is just a matter of editing the infrastructure subversion/asf-authorization file, right?I'm on the Incubator PMC, so karma for that shouldn't be a problem. Craig-- Martin Cooper On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: Jonas Jacobi wrote: Hi Craig, It is now three weeks since the announcement of the newadffaces-xxx mailing lists. I know you are busy, but do you have a status update on the creation of the Subversion repository for these components? Thanks - Jonas -- *Author*: Pro JSF and Ajax: Building Rich Internet Components http://apress.com/book/bookDisplay.html?bID=10044*Blog*: http://www.orablogs.com/jjacobi When I looked yesterday, the request to create this subversion repository was 23rd on the list of outstanding infrastructure issues (yes, it takes a long time :-( sometimes).However, in response tosome pings from me on Monday, it at least got assigned to someone who promised to look at it this week.Same thing (but different volunteer) for the new account setups.I'll try again. Unless there's more to it than I think there is, I should be able totake care of the SVN repo this evening, if Garrett doesn't beat me to it. I believe all that's involved is adding the directories in SVN andupdating the auth and mailer config files. That would be awesome.Thanks Martin!! -- Martin Cooper Craig Craig
Re: Any status update on the Subversion repos?
Darnit Martin, you keep working that fast, I'm gonna run out of excuses in a hurry! ;) Just verified commits work fine for me. Thanks for the super-fast turn around! I'll talk to Omar and Jonas about the ICLAs. It wouldn't surprise me if Omar doesn't want one - he's been a huge asset for slashing through the inevitable red tape on the Oracle side of things. -- Adam On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: On 4/13/06, Adam Winer [EMAIL PROTECTED] wrote: Scratch item #1 - just got the e-mail, [EMAIL PROTECTED] now exists. ;) Who can grant me karma for http://svn.apache.org/repos/asf/incubator/adffaces/ ? Scratch #2 - you now have karma. Now all you need is free time. ;-) John Fallows also now has karma. FYI, we still don't have ICLAs from Jonas Jacobi or Omar Tazi. -- Martin Cooper -- Adam On 4/13/06, Adam Winer [EMAIL PROTECTED] wrote: Excellent, thanks! Once I get an apache account, karma for the SVN, and a bit of free time, I can check this puppy in and we can started for real! -- Adam On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: I believe this is done. Your repo is at: https://svn.apache.org/repos/asf/incubator/adffaces/ Note that I have not created the standard trunk / tags / branches directories in there, since incubator podlings appear to be doing things differently - some have them, some don't - so I figured I'd let you decide what you want to do. I've given karma to craigmcc, matzew, mmarinschek and baranda, per INCUBATOR-17. Commits should go to the right place. If someone could verify for me that it's all working, I'll go ahead and close out the JIRA issues. Works for me (complete with email to the commits list) ... thanks Martin! I assume that granting karma to other authorized committers is just a matter of editing the infrastructure subversion/asf-authorization file, right? I'm on the Incubator PMC, so karma for that shouldn't be a problem. Craig -- Martin Cooper On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: Jonas Jacobi wrote: Hi Craig, It is now three weeks since the announcement of the new adffaces-xxx mailing lists. I know you are busy, but do you have a status update on the creation of the Subversion repository for these components? Thanks - Jonas -- *Author*: Pro JSF and Ajax: Building Rich Internet Components http://apress.com/book/bookDisplay.html?bID=10044 *Blog*: http://www.orablogs.com/jjacobi When I looked yesterday, the request to create this subversion repository was 23rd on the list of outstanding infrastructure issues (yes, it takes a long time :-( sometimes). However, in response to some pings from me on Monday, it at least got assigned to someone who promised to look at it this week. Same thing (but different volunteer) for the new account setups. I'll try again. Unless there's more to it than I think there is, I should be able to take care of the SVN repo this evening, if Garrett doesn't beat me to it. I believe all that's involved is adding the directories in SVN and updating the auth and mailer config files. That would be awesome. Thanks Martin!! -- Martin Cooper Craig Craig