Re: [Myfaces Wiki] Update of DoraRajappan by DoraRajappan
Thank you for sharing that information. I have created new page https://wiki.apache.org/myfaces/core22_inputfile. Myfaces wiki is indeed very useful. From: Mike Kienenberger mkien...@gmail.com To: MyFaces Development dev@myfaces.apache.org Cc: Dora Rajappan dorarajap...@yahoo.com Sent: Thursday, July 25, 2013 7:50 PM Subject: Re: [Myfaces Wiki] Update of DoraRajappan by DoraRajappan You should probably pick a better page name for your article on setting up file transfers. Page names with the same name as the wiki user are normally spam. On Thu, Jul 25, 2013 at 8:33 AM, Apache Wiki wikidi...@apache.org wrote: The DoraRajappan page has been changed by DoraRajappan: https://wiki.apache.org/myfaces/DoraRajappan New page: ##language:en == Your Name == Email: MailTo( dorarajap...@yahoo.com ) ... core 2.2 How to set up tomcat 7 for file transfer and ensure file is transferred. 1. in context.xml of the server conf directory add the attribute allowCasualMultipartParsing and set the value to true. Context ... allowCasualMultipartParsing=true ||style=text-align: leftallowCasualMultipartParsing ||style=text-align: leftSet to true if Tomcat should automatically parse multipart/form-data request bodies when HttpServletRequest.getPart* or HttpServletRequest.getParameter* is called, even when the target servlet isn't marked with the @MultipartConfig annotation (See Servlet Specification 3.0, Section 3.2 for details). Note that any setting other than false causes Tomcat to behave in a way that is not technically spec-compliant. The default is false || 2. Install wireshark http://www.wireshark.org/docs/wsug_html_chunked/ChBuildInstallWinInstall.html 3.If you are using usb to connect to the network install usbpcap http://wiki.wireshark.org/CaptureSetup/USB 4.Start tomcat and start capture of http packets. Refer http://www.wireshark.org/docs/wsug_html_chunked/ChapterCapture.htmlto know to start the capture. Then submit file from the browser. 5.Analyse the http packets and ensure the file is transferred fully.
Re: [Myfaces Wiki] Update of DoraRajappan by DoraRajappan
You should probably pick a better page name for your article on setting up file transfers. Page names with the same name as the wiki user are normally spam. On Thu, Jul 25, 2013 at 8:33 AM, Apache Wiki wikidi...@apache.org wrote: The DoraRajappan page has been changed by DoraRajappan: https://wiki.apache.org/myfaces/DoraRajappan New page: ##language:en == Your Name == Email: MailTo( dorarajap...@yahoo.com ) ... core 2.2 How to set up tomcat 7 for file transfer and ensure file is transferred. 1. in context.xml of the server conf directory add the attribute allowCasualMultipartParsing and set the value to true. Context ... allowCasualMultipartParsing=true ||style=text-align: leftallowCasualMultipartParsing ||style=text-align: leftSet to true if Tomcat should automatically parse multipart/form-data request bodies when HttpServletRequest.getPart* or HttpServletRequest.getParameter* is called, even when the target servlet isn't marked with the @MultipartConfig annotation (See Servlet Specification 3.0, Section 3.2 for details). Note that any setting other than false causes Tomcat to behave in a way that is not technically spec-compliant. The default is false || 2. Install wireshark http://www.wireshark.org/docs/wsug_html_chunked/ChBuildInstallWinInstall.html 3.If you are using usb to connect to the network install usbpcap http://wiki.wireshark.org/CaptureSetup/USB 4.Start tomcat and start capture of http packets. Refer http://www.wireshark.org/docs/wsug_html_chunked/ChapterCapture.html to know to start the capture. Then submit file from the browser. 5.Analyse the http packets and ensure the file is transferred fully.
Re: myfaces wiki
Hi, Yes, great idea, Gerhard. +1 on that from me! Regards, Jakob 2010/6/11 Gerhard Petracek gerhard.petra...@gmail.com hi @ all, i've started to move some parts to our new (c)wiki. however, imo we should just move the information which is important for users. that means we should continue to use the moinmoin wiki just for information related to our dev-team (e.g. our reports, release wiki pages, drafts,...). so users benefit from the additional features of confluence and it's easier for them to look through the released documentation. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: myfaces wiki
+1 Am 11.06.10 20:34, schrieb Jakob Korherr: Hi, Yes, great idea, Gerhard. +1 on that from me! Regards, Jakob 2010/6/11 Gerhard Petracek gerhard.petra...@gmail.com mailto:gerhard.petra...@gmail.com hi @ all, i've started to move some parts to our new (c)wiki. however, imo we should just move the information which is important for users. that means we should continue to use the moinmoin wiki just for information related to our dev-team (e.g. our reports, release wiki pages, drafts,...). so users benefit from the additional features of confluence and it's easier for them to look through the released documentation. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: myfaces wiki
+1. Very good idea. On Fri, Jun 11, 2010 at 12:10 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi @ all, i've started to move some parts to our new (c)wiki. however, imo we should just move the information which is important for users. that means we should continue to use the moinmoin wiki just for information related to our dev-team (e.g. our reports, release wiki pages, drafts,...). so users benefit from the additional features of confluence and it's easier for them to look through the released documentation. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 http://www.amazon.com/-/e/B002M052KY Web blog: http://hazems.blogetery.com/ [Web 2.0] Mashups Integration with JSF: http://code.google.com/p/mashups4jsf/
Re: myfaces wiki
+1 Am 29.03.10 11:00, schrieb Gerhard Petracek: hi, yes - i'll help with the admin tasks... @space-key: +1 for myfaces regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/29 Matthias Wessendorf mat...@apache.org mailto:mat...@apache.org # Include the cwiki account name of a PMC member (preferably the PMC chair) who will help administer the space. Gerhard, do you want to help to administer the space? For the next weeks I have not much to time for that... # Also specify the key name for the Space. The key name cannot be changed. = myfaces ? :) .Matthias On Mon, Mar 29, 2010 at 10:25 AM, Gerhard Petracek gerhard.petra...@gmail.com mailto:gerhard.petra...@gmail.com wrote: ok - i propose that we do it step by step. let's start to move the wiki of codi and extval to confluence. is that ok for everyone? @matthias: [1] describes the steps to request a cwiki space. regards, gerhard [1] http://cwiki.apache.org/confluence/display/CWIKI/Index http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/24 Gabrielle Crawford gabrielle.crawf...@oracle.com mailto:gabrielle.crawf...@oracle.com +1 confluence is so much better Jakob Korherr wrote: +1 from me :) Frankly I don't really like the current wiki.. Regards, Jakob 2010/3/24 Matthias Wessendorf mat...@apache.org mailto:mat...@apache.org mailto:mat...@apache.org mailto:mat...@apache.org +1 I don't remember the outcome of the old discussion, wasn't there one? Anyways I am +1 on confluence... -Matthias On Wed, Mar 24, 2010 at 11:30 AM, Gerhard Petracek gerhard.petra...@gmail.com mailto:gerhard.petra...@gmail.com mailto:gerhard.petra...@gmail.com mailto:gerhard.petra...@gmail.com wrote: hi @ all, what do you think about moving our wiki to confluence[1]? regards, gerhard [1] http://cwiki.apache.org/confluence/ http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: myfaces wiki
today i created a jira issue for it [1]. - it's just a matter of time. regards, gerhard [1] http://issues.apache.org/jira/browse/INFRA-2579 http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/30 Werner Punz werner.p...@gmail.com +1 Am 29.03.10 11:00, schrieb Gerhard Petracek: hi, yes - i'll help with the admin tasks... @space-key: +1 for myfaces regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/29 Matthias Wessendorf mat...@apache.org mailto: mat...@apache.org # Include the cwiki account name of a PMC member (preferably the PMC chair) who will help administer the space. Gerhard, do you want to help to administer the space? For the next weeks I have not much to time for that... # Also specify the key name for the Space. The key name cannot be changed. = myfaces ? :) .Matthias On Mon, Mar 29, 2010 at 10:25 AM, Gerhard Petracek gerhard.petra...@gmail.com mailto:gerhard.petra...@gmail.com wrote: ok - i propose that we do it step by step. let's start to move the wiki of codi and extval to confluence. is that ok for everyone? @matthias: [1] describes the steps to request a cwiki space. regards, gerhard [1] http://cwiki.apache.org/confluence/display/CWIKI/Index http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/24 Gabrielle Crawford gabrielle.crawf...@oracle.com mailto:gabrielle.crawf...@oracle.com +1 confluence is so much better Jakob Korherr wrote: +1 from me :) Frankly I don't really like the current wiki.. Regards, Jakob 2010/3/24 Matthias Wessendorf mat...@apache.org mailto:mat...@apache.org mailto:mat...@apache.org mailto:mat...@apache.org +1 I don't remember the outcome of the old discussion, wasn't there one? Anyways I am +1 on confluence... -Matthias On Wed, Mar 24, 2010 at 11:30 AM, Gerhard Petracek gerhard.petra...@gmail.com mailto:gerhard.petra...@gmail.com mailto:gerhard.petra...@gmail.com mailto:gerhard.petra...@gmail.com wrote: hi @ all, what do you think about moving our wiki to confluence[1]? regards, gerhard [1] http://cwiki.apache.org/confluence/ http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: myfaces wiki
cool, thanks! -Matthias On Tue, Mar 30, 2010 at 7:52 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: today i created a jira issue for it [1]. - it's just a matter of time. regards, gerhard [1] http://issues.apache.org/jira/browse/INFRA-2579 http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/30 Werner Punz werner.p...@gmail.com +1 Am 29.03.10 11:00, schrieb Gerhard Petracek: hi, yes - i'll help with the admin tasks... @space-key: +1 for myfaces regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/29 Matthias Wessendorf mat...@apache.org mailto:mat...@apache.org # Include the cwiki account name of a PMC member (preferably the PMC chair) who will help administer the space. Gerhard, do you want to help to administer the space? For the next weeks I have not much to time for that... # Also specify the key name for the Space. The key name cannot be changed. = myfaces ? :) .Matthias On Mon, Mar 29, 2010 at 10:25 AM, Gerhard Petracek gerhard.petra...@gmail.com mailto:gerhard.petra...@gmail.com wrote: ok - i propose that we do it step by step. let's start to move the wiki of codi and extval to confluence. is that ok for everyone? @matthias: [1] describes the steps to request a cwiki space. regards, gerhard [1] http://cwiki.apache.org/confluence/display/CWIKI/Index http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/24 Gabrielle Crawford gabrielle.crawf...@oracle.com mailto:gabrielle.crawf...@oracle.com +1 confluence is so much better Jakob Korherr wrote: +1 from me :) Frankly I don't really like the current wiki.. Regards, Jakob 2010/3/24 Matthias Wessendorf mat...@apache.org mailto:mat...@apache.org mailto:mat...@apache.org mailto:mat...@apache.org +1 I don't remember the outcome of the old discussion, wasn't there one? Anyways I am +1 on confluence... -Matthias On Wed, Mar 24, 2010 at 11:30 AM, Gerhard Petracek gerhard.petra...@gmail.com mailto:gerhard.petra...@gmail.com mailto:gerhard.petra...@gmail.com mailto:gerhard.petra...@gmail.com wrote: hi @ all, what do you think about moving our wiki to confluence[1]? regards, gerhard [1] http://cwiki.apache.org/confluence/ http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: myfaces wiki
ok - i propose that we do it step by step. let's start to move the wiki of codi and extval to confluence. is that ok for everyone? @matthias: [1] describes the steps to request a cwiki space. regards, gerhard [1] http://cwiki.apache.org/confluence/display/CWIKI/Index http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/24 Gabrielle Crawford gabrielle.crawf...@oracle.com +1 confluence is so much better Jakob Korherr wrote: +1 from me :) Frankly I don't really like the current wiki.. Regards, Jakob 2010/3/24 Matthias Wessendorf mat...@apache.org mailto: mat...@apache.org +1 I don't remember the outcome of the old discussion, wasn't there one? Anyways I am +1 on confluence... -Matthias On Wed, Mar 24, 2010 at 11:30 AM, Gerhard Petracek gerhard.petra...@gmail.com mailto:gerhard.petra...@gmail.com wrote: hi @ all, what do you think about moving our wiki to confluence[1]? regards, gerhard [1] http://cwiki.apache.org/confluence/ http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: myfaces wiki
Yes, great idea Gerhard! 2010/3/29 Gerhard Petracek gerhard.petra...@gmail.com ok - i propose that we do it step by step. let's start to move the wiki of codi and extval to confluence. is that ok for everyone? @matthias: [1] describes the steps to request a cwiki space. regards, gerhard [1] http://cwiki.apache.org/confluence/display/CWIKI/Index http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/24 Gabrielle Crawford gabrielle.crawf...@oracle.com +1 confluence is so much better Jakob Korherr wrote: +1 from me :) Frankly I don't really like the current wiki.. Regards, Jakob 2010/3/24 Matthias Wessendorf mat...@apache.org mailto: mat...@apache.org +1 I don't remember the outcome of the old discussion, wasn't there one? Anyways I am +1 on confluence... -Matthias On Wed, Mar 24, 2010 at 11:30 AM, Gerhard Petracek gerhard.petra...@gmail.com mailto:gerhard.petra...@gmail.com wrote: hi @ all, what do you think about moving our wiki to confluence[1]? regards, gerhard [1] http://cwiki.apache.org/confluence/ http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: myfaces wiki
hi, yes - i'll help with the admin tasks... @space-key: +1 for myfaces regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/29 Matthias Wessendorf mat...@apache.org # Include the cwiki account name of a PMC member (preferably the PMC chair) who will help administer the space. Gerhard, do you want to help to administer the space? For the next weeks I have not much to time for that... # Also specify the key name for the Space. The key name cannot be changed. = myfaces ? :) .Matthias On Mon, Mar 29, 2010 at 10:25 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: ok - i propose that we do it step by step. let's start to move the wiki of codi and extval to confluence. is that ok for everyone? @matthias: [1] describes the steps to request a cwiki space. regards, gerhard [1] http://cwiki.apache.org/confluence/display/CWIKI/Index http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/24 Gabrielle Crawford gabrielle.crawf...@oracle.com +1 confluence is so much better Jakob Korherr wrote: +1 from me :) Frankly I don't really like the current wiki.. Regards, Jakob 2010/3/24 Matthias Wessendorf mat...@apache.org mailto:mat...@apache.org +1 I don't remember the outcome of the old discussion, wasn't there one? Anyways I am +1 on confluence... -Matthias On Wed, Mar 24, 2010 at 11:30 AM, Gerhard Petracek gerhard.petra...@gmail.com mailto:gerhard.petra...@gmail.com wrote: hi @ all, what do you think about moving our wiki to confluence[1]? regards, gerhard [1] http://cwiki.apache.org/confluence/ http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: myfaces wiki
+1 I don't remember the outcome of the old discussion, wasn't there one? Anyways I am +1 on confluence... -Matthias On Wed, Mar 24, 2010 at 11:30 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi @ all, what do you think about moving our wiki to confluence[1]? regards, gerhard [1] http://cwiki.apache.org/confluence/ http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: myfaces wiki
+1 from me :) Frankly I don't really like the current wiki.. Regards, Jakob 2010/3/24 Matthias Wessendorf mat...@apache.org +1 I don't remember the outcome of the old discussion, wasn't there one? Anyways I am +1 on confluence... -Matthias On Wed, Mar 24, 2010 at 11:30 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi @ all, what do you think about moving our wiki to confluence[1]? regards, gerhard [1] http://cwiki.apache.org/confluence/ http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: myfaces wiki
I'm happy with the current wiki, and I haven't enjoyed working with confluence. We also seem to have a lot of assorted problems with it on the Cayenne project. But I'm not opposed to switching if that's what everyone else really wants. On Wed, Mar 24, 2010 at 2:35 PM, Jakob Korherr jakob.korh...@gmail.com wrote: +1 from me :) Frankly I don't really like the current wiki.. Regards, Jakob 2010/3/24 Matthias Wessendorf mat...@apache.org +1 I don't remember the outcome of the old discussion, wasn't there one? Anyways I am +1 on confluence... -Matthias On Wed, Mar 24, 2010 at 11:30 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi @ all, what do you think about moving our wiki to confluence[1]? regards, gerhard [1] http://cwiki.apache.org/confluence/ http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: myfaces wiki
+1 confluence is so much better Jakob Korherr wrote: +1 from me :) Frankly I don't really like the current wiki.. Regards, Jakob 2010/3/24 Matthias Wessendorf mat...@apache.org mailto:mat...@apache.org +1 I don't remember the outcome of the old discussion, wasn't there one? Anyways I am +1 on confluence... -Matthias On Wed, Mar 24, 2010 at 11:30 AM, Gerhard Petracek gerhard.petra...@gmail.com mailto:gerhard.petra...@gmail.com wrote: hi @ all, what do you think about moving our wiki to confluence[1]? regards, gerhard [1] http://cwiki.apache.org/confluence/ http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Myfaces Wiki] Update of Code Generation
In the practice the problem is that jsf core (myfaces and ri) uses reflection to set the attributes and the following case fail: Fail with the following exception java.lang.IllegalAccessException: Class javax.faces.component._Util can not access a member of class org.apache.myfaces.test.AbstractComponent with modifiers public at sun.reflect.Reflection.ensureMemberAccess(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at javax.faces.component._Util.getValue(_Util.java:54) at javax.faces.component.BaseComponent.getValueReflection( BaseComponent.java:32) at javax.faces.other.ComponentTest.main(ComponentTest.java:14) This behavior is a JDK bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4071957 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4533479 One possible workaround is put the following line before invoke: readMethod.setAccessible(true); Or make AbstractComponent public. The conclusion is that the abstract base class should be public if and only if it has in his body a attribute definition available on the tld. If the abstract base class has some different code it can be package scope. This behavior discard this approach for myfaces core api! I'm not sure this behaviour is a bug, or that it is fatal for the purposes of generating base classes for myfaces-api. When a Method object refers to a public method in a package-scoped class, then Method.invoke fails with the above exception *when executed by some class outside that package*. However it succeeds fine when invoked by code within that package (eg its concrete subclass) or by the class itself. I have tested this behaviour and it is the same on both java1.6 and java1.3. It also seems quite reasonable behaviour. So one solution is for the generated base class to override getAttributes() to return a custom map where that class itself implements the fetching of the attributes it implements, and delegates to the map created by UIComponentBase.getAttributes() for anything else. This seems quite feasable. Regards, Simon -- View this message in context: http://www.nabble.com/Re%3A--Myfaces-Wiki--Update-of-%22Code-Generation%22-by-SimonKitching-tp15216313p15353739.html Sent from the My Faces - Dev mailing list archive at Nabble.com.
Re: [Myfaces Wiki] Update of Code Generation
Yes, third-party code that tries to use reflection on such a UIComponent to access the standard JSF attributes will fail. The question is whether the TCK will test this (I doubt it), and whether for other cases we care. One case where it would be significant is if GUI-builders for JSF use reflection on UIComponent objects. But if not, then I cannot imagine any other case where anyone would actually do that; the attributes map already provides access to that info. It would be really nice to have the same approach for myfaces core as for the other modules. Regards, Simon Martin Marinschek [EMAIL PROTECTED] schrieb: Hi Simon, this is true - but what happens if someone else tries to access component attributes via reflection? regards, Martin On 2/8/08, Simon Kitching [EMAIL PROTECTED] wrote: In the practice the problem is that jsf core (myfaces and ri) uses reflection to set the attributes and the following case fail: Fail with the following exception java.lang.IllegalAccessException: Class javax.faces.component._Util can not access a member of class org.apache.myfaces.test.AbstractComponent with modifiers public at sun.reflect.Reflection.ensureMemberAccess(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at javax.faces.component._Util.getValue(_Util.java:54) at javax.faces.component.BaseComponent.getValueReflection( BaseComponent.java:32) at javax.faces.other.ComponentTest.main(ComponentTest.java:14) This behavior is a JDK bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4071957 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4533479 One possible workaround is put the following line before invoke: readMethod.setAccessible(true); Or make AbstractComponent public. The conclusion is that the abstract base class should be public if and only if it has in his body a attribute definition available on the tld. If the abstract base class has some different code it can be package scope. This behavior discard this approach for myfaces core api! I'm not sure this behaviour is a bug, or that it is fatal for the purposes of generating base classes for myfaces-api. When a Method object refers to a public method in a package-scoped class, then Method.invoke fails with the above exception *when executed by some class outside that package*. However it succeeds fine when invoked by code within that package (eg its concrete subclass) or by the class itself. I have tested this behaviour and it is the same on both java1.6 and java1.3. It also seems quite reasonable behaviour. So one solution is for the generated base class to override getAttributes() to return a custom map where that class itself implements the fetching of the attributes it implements, and delegates to the map created by UIComponentBase.getAttributes() for anything else. This seems quite feasable. Regards, Simon -- View this message in context: http://www.nabble.com/Re%3A--Myfaces-Wiki--Update-of-%22Code-Generation%22-by-SimonKitching-tp15216313p15353739.html Sent from the My Faces - Dev mailing list archive at Nabble.com. -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [Myfaces Wiki] Update of Code Generation
Hi Simon, this is true - but what happens if someone else tries to access component attributes via reflection? regards, Martin On 2/8/08, Simon Kitching [EMAIL PROTECTED] wrote: In the practice the problem is that jsf core (myfaces and ri) uses reflection to set the attributes and the following case fail: Fail with the following exception java.lang.IllegalAccessException: Class javax.faces.component._Util can not access a member of class org.apache.myfaces.test.AbstractComponent with modifiers public at sun.reflect.Reflection.ensureMemberAccess(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at javax.faces.component._Util.getValue(_Util.java:54) at javax.faces.component.BaseComponent.getValueReflection( BaseComponent.java:32) at javax.faces.other.ComponentTest.main(ComponentTest.java:14) This behavior is a JDK bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4071957 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4533479 One possible workaround is put the following line before invoke: readMethod.setAccessible(true); Or make AbstractComponent public. The conclusion is that the abstract base class should be public if and only if it has in his body a attribute definition available on the tld. If the abstract base class has some different code it can be package scope. This behavior discard this approach for myfaces core api! I'm not sure this behaviour is a bug, or that it is fatal for the purposes of generating base classes for myfaces-api. When a Method object refers to a public method in a package-scoped class, then Method.invoke fails with the above exception *when executed by some class outside that package*. However it succeeds fine when invoked by code within that package (eg its concrete subclass) or by the class itself. I have tested this behaviour and it is the same on both java1.6 and java1.3. It also seems quite reasonable behaviour. So one solution is for the generated base class to override getAttributes() to return a custom map where that class itself implements the fetching of the attributes it implements, and delegates to the map created by UIComponentBase.getAttributes() for anything else. This seems quite feasable. Regards, Simon -- View this message in context: http://www.nabble.com/Re%3A--Myfaces-Wiki--Update-of-%22Code-Generation%22-by-SimonKitching-tp15216313p15353739.html Sent from the My Faces - Dev mailing list archive at Nabble.com. -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [Myfaces Wiki] Update of Code Generation
Hi, 1. to JDK bug: it's not a bug according to Java language Specification: http://java.sun.com/docs/books/jls/third_edition/html/classes.html#23530 2. to attributes: JSF specification states that components have properties (so called renderkit independend), which are getter/setter based AND attributes (renderkit dependend). Maybe we could use it as it says: - have getter/setter pairs for properties (defined in spec alone) and rest - attributes in HTML renderkit's doc (called as ATTRIBUTES anyway) along with all enhancing TLD tags' attributes - use as keys/values in getAttributes() Map. As all properties are set in stone, this would be one-time work to write them. Adding attributes would be automaticly handled by Map. This access would mean to change PROGRAMMATIC access to components from setXXX(val) to getAttributes().put(XXX, val). To switch to this from users' side (when using only in JSF pages) it would mean to rewrite direct setting in tag handlers to use Map. (Map handles calling setters/getters too if needed/forgotten) BTW, Mojarra stopped in half way with handling HTML attributes only with Map. Now they have mixed approach - using getter/setter pair BUT accessing value from Map in renderer. Regards, Zdenek Simon Kitching napsal(a): Yes, third-party code that tries to use reflection on such a UIComponent to access the standard JSF attributes will fail. The question is whether the TCK will test this (I doubt it), and whether for other cases we care. One case where it would be significant is if GUI-builders for JSF use reflection on UIComponent objects. But if not, then I cannot imagine any other case where anyone would actually do that; the attributes map already provides access to that info. It would be really nice to have the same approach for myfaces core as for the other modules. Regards, Simon Martin Marinschek [EMAIL PROTECTED] schrieb: Hi Simon, this is true - but what happens if someone else tries to access component attributes via reflection? regards, Martin On 2/8/08, Simon Kitching [EMAIL PROTECTED] wrote: In the practice the problem is that jsf core (myfaces and ri) uses reflection to set the attributes and the following case fail: Fail with the following exception java.lang.IllegalAccessException: Class javax.faces.component._Util can not access a member of class org.apache.myfaces.test.AbstractComponent with modifiers public at sun.reflect.Reflection.ensureMemberAccess(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at javax.faces.component._Util.getValue(_Util.java:54) at javax.faces.component.BaseComponent.getValueReflection( BaseComponent.java:32) at javax.faces.other.ComponentTest.main(ComponentTest.java:14) This behavior is a JDK bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4071957 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4533479 One possible workaround is put the following line before invoke: readMethod.setAccessible(true); Or make AbstractComponent public. The conclusion is that the abstract base class should be public if and only if it has in his body a attribute definition available on the tld. If the abstract base class has some different code it can be package scope. This behavior discard this approach for myfaces core api! I'm not sure this behaviour is a bug, or that it is fatal for the purposes of generating base classes for myfaces-api. When a Method object refers to a public method in a package-scoped class, then Method.invoke fails with the above exception *when executed by some class outside that package*. However it succeeds fine when invoked by code within that package (eg its concrete subclass) or by the class itself. I have tested this behaviour and it is the same on both java1.6 and java1.3. It also seems quite reasonable behaviour. So one solution is for the generated base class to override getAttributes() to return a custom map where that class itself implements the fetching of the attributes it implements, and delegates to the map created by UIComponentBase.getAttributes() for anything else. This seems quite feasable. Regards, Simon -- View this message in context: http://www.nabble.com/Re%3A--Myfaces-Wiki--Update-of-%22Code-Generation%22-by-SimonKitching-tp15216313p15353739.html Sent from the My Faces - Dev mailing list archive at Nabble.com. -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [Myfaces Wiki] Update of Code Generation by SimonKitching
Ok, in the end this means we cannot go with this - I am for using
templates in the API and base-classes for everything else.
regards,
Martin
On Feb 7, 2008 6:47 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
Hi
This mail is about the wiki http://wiki.apache.org/myfaces/Code_Generation:
An the topic on this wiki page
Generating base classes instead of templatesFinally I have found the
reasons about my previous suggestions, so I will proceed with the proper
update of the wiki. These are the changes:
...Note that (in a feature that may surprise some Java developers) it
appears quite valid for a class to have a package-scoped parent; the class
can still be subclassed or instantiated from outside the package. It
inherits public and protected members from its package-scoped parent which
can be called as normal. The only constraint is that it cannot be cast to
its parent type, as this is not accessible (although the Class object for
that type can still be obtained). It is not yet known whether inserting such
a package-scoped ancestor class into the ancestry of a component class in
the javax.faces package scope would be acceptable to the JSF TCK or not. If
the TCK accepts this, then the approach of generating a base class could
also be applied to myfaces core components...
In the practice the problem is that jsf core (myfaces and ri) uses
reflection to set the attributes and the following case fail:
//base component class from api
public class BaseComponent extends Object
{
//..//
}
//package scope class
abstract class AbstractComponent extends BaseComponent
{
private String value;
public String getValue()
{
return value;
}
public void setValue(String value)
{
this.value = value;
}
}
public class RealComponent extends AbstractComponent
{
//..//
}
If an instance of RealComponent is created, you can access to the public api
defined on AbstractComponent. But if you use reflection to call
getValue or setValue using a code like this:
public Object getValue(BaseComponent component){
Object resp = null;
try
{
BeanInfo beanInfo = null;
try
{
beanInfo = Introspector.getBeanInfo(component.getClass());
}
catch (IntrospectionException e)
{
e.printStackTrace();
}
PropertyDescriptor[] propertyDescriptors = beanInfo
.getPropertyDescriptors();
HashMapString, PropertyDescriptor _propertyDescriptorMap = new
HashMapString, PropertyDescriptor();
for (int i = 0; i propertyDescriptors.length; i++)
{
PropertyDescriptor propertyDescriptor =
propertyDescriptors[i];
if (propertyDescriptor.getReadMethod() != null)
{
_propertyDescriptorMap.put(propertyDescriptor.getName(),
propertyDescriptor);
}
}
PropertyDescriptor pd = _propertyDescriptorMap.get(value);
Method readMethod = pd.getReadMethod();
Object[] EMPTY_ARGS = new Object[0];
resp = readMethod.invoke(component, EMPTY_ARGS);
}
catch (Exception e)
{
e.printStackTrace();
}
return resp;
}
Fail with the following exception
java.lang.IllegalAccessException: Class javax.faces.component._Util can not
access a member of class org.apache.myfaces.test.AbstractComponent with
modifiers public
at sun.reflect.Reflection.ensureMemberAccess(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at javax.faces.component._Util.getValue(_Util.java:54)
at
javax.faces.component.BaseComponent.getValueReflection(BaseComponent.java:32)
at javax.faces.other.ComponentTest.main(ComponentTest.java:14)
This behavior is a JDK bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4071957
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4533479
One possible workaround is put the following line before invoke:
readMethod.setAccessible(true);
Or make AbstractComponent public.
The conclusion is that the abstract base class should be public if and only
if it has in his body a attribute definition available on the tld. If the
abstract base class has some different code it can be package scope. This
behavior discard this approach for myfaces core api!
.Question: When there are multiple source trees for a module, does
maven build against them all simultaneously? That is, if a normal source
file references a source file in the generated-source tree which itself
references a source file in the normal source tree, does this work?...
Response: One successful example is this hierarchy used for t:schedule
Re: [Myfaces Wiki] Update of Code Generation by SimonKitching
Hi
This mail is about the wiki http://wiki.apache.org/myfaces/Code_Generation:
An the topic on this wiki page
Generating base classes instead of templatesFinally I have found the reasons
about my previous suggestions, so I will proceed with the proper update of
the wiki. These are the changes:
*...Note that (in a feature that may surprise some Java developers) it
appears quite valid for a class to have a package-scoped parent; the class
can still be subclassed or instantiated from outside the package. It
inherits public and protected members from its package-scoped parent which
can be called as normal. The only constraint is that it cannot be cast to
its parent type, as this is not accessible (although the Class object for
that type can still be obtained). It is not yet known whether inserting such
a package-scoped ancestor class into the ancestry of a component class in
the javax.faces package scope would be acceptable to the JSF TCK or not. If
the TCK accepts this, then the approach of generating a base class could
also be applied to myfaces core components...*
In the practice the problem is that jsf core (myfaces and ri) uses
reflection to set the attributes and the following case fail:
//base component class from api
public class BaseComponent extends Object
{
//..//
}
//package scope class
abstract class AbstractComponent extends BaseComponent
{
private String value;
public String getValue()
{
return value;
}
public void setValue(String value)
{
this.value = value;
}
}
public class RealComponent extends AbstractComponent
{
//..//
}
If an instance of RealComponent is created, you can access to the public api
defined on AbstractComponent. But if you use reflection to call
getValue or setValue using a code like this:
public Object getValue(BaseComponent component){
Object resp = null;
try
{
BeanInfo beanInfo = null;
try
{
beanInfo = Introspector.getBeanInfo(component.getClass());
}
catch (IntrospectionException e)
{
e.printStackTrace();
}
PropertyDescriptor[] propertyDescriptors = beanInfo
.getPropertyDescriptors();
HashMapString, PropertyDescriptor _propertyDescriptorMap = new
HashMapString, PropertyDescriptor();
for (int i = 0; i propertyDescriptors.length; i++)
{
PropertyDescriptor propertyDescriptor =
propertyDescriptors[i];
if (propertyDescriptor.getReadMethod() != null)
{
_propertyDescriptorMap.put(propertyDescriptor.getName(),
propertyDescriptor);
}
}
PropertyDescriptor pd = _propertyDescriptorMap.get(value);
Method readMethod = pd.getReadMethod();
Object[] EMPTY_ARGS = new Object[0];
resp = readMethod.invoke(component, EMPTY_ARGS);
}
catch (Exception e)
{
e.printStackTrace();
}
return resp;
}
Fail with the following exception
java.lang.IllegalAccessException: Class javax.faces.component._Util can not
access a member of class org.apache.myfaces.test.AbstractComponent with
modifiers public
at sun.reflect.Reflection.ensureMemberAccess(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at javax.faces.component._Util.getValue(_Util.java:54)
at javax.faces.component.BaseComponent.getValueReflection(
BaseComponent.java:32)
at javax.faces.other.ComponentTest.main(ComponentTest.java:14)
This behavior is a JDK bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4071957
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4533479
One possible workaround is put the following line before invoke:
readMethod.setAccessible(true);
Or make AbstractComponent public.
The conclusion is that the abstract base class should be public if and only
if it has in his body a attribute definition available on the tld. If the
abstract base class has some different code it can be package scope. This
behavior discard this approach for myfaces core api!
*.Question: When there are multiple source trees for a module, does
maven build against them all simultaneously? That is, if a normal source
file references a source file in the generated-source tree which itself
references a source file in the normal source tree, does this work?...
*
Response: One successful example is this hierarchy used for t:schedule
javax.faces.UIComponentBase
---myfaces core api
org.apache.myfaces.custom.schedule.AbstractUIScheduleBase--- on
src/main/java
org.apache.myfaces.custom.schedule.UIScheduleBase
generated on target/maven-faces-plugin/main/java
org.apache.myfaces.custom.schedule.UISchedule
on src/main/java
Re: [Myfaces Wiki] Update of CompatibilityMatrix by AndrewRobinson
Hope no one minds me adding this, I think we should all be sick of the questions for this page by now. -Andrew On Feb 7, 2008 9:41 AM, Apache Wiki [EMAIL PROTECTED] wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Myfaces Wiki for change notification. The following page has been changed by AndrewRobinson: http://wiki.apache.org/myfaces/CompatibilityMatrix The comment on the change is: Add emphasis on who maintains this page -- This table is maintained by the !MyFaces user community as a guide to what versions of various libraries have been found to be compatible. If you have successfully used a combination that is not currently in this table (or found serious incompatibilities), then please update the table with that information, as a service to your fellow software developers and !MyFaces users. + + 'This is a common question, so let's repeat the answer:' as a '''user''', it is '''your''' responsibility to update this matrix, it generally will '''not''' be updated by the !MyFaces developers. Please '''do not''' ask why this matrix is out of date on the mailing lists. || Component Library || !MyFaces 1.2.0 || [ http://www.apache.org/dyn/closer.cgi/myfaces/binaries/myfaces-core-1.1.5-bin.zipMyFaces 1.1.5] || !MyFaces 1.1.4 || !MyFaces 1.1.3 || !MyFaces 1.1.2 || !MyFaces 1.1.1 || !MyFaces 1.0.9 || Sun RI 1.2_07-b03 || || Tomahawk 1.1.6 || -- || -- || -- || -- || -- || -- || -- || ||
Re: [Myfaces Wiki] Update of JSF and MVC by SimonKitching
Hi! I don't think this will be controversial - I find it a rather good basic introduction to the concepts behind JSF, actually. I too think that this is a good introduction for any newbie. Something you'll normally read in a book but now public for everyone. Ciao, Mario regards, Martin On Wed, Feb 6, 2008 at 12:03 AM, Matthias Wessendorf [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: haha :) On Feb 5, 2008 10:37 PM, Andrew Robinson [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I was wondering what the purpose was. It seemed to me like the apache wiki was going to start turning into a personal blog site :) On Feb 5, 2008 1:34 PM, simon [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Tue, 2008-02-05 at 20:31 +, Apache Wiki wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Myfaces Wiki for change notification. The following page has been changed by SimonKitching: http://wiki.apache.org/myfaces/JSF_and_MVC I expect this page will be a little controversial :-) The main goal was to address the why doesn't it work like struts/webwork questions. But feel free to modify any bits that you don't agree with.. Regards, Simon -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- mit freundlichen Grüßen Mario Ivankovits Software Engineering OPS EDV VertriebsgesmbH A-1120 Wien, Michael-Bernhard-Gasse 10 Firmenbuch Nr.: FN51233v, Handelsgericht Wien Tel.: +43-1-8938810; Fax: +43-1-8938810/3700 http://www.ops.co.at E-Mail: [EMAIL PROTECTED] Skype: mario_ivankovits
Re: [Myfaces Wiki] Update of JSF and MVC by SimonKitching
On Tue, 2008-02-05 at 20:31 +, Apache Wiki wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Myfaces Wiki for change notification. The following page has been changed by SimonKitching: http://wiki.apache.org/myfaces/JSF_and_MVC I expect this page will be a little controversial :-) The main goal was to address the why doesn't it work like struts/webwork questions. But feel free to modify any bits that you don't agree with.. Regards, Simon
Re: [Myfaces Wiki] Update of Code Generation by SimonKitching
Hi
I have checked this topic of the wiki
http://wiki.apache.org/myfaces/Code_Generation:
Generating base classes instead of templatesAnd based on some work with
tomahawk I have some observations to do:
*...Note that (in a feature that may surprise some Java developers) it
appears quite valid for a class to have a package-scoped parent; the class
can still be subclassed or instantiated from outside the package. It
inherits public and protected members from its package-scoped parent which
can be called as normal. The only constraint is that it cannot be cast to
its parent type, as this is not accessible (although the Class object for
that type can still be obtained). It is not yet known whether inserting such
a package-scoped ancestor class into the ancestry of a component class in
the javax.faces package scope would be acceptable to the JSF TCK or not. If
the TCK accepts this, then the approach of generating a base class could
also be applied to myfaces core components...
*
In some cases doing something like this:
abstract class AbstractHtmlInputText
extends javax.faces.component.html.HtmlInputText
implements UserRoleAware, DisplayValueOnlyCapable
{
works but in other cases do not, It throws an exception like this:
java.lang.IllegalAccessException: Class
javax.faces.component._ComponentAttributesMap can not access a member of
class org.apache.myfaces.custom.tabbedpane.AbstractHtmlPanelTabbedPane with
modifiers public abstract
at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:65)
at java.lang.reflect.Method.invoke(Method.java:588)
at javax.faces.component._ComponentAttributesMap.getComponentProperty
(_ComponentAttributesMap.java:390)
at javax.faces.component._ComponentAttributesMap.put
(_ComponentAttributesMap.java:311)
at javax.faces.component.UIComponent.setValueExpression(UIComponent.java
:112)
at
org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPaneTag.setProperties(
HtmlPanelTabbedPaneTag.java:389)
at javax.faces.webapp.UIComponentELTag.createComponent(
UIComponentELTag.java:100)
There are some methods on java api that use reflection to set some
variables, and fails if the parent class is not public, so I do not believe
that this approach works for myfaces core api, and pass the TCK.
*With this setup, we have the question of which source directory the
generated base class gets written to. Option (1) is to write it to a
generated-source dir, option (2) is to write it to the normal source
dir.
*
*.Question: When there are multiple source trees for a module, does
maven build against them all simultaneously? That is, if a normal source
file references a source file in the generated-source tree which itself
references a source file in the normal source tree, does this work?...
*
Yes, this works and it is awesome. One successful example is this hierarchy
used for t:schedule
javax.faces.UIComponentBase
---myfaces core api
org.apache.myfaces.custom.schedule.AbstractUIScheduleBase--- on
src/main/java
org.apache.myfaces.custom.schedule.UIScheduleBase
generated on target/maven-faces-plugin/main/java
org.apache.myfaces.custom.schedule.UISchedule
on src/main/java
org.apache.myfaces.custom.schedule.HtmlSchedule
generated on target/maven-faces-plugin/main/java
On eclipse I works like if all files were on the same directory. Code
completion works using base classes (with templates do not!).
Generate in src/main/java or in target/maven-faces-plugin/main/java is
transparent for the IDE. If we generate in src/main/java, the generated code
will mix with hand written code, if we translate generated code to a
separate directory on src/main/java technically it is equivalent to generate
in target/maven-faces-plugin/main/java.
In conclusion: Actually 100% of the components in tomahawk (I have only a
problem with t:tree2 that can be solved with more work) can use abstract
classes aproach (with some little modifications on myfaces-faces-plugin).
The list of modifications is this. :
- component-includes parameter on component-extension
- component-serial-uid parameter on component-extension
- is-get-local-method-scope and is-get-local-method parameters on
property-extension to generate automatically getLocalXXX method
- is-set-method-scope and is-set-method parameters on property-extension to
generate automatically isSet method.
regards
Leonardo Uribe
Re: [Myfaces Wiki] Update of JSF and MVC by SimonKitching
I was wondering what the purpose was. It seemed to me like the apache wiki was going to start turning into a personal blog site :) On Feb 5, 2008 1:34 PM, simon [EMAIL PROTECTED] wrote: On Tue, 2008-02-05 at 20:31 +, Apache Wiki wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Myfaces Wiki for change notification. The following page has been changed by SimonKitching: http://wiki.apache.org/myfaces/JSF_and_MVC I expect this page will be a little controversial :-) The main goal was to address the why doesn't it work like struts/webwork questions. But feel free to modify any bits that you don't agree with.. Regards, Simon
Re: [Myfaces Wiki] Update of JSF and MVC by SimonKitching
haha :) On Feb 5, 2008 10:37 PM, Andrew Robinson [EMAIL PROTECTED] wrote: I was wondering what the purpose was. It seemed to me like the apache wiki was going to start turning into a personal blog site :) On Feb 5, 2008 1:34 PM, simon [EMAIL PROTECTED] wrote: On Tue, 2008-02-05 at 20:31 +, Apache Wiki wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Myfaces Wiki for change notification. The following page has been changed by SimonKitching: http://wiki.apache.org/myfaces/JSF_and_MVC I expect this page will be a little controversial :-) The main goal was to address the why doesn't it work like struts/webwork questions. But feel free to modify any bits that you don't agree with.. Regards, Simon -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [Myfaces Wiki] Update of JSF and MVC by SimonKitching
I don't think this will be controversial - I find it a rather good basic introduction to the concepts behind JSF, actually. regards, Martin On Wed, Feb 6, 2008 at 12:03 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: haha :) On Feb 5, 2008 10:37 PM, Andrew Robinson [EMAIL PROTECTED] wrote: I was wondering what the purpose was. It seemed to me like the apache wiki was going to start turning into a personal blog site :) On Feb 5, 2008 1:34 PM, simon [EMAIL PROTECTED] wrote: On Tue, 2008-02-05 at 20:31 +, Apache Wiki wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Myfaces Wiki for change notification. The following page has been changed by SimonKitching: http://wiki.apache.org/myfaces/JSF_and_MVC I expect this page will be a little controversial :-) The main goal was to address the why doesn't it work like struts/webwork questions. But feel free to modify any bits that you don't agree with.. Regards, Simon -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [Myfaces Wiki] Update of Code Generation by SimonKitching
I look at the vast list of bugs raised against tomahawk 1.1.6, and look at the scary output of the maven reports (findbugs, pmd, etc) and think that there are higher priorities than reinventing the build process right now, when the current approach works. Yes it is ugly, but 1.1.7 is mostly a bugfix release; we don't need to add many components or change many APIs. We do want to promote a couple of sandbox components which is a nuisance but can be managed. for all this, I want a generator (and we haven't had one for ages - I'm not gonna wait for more time). Don't forget facelets-support, by the way. Do you really want another tomahawk-release without it? Plus, as I said before, I want to play around with performance, and need a generator for this as well. I am advocating we can go with the Trinidad-approach plus changing over from templates to base-classes for now; and you can always change this again if you have time later - it will be A LOT easier with a generator in place. Of course this is open-source, so nobody can be told what to work on, and what not. But I don't personally want to be testing a temporary new build process while also testing a tomahawk rc. you only have to test the rc - you will not note any differences to the old approach of doing components, I promise. The changes in the new component generator to the one in Trinidad will be minimal, so there is not much to test - the component generator of Trinidad is well tested. I think it would be better to solve the build process issue just once, but it looks like that would delay a tomahawk release - unless we get consensus to use the trinidad approach (which doesn't seem to be the case ATM). as Leonardo will probably do the release work, it's his choice what he tries/can achieve before he does the release The last tomahawk release is over 6 months ago, which is the release cycle for a whole Ubuntu distro, or a linux kernel...it would be nice to get one out without further delays. yes - and finally we have found someone who actually does the release work with Leonardo, so please, just let him continue doing his work. regards, Martin
Re: [Myfaces Wiki] Update of Code Generation by SimonKitching
Hi Simon, And this approach is not possible for uicomponent classes defined in the standard as these have defined hierarchies that cannot be modified. does this stem from actually trying it out? I tried it in the project I am currently working on, and it worked. I need to admit I did not check the Java-language specification. regards, Martin
Re: [Myfaces Wiki] Update of Code Generation by SimonKitching
Martin Marinschek [EMAIL PROTECTED] schrieb: Hi Simon, And this approach is not possible for uicomponent classes defined in the standard as these have defined hierarchies that cannot be modified. does this stem from actually trying it out? I tried it in the project I am currently working on, and it worked. I need to admit I did not check the Java-language specification. You're quite right, it does work! I had just assumed that creating a public subclass of a package-scope class would not work. I have updated the wiki. But all my tests show it functions fine. A public subclass inherits any public or protected members that the package-private class defines. Subclasses of it can be declared in other packages, and instances of it can be created and invoked. The only thing that cannot be done is to cast it to its parent type. Interestingly, generating the normal javadoc doesn't show any trace of the package-scoped parent at all; anything public/protected the child inherits from its parent is just listed as if it were defined by the child itself. This is all exactly what we would want; the parent class is effectively invisible except in one case: when calling Child.class.getSuperclass(). Then, a Class instance for the package-scoped parent is returned. Well, I guess stack-traces will show it too. There is still the question of whether the TCK would pass if classes in javax.faces had package-scoped parents that are not defined in the spec. Is there someone here that can check that? If that is allowable, then this base-class approach becomes much more interesting... Regards, Simon
Re: [Myfaces Wiki] Update of Code Generation by SimonKitching
Hi Simon, Zdenek, There is still the question of whether the TCK would pass if classes in javax.faces had package-scoped parents that are not defined in the spec. Is there someone here that can check that? If that is allowable, then this base-class approach becomes much more interesting... I don't think it would ever past TCK - if TCK fails even with protected methods in classes, having more generic acces class in package should definately fail. I'm pretty sure the TCK will pass - Leonardo, can you try this please with one component in API? regards, Martin
Re: [Myfaces Wiki] Update of Code Generation by SimonKitching
Hi Zdenek, A question was raised about why state isn't retrieved from the attributes map - this cannot be used, however, cause it would use reflection internally and call the getter of the method, if a value is not directly stored in the attributes map. As soon as the getter is called, after the check for the local value returns null, you will get back the value from a value-expression, and you do not want to save this value in the state, as the value-expression itself is already stored! so you want to get rid of the concept of a local value completely, and store everything in the attribute map? Now I see. This might actually work, yes. regards, Martin
Re: [Myfaces Wiki] Update of Code Generation by SimonKitching
Hi all, some clarifications from my side: Quote 1: One of the last developers to work on the old code-generation framework commented that it was very painful. Not sure whether this comment was about the basic concept of this approach, or just the implementation. It was about changes made to code within generation marks in Tomahawk Core components. To make the old generator work again, it had to be extended to take in account: a) modifications in either getter or setter (or both), which comprises of custom added behavior (overriding other properties, additional checks) b) modifications in save/restoreState methods (overriding several properties based on checks) c) missing attributes everywhere - xml, tld, tag, component (basicly everywhere it could be) I think items a) and b) aren't addressed in current Trinidad's generation. Quote 2: A question was raised about why state isn't retrieved from the attributes map - this cannot be used, however, cause it would use reflection internally and call the getter of the method, if a value is not directly stored in the attributes map. As soon as the getter is called, after the check for the local value returns null, you will get back the value from a value-expression, and you do not want to save this value in the state, as the value-expression itself is already stored! - saveState/restoreState for components derived from API's base already saves/restores the whole Map, so no need to do it again in derived classes - no additional reflection (which should never be done in the first place). - if a value isn't in attribute map it means it's not a crucial value to restore state, is it? (mind that all value bindings and listeners are saved/restored by API's base too) Regards, Zdenek
Re: [Myfaces Wiki] Update of Code Generation by SimonKitching
Hi, Simon Kitching napsal(a): Martin Marinschek [EMAIL PROTECTED] schrieb: Hi Simon, And this approach is not possible for uicomponent classes defined in the standard as these have defined hierarchies that cannot be modified. does this stem from actually trying it out? I tried it in the project I am currently working on, and it worked. I need to admit I did not check the Java-language specification. You're quite right, it does work! I had just assumed that creating a public subclass of a package-scope class would not work. I have updated the wiki. But all my tests show it functions fine. A public subclass inherits any public or protected members that the package-private class defines. Subclasses of it can be declared in other packages, and instances of it can be created and invoked. The only thing that cannot be done is to cast it to its parent type. This could lead to few problems: 1. deeper class tree can't use common parent to use it's methods (instanceof check-based) 2. deeper class in tree would then inherit just dumb methods generated or else we got in deadly circle again - dumb concrete (component A)dumbconcrete class (component B). That would make IDEs complaining again w/o checking in generated stuff. Interestingly, generating the normal javadoc doesn't show any trace of the package-scoped parent at all; anything public/protected the child inherits from its parent is just listed as if it were defined by the child itself. This is all exactly what we would want; the parent class is effectively invisible except in one case: when calling Child.class.getSuperclass(). Then, a Class instance for the package-scoped parent is returned. Well, I guess stack-traces will show it too. There is still the question of whether the TCK would pass if classes in javax.faces had package-scoped parents that are not defined in the spec. Is there someone here that can check that? If that is allowable, then this base-class approach becomes much more interesting... I don't think it would ever past TCK - if TCK fails even with protected methods in classes, having more generic acces class in package should definately fail. Regards, Zdenek Regards, Simon
Re: [Myfaces Wiki] Update of Code Generation by SimonKitching
Hi,
Martin Marinschek napsal(a):
Hi Zdenek,
A question was raised about why state isn't retrieved from the
attributes map - this cannot be used, however, cause it would use
reflection internally and call the getter of the method, if a value is
not directly stored in the attributes map. As soon as the getter is
called, after the check for the local value returns null, you will get
back the value from a value-expression, and you do not want to save this
value in the state, as the value-expression itself is already stored!
so you want to get rid of the concept of a local value completely, and
store everything in the attribute map? Now I see. This might actually
work, yes.
1. getting rid of attributes' local values - yes,
2. getting rid of most getters/setters w/o special code in them (as
typical use today)
2 should be possible with JSP tags, don't know about Facelets (maybe
tag-handlers could do this)
From spec and API's JavaDoc i got this idea of processing attributes:
reading:
- check if special getter - use it (if it looks at Map/VB is optional)
- check if in map - use it
- check if value binded - resolve and use it (or use default in some cases)
writing:
- check if special setter - use it AND
- store in map
using in lifecycle's process:
- Restore view:
- restore Map (done by ancester in API)
- Apply Request:
- resolve all ValueBindings and store them in Map to avoid multiple
resolving
- basically reading all attributes defined in tld and still not in Map
This should make this work for Mojarra's all getter/setter way (if
forgot writing values into Map)
- possible optimization could be in lazy fetching attributes when
needed (once fetched, store in Map)
To avoid saving these generated attributes' values, add/alter special
key in Map (e.g. o_a_m_generatedAttributes) with array containing
names of those attributes
- next phases:
- use values from Map (if not lazily fetched already complete, adding
new entries when not along with modifications of special key's value)
- NOT using reading of attributes as above if already in Map
- writing attributes as above and if attribute's name present in
special key's array, remove it from that array
- any direct modifications w/o deletion in array (e.g. for internal
processing) made in Map's values of generated attributes will be ignored
in state saving
- Render Response:
- clean Map of generated stuff:
- remove all entries with null value
- remove all entries with names in special key's array
- remove special key
- saving Map (done by ancester in API)
Having attributes both in Map and local properties (as of today and
present in API) is not an obstruction - values in local properties take
precedence,
because Map is stored/restored first.
Using this could possibly make any kind of generator for COMPONENT
classes needless - all generic code for all attributes would be written
once.
Only setters/getters i'd like to see in components' classes are with
special behaviour code (but still using Map in the end).
Tasks in this approach:
- generating TAGS (JSP and Facelets)
- create utility class for
a) getting values from Map to use in component's methods, e.g:
static public Boolean getBoolean(UIComponent comp, String attr,
Boolean default) {
Object res = comp.getAttributes().get(attr);
if (obj != null) return (Boolean)res;
// check if in special key - it may got resolved to null - return
default
// not in special key - resolve it, add to Map (along with adding
to special key's array)
// resolved != null ? return (Boolean)resolved : default;
}
(I think default can be got from TLD for JSF 1.2)
b) setting values to Map, e.g.
static public void setBoolean(UIComponent comp, String attr, Boolean
value) {
// if special setter, use it
comp.getAttributes().put(attr, value);
if (comp.getAttributesMap().get(o_a_m_generatedAttributes) != null) {
// remove attr from array
}
}
This way it would be only in Tag class/TLD to define new attributes
which would be automatically saved/restored.
(This also fulfills JSF 1.1 spec in handling generic atributes from
section 3.1.10)
OR (to be really on business of thread):
With this approach it would be pretty easy to support one method of
generating libs:
Annotations (or XDoclet) written for component class defining attributes
- name, type, default value, target language, description...
This annotation should inherit all definitions from component's parent
class.
- this way developer can really see which attributes he can really use
in component's code AND
- the class is compilable on it's own (it's accessing already existing Map)
Regards,
Zdenek
regards,
Martin
Re: [Myfaces Wiki] Update of Code Generation by SimonKitching
Hi Zdenek, writing: - check if special setter - use it AND - store in map this won't work, of course - we are in a setter already, so we cannot use the attribute-map - thanks for setting me straight again. What you are suggesting would effectively change the API of every single JSF-component (contrary to your opinion, having getters and setters _does_ make sense to me - especially if you access the components from Java, and in any case, the spec mandates having them in the component class). We need to find a different way of doing things. regards, Martin
Re: [Myfaces Wiki] Update of Code Generation by SimonKitching
On Thu, 2008-01-31 at 21:40 +, Apache Wiki wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Myfaces Wiki for change notification. The following page has been changed by SimonKitching: http://wiki.apache.org/myfaces/Code_Generation Ok, as promised here is the wiki page summarising the recent email thread. I hope I've got everybody's opinions fairly represented, but of course if corrections need to be made - hack away! Personally I'm keen to try to build something along the lines I was proposing - but first need to help get a new Orchestra release out. There isn't any hurry on getting this tomahawk build process sorted is there? I don't see any reason why tomahawk 1.1.7 cannot go out with the current build process.. Regards, Simon
Re: [Myfaces Wiki] Update of Code Generation by SimonKitching
Hi Simon, Ok, as promised here is the wiki page summarising the recent email thread. I hope I've got everybody's opinions fairly represented, but of course if corrections need to be made - hack away! I've added and clarified where I thought it was appropriate. Personally I'm keen to try to build something along the lines I was proposing - but first need to help get a new Orchestra release out. If you can solve the problem with restore-state and save-state and your solution does not decrease runtime performance, and you show me a compact way of including all meta-data in annotations, I'd be very grateful to see you hack away! However, we should discuss the options we have for getting the restore-state and save-state problem fixed first - I am pretty sure we will not find one if we want to extend from the JSF base classes. There isn't any hurry on getting this tomahawk build process sorted is there? I don't see any reason why tomahawk 1.1.7 cannot go out with the current build process.. I do not see a reason why it should - especially as even the trinidad-based approach will make it easier for you to work on your component-based approach, cause you can then generate your generator base-classes with the generator and don't have to go through all component-classes. Work that Leonardo has already done for you. We need to switch to using a generator - improving the way of generating things is then easy. I also need a generator cause I finally want to improve the performance in the components - and for checking out several ways of doing this, it is necessary to have a generator (except we find a solution along your lines with regards to restoreState/saveState). regards, Martin
Re: [Myfaces Wiki] Update of Code Generation by SimonKitching
Okay, feel free to flame.
Possibility of merging annotations w/ code generation:
@Component(
type = ...,
family = ...,
rendererType = ...,
tagClass = ...,
events = {
@ComponentEvent(
type = ...,
phases = { ..., ... }),
...
)
public abstract class MyComponent extends UIXComponent
{
@ComponentProperty(
description = or is this better in javadoc? -- harder to code the
generator, but easier to document,
extensions = {
@PropertyExtension(name = preferred, value = Boolean.TRUE),
@PropertyExtension(name = ..., value = ...)
})
private String _foo;
@ComponentPropertySkel
public abstract String getFoo();
public void broadcast(FacesEvent event)
{
// custom code
}
}
This would be in a pre-processing folder of maven (not src/main/java). The
plugin can then take this file an build the concrete class from it.
This is basically the same as the trinidad approach but it merges the xml
with the template.
This way you don't get tedious xml like:
property-extension
mfp:method-binding-signature
mfp:return-typejava.lang.String/mfp:return-type
/mfp:method-binding-signature
Just a thought.
-Andrew
On Jan 31, 2008 3:59 PM, Martin Marinschek [EMAIL PROTECTED]
wrote:
Hi Simon,
Ok, as promised here is the wiki page summarising the recent email
thread. I hope I've got everybody's opinions fairly represented, but of
course if corrections need to be made - hack away!
I've added and clarified where I thought it was appropriate.
Personally I'm keen to try to build something along the lines I was
proposing - but first need to help get a new Orchestra release out.
If you can solve the problem with restore-state and save-state and your
solution does not decrease runtime performance, and you show me a compact
way of including all meta-data in annotations, I'd be very grateful to see
you hack away! However, we should discuss the options we have for getting
the restore-state and save-state problem fixed first - I am pretty sure we
will not find one if we want to extend from the JSF base classes.
There isn't any hurry on getting this tomahawk build process sorted is
there? I don't see any reason why tomahawk 1.1.7 cannot go out with the
current build process..
I do not see a reason why it should - especially as even the
trinidad-based approach will make it easier for you to work on your
component-based approach, cause you can then generate your generator
base-classes with the generator and don't have to go through all
component-classes. Work that Leonardo has already done for you. We need to
switch to using a generator - improving the way of generating things is then
easy. I also need a generator cause I finally want to improve the
performance in the components - and for checking out several ways of doing
this, it is necessary to have a generator (except we find a solution along
your lines with regards to restoreState/saveState).
regards,
Martin
Re: [Myfaces Wiki] Update of Code Generation by SimonKitching
@Component(
type = ...,
family = ...,
rendererType = ...,
tagClass = ...,
events = {
@ComponentEvent(
type = ...,
phases = { ..., ... }),
...
)
public abstract class MyComponent extends UIXComponent
{
@ComponentProperty(
description = or is this better in javadoc? -- harder to code the
generator, but easier to document,
extensions = {
@PropertyExtension(name = preferred, value = Boolean.TRUE),
@PropertyExtension(name = ..., value = ...)
})
private String _foo;
@ComponentPropertySkel
public abstract String getFoo();
public void broadcast(FacesEvent event)
{
// custom code
}
}
another option - why don't you add it to the wiki?I would be against it,
cause it is one of these options which need a full rebuild on a change in
the component-class.
regards,
Martin
Re: [Myfaces Wiki] Update of Code Generation by SimonKitching
http://wiki.apache.org/myfaces/Code_Generation 2) Generating base classes instead of templates from xml-config-files For what it's worth, what you're describing here is the Generation Gap pattern. I've got a lot of experience using it with Cayenne over the years (and WebObjects years before that), and it's effective. It's sometimes painful to write and maintain your base class in a templating language, though, but once your base class is done, you don't need to mess with it again, so this is a one-time painful experience. And yes, you would typically generate an empty concrete subclass whenever one doesn't exist (the first time code generation runs for a given component). I check the code thus generated into the repository. I also keep the generated code in a subpackage called *.generated off the concrete subclasses's package.
Re: [Myfaces Wiki] Update of Code Generation by SimonKitching
On Thu, 2008-01-31 at 23:59 +0100, Martin Marinschek wrote: Personally I'm keen to try to build something along the lines I was proposing - but first need to help get a new Orchestra release out. If you can solve the problem with restore-state and save-state and your solution does not decrease runtime performance, and you show me a compact way of including all meta-data in annotations, I'd be very grateful to see you hack away! However, we should discuss the options we have for getting the restore-state and save-state problem fixed first - I am pretty sure we will not find one if we want to extend from the JSF base classes. Yep, it's just an idea at the moment; actually trying it will show whether there are reasonable solutions to your points or not.. There isn't any hurry on getting this tomahawk build process sorted is there? I don't see any reason why tomahawk 1.1.7 cannot go out with the current build process.. I do not see a reason why it should - especially as even the trinidad-based approach will make it easier for you to work on your component-based approach, cause you can then generate your generator base-classes with the generator and don't have to go through all component-classes. Work that Leonardo has already done for you. We need to switch to using a generator - improving the way of generating things is then easy. I also need a generator cause I finally want to improve the performance in the components - and for checking out several ways of doing this, it is necessary to have a generator (except we find a solution along your lines with regards to restoreState/saveState). I look at the vast list of bugs raised against tomahawk 1.1.6, and look at the scary output of the maven reports (findbugs, pmd, etc) and think that there are higher priorities than reinventing the build process right now, when the current approach works. Yes it is ugly, but 1.1.7 is mostly a bugfix release; we don't need to add many components or change many APIs. We do want to promote a couple of sandbox components which is a nuisance but can be managed. And the thought of changing the build process for 1.1.7, then changing it again for 1.1.8 is not too tempting. Of course this is open-source, so nobody can be told what to work on, and what not. But I don't personally want to be testing a temporary new build process while also testing a tomahawk rc. I think it would be better to solve the build process issue just once, but it looks like that would delay a tomahawk release - unless we get consensus to use the trinidad approach (which doesn't seem to be the case ATM). The last tomahawk release is over 6 months ago, which is the release cycle for a whole Ubuntu distro, or a linux kernel...it would be nice to get one out without further delays. Regards, Simon
Re: [Myfaces Wiki] Update of TrinidadTwoTrunks by MatthiasWessendorf
When are we going to remove the extra trinidad in the trunk folder hierarchy? -Andrew On Dec 11, 2007 4:57 AM, Apache Wiki [EMAIL PROTECTED] wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Myfaces Wiki for change notification. The following page has been changed by MatthiasWessendorf: http://wiki.apache.org/myfaces/TrinidadTwoTrunks New page: Trinidad has two trunks. One (1.0.x) is for JSF 1.1 and the other trunk (1.2.x) is for JSF 1.2. All bug fixes MUST be applied to both trunks (1.0.x AND 1.2.x). This is important to have synced Trinidad releases. There are two cases where the fix only needs to go into one of the trunks (1.0.x OR 1.2.x). If your fix is only working with JSF 1.2, then create a patch against the 12_x trunk. In case it is only for JSF 1.1, create the fix against the 1.0.x trunk. The URLs to the trunks are: 1.2.x trunk: http://svn.apache.org/repos/asf/myfaces/trinidad/trunk_1.2.x/ 1.0.x trunk: http://svn.apache.org/repos/asf/myfaces/trinidad/trunk/trinidad/
Re: [Myfaces Wiki] Update of TrinidadTwoTrunks by MatthiasWessendorf
yes, we are. but haven't done yet. -M On Dec 11, 2007 5:14 PM, Andrew Robinson [EMAIL PROTECTED] wrote: When are we going to remove the extra trinidad in the trunk folder hierarchy? -Andrew On Dec 11, 2007 4:57 AM, Apache Wiki [EMAIL PROTECTED] wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Myfaces Wiki for change notification. The following page has been changed by MatthiasWessendorf: http://wiki.apache.org/myfaces/TrinidadTwoTrunks New page: Trinidad has two trunks. One (1.0.x) is for JSF 1.1 and the other trunk (1.2.x) is for JSF 1.2. All bug fixes MUST be applied to both trunks (1.0.x AND 1.2.x). This is important to have synced Trinidad releases. There are two cases where the fix only needs to go into one of the trunks (1.0.x OR 1.2.x). If your fix is only working with JSF 1.2, then create a patch against the 12_x trunk. In case it is only for JSF 1.1, create the fix against the 1.0.x trunk. The URLs to the trunks are: 1.2.x trunk: http://svn.apache.org/repos/asf/myfaces/trinidad/trunk_1.2.x/ 1.0.x trunk: http://svn.apache.org/repos/asf/myfaces/trinidad/trunk/trinidad/ -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [Myfaces Wiki] Update of Use Facelets with Tomahawk by Zied
Zied, Thanks for taking the time to update this page. However, some of the information you've removed or changed should not have been changed. For example, with facelets, you should not use UpdateActionListenerTagHandler, but instead use setPropertyActionListener. Not only is this forward-compatible, but at least one other attempt to write an updateActionListener resulted in incorrect compatibility with facelets, as the original comment below states. If you would like to provide an alternate UpdateActionListenerTagHandler, please leave the original comment in, and test your tag handler to be sure it really works as well as setPropertyActionListener. Honestly, though, if it's just a matter of name compatiblity, you're still better off defining updateActionListener to point to a subclass of the setPropertyActionListener handler which using aliases for the attribute names. - !-- - tag-nameupdateActionListener/tag-name requires a Facelets TagHandler. Use the functionality-equivalent JSF 1.2 f:setPropertyActionListener instead. f:setPropertyActionListener has been backported as of facelets 1.1.11. Note that the jsf-comp updateActionListener does not handle setting values on ui:include parameters while setPropertyActionListener will correctly propagate these values. - -- + tag + tag-nameupdateActionListener/tag-name + handler-classcom.google.code.tomahawk.facelets.UpdateActionListenerTagHandler/handler-class + /tag Also, there are no instructions on where to find the code for the tag handler you've defined. Furthermore, you seem to have arbitrarily moved around some of the definitions for no apparent reason. Please leave the entries in alphabetical order. Because of all of this, I'm going to revert your changes, and add in what useful changes you've made. As far as I can tell, this is fixing a bug in the renderer-type for commandNavigation, adding a definition for dojoInitializer, adding a definition for panelStack, and adding a renderer-type for schedule. In the future, please make changes incrementally and use wiki comments to describe changes you've made. If at all possible, do not make whitespaces/formatting changes at the same time as functionality changes. On 10/2/07, Apache Wiki [EMAIL PROTECTED] wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Myfaces Wiki for change notification. The following page has been changed by Zied: http://wiki.apache.org/myfaces/Use_Facelets_with_Tomahawk -- tag tag-namecommandButton/tag-name component - component-typeorg.apache.myfaces.HtmlCommandButton/component-type + component-typeorg.apache.myfaces.HtmlCommandButton/component-type /component /tag tag @@ -73, +73 @@ tag-namecommandNavigation/tag-name component component-typeorg.apache.myfaces.HtmlCommandNavigation/component-type - renderer-typeorg.apache.myfaces.Navigation/renderer-type + renderer-typejavax.faces.Link/renderer-type - /component - /tag - tag - tag-namecommandNavigation2/tag-name - component - component-typeorg.apache.myfaces.HtmlCommandNavigationItem/component-type - renderer-typeorg.apache.myfaces.NavigationMenu/renderer-type /component /tag tag @@ -112, +105 @@ /component /tag tag + tag-namedojoInitializer/tag-name + component + component-typeorg.apache.myfaces.DojoInitializer/component-type + renderer-typeorg.apache.myfaces.DojoInitializerRenderer/renderer-type + /component + /tag + tag tag-namediv/tag-name component component-typeorg.apache.myfaces.Div/component-type /component - /tag - tag - tag-namedocument/tag-name - component - component-typeorg.apache.myfaces.Document/component-type - /component - /tag - tag - tag-namedocumentBody/tag-name - component - component-typeorg.apache.myfaces.DocumentBody/component-type - /component - /tag - tag - tag-namedocumentHead/tag-name - component - component-typeorg.apache.myfaces.DocumentHead/component-type - /component /tag tag tag-namegraphicImage/tag-name @@ -182, +164 @@ component-typeorg.apache.myfaces.InputHtml/component-type renderer-typeorg.apache.myfaces.InputHtml/renderer-type /component - /tag + /tag tag tag-nameinputSecret/tag-name component @@ -212, +194 @@ /component /tag tag + tag-namemessage/tag-name + component +
Re: [Myfaces Wiki] Update of Use Facelets with Tomahawk by Zied
Zied, I've glanced at the HtmlCommandNavigationTag for jsp, and the renderer type matches org.apache.myfaces.Navigation, which was what was there before you changed it to javax.faces.Link. Why do you think it needs to be changed? On 10/16/07, Mike Kienenberger [EMAIL PROTECTED] wrote: [...] As far as I can tell, this is fixing a bug in the renderer-type for commandNavigation [...] tag-namecommandNavigation/tag-name component component-typeorg.apache.myfaces.HtmlCommandNavigation/component-type - renderer-typeorg.apache.myfaces.Navigation/renderer-type + renderer-typejavax.faces.Link/renderer-type - /component - /tag [...]
Re: [Myfaces Wiki] Update of Trinidad Archetype by MartinMarinschek
There is nothing like a good reminder ;)
regards,
Martin
On 7/11/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
this reminds me to release them :-)
On 7/11/07, Apache Wiki [EMAIL PROTECTED] wrote:
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Myfaces Wiki
for change notification.
The following page has been changed by MartinMarinschek:
http://wiki.apache.org/myfaces/Trinidad_Archetype
--
{{{
mvn archetype:create -DarchetypeGroupId=
org.apache.myfaces.trinidadbuild \
-DarchetypeArtifactId=myfaces-archetype-trinidad
\
- -DarchetypeVersion=incubator-m1-SNAPSHOT
\
+ -DarchetypeVersion=1.0.2-SNAPSHOT
\
-DgroupId=myAppId \
-DartifactId=testApp
}}}
@@ -30, +30 @@
To be able to use the archetype the first thing you should do is to
checkout the Trinidad Archetype source from the svn, using the command:
{{{
- svn co
http://svn.apache.org/repos/asf/incubator/adffaces/trunk/plugins/myfaces-archetype-trinidad/trinidad-archetype
+ svn co
http://svn.apache.org/repos/asf/myfaces/maven/trunk/archetypes/myfaces-archetype-trinidad/trinidad-archetype
}}}
Now, let's install the plugin locally (this supposes that you have
maven 2.x already installed). Navigate to the plugin root folder and use
the mvn install command:
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [Myfaces Wiki] Update of Trinidad Archetype by MartinMarinschek
this reminds me to release them :-)
On 7/11/07, Apache Wiki [EMAIL PROTECTED] wrote:
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Myfaces Wiki for
change notification.
The following page has been changed by MartinMarinschek:
http://wiki.apache.org/myfaces/Trinidad_Archetype
--
{{{
mvn archetype:create -DarchetypeGroupId=org.apache.myfaces.trinidadbuild \
-DarchetypeArtifactId=myfaces-archetype-trinidad \
- -DarchetypeVersion=incubator-m1-SNAPSHOT
\
+ -DarchetypeVersion=1.0.2-SNAPSHOT\
-DgroupId=myAppId \
-DartifactId=testApp
}}}
@@ -30, +30 @@
To be able to use the archetype the first thing you should do is to checkout
the Trinidad Archetype source from the svn, using the command:
{{{
- svn co
http://svn.apache.org/repos/asf/incubator/adffaces/trunk/plugins/myfaces-archetype-trinidad/
trinidad-archetype
+ svn co
http://svn.apache.org/repos/asf/myfaces/maven/trunk/archetypes/myfaces-archetype-trinidad/
trinidad-archetype
}}}
Now, let's install the plugin locally (this supposes that you have maven 2.x
already installed). Navigate to the plugin root folder and use the mvn install
command:
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
Re: [Myfaces Wiki] Update of ClearInputComponents by SimonKitching
Simon, I noticed a probable mistake in the following line from your addition: + However when using command components with immediate=false, things become more complex. Here you are actually talking about the scenario immediate=true! You described immediate=false in a previous paragraph. I have made this change already for you on the wiki, but if I am mistaken please revert it. :) Regards, Jeff Bischoff Kenneth L Kurz Associates, Inc. Mike Kienenberger wrote: Simon, Since you're working on this page, can you please remove this part at the bottom of the page? I've successfully used the return non-null navigation outcome to the same page in order to reset form values. Note that this approach has not been tested; if you find it does work, then please update this page. On 1/25/07, Apache Wiki [EMAIL PROTECTED] wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Myfaces Wiki for change notification. The following page has been changed by SimonKitching: http://wiki.apache.org/myfaces/ClearInputComponents -- + === Problem Description === + Sometimes you want to provide a command component (eg a link or button) that performs some server action, and - renders the same page but with completely fresh values for all components. However this doesn't work well + renders the same page but with completely fresh values for all components. - when the component is immediate; in this case input components get their submitted value set during the postback - and re-render that submitted value even when the backing values for those input components have been reset to default values. + When using command components with the normal immediate setting (false), achieving this is just a matter of clearing the beans that the JSF component value attributes access. Any values entered by the user will have been pushed into these beans as part of the Update Model phase, so the components themselves will not be holding any information about submitted data. The action method associated with the command is then run which resets the model, and when the components render themselves they will draw fresh data from the (reset) beans. + + Note that because data is being pushed into the model, the validation phase must run, and therefore any invalid data in the page will cause the action to be skipped, and the page is redisplayed with the validation errors displayed. This is not generally the desired behaviour for a clear type operation! The solution is to set attribute immediate=true on the command so that its associated action is invoked before validation is applied to the input components in the same view (see [How_The_Immediate_Attribute_Works]). + + However when using command components with immediate=false, things become more complex. All components will retrieve the raw submitted values submitted by the user, but the immediate command will then run before they can be pushed into the backing beans; the components therefore remember this data. When the (immediate) action causes navigation to another view then this is no problem; these components will be discarded anyway. However if the action method causes JSF to go directly to the render phase 'of the same view' [by calling facesContext.renderResponse()], then the components will behave as they do for a validation failure - by displaying the value cached in the component rather than fetching data from the backing bean. + - Here are a number of possible solutions + Below are a number of possible solutions. === Force a new View === Call this method from the action method of the immediate command component:
Re: [Myfaces Wiki] Update of CoreRelease114 by WendySmoak
On 9/11/06, Apache Wiki [EMAIL PROTECTED] wrote: The following page has been changed by WendySmoak: http://wiki.apache.org/myfaces/CoreRelease114 The comment on the change is: three years later... - * 2009-09-11 - Release vote thread: http://www.nabble.com/-VOTE--Release-MyFaces-Core-1.1.4-t2253192.html + * 2006-09-11 - Release vote thread: http://www.nabble.com/-VOTE--Release-MyFaces-Core-1.1.4-t2253192.html Nah, it only seems like it's been three years :-)
Re: Myfaces Wiki ComponentMaintainers
Ok, Mike told me that I was wrong to move this discussion to pmc@ and I should repost it at [EMAIL PROTECTED] Now, I dont want to rewarm this discussion, but when I reread my own post I think there are still valid points within. So - here we go: On 8/22/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! Moved to private@ ... Also not really Apache, so why just discussed stuff during a beer, or more ... I think the problem is, that our projects are getting more and more complex. And its not just a deprecate this or that component, its the system as whole. Now what we see - I cant speak for apache at all, but at least for a project which itself is more a umbrella than a single focused project - is, that people tend to concentrate on their work only. As a developer in a mid range company like me I'd say this is perfectly reasonable, we have so much work to do outside of apache that it is hard to keep up to date with the project. Often more than not I have to spend my after work time to do some apache work, enhancements of fixing bugs. I do not think that adding our names to the wiki page will increase the number of private mails, but it will help us to be up to date with the interests of a developer. Something we have in jakarta commons (http://wiki.apache.org/jakarta-commons/CommonsPeople), there we are also responsible for the commons code, but it is also clear that e.g. I am not the best commons-math developer due to the lack of knowledge in this area. That way we can react early if a component get dormant. If ComponentMaintainer sounds too harsh we could find another name for sure, maybe DeveloperInterests and have the same wordings like on the commons page. As I see currently, tomahawk is more a umbrella for different kind of things than a component library only. Maybe splitting this project might help so that we can decrease the scope of responsibility (SoR ;-) ) for every single developer. Where and what to split can be discussed later. Also I do not like the wording responsibility. Responsible against whom, the other developers, the users, Well, I take my responsibility seriously, but I don't wanted to be forced to be responsible for anything - especially not for the whole project. Thats why I think a ComponentMaintainers page fits well. There we can express what responsibility we would like to have currently. But notice, I just mean the responsibility to fix bugs in a specific area. As a committer especially if you are on the pmc you are still responsible for the way the project should go. This kind of responsibility is often just participating in discussions or +1/-1 to a vote. It's not that much work than setup a test environment, dig into the code and fix a bug. For example: If there are some problems during the release process, the release manager still should post to the dev mailing list, but maybe then with Hey Mario! In your ConversationTag ... bla bla bla. If I do not answer within two or three (e.g. due to vacation) days its still enough room for others to jump in and fix the problem. But ... If you look at the release process in the past you'll see that the number of developers helping out in such situations do not nearly match with the number of committers we have. Another example: Fixing stuff in the view serialization stuff is hard. This code is not that easy to read and follow. (This is no valuation of the code itself) Now, if we see there is no maintainer for this piece of code (no name in ComponentMaintainer) we have to find another one. This can be done by posting to the dev list volunteer needed for . Hopefully another committer will jump up. It is more than demotivating if you have problems (e.g. again during the release process) and you try to find a developer to fix something but none is responding. Just an idea, maybe unconventional, but hey ... Said that, I do not consist on the existence of this wiki page. I just thought it will be helpful for us, but if you don't like it, lets remove the names :-) Ok, this already happened ;-) Ciao, Mario
Re: Myfaces Wiki ComponentMaintainers
Good points in this thread. Yes, the list of components is ok, but names should be removed right away. Even without putting the name elsewhere (apart from being the author of those classes) you still get personal mails about that classes/component. Let's delete the names, then... and maybe, instead of having a new classification, we could put the information in the existing component pages (e.g. uses dojo, ...) Cheers, Bruno On 8/21/06, Cagatay Civici [EMAIL PROTECTED] wrote: I don't think anyone will disagree to a wiki page that shows the organization of the components. So +1 for that. Also I agree with; We are all corporately responsible for all of the code, and have freedom to get involved with any of it. So -1 for stating committer names as the maintainer of each component. Cagatay p.s. I'm really getting used to the +1, -1 business :) On 8/21/06, Werner Punz [EMAIL PROTECTED] wrote: Ok valid points are risen, that it is not Apache like... I think a vote on whether we keep the page or not might be good... as I said, I wanted to achieve a different purpose for this, namely to have categorized which components are dojoized, so that I have it easier to test after dojo upgrades (hence also the current maintainers of the components) but Craig and the others have risen a valid point. Lets either vote on this, or just do it the wiki way and remove yourself if you feel out of place in there. All I really need is some sort of component categorization so that I can keep track of things... I did not want to open a Pandoras box here.
Re: Myfaces Wiki ComponentMaintainers
Ok, since the feedback was mostly negative and one -1 voting and no +1s I removed the maintainers but kept the kategorization, I really need the cats for future testing purposes. Also the feedback on the idea of categorizing the components was positive: http://wiki.apache.org/myfaces/ComponentCategorization is the new page. Werner Bruno Aranda schrieb: Good points in this thread. Yes, the list of components is ok, but names should be removed right away. Even without putting the name elsewhere (apart from being the author of those classes) you still get personal mails about that classes/component. Let's delete the names, then... and maybe, instead of having a new classification, we could put the information in the existing component pages (e.g. uses dojo, ...) Cheers, Bruno On 8/21/06, Cagatay Civici [EMAIL PROTECTED] wrote: I don't think anyone will disagree to a wiki page that shows the organization of the components. So +1 for that. Also I agree with; We are all corporately responsible for all of the code, and have freedom to get involved with any of it. So -1 for stating committer names as the maintainer of each component. Cagatay p.s. I'm really getting used to the +1, -1 business :) On 8/21/06, Werner Punz [EMAIL PROTECTED] wrote: Ok valid points are risen, that it is not Apache like... I think a vote on whether we keep the page or not might be good... as I said, I wanted to achieve a different purpose for this, namely to have categorized which components are dojoized, so that I have it easier to test after dojo upgrades (hence also the current maintainers of the components) but Craig and the others have risen a valid point. Lets either vote on this, or just do it the wiki way and remove yourself if you feel out of place in there. All I really need is some sort of component categorization so that I can keep track of things... I did not want to open a Pandoras box here.
Re: Myfaces Wiki ComponentMaintainers
Op ma, 21-08-2006 te 11:14 -0400, schreef Mike Kienenberger: Do we want to list out who's responsible for components on the wiki? It seems like ththis would encourage having people send email directly an individual committer rather than the MyFaces community. Hmm, good point. Once things are checked into the repository, we should all be collectively responsible for the code. There are going to be people who have a lot more invested into a component, but does that require a tracking page?SVN logs will show who has been committing changes to a particular component. Personally I favour the way they do things at Gentoo Linux: instead of everyone being collectively responsible for the code, they have divided their committer community into groups, each with a project lead. For example, they have a Java group, an Apache group, etc. Jurgen
Re: Myfaces Wiki ComponentMaintainers
Jurgen Lust schrieb: Op ma, 21-08-2006 te 11:14 -0400, schreef Mike Kienenberger: Do we want to list out who's responsible for components on the wiki? It seems like ththis would encourage having people send email directly an individual committer rather than the MyFaces community. Hmm, good point. Once things are checked into the repository, we should all be collectively responsible for the code. There are going to be people who have a lot more invested into a component, but does that require a tracking page?SVN logs will show who has been committing changes to a particular component. Personally I favour the way they do things at Gentoo Linux: instead of everyone being collectively responsible for the code, they have divided their committer community into groups, each with a project lead. For example, they have a Java group, an Apache group, etc. Jurgen Actually I just started the page to document which components are dojoized and which are not, the maintainers are not really mandatory on this, it just makes things easier... I like the idea with the groups btw...
Re: Myfaces Wiki ComponentMaintainers
On 8/21/06, Werner Punz [EMAIL PROTECTED] wrote: Jurgen Lust schrieb: Op ma, 21-08-2006 te 11:14 -0400, schreef Mike Kienenberger: Do we want to list out who's responsible for components on the wiki? It seems like ththis would encourage having people send email directly an individual committer rather than the MyFaces community. Hmm, good point. Once things are checked into the repository, we should all be collectively responsible for the code. There are going to be people who have a lot more invested into a component, but does that require a tracking page?SVN logs will show who has been committing changes to a particular component. Personally I favour the way they do things at Gentoo Linux: instead of everyone being collectively responsible for the code, they have divided their committer community into groups, each with a project lead. For example, they have a Java group, an Apache group, etc. JurgenActually I just started the page to document which componentsare dojoized and which are not,the maintainers are not really mandatory on this,it just makes things easier... I like the idea with the groups btw...In every large open source project, it's natural that certain developers tend to focus on certain parts of the code. However, assigning formal ownership or responsibility -- or even implying that there is such a thing -- is not the way Apache projects work. We are all corporately responsible for all of the code, and have freedom to get involved with any of it. Need to coordinate, or ask who might be affected by a change you want to make? That's what the dev list is for.Craig
Re: Myfaces Wiki ComponentMaintainers
On 8/21/06, Mike Kienenberger [EMAIL PROTECTED] wrote: Do we want to list out who's responsible for components on the wiki? It seems like ththis would encourage having people send email directly an individual committer rather than the MyFaces community. I agree with Mike, I saw the page this morning and was also not really thrilled with having that. I get lot's of direct emails, I think Mike is right, that this can (or will) increase the number of offline emails. So -1 on a wiki page like that). -Matthias Once things are checked into the repository, we should all be collectively responsible for the code. There are going to be people who have a lot more invested into a component, but does that require a tracking page?SVN logs will show who has been committing changes to a particular component. -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Myfaces Wiki ComponentMaintainers
On 8/21/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I get lot's of direct emails, I think Mike is right, that this can (orwill) increase the number of offline emails.You'd be amazed at how many personal Tomcat questions I still get, after not having worked on that project for several years, simply because my name is listed as an author on one of the developer guides :-). Craig
Re: Myfaces Wiki ComponentMaintainers
Oh boy, I belive that. I bet you also get lot's of stuff on Jakarta Commons. :) and Struts ;) On 8/21/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 8/21/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I get lot's of direct emails, I think Mike is right, that this can (or will) increase the number of offline emails. You'd be amazed at how many personal Tomcat questions I still get, after not having worked on that project for several years, simply because my name is listed as an author on one of the developer guides :-). Craig -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Myfaces Wiki ComponentMaintainers
Ok valid points are risen, that it is not Apache like... I think a vote on whether we keep the page or not might be good... as I said, I wanted to achieve a different purpose for this, namely to have categorized which components are dojoized, so that I have it easier to test after dojo upgrades (hence also the current maintainers of the components) but Craig and the others have risen a valid point. Lets either vote on this, or just do it the wiki way and remove yourself if you feel out of place in there. All I really need is some sort of component categorization so that I can keep track of things... I did not want to open a Pandoras box here.
Re: Myfaces Wiki ComponentMaintainers
I mean Mario and me talked about a thing like fix 2 bugs a month. Also not really Apache, so why just discussed stuff during a beer, or more ... :) On 8/21/06, Werner Punz [EMAIL PROTECTED] wrote: Ok valid points are risen, that it is not Apache like... I think a vote on whether we keep the page or not might be good... as I said, I wanted to achieve a different purpose for this, namely to have categorized which components are dojoized, so that I have it easier to test after dojo upgrades (hence also the current maintainers of the components) but Craig and the others have risen a valid point. Lets either vote on this, or just do it the wiki way and remove yourself if you feel out of place in there. All I really need is some sort of component categorization so that I can keep track of things... I did not want to open a Pandoras box here. -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [Myfaces Wiki] Update of FrontPage by LanceFrohman
On 8/10/06, Apache Wiki [EMAIL PROTECTED] wrote: + * [Parameters_In_EL] - Howto pass parameters in an EL expression. Hey Lance. You might want to call this Parameters_In_EL_Functions - How to pass parameters in an EL expression function. Otherwise it might get confused with other parameter meanings, like request parameters.
RE: [Myfaces Wiki] Update of FrontPage by LanceFrohman
is there a way to rename a wiki page? -Message d'origine- De : Mike Kienenberger [mailto:[EMAIL PROTECTED] Envoyé : jeudi 10 août 2006 18:52 À : MyFaces Development Cc : L Frohman Objet : Re: [Myfaces Wiki] Update of FrontPage by LanceFrohman On 8/10/06, Apache Wiki [EMAIL PROTECTED] wrote: + * [Parameters_In_EL] - Howto pass parameters in an EL expression. Hey Lance. You might want to call this Parameters_In_EL_Functions - How to pass parameters in an EL expression function. Otherwise it might get confused with other parameter meanings, like request parameters.
Re: [Myfaces Wiki] Update of FrontPage by LanceFrohman
There's a Rename Page under the More Actions pulldown, but I think you have to manually change any links pointing to that page afterward. On 8/10/06, L Frohman [EMAIL PROTECTED] wrote: is there a way to rename a wiki page? -Message d'origine- De : Mike Kienenberger [mailto:[EMAIL PROTECTED] Envoyé : jeudi 10 août 2006 18:52 À : MyFaces Development Cc : L Frohman Objet : Re: [Myfaces Wiki] Update of FrontPage by LanceFrohman On 8/10/06, Apache Wiki [EMAIL PROTECTED] wrote: + * [Parameters_In_EL] - Howto pass parameters in an EL expression. Hey Lance. You might want to call this Parameters_In_EL_Functions - How to pass parameters in an EL expression function. Otherwise it might get confused with other parameter meanings, like request parameters.
Re: [Myfaces Wiki] Update of LocalSpellingWords by MikeKienenberger
hu? what is that for a page? On 8/9/06, Apache Wiki [EMAIL PROTECTED] wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Myfaces Wiki for change notification. The following page has been changed by MikeKienenberger: http://wiki.apache.org/myfaces/LocalSpellingWords -- Sperrmechanismus about active all and application are as be bit boolean build but by good just latest normal not of on session should way what when which + + action add Add already apache api Because been body Buffer buffer can case change changed Check Class class Code command commons component configured copy correct correctly could covered custom deploy do Dummy dummy each easiest element Error Example example Exception execute exist exists Explanation Extension extension Extensions extensions Faces faces Factory file filter Filter following for Form form Found from has have header How if If Illegal impl implementation in In include is jar java jboss jsf jsp lang lib libraries Links Make make mapping mappings Method missing Missing Modify My my myfaces name necessary needs new No ok other package pages pattern Please present problem Remove removed renderkit Replace replace Resource Response result same see server servlet Servlet shared So some something Source State Such sure tag tags that The the thing this throw to Tomahawk tomahawk Update upgrade util Utils version versions web webapp with within Wrapper Write Writer you -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [Myfaces Wiki] Update of LocalSpellingWords by MikeKienenberger
Apparently, it's a poor-man's spell checker for a wiki. If you chose spell check while ending a page, it compares all words in the document with all words on that page and lists out the ones found in your document that aren't in that page. At this point, you can determine if it's a valid word (or a typo) to add it to the page. On 8/9/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: hu? what is that for a page? On 8/9/06, Apache Wiki [EMAIL PROTECTED] wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Myfaces Wiki for change notification. The following page has been changed by MikeKienenberger: http://wiki.apache.org/myfaces/LocalSpellingWords -- Sperrmechanismus about active all and application are as be bit boolean build but by good just latest normal not of on session should way what when which + + action add Add already apache api Because been body Buffer buffer can case change changed Check Class class Code command commons component configured copy correct correctly could covered custom deploy do Dummy dummy each easiest element Error Example example Exception execute exist exists Explanation Extension extension Extensions extensions Faces faces Factory file filter Filter following for Form form Found from has have header How if If Illegal impl implementation in In include is jar java jboss jsf jsp lang lib libraries Links Make make mapping mappings Method missing Missing Modify My my myfaces name necessary needs new No ok other package pages pattern Please present problem Remove removed renderkit Replace replace Resource Response result same see server servlet Servlet shared So some something Source State Such sure tag tags that The the thing this throw to Tomahawk tomahawk Update upgrade util Utils version versions web webapp with within Wrapper Write Writer y ou -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [Myfaces Wiki] Update of LocalSpellingWords by MikeKienenberger
ah! cool I was not knowing that :) On 8/9/06, Mike Kienenberger [EMAIL PROTECTED] wrote: Apparently, it's a poor-man's spell checker for a wiki. If you chose spell check while ending a page, it compares all words in the document with all words on that page and lists out the ones found in your document that aren't in that page. At this point, you can determine if it's a valid word (or a typo) to add it to the page. On 8/9/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: hu? what is that for a page? On 8/9/06, Apache Wiki [EMAIL PROTECTED] wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Myfaces Wiki for change notification. The following page has been changed by MikeKienenberger: http://wiki.apache.org/myfaces/LocalSpellingWords -- Sperrmechanismus about active all and application are as be bit boolean build but by good just latest normal not of on session should way what when which + + action add Add already apache api Because been body Buffer buffer can case change changed Check Class class Code command commons component configured copy correct correctly could covered custom deploy do Dummy dummy each easiest element Error Example example Exception execute exist exists Explanation Extension extension Extensions extensions Faces faces Factory file filter Filter following for Form form Found from has have header How if If Illegal impl implementation in In include is jar java jboss jsf jsp lang lib libraries Links Make make mapping mappings Method missing Missing Modify My my myfaces name necessary needs new No ok other package pages pattern Please present problem Remove removed renderkit Replace replace Resource Response result same see server servlet Servlet shared So some something Source State Such sure tag tags that The the thing this throw to Tomahawk tomahawk Update upgrade util Utils version versions web webapp with within Wrapper Write Writer y ou -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [Myfaces Wiki] Trivial Update of ADF Faces by JonasJacobi
For some reasons I didn't changed this :) On 6/12/06, Apache Wiki [EMAIL PROTECTED] wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Myfaces Wiki for change notification. The following page has been changed by JonasJacobi: http://wiki.apache.org/myfaces/ADF_Faces -- == Using Trinidad / ADF Faces == - *[Building ADF Faces With Maven] - Maven build instructions + *[Building ADF With Maven] - Maven build instructions == compiled JAR files for Trinidad == -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [Myfaces Wiki] Update of css component ids by MatthiasWessendorf
That only works for Firefox, though. Not for IE, afaik.
regards,
Martin
On 4/20/06, Apache Wiki [EMAIL PROTECTED] wrote:
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Myfaces Wiki for
change notification.
The following page has been changed by MatthiasWessendorf:
http://wiki.apache.org/myfaces/css_component_ids
New page:
Since JSF's NamingContainer's cause rendered ids like foo:bar, here is
described howto work around for CSS.
You just need to use a backslash to escape the colon
{{{
style
div#foo { background-color:red}
div#foo\:bar { background-color:green}
/style
}}}
Rendered markup by a component
{{{
div id=fooFoo/div
div id=foo:barFoo:Bar/div
}}}
Note, that JSF is not incompatible to CSS
BTW. the standard naming container components are:
* h:form
* f:subview
* h:dataTable
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [Myfaces Wiki] Update of css component ids by MatthiasWessendorf
damn,
just tested. Firefox shows the div as green, but IE not.
thanks for pointing it out, I just updated the wiki.
On 4/20/06, Martin Marinschek [EMAIL PROTECTED] wrote:
That only works for Firefox, though. Not for IE, afaik.
regards,
Martin
On 4/20/06, Apache Wiki [EMAIL PROTECTED] wrote:
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Myfaces Wiki for
change notification.
The following page has been changed by MatthiasWessendorf:
http://wiki.apache.org/myfaces/css_component_ids
New page:
Since JSF's NamingContainer's cause rendered ids like foo:bar, here is
described howto work around for CSS.
You just need to use a backslash to escape the colon
{{{
style
div#foo { background-color:red}
div#foo\:bar { background-color:green}
/style
}}}
Rendered markup by a component
{{{
div id=fooFoo/div
div id=foo:barFoo:Bar/div
}}}
Note, that JSF is not incompatible to CSS
BTW. the standard naming container components are:
* h:form
* f:subview
* h:dataTable
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
Matthias Wessendorf
Aechterhoek 18
48282 Emsdetten
http://jroller.com/page/mwessendorf
mwessendorf-at-gmail-dot-com
Re: [Myfaces Wiki] Update of css component ids by MatthiasWessendorf
One thing you could also promote is to stick to classes for styling--
the 37Signals guys do this, leaving identifiers up to server-side code
and promoting re-use of content.
Matthias Wessendorf wrote:
damn,
just tested. Firefox shows the div as green, but IE not.
thanks for pointing it out, I just updated the wiki.
On 4/20/06, Martin Marinschek [EMAIL PROTECTED] wrote:
That only works for Firefox, though. Not for IE, afaik.
regards,
Martin
On 4/20/06, Apache Wiki [EMAIL PROTECTED] wrote:
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Myfaces Wiki for
change notification.
The following page has been changed by MatthiasWessendorf:
http://wiki.apache.org/myfaces/css_component_ids
New page:
Since JSF's NamingContainer's cause rendered ids like foo:bar, here is
described howto work around for CSS.
You just need to use a backslash to escape the colon
{{{
style
div#foo { background-color:red}
div#foo\:bar { background-color:green}
/style
}}}
Rendered markup by a component
{{{
div id=fooFoo/div
div id=foo:barFoo:Bar/div
}}}
Note, that JSF is not incompatible to CSS
BTW. the standard naming container components are:
* h:form
* f:subview
* h:dataTable
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
Matthias Wessendorf
Aechterhoek 18
48282 Emsdetten
http://jroller.com/page/mwessendorf
mwessendorf-at-gmail-dot-com
--
--
Sent from my FrankenBerry Wireless Handheld
Re: [Myfaces Wiki] Update of css component ids by MatthiasWessendorf
Yes, of course, style classes are an option.
But believe it or not, you can't use style classes everywhere. There
are CSS constructs, where it's just not possible to use classes, eg.
when you need to do subselects.
If you add to this the necessity to work with external designers,
you're out of luck.
regards,
Martin
On 4/20/06, Jacob Hookom [EMAIL PROTECTED] wrote:
One thing you could also promote is to stick to classes for styling--
the 37Signals guys do this, leaving identifiers up to server-side code
and promoting re-use of content.
Matthias Wessendorf wrote:
damn,
just tested. Firefox shows the div as green, but IE not.
thanks for pointing it out, I just updated the wiki.
On 4/20/06, Martin Marinschek [EMAIL PROTECTED] wrote:
That only works for Firefox, though. Not for IE, afaik.
regards,
Martin
On 4/20/06, Apache Wiki [EMAIL PROTECTED] wrote:
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Myfaces Wiki for
change notification.
The following page has been changed by MatthiasWessendorf:
http://wiki.apache.org/myfaces/css_component_ids
New page:
Since JSF's NamingContainer's cause rendered ids like foo:bar, here is
described howto work around for CSS.
You just need to use a backslash to escape the colon
{{{
style
div#foo { background-color:red}
div#foo\:bar { background-color:green}
/style
}}}
Rendered markup by a component
{{{
div id=fooFoo/div
div id=foo:barFoo:Bar/div
}}}
Note, that JSF is not incompatible to CSS
BTW. the standard naming container components are:
* h:form
* f:subview
* h:dataTable
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
Matthias Wessendorf
Aechterhoek 18
48282 Emsdetten
http://jroller.com/page/mwessendorf
mwessendorf-at-gmail-dot-com
--
--
Sent from my FrankenBerry Wireless Handheld
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [Myfaces Wiki] Update of MyFacesExtensionsFilter by MarioIvankovits
On 4/7/06, Apache Wiki [EMAIL PROTECTED] wrote: The following page has been changed by MarioIvankovits: http://wiki.apache.org/myfaces/MyFacesExtensionsFilter New page: = MyFaces Extensions Filter = Mario, Rather than trying to maintain two separate pages that provide the same information, I'd suggest you update the MyFacesExtensionsFilter web page and have the wiki point to that page instead. End-users don't need to be editing documentation on the MyFacesExtensionsFilter anyways. http://myfaces.apache.org/tomahawk/extensionsFilter.html
Re: [Myfaces Wiki] Update of MyFacesExtensionsFilter by MarioIvankovits
Hi! http://myfaces.apache.org/tomahawk/extensionsFilter.html Thanks alot, I searched a page but didnt find it - shame on me - I'll change it. Ciao, Mario
Re: [Myfaces Wiki] Update of Top 10 Questions by Dennis Byrne
On 3/17/06, Apache Wiki [EMAIL PROTECTED] wrote: The following page has been changed by Dennis Byrne: http://wiki.apache.org/myfaces/Top_10_Questions Hey Dennis. Why a new page? Why not add them to the FAQ Wiki page? I don't see any advantage to having two FAQs -Mike
Re: [Myfaces Wiki] Update of
Man, I must have looked right past that. I move the new info over later today. Thanks. Dennis Byrne -Original Message- From: Mike Kienenberger [mailto:[EMAIL PROTECTED] Sent: Friday, March 17, 2006 09:54 AM To: 'MyFaces Development' Subject: Re: [Myfaces Wiki] Update of Top 10 Questions by Dennis Byrne On 3/17/06, Apache Wiki [EMAIL PROTECTED] wrote: The following page has been changed by Dennis Byrne: http://wiki.apache.org/myfaces/Top_10_Questions Hey Dennis. Why a new page? Why not add them to the FAQ Wiki page? I don't see any advantage to having two FAQs -Mike
Re: [Myfaces Wiki] Update of IDAssignment by StevePeterson
Why? Can you explain reasons to do so? I don't think so, exept for some special reasons (javascript access etc.) there is IMO no sense have ids on all those components. Regards, Volker Apache Wiki wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Myfaces Wiki for change notification. The following page has been changed by StevePeterson: http://wiki.apache.org/myfaces/IDAssignment New page: It's a Good Thing to ensure that there are IDs present the following JSF tags: * anything that's a NamingContainer * PanelNavigationMenu * DataTable * NewspaperTable * Columns * Form * Tree * elements that are form fields * any sort of input field * anything that is a button * elements that send commands -- 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.
Re: Myfaces Wiki Update of Building With Maven by MikeKienenberger
Hi! It looks like this is not possible, at least I dont see how to do it. What will be possible is to add myfaces-shared-impl-2.0.0-SNAPSHOT.jar (the classes) to the classpath and attach myfaces-shared-impl-2.0.0-SNAPSHOT-sources.jar as source to it. Yes, that's exactly what I do (ie. the new idea-plugin does) in IDEA. So with eclipse this is possible too then, maybe the maven-eclipse-plugin need some handwork ... In either case, you will have multiple independent versions of these classes in your IDE. The problem is due to the different package names. What do you mean by independent? I meant with independent, the IDE cant help as it sees three different classes. The way may be painful in some points but I'm sure it's worth the only single drawback we have now: We cannot do IDE-supported refactoring of a shared class. Never thought that price will be worth it, but hey: I trust you :-) I am pretty sure you wouldnt have done it if there were another way. So - at all - thanks for your (and all the mavenizers here ;-) ) hard work! Ciao, Mario
Re: Myfaces Wiki Update of Building With Maven by MikeKienenberger
Maybe we can have an optional ant script to build the jars locally for users who need them for IDE purposes? Sean On 3/1/06, Manfred Geiler [EMAIL PROTECTED] wrote: Mario, Mike, Is there no easy way to add a jar as Source in eclipse? If yes, it would be better to add myfaces-shared-impl-2.0.0-SNAPSHOT-sources.jar and myfaces-shared-tomahawk-2.0.0-SNAPSHOT-sources.jar instead of those mutable target/refactored-shared-sources dirs. That's what I do in IDEA. And the new idea-plugin does this even automatically. Manfred On 3/1/06, Apache Wiki [EMAIL PROTECTED] wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Myfaces Wiki for change notification. The following page has been changed by MikeKienenberger: http://wiki.apache.org/myfaces/Building_With_Maven The comment on the change is: Updated eclipse instructions. Thanks to Mario for figuring it out. -- I didn't have to do anything else to have everything working, but it's possible that some setup carried over from earlier attempts to import MyFaces (like the maven2 plugin and M2_REPO eclipse variable). Once all of the projects were imported, I moved them all into a workspace group called JSF to keep everything together. Thanks to Sean and Werner for doing all of the hard work to figure this out. --mkienenb + = Eclipse update 2006-03-01 = + + Starting with the 2006-03-01 creation of the myfaces-shared-impl and myfaces-shared-tomahawk, there are three additional steps needed. Hopefully these issues will be resolved soon. + + * Select the myfaces-shared-impl project, right-click to properties, choose Java Build Path and the Source tab. Add Folder myfaces-shared-impl/target/refactored-shared-sources/main/java to the build path. + * Select the myfaces-shared-tomahawk project, right-click to properties, choose Java Build Path and the Source tab. Add Folder myfaces-shared-tomahawk/target/refactored-shared-sources/main/java to the build path. + * Select the tomahawk-sandbox project, right-click to properties, choose Java Build Path and the Projects tab. Add Project myfaces-shared-tomahawk to the build path. +
Re: Myfaces Wiki Update of Building With Maven by MikeKienenberger
Hi Manfred! Is there no easy way to add a jar as Source in eclipse? It looks like this is not possible, at least I dont see how to do it. What will be possible is to add myfaces-shared-impl-2.0.0-SNAPSHOT.jar (the classes) to the classpath and attach myfaces-shared-impl-2.0.0-SNAPSHOT-sources.jar as source to it. But this makes no difference to the way it is now. I konw IDEA, but what is different to attach the -source.jars instead of the directories? In either case, you will have multiple independent versions of these classes in your IDE. The problem is due to the different package names. Sorry for being ignorant, but - could you please direct me to the post where I can read why this all was necessary? My problem is, that I have to do something with the AddResource et al stuff. It is nearly impossible to refactor like the way it is now as the same AddResource is available in three packages and I have to change it in the package which is NOT used in any package. On the other hand Martin told me that we have to move the tomahawk stuff out of shared-core and thus this limitation (at least for my current pain) will go away :-) Ciao, Mario
Re: [Myfaces Wiki] Update of MyFaces Developer Notes by schof
Sean, is there an important reason for not having these svn macros? Manfred On 2/22/06, Apache Wiki [EMAIL PROTECTED] wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Myfaces Wiki for change notification. The following page has been changed by schof: http://wiki.apache.org/myfaces/MyFaces_Developer_Notes -- /** * Very detailed description goes here... ;-) * + * @author Bug Rogers - * @author Bug Rogers (latest modification by $Author$) - * @version $Revision$ $Date$ */ }}}
Re: [Myfaces Wiki] Update of MyFaces Developer Notes by schof
We stopped using them a while ago. SVN keeps track of who last modified etc. In fact, SVN tells you who last modified what line (svn blame). A while back I seem to recall us deciding that since SVN is keeeping track of all of this there was no need to keep up the practice. Sean On 2/22/06, Manfred Geiler [EMAIL PROTECTED] wrote: Sean, is there an important reason for not having these svn macros? Manfred On 2/22/06, Apache Wiki [EMAIL PROTECTED] wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Myfaces Wiki for change notification. The following page has been changed by schof: http://wiki.apache.org/myfaces/MyFaces_Developer_Notes -- /** * Very detailed description goes here... ;-) * + * @author Bug Rogers - * @author Bug Rogers (latest modification by $Author$) - * @version $Revision$ $Date$ */ }}}
Re: [Myfaces Wiki] Update of MyFaces Developer Notes by schof
ok, fine. It also seems to work sometimes and sometimes not. I recently checked in two classes. One had the last modified and revision updated one not. Curious. Ok, let's get rid of these. Manfred On 2/22/06, Sean Schofield [EMAIL PROTECTED] wrote: We stopped using them a while ago. SVN keeps track of who last modified etc. In fact, SVN tells you who last modified what line (svn blame). A while back I seem to recall us deciding that since SVN is keeeping track of all of this there was no need to keep up the practice. Sean On 2/22/06, Manfred Geiler [EMAIL PROTECTED] wrote: Sean, is there an important reason for not having these svn macros? Manfred On 2/22/06, Apache Wiki [EMAIL PROTECTED] wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Myfaces Wiki for change notification. The following page has been changed by schof: http://wiki.apache.org/myfaces/MyFaces_Developer_Notes -- /** * Very detailed description goes here... ;-) * + * @author Bug Rogers - * @author Bug Rogers (latest modification by $Author$) - * @version $Revision$ $Date$ */ }}}
Re: [Myfaces Wiki] Update of MyFaces Developer Notes by schof
$Rev$ does the trick ;-) On 2/22/06, Manfred Geiler [EMAIL PROTECTED] wrote: ok, fine. It also seems to work sometimes and sometimes not. I recently checked in two classes. One had the last modified and revision updated one not. Curious. Ok, let's get rid of these. Manfred On 2/22/06, Sean Schofield [EMAIL PROTECTED] wrote: We stopped using them a while ago. SVN keeps track of who last modified etc. In fact, SVN tells you who last modified what line (svn blame). A while back I seem to recall us deciding that since SVN is keeeping track of all of this there was no need to keep up the practice. Sean On 2/22/06, Manfred Geiler [EMAIL PROTECTED] wrote: Sean, is there an important reason for not having these svn macros? Manfred On 2/22/06, Apache Wiki [EMAIL PROTECTED] wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Myfaces Wiki for change notification. The following page has been changed by schof: http://wiki.apache.org/myfaces/MyFaces_Developer_Notes -- /** * Very detailed description goes here... ;-) * + * @author Bug Rogers - * @author Bug Rogers (latest modification by $Author$) - * @version $Revision$ $Date$ */ }}} -- Matthias Wessendorf Zülpicher Wall 12, 239 50674 Köln http://www.wessendorf.net mwessendorf-at-gmail-dot-com
Re: [Myfaces Wiki] Update of MyFaces Developer Notes by schof
I just don't think its necessary regardless of whether it works. If you want to leave them that's ok but I think its overkill and makes the code slightly longer and more difficult to read. I wouldn't be in a hurry to remove them - just whenever we spot one and we're committing anyways. Sean On 2/22/06, Manfred Geiler [EMAIL PROTECTED] wrote: Maybe, but also the $Author$ was changed in one case and not in the other case. Manfred On 2/22/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: $Rev$ does the trick ;-) On 2/22/06, Manfred Geiler [EMAIL PROTECTED] wrote: ok, fine. It also seems to work sometimes and sometimes not. I recently checked in two classes. One had the last modified and revision updated one not. Curious. Ok, let's get rid of these. Manfred On 2/22/06, Sean Schofield [EMAIL PROTECTED] wrote: We stopped using them a while ago. SVN keeps track of who last modified etc. In fact, SVN tells you who last modified what line (svn blame). A while back I seem to recall us deciding that since SVN is keeeping track of all of this there was no need to keep up the practice. Sean On 2/22/06, Manfred Geiler [EMAIL PROTECTED] wrote: Sean, is there an important reason for not having these svn macros? Manfred On 2/22/06, Apache Wiki [EMAIL PROTECTED] wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Myfaces Wiki for change notification. The following page has been changed by schof: http://wiki.apache.org/myfaces/MyFaces_Developer_Notes -- /** * Very detailed description goes here... ;-) * + * @author Bug Rogers - * @author Bug Rogers (latest modification by $Author$) - * @version $Revision$ $Date$ */ }}} -- Matthias Wessendorf Zülpicher Wall 12, 239 50674 Köln http://www.wessendorf.net mwessendorf-at-gmail-dot-com
