Re: Bean Validation?
Yep, it was just the wordings that confused me (maybe because I'm not a native English speaker). I'm almost finished now. It's not that difficult once it's clear... /Jan-Kees 2009/7/9 Gerhard Petracek gerhard.petra...@gmail.com: the parameters you have to consider are: 1) javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL 2) javax.faces.VALIDATE_EMPTY_FIELDS 3) javax.faces.validator.DISABLE_DEFAULT_BEAN_VALIDATOR *_PARAM_NAME are specific variable names of mojarra. anyway, the spec. is quite clear. imo 2) just helps to avoid backward compatibility issues. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2009/7/9 Matthias Wessendorf mwessend...@gmail.com Sent from my iPod. On 09.07.2009, at 21:26, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: Hmm, I'm getting closer. I misunderstood the indenting of the bullets in the JavaDocs. The first bullet explains it. But the second bullet still looks silly (the part where VALIDATE_EMPTY_FIELDS_PARAM_NAME is explained). It says something about the system being directed to validate empty fields, and then it explains what to do with VALIDATE_EMPTY_FIELDS_PARAM_NAME. These two sentences seem to be telling the same thing. I suppose the second sentence is an in-depth explanation of the first? Feel free to add better javadoc for myfaces ;) Regards, Jan-Kees Ps. Is it allowed to quote JavaDocs on the mailinglist? That would I'd say so make explaining problems easier, but I can remember a discussion about copying JavaDocs to source code... :-) That is _totally_ different ;) 2009/7/9 Gerhard Petracek gerhard.petra...@gmail.com: hi jan-kees, jsf-validators (if present) are invoked in any case. that means: - bv is not available - everything works as usual - bv is available - a default validator gets added (see the new default-validator mechanism) which delegates to bv. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2009/7/9 Jan-Kees van Andel jankeesvanan...@gmail.com Hey, I'm currently implementing the JSF 2.0 changes in UIInput.validateValue() for MyFaces, but the descriptions in the spec seem odd. When I'm reading the PDF, it says that when Bean Validation is enabled, during the RENDER RESPONSE phase, every UIInput gets a javax.faces.Bean Validator attached to it. Then, on the other hand, when I read the JavaDocs for UIInput.validateValue(), I see the validation process with regards to Bean Validation. The second step (described by the JavaDocs for validateValue) don't make much sense to me. The way I understand it, there are two issues with the described approach: 1 Duplication, since Bean Validators are only attached components when Bean Validation is present. The validateValue method can piggyback on this fact and just follow the old mechanism. 2 Backwards compatibility when Bean Validation is not present in the container. In the JavaDocs for validateValue, I don't see that normal Validators are called when Bean Validation is not present in the container or when it it explicitly turned off. Is this an error in the spec or am I reading it the wrong way? What's your opinion? Regards, Jan-Kees
Re: MyFaces Core + Trinidad + Facelets in OSGi container
Hi again, Hope you have recovered and all is well. Thanks, I'm fine at the moment. :-D Here you are talking about using Facelets as a bundle, which is another story. My mail referred to modifications to MyFaces Core and Trinidad. My expression some modifications is related to MyFaces Core and Trinidad, not Facelets. I'm not sure what you mean with h:form is a built-in Facelets component? I assume that you mean Facelets needs a way to parse taglibs from other bundles like Myfaces Core and Trinidad. Just a short summary of the way I deal with Facelets. First, I didn't find a bundled version for Facelets version 1.1.14. So I re-package it myself adding the necessary metadata. Neither have I changed anything about Facelets, but somehow one has to adapt its usage in an OSGi container, because it won't work without. However, if I'm not mistaken you are using Facelets as a bundle since you've repackaged it in order to add the necessary metadata, but nevermind. Facelets uses the ContextClassLoader quite often. Luckily, there are well defined entry points into the Facelets bundle which is the FaceletViewHandler. I wrote a wrapper for FaceletViewHandler which sets the ContextClassLoader of the current thread to an appropriate bundle classloader. Hence, resources are loaded through this bundle classloader. Okay, that's something I've missed so far, however, as I've already mentioned there is another problem. Even if Facelets uses the correct bundle classloader it won't find any taglibs because of the resource URL format. I don't know if this is standard OSGi behaviour or not, but resources within an OSGi bundle start with bundle:// instead of jar:// which Facelets doesn't recognize and hence doesn't parse (at least that's the case for Apache Felix). That's what I've meant by saying that those built-in components didn't work for me as Facelets wasn't even able to parse its internal taglib files and so the HTML output contained non-processed h:form tags and so on. Class loading for beans is done through the bundle classloader. If you declare your bean packages properly in your MANIFEST.MF this class loader will find it. Let's clarify this, please. First of all I assume that there are separate bundles for the MyFaces API, the MyFaces implementation and your web application (Facelets, etc. doesn't matter in this case). The MyFaces implementation bundle is responsible for instantiating the beans, but which bundle classloader are you talking about then? - The web application bundle classloader: During start-up the web application bundle somehow initializes MyFaces and in the course of this the web application somehow injects its own bundle classloader to, among others, the managed bean facility so that it has got access to the bean classes. However, if that would be the case, there's no need to declare anything in the manifest file, hence I doubt that you've chosen this approach. If I'm mistaken, please feel free to correct me, then we can discuss this approach in more detail (Btw. I've chosen this approach). - The MyFaces implementation bundle classloader: The managed bean facility, again amongst others, uses the bundle classloader of its own bundle. In doing so it has got access only to the classes within the implementation bundle - which doesn't help at all regarding managed beans - and to packages being exported by other bundles. That would explain your need for declaring bean packages properly in the manifest file. However, again, if I'm not mistaken exporting packages is not sufficient as MyFaces will have to import them as well. Are you suggesting that web application developers have to customize the MyFaces implementation bundle by adapting the imports every time they create new managed beans? - Equinox as OSGi container - HTTP service is provided by Tomcat. Could also be Jetty but I didn't manage to setup a working environment in combination with JSP (though PAX web apparently provides one). - I use Spring DM tools for WAR deployment. A similar solution exists from PAX Web for Jetty. So, you don't use the OSGi HTTP service API [1] at all? Seems that your OSGi environment is capable of parsing a web.xml file, which I think isn't standard behaviour. However, I think it's acceptable if it works for major OSGi containers (haven't tried Equinox and the Spring DM tools yet). Additionally it seems that you're more or less talking about the deployment of a WAR file, i.e. the whole web application consists of a single archive file with the only difference that you don't have to embed the dependencies within it as OSGi is responsible for resolving dependencies. However, I've intended to adapt MyFaces in a way so that it's possible to split even the web application into separate bundles, where each bundle is able to define its own JSF configuration file, etc. In doing so, each bundle provides just a part of the resulting web application, which means that you can reuse these parts in
[jira] Commented: (TRINIDAD-1480) XMLMenuModel resourceBundle does not use f:view (viewRoot) locale
[ https://issues.apache.org/jira/browse/TRINIDAD-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12729631#action_12729631 ] Jasper de Vries commented on TRINIDAD-1480: --- Hi Matthias, We have a test application, but I haven't found the time to review it. I'll try to test it myself soon. Is a WAR file ok for you? Regards, Jasper XMLMenuModel resourceBundle does not use f:view (viewRoot) locale - Key: TRINIDAD-1480 URL: https://issues.apache.org/jira/browse/TRINIDAD-1480 Project: MyFaces Trinidad Issue Type: Bug Environment: Tomcat 6.0, Trinidad 1.2.11, JDK 1.6.0_07, Windows XP SP2 and Ubuntu 8.04 Reporter: Jasper de Vries XMLMenuModel resourceBundle does not use f:view (viewRoot) locale. We have multiple languages defined in our faces-config. Our viewRoot locale works as expected. XMLMenuModel resourceBundle seems to be using the OS locale. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1530) The onsubmit function of tr:form is called after a client side validation error occurs and the form is not submitted.
[ https://issues.apache.org/jira/browse/TRINIDAD-1530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf updated TRINIDAD-1530: - Resolution: Fixed Fix Version/s: 1.2.10-plugins Assignee: Matthias Weßendorf Status: Resolved (was: Patch Available) The onsubmit function of tr:form is called after a client side validation error occurs and the form is not submitted. - Key: TRINIDAD-1530 URL: https://issues.apache.org/jira/browse/TRINIDAD-1530 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.11-core Reporter: Bernd Bohmann Assignee: Matthias Weßendorf Fix For: 1.2.10-plugins Attachments: TRINIDAD-1530.patch Documentation of the onsubmit attribute of tr:form: Javascript code to be called when the form is submitted. I don't expect that this code is called if a client side validation error occurs and the form is not submitted. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1107) tr:table - scrolling of content
[
https://issues.apache.org/jira/browse/TRINIDAD-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12729637#action_12729637
]
Cedric Durmont commented on TRINIDAD-1107:
--
The source code ( DesktopTableRenderer.java ) mentions an undocumented 'height'
attribute.
What is intriguing is that it looks like this attribute triggers portions of
code that make the table scrollable, including the use of thead/tbody and
numerous IE-centric hacks.
Maybe there's a good reason why this is a hidden/disabled feature, but
otherwise it could be a nice addition to Trinidad, with minimum effort :o)
I'm fairly sure this is too good to be true, but maybe someone could check it,
just to be sure...
Chosen extracts from DesktopTableRenderer.java :
protected void findTypeConstants(FacesBean.Type type)
[...]
_heightKey = type.findKey(height);
[...]
protected void renderTableContent(...)
[...]
if ((height != null) isIE(arc))
{
[...]
writer.startElement(div, null);
// IE in standards compliant mode needs the width:100% for the vertical
// scroll bars to appear:
writer.writeAttribute(style,
overflow:auto;overflow-x:hidden;width:100%;height:+height, null);
[...]
tr:table - scrolling of content
---
Key: TRINIDAD-1107
URL: https://issues.apache.org/jira/browse/TRINIDAD-1107
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Components
Reporter: Gerhard Petracek
if a table is too long and it comes to page scrollbars, you cannot see the
header all the time (e.g. after scrolling to the bottom of the table).
so we need a scrollbar for the table body.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1529) Enhanced support for tag doc generation to support screenshots and better formatting of example code snippets
[ https://issues.apache.org/jira/browse/TRINIDAD-1529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12729645#action_12729645 ] Andrew Robinson commented on TRINIDAD-1529: --- plugins2.patch does not compile when applied to the trunk (https://svn.apache.org/repos/asf/myfaces/trinidad-maven/trunk): [INFO] Compiling 1 source file to /home/anrobins/development/maven-trinidad/trunk/maven-tagdoc-plugin/target/classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /home/anrobins/development/maven-trinidad/trunk/maven-tagdoc-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/tagdoc/TagdocReport.java:[1110,13] cannot find symbol symbol : method hasScreenshots() location: class org.apache.myfaces.trinidadbuild.plugin.faces.parse.AbstractTagBean /home/anrobins/development/maven-trinidad/trunk/maven-tagdoc-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/tagdoc/TagdocReport.java:[1122,24] cannot find symbol symbol : method screenshots() location: class org.apache.myfaces.trinidadbuild.plugin.faces.parse.AbstractTagBean Enhanced support for tag doc generation to support screenshots and better formatting of example code snippets - Key: TRINIDAD-1529 URL: https://issues.apache.org/jira/browse/TRINIDAD-1529 Project: MyFaces Trinidad Issue Type: Improvement Components: Plugins Reporter: Maria Kaval Attachments: plugins.patch, plugins2.patch This JIRA is to support having a tag to mark screenshots within the tag doc xml. This will ensure that all pages have the same formatting for screenshots (e.g. the header text will be the same, one can easily skin the section, and the screenshots will appear at the same section of the tag doc, etc). I suggest modifying the plugin to understand: mfp:screenshot mfp:image HERE YOU PLACE YOUR IMG TAG/mfp:image mfp:description HERE YOU PLACE THE CAPTION THAT GOES WITH YOUR IMG TAG /mfp:description /mfp:screenshot A real-world example would look like: mfp:screenshot mfp:image ![CDATA[ img src=../images/inputDate.png alt=inputDate screenshot/img ]] /mfp:image mfp:description inputDate component as shown when rendered in a simple form /mfp:description /mfp:screenshot This JIRA also covers modifying the plugin for how it generates the mfp:example tag. Currently mfp:example outputs bold text at the end of the description with Example:. The issue is that depending on what text is towards the end of the long description, sometimes it appears the Example is for something very specific to that page instead of generic to the component. I've therefore modifed the plugin to create a new section when mfp:example tag is encountered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] SVN structure change (was: Re: [MyFaces CORE] SVN layout (was: Re: [source control] git and the ASF ...))
+1 On Thu, Jul 9, 2009 at 12:20 AM, Manfred Geilermanfred.gei...@gmail.com wrote: +1 thanks leonardo --Manfred On Thu, Jul 9, 2009 at 04:24, Leonardo Uribelu4...@gmail.com wrote: Hi Myfaces core 1.2.7 and 1.1.7 were released. So we can close this vote and make the necessary changes. Just to note it, after reading all previous emails the suggested layout is this: /trunk - 2.0 /branches/1.1.x /branches/1.2.x If no objections I'll do the necessary changes on svn (note that to do this change we need to update nightly build configuration and I can't help with that). regards Leonardo Uribe 2009/5/28 Simon Lessard simon.lessar...@gmail.com +1 On Thu, May 28, 2009 at 2:23 AM, Matthias Wessendorf mat...@apache.org wrote: sure! On Thu, May 28, 2009 at 6:34 AM, Leonardo Uribe lu4...@gmail.com wrote: +1, but just a small suggestion. Right now I'm running the necessary steps for release myfaces core 1.2.7, core 1.1.7, so I would like if it is possible to delay this change after the release. regards Leonardo Uribe 2009/5/27 Cagatay Civici cagatay.civ...@gmail.com +1 for sure On Wed, May 27, 2009 at 8:53 AM, Bruno Aranda brunoara...@gmail.com wrote: +1 sounds good to me 2009/5/27 Matthias Wessendorf mat...@apache.org: so, there are no objections in making the MyFaces 2.0 efforts become trunk ? -Matthias On Fri, May 22, 2009 at 9:10 PM, Bernd Bohmann bernd.bohm...@atanion.com wrote: Hello, +1 I would prefer /trunk - 2.0 /branches/myfaces-1.1.x /branches/myfaces-1.2.x because we are not using cvs anymore and the path already contains http://svn.apache.org/repos/asf/myfaces/core/ maybe we can omit the 'myfaces' in the branch name. Regards Bernd On Fri, May 22, 2009 at 5:27 PM, Matthias Wessendorf mat...@apache.org wrote: actually, I agree with Bernd. For the following layout: /trunk - 2.0 /branches/myfaces_1_1_x /branches/myfaces_1_2_x Two reasons for way making 2.0 trunk: -most current development is on-going in 2.0 (new spec) -most commits are going to the 2.0 branch (so, let's make it trunk) So, I am +1 on the above svn layout -Matthias On Sat, May 16, 2009 at 1:04 PM, Matthias Wessendorf mat...@apache.org wrote: from Bernd, on a different thread: Hello, I would suggest following layout 1.1.x branch/1.1.x 1.2.x branch/1.2.x 2.0.x trunk because the 2.0.x version is in development the other branches are only in bugfix state. On Fri, May 15, 2009 at 1:13 PM, Werner Punz werner.p...@gmail.com wrote: Matthias Wessendorf schrieb: Hi, ... Ok, I filed this: https://issues.apache.org/jira/browse/INFRA-2053 maybe we should also think about making the JSF 1.1.x stuff a branch ... (since we already work on 2.0.x) what do people think if the 1.2 stuff becomes trunk And the following efforts are on a branch: -2.0.x -1.1.x +1 -- 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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (TRINIDAD-1505) Encoding on IE
[ https://issues.apache.org/jira/browse/TRINIDAD-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12729648#action_12729648 ] Bernhard Seebass commented on TRINIDAD-1505: The problem was introduced in SVN-Revision 713294 by changes in org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl TrinidadFilterImpl line 123 (new):String noJavaScript = request.getParameter(XhtmlConstants.NON_JS_BROWSER); The call getParameter() is executed before the correct encoding has been set to org.apache.tomcat.util.http.Parameters (in org.apache.coyote.Request). Therefore the default encoding ISO-8859-1 is applied which breaks handling of UTF-8 encoded characters in submitted forms. Encoding on IE -- Key: TRINIDAD-1505 URL: https://issues.apache.org/jira/browse/TRINIDAD-1505 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.11-core Environment: Apache Tomcat 6.0.18 Sun Win32 JDK 1.6.14u Reporter: João Rui Barradas Peixoto On IE (my application uses PPR) when you try to insert some characters (using simple and multiple lines tr:inputtext ) different from English encoding you will get those characters incorrectly shown . I have returned to version 1.2.10 from version 1.2.11 and it have solved my problem. This problem doesn't occurs on Firefox. Any additional information help you need let me know please. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-1505) Encoding on IE
[ https://issues.apache.org/jira/browse/TRINIDAD-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf resolved TRINIDAD-1505. -- Resolution: Duplicate Assignee: Matthias Weßendorf this guy is already fixed: https://issues.apache.org/jira/browse/TRINIDAD-1430 a release will be out, soon Encoding on IE -- Key: TRINIDAD-1505 URL: https://issues.apache.org/jira/browse/TRINIDAD-1505 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.11-core Environment: Apache Tomcat 6.0.18 Sun Win32 JDK 1.6.14u Reporter: João Rui Barradas Peixoto Assignee: Matthias Weßendorf On IE (my application uses PPR) when you try to insert some characters (using simple and multiple lines tr:inputtext ) different from English encoding you will get those characters incorrectly shown . I have returned to version 1.2.10 from version 1.2.11 and it have solved my problem. This problem doesn't occurs on Firefox. Any additional information help you need let me know please. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
GAE/J and JSF
I ran into this: https://javaserverfaces.dev.java.net/nonav/rlnotes/1.2_13/changelog.html maybe we could do a similar thing w/ MyFaces as well ? -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: GAE/J and JSF
How many thread do we use to start MyFaces? To make it work in GAE we need only one thread, add facelets and the EL dependencies. That should work right? Bruno 2009/7/10 Matthias Wessendorf mat...@apache.org: I ran into this: https://javaserverfaces.dev.java.net/nonav/rlnotes/1.2_13/changelog.html maybe we could do a similar thing w/ MyFaces as well ? -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (TRINIDAD-1529) Enhanced support for tag doc generation to support screenshots and better formatting of example code snippets
[ https://issues.apache.org/jira/browse/TRINIDAD-1529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12729741#action_12729741 ] Andrew Robinson commented on TRINIDAD-1529: --- My bad, the reason it isn't working is that the patch isn't applying to the trunk: anrob...@anrobins-pc:~/development/maven-trinidad/trunk$ svn info Path: . URL: https://svn.apache.org/repos/asf/myfaces/trinidad-maven/trunk Repository Root: https://svn.apache.org/repos/asf Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 793056 Node Kind: directory Schedule: normal Last Changed Author: matzew Last Changed Rev: 782175 Last Changed Date: 2009-06-05 18:45:28 -0600 (Fri, 05 Jun 2009) anrob...@anrobins-pc:~/development/maven-trinidad/trunk$ svn up At revision 793056. anrob...@anrobins-pc:~/development/maven-trinidad/trunk$ curl https://issues.apache.org/jira/secure/attachment/12413063/plugins2.patch | patch -p0 % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 12559 100 125590 0 7180 0 0:00:01 0:00:01 --:--:-- 9690 (Stripping trailing CRs from patch.) patching file maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/parse/AbstractTagBean.java Hunk #1 FAILED at 33. Hunk #2 FAILED at 52. Hunk #3 FAILED at 228. Hunk #4 FAILED at 345. 4 out of 4 hunks FAILED -- saving rejects to file maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/parse/AbstractTagBean.java.rej (Stripping trailing CRs from patch.) patching file maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/parse/FacesConfigParser.java (Stripping trailing CRs from patch.) patching file maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/parse/ScreenshotBean.java (Stripping trailing CRs from patch.) patching file maven-faces-plugin/src/main/resources/org/apache/myfaces/trinidadbuild/plugin/faces/resources/transform12.xsl (Stripping trailing CRs from patch.) patching file maven-tagdoc-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/tagdoc/TagdocReport.java Enhanced support for tag doc generation to support screenshots and better formatting of example code snippets - Key: TRINIDAD-1529 URL: https://issues.apache.org/jira/browse/TRINIDAD-1529 Project: MyFaces Trinidad Issue Type: Improvement Components: Plugins Reporter: Maria Kaval Attachments: plugins.patch, plugins2.patch This JIRA is to support having a tag to mark screenshots within the tag doc xml. This will ensure that all pages have the same formatting for screenshots (e.g. the header text will be the same, one can easily skin the section, and the screenshots will appear at the same section of the tag doc, etc). I suggest modifying the plugin to understand: mfp:screenshot mfp:image HERE YOU PLACE YOUR IMG TAG/mfp:image mfp:description HERE YOU PLACE THE CAPTION THAT GOES WITH YOUR IMG TAG /mfp:description /mfp:screenshot A real-world example would look like: mfp:screenshot mfp:image ![CDATA[ img src=../images/inputDate.png alt=inputDate screenshot/img ]] /mfp:image mfp:description inputDate component as shown when rendered in a simple form /mfp:description /mfp:screenshot This JIRA also covers modifying the plugin for how it generates the mfp:example tag. Currently mfp:example outputs bold text at the end of the description with Example:. The issue is that depending on what text is towards the end of the long description, sometimes it appears the Example is for something very specific to that page instead of generic to the component. I've therefore modifed the plugin to create a new section when mfp:example tag is encountered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: [jira] Commented: (TRINIDAD-1529) Enhanced support for tag doc generation to support screenshots and better formatting of example code snippets
Ok,great, thanks Andrew for trying it out. If it had been a real bug, I would have been glad to catch it earlier rather than later! Jeanne, can you go ahead and commit the patch? Maria -Original Message- From: Andrew Robinson (JIRA) [mailto:d...@myfaces.apache.org] Sent: Friday, July 10, 2009 10:59 AM To: MARIA KAVAL Subject: [jira] Commented: (TRINIDAD-1529) Enhanced support for tag doc generation to support screenshots and better formatting of example code snippets [ https://issues.apache.org/jira/browse/TRINIDAD-1529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12729741#action_12729741 ] Andrew Robinson commented on TRINIDAD-1529: --- My bad, the reason it isn't working is that the patch isn't applying to the trunk: anrob...@anrobins-pc:~/development/maven-trinidad/trunk$ svn info Path: . URL: https://svn.apache.org/repos/asf/myfaces/trinidad-maven/trunk Repository Root: https://svn.apache.org/repos/asf Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 793056 Node Kind: directory Schedule: normal Last Changed Author: matzew Last Changed Rev: 782175 Last Changed Date: 2009-06-05 18:45:28 -0600 (Fri, 05 Jun 2009) anrob...@anrobins-pc:~/development/maven-trinidad/trunk$ svn up At revision 793056. anrob...@anrobins-pc:~/development/maven-trinidad/trunk$ curl https://issues.apache.org/jira/secure/attachment/12413063/plugins2.patch | patch -p0 % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 12559 100 125590 0 7180 0 0:00:01 0:00:01 --:--:-- 9690 (Stripping trailing CRs from patch.) patching file maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/parse/AbstractTagBean.java Hunk #1 FAILED at 33. Hunk #2 FAILED at 52. Hunk #3 FAILED at 228. Hunk #4 FAILED at 345. 4 out of 4 hunks FAILED -- saving rejects to file maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/parse/AbstractTagBean.java.rej (Stripping trailing CRs from patch.) patching file maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/parse/FacesConfigParser.java (Stripping trailing CRs from patch.) patching file maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/parse/ScreenshotBean.java (Stripping trailing CRs from patch.) patching file maven-faces-plugin/src/main/resources/org/apache/myfaces/trinidadbuild/plugin/faces/resources/transform12.xsl (Stripping trailing CRs from patch.) patching file maven-tagdoc-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/tagdoc/TagdocReport.java Enhanced support for tag doc generation to support screenshots and better formatting of example code snippets -- --- Key: TRINIDAD-1529 URL: https://issues.apache.org/jira/browse/TRINIDAD-1529 Project: MyFaces Trinidad Issue Type: Improvement Components: Plugins Reporter: Maria Kaval Attachments: plugins.patch, plugins2.patch This JIRA is to support having a tag to mark screenshots within the tag doc xml. This will ensure that all pages have the same formatting for screenshots (e.g. the header text will be the same, one can easily skin the section, and the screenshots will appear at the same section of the tag doc, etc). I suggest modifying the plugin to understand: mfp:screenshot mfp:image HERE YOU PLACE YOUR IMG TAG/mfp:image mfp:description HERE YOU PLACE THE CAPTION THAT GOES WITH YOUR IMG TAG /mfp:description /mfp:screenshot A real-world example would look like: mfp:screenshot mfp:image ![CDATA[ img src=../images/inputDate.png alt=inputDate screenshot/img ]] /mfp:image mfp:description inputDate component as shown when rendered in a simple form /mfp:description /mfp:screenshot This JIRA also covers modifying the plugin for how it generates the mfp:example tag. Currently mfp:example outputs bold text at the end of the description with Example:. The issue is that depending on what text is towards the end of the long description, sometimes it appears the Example is for something very specific to that page instead of generic to the component. I've therefore modifed the plugin to create a new section when mfp:example tag is encountered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1529) Enhanced support for tag doc generation to support screenshots and better formatting of example code snippets
[ https://issues.apache.org/jira/browse/TRINIDAD-1529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12729758#action_12729758 ] Andrew Robinson commented on TRINIDAD-1529: --- Trying again, the problem was that some java files were checked into SVN with windows new-line endings and the svn:eol-style was not set on the files. Enhanced support for tag doc generation to support screenshots and better formatting of example code snippets - Key: TRINIDAD-1529 URL: https://issues.apache.org/jira/browse/TRINIDAD-1529 Project: MyFaces Trinidad Issue Type: Improvement Components: Plugins Reporter: Maria Kaval Attachments: plugins.patch, plugins2.patch This JIRA is to support having a tag to mark screenshots within the tag doc xml. This will ensure that all pages have the same formatting for screenshots (e.g. the header text will be the same, one can easily skin the section, and the screenshots will appear at the same section of the tag doc, etc). I suggest modifying the plugin to understand: mfp:screenshot mfp:image HERE YOU PLACE YOUR IMG TAG/mfp:image mfp:description HERE YOU PLACE THE CAPTION THAT GOES WITH YOUR IMG TAG /mfp:description /mfp:screenshot A real-world example would look like: mfp:screenshot mfp:image ![CDATA[ img src=../images/inputDate.png alt=inputDate screenshot/img ]] /mfp:image mfp:description inputDate component as shown when rendered in a simple form /mfp:description /mfp:screenshot This JIRA also covers modifying the plugin for how it generates the mfp:example tag. Currently mfp:example outputs bold text at the end of the description with Example:. The issue is that depending on what text is towards the end of the long description, sometimes it appears the Example is for something very specific to that page instead of generic to the component. I've therefore modifed the plugin to create a new section when mfp:example tag is encountered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1529) Enhanced support for tag doc generation to support screenshots and better formatting of example code snippets
[ https://issues.apache.org/jira/browse/TRINIDAD-1529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson updated TRINIDAD-1529: -- Resolution: Fixed Fix Version/s: 1.2.10-plugins Status: Resolved (was: Patch Available) Applied patch after fixing the \r\n line endings Enhanced support for tag doc generation to support screenshots and better formatting of example code snippets - Key: TRINIDAD-1529 URL: https://issues.apache.org/jira/browse/TRINIDAD-1529 Project: MyFaces Trinidad Issue Type: Improvement Components: Plugins Reporter: Maria Kaval Fix For: 1.2.10-plugins Attachments: plugins.patch, plugins2.patch This JIRA is to support having a tag to mark screenshots within the tag doc xml. This will ensure that all pages have the same formatting for screenshots (e.g. the header text will be the same, one can easily skin the section, and the screenshots will appear at the same section of the tag doc, etc). I suggest modifying the plugin to understand: mfp:screenshot mfp:image HERE YOU PLACE YOUR IMG TAG/mfp:image mfp:description HERE YOU PLACE THE CAPTION THAT GOES WITH YOUR IMG TAG /mfp:description /mfp:screenshot A real-world example would look like: mfp:screenshot mfp:image ![CDATA[ img src=../images/inputDate.png alt=inputDate screenshot/img ]] /mfp:image mfp:description inputDate component as shown when rendered in a simple form /mfp:description /mfp:screenshot This JIRA also covers modifying the plugin for how it generates the mfp:example tag. Currently mfp:example outputs bold text at the end of the description with Example:. The issue is that depending on what text is towards the end of the long description, sometimes it appears the Example is for something very specific to that page instead of generic to the component. I've therefore modifed the plugin to create a new section when mfp:example tag is encountered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1531) window.external.AutoCompleteSaveForm throws an exception if using IE embedded in lotus notes
[ https://issues.apache.org/jira/browse/TRINIDAD-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann updated TRINIDAD-1531: Resolution: Fixed Fix Version/s: 1.2.12-core Status: Resolved (was: Patch Available) window.external.AutoCompleteSaveForm throws an exception if using IE embedded in lotus notes Key: TRINIDAD-1531 URL: https://issues.apache.org/jira/browse/TRINIDAD-1531 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.11-core Environment: lotus notes 6.0 IE 6.0 Reporter: Bernd Bohmann Assignee: Bernd Bohmann Priority: Minor Fix For: 1.2.12-core Attachments: error.JPG, TRINIDAD-1531.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1532) PPR Based Components Not Working in Windows Mobile 6
PPR Based Components Not Working in Windows Mobile 6 Key: TRINIDAD-1532 URL: https://issues.apache.org/jira/browse/TRINIDAD-1532 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.11-core Environment: Windows Mobile 6 Reporter: Mamallan Uthaman In windows mobile 6, PPR based components neither send any PPR request nor do a full page submit. Hence, all PPR based components (like pagination in tr:table) are currently not working in windows mobile 6. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2273) ClientBehaviorRenderer/ClientbehaviorBase TODOs
[ https://issues.apache.org/jira/browse/MYFACES-2273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Concini resolved MYFACES-2273. -- Resolution: Fixed Fix Version/s: 2.0.0-alpha ClientBehaviorRenderer/ClientbehaviorBase TODOs --- Key: MYFACES-2273 URL: https://issues.apache.org/jira/browse/MYFACES-2273 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Michael Concini Assignee: Michael Concini Priority: Minor Fix For: 2.0.0-alpha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: [jira] Updated: (TRINIDAD-1529) Enhanced support for tag doc generation to support screenshots and better formatting of example code snippets
Thank you very much for your assistance Andrew! Maria -Original Message- From: Andrew Robinson (JIRA) [mailto:d...@myfaces.apache.org] Sent: Friday, July 10, 2009 11:31 AM To: dev@myfaces.apache.org Subject: [jira] Updated: (TRINIDAD-1529) Enhanced support for tag doc generation to support screenshots and better formatting of example code snippets [ https://issues.apache.org/jira/browse/TRINIDAD-1529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson updated TRINIDAD-1529: -- Resolution: Fixed Fix Version/s: 1.2.10-plugins Status: Resolved (was: Patch Available) Applied patch after fixing the \r\n line endings Enhanced support for tag doc generation to support screenshots and better formatting of example code snippets -- --- Key: TRINIDAD-1529 URL: https://issues.apache.org/jira/browse/TRINIDAD-1529 Project: MyFaces Trinidad Issue Type: Improvement Components: Plugins Reporter: Maria Kaval Fix For: 1.2.10-plugins Attachments: plugins.patch, plugins2.patch This JIRA is to support having a tag to mark screenshots within the tag doc xml. This will ensure that all pages have the same formatting for screenshots (e.g. the header text will be the same, one can easily skin the section, and the screenshots will appear at the same section of the tag doc, etc). I suggest modifying the plugin to understand: mfp:screenshot mfp:image HERE YOU PLACE YOUR IMG TAG/mfp:image mfp:description HERE YOU PLACE THE CAPTION THAT GOES WITH YOUR IMG TAG /mfp:description /mfp:screenshot A real-world example would look like: mfp:screenshot mfp:image ![CDATA[ img src=../images/inputDate.png alt=inputDate screenshot/img ]] /mfp:image mfp:description inputDate component as shown when rendered in a simple form /mfp:description /mfp:screenshot This JIRA also covers modifying the plugin for how it generates the mfp:example tag. Currently mfp:example outputs bold text at the end of the description with Example:. The issue is that depending on what text is towards the end of the long description, sometimes it appears the Example is for something very specific to that page instead of generic to the component. I've therefore modifed the plugin to create a new section when mfp:example tag is encountered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1532) PPR Based Components Not Working in Windows Mobile 6
[ https://issues.apache.org/jira/browse/TRINIDAD-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamallan Uthaman updated TRINIDAD-1532: --- Status: Patch Available (was: Open) PPR Based Components Not Working in Windows Mobile 6 Key: TRINIDAD-1532 URL: https://issues.apache.org/jira/browse/TRINIDAD-1532 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.11-core Environment: Windows Mobile 6 Reporter: Mamallan Uthaman In windows mobile 6, PPR based components neither send any PPR request nor do a full page submit. Hence, all PPR based components (like pagination in tr:table) are currently not working in windows mobile 6. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2151) Make test work using shale test (changes in jsf 2.0 make it fail)
[ https://issues.apache.org/jira/browse/MYFACES-2151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-2151. - Resolution: Fixed Fix Version/s: 2.0.0-alpha Created myfaces-test20 layout and deployed on snapshot repo, so we can remove shale-test dependency. Make test work using shale test (changes in jsf 2.0 make it fail) - Key: MYFACES-2151 URL: https://issues.apache.org/jira/browse/MYFACES-2151 Project: MyFaces Core Issue Type: Task Components: JSR-314 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.0-alpha Attachments: ProvisionalTestSetup-2.patch, ProvisionalTestSetup.patch Some changes added in jsf 2.0 spec make some test using shale-test mock objects fail. The temporal solution is remove this test dependency and move some shale-test code to myfaces api test jar. Then, when we have a shale-test lib for jsf 2.0, remove this files and add the dependency again -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
