Re: redeploy myfaces website
Yes, it is really cool :) Thanks! Bruno On 25/03/2008, Matthias Wessendorf [EMAIL PROTECTED] wrote: really sexy looking website! thanks!!! -Matthias On Sat, Mar 22, 2008 at 2:05 PM, Gerald Müllan [EMAIL PROTECTED] wrote: It is online! Very well done guys; looks really great. cheers, Gerald On 3/22/08, Catalin Kormos [EMAIL PROTECTED] wrote: Hi Bernd, Thanks, i guess it will take some time until we see any change on the myfaces site. regards, Catalin On Sat, Mar 22, 2008 at 1:54 PM, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello Catalin, just added the myfaces-site-skin to the continuum build and forced a new site build on the continuum server. I don't know how the subproject sites are build. Regards Bernd Catalin Kormos schrieb: Could someone help me out with a redeploy of the MyFaces website? as i'm not exactly sure about the process involved here. I just committed the updated skin, and i also applied it on some of the projects, like, core, tomahawk, sandbox and orchestra. Thanks, Catalin Codebeat www.codebeat.ro -- Codebeat www.codebeat.ro -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: redeploy myfaces website
really sexy looking website! thanks!!! -Matthias On Sat, Mar 22, 2008 at 2:05 PM, Gerald Müllan [EMAIL PROTECTED] wrote: It is online! Very well done guys; looks really great. cheers, Gerald On 3/22/08, Catalin Kormos [EMAIL PROTECTED] wrote: Hi Bernd, Thanks, i guess it will take some time until we see any change on the myfaces site. regards, Catalin On Sat, Mar 22, 2008 at 1:54 PM, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello Catalin, just added the myfaces-site-skin to the continuum build and forced a new site build on the continuum server. I don't know how the subproject sites are build. Regards Bernd Catalin Kormos schrieb: Could someone help me out with a redeploy of the MyFaces website? as i'm not exactly sure about the process involved here. I just committed the updated skin, and i also applied it on some of the projects, like, core, tomahawk, sandbox and orchestra. Thanks, Catalin Codebeat www.codebeat.ro -- Codebeat www.codebeat.ro -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: redeploy myfaces website
Hello, just added the logo of the portlet bridge to the myfaces-site-skin. Is a trinidad logo available? And I would suggest following header Apache|MyFaces|Core|Trinidad|Tobago|Tomahawk|Orchestra|Portlet Bridge (no Sandbox every project has a sandbox no JSF 1.1-1.2) or Apache|MyFaces|Download|Mailing Lists (News archive makes no sense in the header) for the subprojects for example Tobago Apache|MyFaces|Tobago|Download|Mailing Lists I would suggest following banner on the main page MyFaces Logo| Apache Logo for the subprojects Subproject Logo or Name | MyFaces Logo We should include the conference banner on every page. I would like to place the banner on the left site of the Apache/MyFaces Logo. Regards Bernd Bruno Aranda schrieb: Yes, it is really cool :) Thanks! Bruno On 25/03/2008, Matthias Wessendorf [EMAIL PROTECTED] wrote: really sexy looking website! thanks!!! -Matthias On Sat, Mar 22, 2008 at 2:05 PM, Gerald Müllan [EMAIL PROTECTED] wrote: It is online! Very well done guys; looks really great. cheers, Gerald On 3/22/08, Catalin Kormos [EMAIL PROTECTED] wrote: Hi Bernd, Thanks, i guess it will take some time until we see any change on the myfaces site. regards, Catalin On Sat, Mar 22, 2008 at 1:54 PM, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello Catalin, just added the myfaces-site-skin to the continuum build and forced a new site build on the continuum server. I don't know how the subproject sites are build. Regards Bernd Catalin Kormos schrieb: Could someone help me out with a redeploy of the MyFaces website? as i'm not exactly sure about the process involved here. I just committed the updated skin, and i also applied it on some of the projects, like, core, tomahawk, sandbox and orchestra. Thanks, Catalin Codebeat www.codebeat.ro -- Codebeat www.codebeat.ro -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: redeploy myfaces website
I've noticed some other inconsistent stuff that needs to be fixed. I think the most important is the issue I raised before: what should the top menu bar look like for sub-projects. If you look at the core modules for the moment, those links are all specific to myfaces as a whole, not to the subproject currently being viewed. I would expect overview to take me to the overview for the project I am currently viewing, not to the myfaces overview. Also, while we do *currently* have a shared downloads page for all projects, and a common set of mailing lists for all projects I don't think this will always be the case. So I don't think the download or mailing list links are appropriate here. What I've done for tomahawk for example is just to have Apache and MyFaces links, and nothing else. I think this is nicer. Obviously, it would be even nicer to be consistent across all projects. core11/core12: * icons need updating Trinidad: * has the faces icon on the right, not on the left. * has no title in the first block of the left-hand pane. * has no list-of-myfaces-projects in the left-hand pane. This might actually be nicer than replicating the list-of-projects on each page (people can always go up to the main myfaces site) but we should be consistent. * has no link to apache in the top menu bar, just MyFaces * has the foundation section at the top, not the bottom * date-published format is -mm-dd, not dd MMM Regards, Simon
Re: [Trinidad] implementing tabIndex attributes on select components
Blake, Andrew - I preferred to wait until we had a good set of concrete focus management use cases. This was my main question after reading the Andrew's wiki page - I want to be sure to understand the use cases that we are trying to address before moving forward with a solution. Many use cases can be addressed by simpler solutions, eg: - The login page initial focus case can be addressed by tr:document initialFocusId. - The skip advertising/chrome use case can be addressed by improved skip link support. - The newspaper-style column-based tab traversal can be addressed by using multi-column panelFormLayouts, or similar dom structures. We should at least consider whether such solutions meet our requirements before deciding to add new functionality. Andy
Re: redeploy myfaces website
Hey Bernd, Where did you get the logo from? I skinned the portlet bridge graphic yesterday and I had to modify some of the white-space to make it look right. Right now the bridge is using it's own logo, but I can certainly pull that from skin if you want me to. One reason we may NOT want to pull these from the skin is that although the MyFaces logo will be needed by the sub-project, the other graphics won't. Yet putting these in the skin will make them available to all projects on their builds. Scott On Tue, Mar 25, 2008 at 4:19 AM, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello, just added the logo of the portlet bridge to the myfaces-site-skin. Is a trinidad logo available? And I would suggest following header Apache|MyFaces|Core|Trinidad|Tobago|Tomahawk|Orchestra|Portlet Bridge (no Sandbox every project has a sandbox no JSF 1.1-1.2) or Apache|MyFaces|Download|Mailing Lists (News archive makes no sense in the header) for the subprojects for example Tobago Apache|MyFaces|Tobago|Download|Mailing Lists I would suggest following banner on the main page MyFaces Logo| Apache Logo for the subprojects Subproject Logo or Name | MyFaces Logo We should include the conference banner on every page. I would like to place the banner on the left site of the Apache/MyFaces Logo. Regards Bernd Bruno Aranda schrieb: Yes, it is really cool :) Thanks! Bruno On 25/03/2008, Matthias Wessendorf [EMAIL PROTECTED] wrote: really sexy looking website! thanks!!! -Matthias On Sat, Mar 22, 2008 at 2:05 PM, Gerald Müllan [EMAIL PROTECTED] wrote: It is online! Very well done guys; looks really great. cheers, Gerald On 3/22/08, Catalin Kormos [EMAIL PROTECTED] wrote: Hi Bernd, Thanks, i guess it will take some time until we see any change on the myfaces site. regards, Catalin On Sat, Mar 22, 2008 at 1:54 PM, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello Catalin, just added the myfaces-site-skin to the continuum build and forced a new site build on the continuum server. I don't know how the subproject sites are build. Regards Bernd Catalin Kormos schrieb: Could someone help me out with a redeploy of the MyFaces website? as i'm not exactly sure about the process involved here. I just committed the updated skin, and i also applied it on some of the projects, like, core, tomahawk, sandbox and orchestra. Thanks, Catalin Codebeat www.codebeat.ro -- Codebeat www.codebeat.ro -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: redeploy myfaces website
2 Opinions: 1. We need to be careful about standardizing the top links. I know that the bridge project should reference the JSR it tries to implement as well as the portal project. It may not be as consistent, but it's nice that everything that a Portlet Faces developer needs is in one site. These comments would be the same for MyFaces. There is nothing wrong with referencing the current JSR and external documentation. If we do want to standardize the top bar, then we'll want to have a useful links page added to each project. I would think that this is an extra click which is largely unnecessary. 2. The Bridge project handles the sub-project idea a bit better if you want to take a look. Just like MyFaces we have two subprojects which address different specs. All of the items in the first box are global. All of the items in the second box are categorized depending on project. So the overview for the Portlet Bridge 2.0 project is listed in the submenu under the Portlet Bridge 2.0 header. This is certainly not perfect and I'm not sure I like the fact that menu's underneath the second box change as a project is selected, but it's certainly much clearer. On Tue, Mar 25, 2008 at 4:22 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I've noticed some other inconsistent stuff that needs to be fixed. I think the most important is the issue I raised before: what should the top menu bar look like for sub-projects. If you look at the core modules for the moment, those links are all specific to myfaces as a whole, not to the subproject currently being viewed. I would expect overview to take me to the overview for the project I am currently viewing, not to the myfaces overview. Also, while we do *currently* have a shared downloads page for all projects, and a common set of mailing lists for all projects I don't think this will always be the case. So I don't think the download or mailing list links are appropriate here. What I've done for tomahawk for example is just to have Apache and MyFaces links, and nothing else. I think this is nicer. Obviously, it would be even nicer to be consistent across all projects. core11/core12: * icons need updating Trinidad: * has the faces icon on the right, not on the left. * has no title in the first block of the left-hand pane. * has no list-of-myfaces-projects in the left-hand pane. This might actually be nicer than replicating the list-of-projects on each page (people can always go up to the main myfaces site) but we should be consistent. * has no link to apache in the top menu bar, just MyFaces * has the foundation section at the top, not the bottom * date-published format is -mm-dd, not dd MMM Regards, Simon
Re: redeploy myfaces website
Hello Scott, I just checked in the logo from the bridge site project to the myfaces-site-skin. The myfaces-site-skin contains already the tobago logo. The tobago logo has the path images/tobagoLogo.png, the bridge logo has the path images/portlet_bridge_logo.png und the myfaces logo has the path images/myfaces-logo.png in the myfaces-site-skin. I think if other subprojects or the master myfaces site are using a logo from a subproject, it should be used from the site-skin. I don't like to duplicate the graphics in the repository. Regards Bernd Scott O'Bryan schrieb: Hey Bernd, Where did you get the logo from? I skinned the portlet bridge graphic yesterday and I had to modify some of the white-space to make it look right. Right now the bridge is using it's own logo, but I can certainly pull that from skin if you want me to. One reason we may NOT want to pull these from the skin is that although the MyFaces logo will be needed by the sub-project, the other graphics won't. Yet putting these in the skin will make them available to all projects on their builds. Scott On Tue, Mar 25, 2008 at 4:19 AM, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello, just added the logo of the portlet bridge to the myfaces-site-skin. Is a trinidad logo available? And I would suggest following header Apache|MyFaces|Core|Trinidad|Tobago|Tomahawk|Orchestra|Portlet Bridge (no Sandbox every project has a sandbox no JSF 1.1-1.2) or Apache|MyFaces|Download|Mailing Lists (News archive makes no sense in the header) for the subprojects for example Tobago Apache|MyFaces|Tobago|Download|Mailing Lists I would suggest following banner on the main page MyFaces Logo| Apache Logo for the subprojects Subproject Logo or Name | MyFaces Logo We should include the conference banner on every page. I would like to place the banner on the left site of the Apache/MyFaces Logo. Regards Bernd Bruno Aranda schrieb: Yes, it is really cool :) Thanks! Bruno On 25/03/2008, Matthias Wessendorf [EMAIL PROTECTED] wrote: really sexy looking website! thanks!!! -Matthias On Sat, Mar 22, 2008 at 2:05 PM, Gerald Müllan [EMAIL PROTECTED] wrote: It is online! Very well done guys; looks really great. cheers, Gerald On 3/22/08, Catalin Kormos [EMAIL PROTECTED] wrote: Hi Bernd, Thanks, i guess it will take some time until we see any change on the myfaces site. regards, Catalin On Sat, Mar 22, 2008 at 1:54 PM, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello Catalin, just added the myfaces-site-skin to the continuum build and forced a new site build on the continuum server. I don't know how the subproject sites are build. Regards Bernd Catalin Kormos schrieb: Could someone help me out with a redeploy of the MyFaces website? as i'm not exactly sure about the process involved here. I just committed the updated skin, and i also applied it on some of the projects, like, core, tomahawk, sandbox and orchestra. Thanks, Catalin Codebeat www.codebeat.ro -- Codebeat www.codebeat.ro -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: redeploy myfaces website
Hello Simon, I think we should try to standardize the first 2 or 3 links in the top menu bar. For the myfaces site Apache|MyFaces|Download|Mailing Lists (News archive makes no sense in the top menu) for the subprojects Apache|MyFaces|subproject name|XXX|Other useful link|YYY Regards Bernd [EMAIL PROTECTED] schrieb: I've noticed some other inconsistent stuff that needs to be fixed. I think the most important is the issue I raised before: what should the top menu bar look like for sub-projects. If you look at the core modules for the moment, those links are all specific to myfaces as a whole, not to the subproject currently being viewed. I would expect overview to take me to the overview for the project I am currently viewing, not to the myfaces overview. Also, while we do *currently* have a shared downloads page for all projects, and a common set of mailing lists for all projects I don't think this will always be the case. So I don't think the download or mailing list links are appropriate here. What I've done for tomahawk for example is just to have Apache and MyFaces links, and nothing else. I think this is nicer. Obviously, it would be even nicer to be consistent across all projects. core11/core12: * icons need updating Trinidad: * has the faces icon on the right, not on the left. * has no title in the first block of the left-hand pane. * has no list-of-myfaces-projects in the left-hand pane. This might actually be nicer than replicating the list-of-projects on each page (people can always go up to the main myfaces site) but we should be consistent. * has no link to apache in the top menu bar, just MyFaces * has the foundation section at the top, not the bottom * date-published format is -mm-dd, not dd MMM Regards, Simon
[jira] Updated: (TOMAHAWK-1216) CAPTCHA component - Enhancement #2 - Removing the dedicated servlet
[ https://issues.apache.org/jira/browse/TOMAHAWK-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Smith updated TOMAHAWK-1216: -- Resolution: Fixed Status: Resolved (was: Patch Available) Patch applied. Thanks Hazem! CAPTCHA component - Enhancement #2 - Removing the dedicated servlet Key: TOMAHAWK-1216 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1216 Project: MyFaces Tomahawk Issue Type: Improvement Affects Versions: 1.1.7-SNAPSHOT Reporter: Hazem Saleh Assignee: Grant Smith Fix For: 1.1.7-SNAPSHOT Attachments: captcha_without_a_servlet.patch, sample-1.jpg Original Estimate: 168h Remaining Estimate: 168h Removing the dedicated servlet from the CAPTCHA -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
MyFaces PMC += Scott O'Bryan
Dear MyFaces community, please welcome our new MyFaces PMC member Scott O'Bryan. Scott is working on the Apache MyFaces and Trinidad stuff. Therefore last week there was a vote to invite him to the MyFaces Project Management Committee (PMC) and fortunately he did accept. Scott, Please subscribe to the [EMAIL PROTECTED] list and update your status on the site. Thanks. -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
MyFaces PMC += Simon Kitching
Dear MyFaces community, please welcome our new MyFaces PMC member Simon Kitching. Simon is working on the Apache MyFaces and Orchestra stuff. Therefore last week there was a vote to invite him to the MyFaces Project Management Committee (PMC) and fortunately he did accept. Simon, Please subscribe to the [EMAIL PROTECTED] list and update your status on the site. Thanks. -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: redeploy myfaces website
Well that was kind of my point. Why should the bridge logo be in the skin? If it is in the skin then every project gets a copy when it's deployed. IMO the myfaces logo should be in the skin and the project logos should be with the project. That said, I'll certainly abide by what everyone else thinks is best because I too can appreciate consistency. Scott Bernd Bohmann wrote: Hello Scott, I just checked in the logo from the bridge site project to the myfaces-site-skin. The myfaces-site-skin contains already the tobago logo. The tobago logo has the path images/tobagoLogo.png, the bridge logo has the path images/portlet_bridge_logo.png und the myfaces logo has the path images/myfaces-logo.png in the myfaces-site-skin. I think if other subprojects or the master myfaces site are using a logo from a subproject, it should be used from the site-skin. I don't like to duplicate the graphics in the repository. Regards Bernd Scott O'Bryan schrieb: Hey Bernd, Where did you get the logo from? I skinned the portlet bridge graphic yesterday and I had to modify some of the white-space to make it look right. Right now the bridge is using it's own logo, but I can certainly pull that from skin if you want me to. One reason we may NOT want to pull these from the skin is that although the MyFaces logo will be needed by the sub-project, the other graphics won't. Yet putting these in the skin will make them available to all projects on their builds. Scott On Tue, Mar 25, 2008 at 4:19 AM, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello, just added the logo of the portlet bridge to the myfaces-site-skin. Is a trinidad logo available? And I would suggest following header Apache|MyFaces|Core|Trinidad|Tobago|Tomahawk|Orchestra|Portlet Bridge (no Sandbox every project has a sandbox no JSF 1.1-1.2) or Apache|MyFaces|Download|Mailing Lists (News archive makes no sense in the header) for the subprojects for example Tobago Apache|MyFaces|Tobago|Download|Mailing Lists I would suggest following banner on the main page MyFaces Logo| Apache Logo for the subprojects Subproject Logo or Name | MyFaces Logo We should include the conference banner on every page. I would like to place the banner on the left site of the Apache/MyFaces Logo. Regards Bernd Bruno Aranda schrieb: Yes, it is really cool :) Thanks! Bruno On 25/03/2008, Matthias Wessendorf [EMAIL PROTECTED] wrote: really sexy looking website! thanks!!! -Matthias On Sat, Mar 22, 2008 at 2:05 PM, Gerald Müllan [EMAIL PROTECTED] wrote: It is online! Very well done guys; looks really great. cheers, Gerald On 3/22/08, Catalin Kormos [EMAIL PROTECTED] wrote: Hi Bernd, Thanks, i guess it will take some time until we see any change on the myfaces site. regards, Catalin On Sat, Mar 22, 2008 at 1:54 PM, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello Catalin, just added the myfaces-site-skin to the continuum build and forced a new site build on the continuum server. I don't know how the subproject sites are build. Regards Bernd Catalin Kormos schrieb: Could someone help me out with a redeploy of the MyFaces website? as i'm not exactly sure about the process involved here. I just committed the updated skin, and i also applied it on some of the projects, like, core, tomahawk, sandbox and orchestra. Thanks, Catalin Codebeat www.codebeat.ro -- Codebeat www.codebeat.ro -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: MyFaces PMC += Scott O'Bryan
Congratulations Scott! On Tue, Mar 25, 2008 at 9:50 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Dear MyFaces community, please welcome our new MyFaces PMC member Scott O'Bryan. Scott is working on the Apache MyFaces and Trinidad stuff. Therefore last week there was a vote to invite him to the MyFaces Project Management Committee (PMC) and fortunately he did accept. Scott, Please subscribe to the [EMAIL PROTECTED] list and update your status on the site. Thanks. -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: MyFaces PMC += Simon Kitching
Congratulations Simon! On Tue, Mar 25, 2008 at 9:51 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Dear MyFaces community, please welcome our new MyFaces PMC member Simon Kitching. Simon is working on the Apache MyFaces and Orchestra stuff. Therefore last week there was a vote to invite him to the MyFaces Project Management Committee (PMC) and fortunately he did accept. Simon, Please subscribe to the [EMAIL PROTECTED] list and update your status on the site. Thanks. -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: redeploy myfaces website
Another option I was thinking of on my way into work this morning is that I could add a links menu off to the side and only have the standard bar across the top. Scott Bernd Bohmann wrote: Hello Simon, I think we should try to standardize the first 2 or 3 links in the top menu bar. For the myfaces site Apache|MyFaces|Download|Mailing Lists (News archive makes no sense in the top menu) for the subprojects Apache|MyFaces|subproject name|XXX|Other useful link|YYY Regards Bernd [EMAIL PROTECTED] schrieb: I've noticed some other inconsistent stuff that needs to be fixed. I think the most important is the issue I raised before: what should the top menu bar look like for sub-projects. If you look at the core modules for the moment, those links are all specific to myfaces as a whole, not to the subproject currently being viewed. I would expect overview to take me to the overview for the project I am currently viewing, not to the myfaces overview. Also, while we do *currently* have a shared downloads page for all projects, and a common set of mailing lists for all projects I don't think this will always be the case. So I don't think the download or mailing list links are appropriate here. What I've done for tomahawk for example is just to have Apache and MyFaces links, and nothing else. I think this is nicer. Obviously, it would be even nicer to be consistent across all projects. core11/core12: * icons need updating Trinidad: * has the faces icon on the right, not on the left. * has no title in the first block of the left-hand pane. * has no list-of-myfaces-projects in the left-hand pane. This might actually be nicer than replicating the list-of-projects on each page (people can always go up to the main myfaces site) but we should be consistent. * has no link to apache in the top menu bar, just MyFaces * has the foundation section at the top, not the bottom * date-published format is -mm-dd, not dd MMM Regards, Simon
[jira] Updated: (TOMAHAWK-1200) Infinite loop when empty table with detailStamp is rendered
[ https://issues.apache.org/jira/browse/TOMAHAWK-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Smith updated TOMAHAWK-1200: -- Resolution: Fixed Fix Version/s: 1.1.7-SNAPSHOT Status: Resolved (was: Patch Available) Patch applied. Thanks Stephen ! Infinite loop when empty table with detailStamp is rendered --- Key: TOMAHAWK-1200 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1200 Project: MyFaces Tomahawk Issue Type: Bug Components: Extended Datatable Affects Versions: 1.1.6 Environment: tested on Mac OS X Reporter: Stephen Cooper Assignee: Grant Smith Fix For: 1.1.7-SNAPSHOT Attachments: HtmlDataTable.java.patch I've found that the detailStamp facit will go into an infinite loop, setting row indexes higher and higher - way past the table size - until an OutOfMemory exception occurs (oddly enough, it occurs before the stack overflows). I've isolated the code involved, and will attach a patch. All I had to do was swap the order of two checks, so that we'd check if we've gotten to the end of the table before we check if the detailStamp for the current row is expanded. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r640864 - in /myfaces/tomahawk/trunk/sandbox: core/src/main/java/org/apache/myfaces/custom/captcha/ core/src/main/java/org/apache/myfaces/custom/captcha/util/ core/src/main/java/org/ap
Hi Grant,
Could you please avoid combining code changes and reformatting in the
same patch? It is just impossible from this patch to determine what
*real* changes you have made to ComponentUtils.
And I believe the coding convention here is to use spaces, *not* tabs,
but you have replaced all spaces *with* tabs in ComponentUtils.
What were the actual ComponentUtils changes?
Thanks,
Simon
[EMAIL PROTECTED] schrieb:
Author: grantsmith
Date: Tue Mar 25 08:40:50 2008
New Revision: 640864
URL: http://svn.apache.org/viewvc?rev=640864view=rev
Log:
https://issues.apache.org/jira/browse/TOMAHAWK-1216 patch applied
Added:
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/captcha/util/CAPTCHAConstants.java
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/captcha/util/CAPTCHAResponseStream.java
Modified:
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/captcha/CAPTCHARenderer.java
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/captcha/util/CAPTCHAImageGenerator.java
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/util/ComponentUtils.java
myfaces/tomahawk/trunk/sandbox/examples/src/main/webapp/WEB-INF/web.xml
Modified:
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/captcha/CAPTCHARenderer.java
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/captcha/CAPTCHARenderer.java?rev=640864r1=640863r2=640864view=diff
==
---
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/captcha/CAPTCHARenderer.java
(original)
+++
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/captcha/CAPTCHARenderer.java
Tue Mar 25 08:40:50 2008
@@ -19,22 +19,40 @@
package org.apache.myfaces.custom.captcha;
import java.io.IOException;
+import java.util.Map;
+import javax.faces.FacesException;
+import javax.faces.FactoryFinder;
import javax.faces.component.UIComponent;
import javax.faces.context.FacesContext;
+import javax.faces.context.FacesContextFactory;
+import javax.faces.context.ResponseStream;
import javax.faces.context.ResponseWriter;
+import javax.faces.lifecycle.Lifecycle;
+import javax.faces.lifecycle.LifecycleFactory;
import javax.faces.render.Renderer;
+import javax.servlet.ServletContext;
+import javax.servlet.http.HttpServletRequest;
+import javax.servlet.http.HttpServletResponse;
+
+import org.apache.myfaces.component.html.util.ParameterResourceHandler;
+import org.apache.myfaces.custom.captcha.util.CAPTCHAImageGenerator;
+import org.apache.myfaces.custom.captcha.util.CAPTCHAResponseStream;
+import org.apache.myfaces.custom.captcha.util.CAPTCHATextGenerator;
+import org.apache.myfaces.custom.util.ComponentUtils;
+import org.apache.myfaces.renderkit.html.util.AddResource;
+import org.apache.myfaces.renderkit.html.util.AddResourceFactory;
+import org.apache.myfaces.renderkit.html.util.ResourceLoader;
+import org.apache.myfaces.shared_tomahawk.renderkit.html.HTML;
-public class CAPTCHARenderer extends Renderer {
-
- private static final String CAPTCHA_SERVLET_NAME =
apache_captcha_servlet_url;
+public class CAPTCHARenderer extends Renderer implements ResourceLoader {
public void encodeBegin(FacesContext context, UIComponent component)
throws IOException {
CAPTCHAComponent captchaComponent = (CAPTCHAComponent)
component;
- renderCAPTCHA(context, captchaComponent);
+ generateImageTag(context, captchaComponent);
}
public void encodeEnd(FacesContext context, UIComponent component)
@@ -43,25 +61,104 @@
}
/*
- * This helper method renders the img tag that will
- * call the CAPTCHAServlet to render the CAPTCHA image.
+ * This helper method is used for generating the img tag that will
+ * use the (AddResource) to generate the url of the generated image.
*/
- private void renderCAPTCHA(FacesContext context, CAPTCHAComponent
component)
+ private void generateImageTag(FacesContext context, CAPTCHAComponent
component)
throws IOException {
+
+AddResource addResource = null;
+String url = null;
+ CAPTCHAComponent captchaComponent = (CAPTCHAComponent)
component;
ResponseWriter writer = context.getResponseWriter();
+Map params = ComponentUtils.getParameterMap(component);
+String captchaSessionKeyName =
captchaComponent.getCaptchaSessionKeyName();
+
+writer.startElement(HTML.IMG_ELEM, captchaComponent);
+
+if (captchaSessionKeyName != null) {
+
Re: MyFaces PMC += Simon Kitching
Congratulations! On Tue, Mar 25, 2008 at 11:55 AM, Matt Cooper [EMAIL PROTECTED] wrote: Congratulations Simon! On Tue, Mar 25, 2008 at 9:51 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Dear MyFaces community, please welcome our new MyFaces PMC member Simon Kitching. Simon is working on the Apache MyFaces and Orchestra stuff. Therefore last week there was a vote to invite him to the MyFaces Project Management Committee (PMC) and fortunately he did accept. Simon, Please subscribe to the [EMAIL PROTECTED] list and update your status on the site. Thanks. -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: MyFaces PMC += Scott O'Bryan
Congratz! On Tue, Mar 25, 2008 at 11:55 AM, Matt Cooper [EMAIL PROTECTED] wrote: Congratulations Scott! On Tue, Mar 25, 2008 at 9:50 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Dear MyFaces community, please welcome our new MyFaces PMC member Scott O'Bryan. Scott is working on the Apache MyFaces and Trinidad stuff. Therefore last week there was a vote to invite him to the MyFaces Project Management Committee (PMC) and fortunately he did accept. Scott, Please subscribe to the [EMAIL PROTECTED] list and update your status on the site. Thanks. -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
[jira] Updated: (TOMAHAWK-1169) In simple layout no linebreaks should be added
[
https://issues.apache.org/jira/browse/TOMAHAWK-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Smith updated TOMAHAWK-1169:
--
Resolution: Fixed
Fix Version/s: 1.1.7-SNAPSHOT
Status: Resolved (was: Patch Available)
Patch applied. Thanks Thorsten!
In simple layout no linebreaks should be added
--
Key: TOMAHAWK-1169
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1169
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Data List
Affects Versions: 1.1.3, 1.1.5, 1.1.6
Reporter: Thorsten Duhn
Assignee: Grant Smith
Priority: Trivial
Fix For: 1.1.7-SNAPSHOT
Attachments: patch_TOMAHAWK-1169.txt
When dataList is used in simple layout no additional linebreaks
(HtmlRendererUtils.writePrettyLineSeparator(facesContext)) should be added
as this breaks usual JSF behaviour. When content before dataList is text and
content of dataList items also is text there should not be whitespace
between. When you do one outputText after another their content also is
rendered together, with no whitespace between, regardless if there is
whitespace between the JSF outputText elements.
For example print out a list inside of brackets, you usually don't want
whitespace after opening or before closing bracket. Printing brackets inside
of dataList is a workaround, only rendered on #{rowIndex eq 0} or
#{rowIndex eq (rowCount - 1)}, but I believe dataList renderer just should
not insert linebreaks in case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TOMAHAWK-1156) UIColumns component must be a child of a UIData component
[ https://issues.apache.org/jira/browse/TOMAHAWK-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Smith updated TOMAHAWK-1156: -- Resolution: Fixed Fix Version/s: 1.1.7-SNAPSHOT Status: Resolved (was: Patch Available) Patch applied. Thanks Bogdan. Please note that patches are usually applied sooner if they are SVN diffs. UIColumns component must be a child of a UIData component -- Key: TOMAHAWK-1156 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1156 Project: MyFaces Tomahawk Issue Type: Bug Components: Columns Affects Versions: 1.1.7-SNAPSHOT Environment: java version 1.6.0_03; tomcat6; JSF RI 1.2_06 Reporter: Bogdan Sava Assignee: Grant Smith Priority: Blocker Fix For: 1.1.7-SNAPSHOT By using t:colums from 1.1.7 version with Sun JSF RI 1.2_06 get java.lang.IllegalStateException with message: UIColumns component must be a child of a UIData component Please note that it is working with MyFaces 1.2 implementation. Can be seen by configuring Dynamic number of columns, add a column tomahawk example with Sun JSF RI 1.2_06 get. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: MyFaces PMC += Simon Kitching
Congrats Simon. Matt Cooper wrote: Congratulations Simon! On Tue, Mar 25, 2008 at 9:51 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Dear MyFaces community, please welcome our new MyFaces PMC member Simon Kitching. Simon is working on the Apache MyFaces and Orchestra stuff. Therefore last week there was a vote to invite him to the MyFaces Project Management Committee (PMC) and fortunately he did accept. Simon, Please subscribe to the [EMAIL PROTECTED] list and update your status on the site. Thanks. -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: MyFaces PMC += Simon Kitching
Nice work, Simon. On Tue, Mar 25, 2008 at 8:23 AM, Scott O'Bryan [EMAIL PROTECTED] wrote: Congrats Simon. Matt Cooper wrote: Congratulations Simon! On Tue, Mar 25, 2008 at 9:51 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Dear MyFaces community, please welcome our new MyFaces PMC member Simon Kitching. Simon is working on the Apache MyFaces and Orchestra stuff. Therefore last week there was a vote to invite him to the MyFaces Project Management Committee (PMC) and fortunately he did accept. Simon, Please subscribe to the [EMAIL PROTECTED] list and update your status on the site. Thanks. -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Grant Smith
[jira] Updated: (TOMAHAWK-1142) Extra TD / LI rendered fpr paginator if using singleTable or singleList layout
[ https://issues.apache.org/jira/browse/TOMAHAWK-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Smith updated TOMAHAWK-1142: -- Resolution: Fixed Fix Version/s: 1.1.7-SNAPSHOT Assignee: Grant Smith Status: Resolved (was: Patch Available) This has already been fixed. Extra TD / LI rendered fpr paginator if using singleTable or singleList layout -- Key: TOMAHAWK-1142 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1142 Project: MyFaces Tomahawk Issue Type: Bug Components: Data Scroller Affects Versions: 1.1.6 Reporter: Alex Savitsky Assignee: Grant Smith Fix For: 1.1.7-SNAPSHOT Attachments: patch.txt, source.html When using Single Element scroller layouts (that is, singleTable or singleList), the renderer creates an extra TD or LI element (thus creating two nested TDs / LIs for the paginator). Not only this is incorrect HTML, it also makes harder to apply CSS styles to the scroller. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: MyFaces PMC += Scott O'Bryan
Good job Scott! On Tue, Mar 25, 2008 at 8:05 AM, Simon Lessard [EMAIL PROTECTED] wrote: Congratz! On Tue, Mar 25, 2008 at 11:55 AM, Matt Cooper [EMAIL PROTECTED] wrote: Congratulations Scott! On Tue, Mar 25, 2008 at 9:50 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Dear MyFaces community, please welcome our new MyFaces PMC member Scott O'Bryan. Scott is working on the Apache MyFaces and Trinidad stuff. Therefore last week there was a vote to invite him to the MyFaces Project Management Committee (PMC) and fortunately he did accept. Scott, Please subscribe to the [EMAIL PROTECTED] list and update your status on the site. Thanks. -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Grant Smith
Re: CAPTCHA component - Enhancement #2 - Removing the dedicated servlet
Done. On Mon, Mar 24, 2008 at 4:51 PM, Hazem Saleh [EMAIL PROTECTED] wrote: Hi all, Please apply this patch if you have sometime. Here is the JIRA issue url : https://issues.apache.org/jira/browse/TOMAHAWK-1216 This patch removes the dedicated servlet from the CAPTCHA component, It integrates the component with the great Extension filter Resource loader :). Thanks all very much. I really appreciate your efforts and I really like this project :). -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog -- Grant Smith
[jira] Created: (MYFACES-1842) commandLink with parameters behaves differently in Firefox and IE
commandLink with parameters behaves differently in Firefox and IE - Key: MYFACES-1842 URL: https://issues.apache.org/jira/browse/MYFACES-1842 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.0 Environment: Windows XP, MyFaces 1.2.0, Jetty, Firefox 2.0.0.12, IE 7.0.570.11 Reporter: Neil Curzon When I have a commandLink element with a parameter, and double click on the link, I get different behavior in IE and Firefox. IE submits the expected query string on the first click, but on the second click generates a query string with the parameter listed twice, both times with the correct value, in its name value pairs. Firefox submits the expected query string on both clicks. The culprit may be the oamSubmitForm javascript. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
renderedIfEmpty parameter for t:messages (for message-updates by AJAX requests)
Hi, I would like to add renderedIfEmpty to the t:messages component which per default is false (current behaviour) The reason for that: To update/append FacesMessages to a messages-component after AJAX requests (e.g. PPR) it has to be possible to locate a DOM element to which this messages can be appended. One could also think of automatically adding a CSS-style display:none if the empty table/list is rendered which is reset by any JavaScript updates to the messages. Alternatively we could create a new messages-component which supports that. If anybody can think of reasons why this parameter should not be added please tell. Otherwise I'll file a JIRA issue and start implementing on thursday evening. kind regards Ernst
Re: Is it possible customize h:message
Hi,
I believe the tomahawk component t:message does something similar to
what you want.
At least it displays the label instead of the id). Maybe you can use
that one or just check
org.apache.myfaces.renderkit.html.ext.HtmlMessageRenderer and do
something similar
in a custom renderer.
cheers
Ernst
On Wed, Mar 19, 2008 at 8:27 AM, prantor [EMAIL PROTECTED] wrote:
Hi all
I am using JSF myfaces implementation with RichFaces
I have a code in rich modal panel like.
h:inputText label=Client id=ClientId value=#{bean.client}
required=true /
rich:message for=ClientRecId
f:facet name=passedMarkerh:graphicImage
value=/images/ajax/passed.gif//f:facet
f:facet name=errorMarkerh:graphicImage
value=/images/ajax/error.gif//f:facet
/rich:message
I am expectiong that it will show message by Label like Client: Value is
required. but it show message by ID like ClientId: Value is required.
Why? Any kind of help regarding this issue is highly appreciated.
--
View this message in context:
http://www.nabble.com/Is-it-possible-customize-%3Ch%3Amessage%3E-tp16138403p16138403.html
Sent from the My Faces - Dev mailing list archive at Nabble.com.
Re: renderedIfEmpty parameter for t:messages (for message-updates by AJAX requests)
On Tue, 2008-03-25 at 20:50 +0100, Ernst Fastl wrote: Hi, I would like to add renderedIfEmpty to the t:messages component which per default is false (current behaviour) The reason for that: To update/append FacesMessages to a messages-component after AJAX requests (e.g. PPR) it has to be possible to locate a DOM element to which this messages can be appended. One could also think of automatically adding a CSS-style display:none if the empty table/list is rendered which is reset by any JavaScript updates to the messages. Alternatively we could create a new messages-component which supports that. If anybody can think of reasons why this parameter should not be added please tell. Otherwise I'll file a JIRA issue and start implementing on thursday evening. Does your second suggestion (CSS-style display:none) mean to always render the div, but when there are no messages do: div id=.. style=display:none/ and let javascript modify the style if messages need to be added to it after a ppr request? If so, I think that is nicer. Logically, it makes sense too; the h:messages has not been marked with rendered=false, it just happens to have no messages. So the div should be present, but hidden. And it means that no extra attribute is needed. I cannot imagine any application that would break because of the introduction of a div with display:none set. Regards, Simon
Re: renderedIfEmpty parameter for t:messages (for message-updates by AJAX requests)
On Tue, 2008-03-25 at 21:45 +0100, simon wrote: On Tue, 2008-03-25 at 20:50 +0100, Ernst Fastl wrote: Hi, I would like to add renderedIfEmpty to the t:messages component which per default is false (current behaviour) The reason for that: To update/append FacesMessages to a messages-component after AJAX requests (e.g. PPR) it has to be possible to locate a DOM element to which this messages can be appended. One could also think of automatically adding a CSS-style display:none if the empty table/list is rendered which is reset by any JavaScript updates to the messages. Alternatively we could create a new messages-component which supports that. If anybody can think of reasons why this parameter should not be added please tell. Otherwise I'll file a JIRA issue and start implementing on thursday evening. Does your second suggestion (CSS-style display:none) mean to always render the div, but when there are no messages do: div id=.. style=display:none/ and let javascript modify the style if messages need to be added to it after a ppr request? If so, I think that is nicer. Logically, it makes sense too; the h:messages has not been marked with rendered=false, it just happens to have no messages. So the div should be present, but hidden. And it means that no extra attribute is needed. I cannot imagine any application that would break because of the introduction of a div with display:none set. BTW, I was thinking about making this change in h:messages, not just in t:messages. However even if the change is done in core, the same functionality would still be needed in t:messages unless Sun Mojarra's h:messages component also renders a hidden div when empty. Any idea what Mojarra does here? Regards, Simon
Re: renderedIfEmpty parameter for t:messages (for message-updates by AJAX requests)
Hi, For t:message and t:messages, there's already a forceSpan attribute, will it work for you Ernst? Cagatay On Tue, Mar 25, 2008 at 11:17 PM, simon [EMAIL PROTECTED] wrote: On Tue, 2008-03-25 at 21:45 +0100, simon wrote: On Tue, 2008-03-25 at 20:50 +0100, Ernst Fastl wrote: Hi, I would like to add renderedIfEmpty to the t:messages component which per default is false (current behaviour) The reason for that: To update/append FacesMessages to a messages-component after AJAX requests (e.g. PPR) it has to be possible to locate a DOM element to which this messages can be appended. One could also think of automatically adding a CSS-style display:none if the empty table/list is rendered which is reset by any JavaScript updates to the messages. Alternatively we could create a new messages-component which supports that. If anybody can think of reasons why this parameter should not be added please tell. Otherwise I'll file a JIRA issue and start implementing on thursday evening. Does your second suggestion (CSS-style display:none) mean to always render the div, but when there are no messages do: div id=.. style=display:none/ and let javascript modify the style if messages need to be added to it after a ppr request? If so, I think that is nicer. Logically, it makes sense too; the h:messages has not been marked with rendered=false, it just happens to have no messages. So the div should be present, but hidden. And it means that no extra attribute is needed. I cannot imagine any application that would break because of the introduction of a div with display:none set. BTW, I was thinking about making this change in h:messages, not just in t:messages. However even if the change is done in core, the same functionality would still be needed in t:messages unless Sun Mojarra's h:messages component also renders a hidden div when empty. Any idea what Mojarra does here? Regards, Simon
Re: redeploy myfaces website
Hello Scott, the tobago project has 30 modules. If the tobago logo isn't included in the myfaces-site-skin the tobago logo must be included in 30 resource dirs of the site or I have to create 30 site.xml files to reference the logo. The portlet bridge has 3 site modules now. For every new module you must create a new site.xml to reference the logo. I don't like to maintain to many files with the same content. But we waste some space on myfaces.apache.org. Regards Bernd Scott O'Bryan schrieb: Well that was kind of my point. Why should the bridge logo be in the skin? If it is in the skin then every project gets a copy when it's deployed. IMO the myfaces logo should be in the skin and the project logos should be with the project. That said, I'll certainly abide by what everyone else thinks is best because I too can appreciate consistency. Scott Bernd Bohmann wrote:d Hello Scott, I just checked in the logo from the bridge site project to the myfaces-site-skin. The myfaces-site-skin contains already the tobago logo. The tobago logo has the path images/tobagoLogo.png, the bridge logo has the path images/portlet_bridge_logo.png und the myfaces logo has the path images/myfaces-logo.png in the myfaces-site-skin. I think if other subprojects or the master myfaces site are using a logo from a subproject, it should be used from the site-skin. I don't like to duplicate the graphics in the repository. Regards Bernd Scott O'Bryan schrieb: Hey Bernd, Where did you get the logo from? I skinned the portlet bridge graphic yesterday and I had to modify some of the white-space to make it look right. Right now the bridge is using it's own logo, but I can certainly pull that from skin if you want me to. One reason we may NOT want to pull these from the skin is that although the MyFaces logo will be needed by the sub-project, the other graphics won't. Yet putting these in the skin will make them available to all projects on their builds. Scott On Tue, Mar 25, 2008 at 4:19 AM, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello, just added the logo of the portlet bridge to the myfaces-site-skin. Is a trinidad logo available? And I would suggest following header Apache|MyFaces|Core|Trinidad|Tobago|Tomahawk|Orchestra|Portlet Bridge (no Sandbox every project has a sandbox no JSF 1.1-1.2) or Apache|MyFaces|Download|Mailing Lists (News archive makes no sense in the header) for the subprojects for example Tobago Apache|MyFaces|Tobago|Download|Mailing Lists I would suggest following banner on the main page MyFaces Logo| Apache Logo for the subprojects Subproject Logo or Name | MyFaces Logo We should include the conference banner on every page. I would like to place the banner on the left site of the Apache/MyFaces Logo. Regards Bernd Bruno Aranda schrieb: Yes, it is really cool :) Thanks! Bruno On 25/03/2008, Matthias Wessendorf [EMAIL PROTECTED] wrote: really sexy looking website! thanks!!! -Matthias On Sat, Mar 22, 2008 at 2:05 PM, Gerald Müllan [EMAIL PROTECTED] wrote: It is online! Very well done guys; looks really great. cheers, Gerald On 3/22/08, Catalin Kormos [EMAIL PROTECTED] wrote: Hi Bernd, Thanks, i guess it will take some time until we see any change on the myfaces site. regards, Catalin On Sat, Mar 22, 2008 at 1:54 PM, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello Catalin, just added the myfaces-site-skin to the continuum build and forced a new site build on the continuum server. I don't know how the subproject sites are build. Regards Bernd Catalin Kormos schrieb: Could someone help me out with a redeploy of the MyFaces website? as i'm not exactly sure about the process involved here. I just committed the updated skin, and i also applied it on some of the projects, like, core, tomahawk, sandbox and orchestra. Thanks, Catalin Codebeat www.codebeat.ro -- Codebeat www.codebeat.ro -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: redeploy myfaces website
Bernd, That isn't entirely true. The bridge has 3 modules (right now) which contribute to the site. The sub-modules just reference the graphic from the main site. In my case I'm even piecing the pieces together amongst a separate site project and core projects (the core references the site project's graphics). In the case of modules under one root, the graphic simply needs to be in your root project. If it is, I believe all the other url's will refer to it correctly because it will know how to construct the relative urls. Scott Bernd Bohmann wrote: Hello Scott, the tobago project has 30 modules. If the tobago logo isn't included in the myfaces-site-skin the tobago logo must be included in 30 resource dirs of the site or I have to create 30 site.xml files to reference the logo. The portlet bridge has 3 site modules now. For every new module you must create a new site.xml to reference the logo. I don't like to maintain to many files with the same content. But we waste some space on myfaces.apache.org. Regards Bernd Scott O'Bryan schrieb: Well that was kind of my point. Why should the bridge logo be in the skin? If it is in the skin then every project gets a copy when it's deployed. IMO the myfaces logo should be in the skin and the project logos should be with the project. That said, I'll certainly abide by what everyone else thinks is best because I too can appreciate consistency. Scott Bernd Bohmann wrote:d Hello Scott, I just checked in the logo from the bridge site project to the myfaces-site-skin. The myfaces-site-skin contains already the tobago logo. The tobago logo has the path images/tobagoLogo.png, the bridge logo has the path images/portlet_bridge_logo.png und the myfaces logo has the path images/myfaces-logo.png in the myfaces-site-skin. I think if other subprojects or the master myfaces site are using a logo from a subproject, it should be used from the site-skin. I don't like to duplicate the graphics in the repository. Regards Bernd Scott O'Bryan schrieb: Hey Bernd, Where did you get the logo from? I skinned the portlet bridge graphic yesterday and I had to modify some of the white-space to make it look right. Right now the bridge is using it's own logo, but I can certainly pull that from skin if you want me to. One reason we may NOT want to pull these from the skin is that although the MyFaces logo will be needed by the sub-project, the other graphics won't. Yet putting these in the skin will make them available to all projects on their builds. Scott On Tue, Mar 25, 2008 at 4:19 AM, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello, just added the logo of the portlet bridge to the myfaces-site-skin. Is a trinidad logo available? And I would suggest following header Apache|MyFaces|Core|Trinidad|Tobago|Tomahawk|Orchestra|Portlet Bridge (no Sandbox every project has a sandbox no JSF 1.1-1.2) or Apache|MyFaces|Download|Mailing Lists (News archive makes no sense in the header) for the subprojects for example Tobago Apache|MyFaces|Tobago|Download|Mailing Lists I would suggest following banner on the main page MyFaces Logo| Apache Logo for the subprojects Subproject Logo or Name | MyFaces Logo We should include the conference banner on every page. I would like to place the banner on the left site of the Apache/MyFaces Logo. Regards Bernd Bruno Aranda schrieb: Yes, it is really cool :) Thanks! Bruno On 25/03/2008, Matthias Wessendorf [EMAIL PROTECTED] wrote: really sexy looking website! thanks!!! -Matthias On Sat, Mar 22, 2008 at 2:05 PM, Gerald Müllan [EMAIL PROTECTED] wrote: It is online! Very well done guys; looks really great. cheers, Gerald On 3/22/08, Catalin Kormos [EMAIL PROTECTED] wrote: Hi Bernd, Thanks, i guess it will take some time until we see any change on the myfaces site. regards, Catalin On Sat, Mar 22, 2008 at 1:54 PM, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello Catalin, just added the myfaces-site-skin to the continuum build and forced a new site build on the continuum server. I don't know how the subproject sites are build. Regards Bernd Catalin Kormos schrieb: Could someone help me out with a redeploy of the MyFaces website? as i'm not exactly sure about the process involved here. I just committed the updated skin, and i also applied it on some of the projects, like, core,
Re: redeploy myfaces website
I wasn't too clear so let me explain, I have 3 top-level projects. Each of the core projects (of which there are 2) have 3 modules with the third module (the examples module) containing two more. In EACH core project I have one site.xml file. The graphic in all of the modules of each core project reference the graphic correctly because they know where they are located relative to the root project. So if Tobago had 1 core project with 40 modules, your root project could refer to your local graphic and the pages for all your modules would reference this graphic correctly. If you had multiple root projects, like the bridge does, you would need a new site.xml for each one anyway. Is this correct or am I missing something? Scott Scott O'Bryan wrote: Bernd, That isn't entirely true. The bridge has 3 modules (right now) which contribute to the site. The sub-modules just reference the graphic from the main site. In my case I'm even piecing the pieces together amongst a separate site project and core projects (the core references the site project's graphics). In the case of modules under one root, the graphic simply needs to be in your root project. If it is, I believe all the other url's will refer to it correctly because it will know how to construct the relative urls. Scott Bernd Bohmann wrote: Hello Scott, the tobago project has 30 modules. If the tobago logo isn't included in the myfaces-site-skin the tobago logo must be included in 30 resource dirs of the site or I have to create 30 site.xml files to reference the logo. The portlet bridge has 3 site modules now. For every new module you must create a new site.xml to reference the logo. I don't like to maintain to many files with the same content. But we waste some space on myfaces.apache.org. Regards Bernd Scott O'Bryan schrieb: Well that was kind of my point. Why should the bridge logo be in the skin? If it is in the skin then every project gets a copy when it's deployed. IMO the myfaces logo should be in the skin and the project logos should be with the project. That said, I'll certainly abide by what everyone else thinks is best because I too can appreciate consistency. Scott Bernd Bohmann wrote:d Hello Scott, I just checked in the logo from the bridge site project to the myfaces-site-skin. The myfaces-site-skin contains already the tobago logo. The tobago logo has the path images/tobagoLogo.png, the bridge logo has the path images/portlet_bridge_logo.png und the myfaces logo has the path images/myfaces-logo.png in the myfaces-site-skin. I think if other subprojects or the master myfaces site are using a logo from a subproject, it should be used from the site-skin. I don't like to duplicate the graphics in the repository. Regards Bernd Scott O'Bryan schrieb: Hey Bernd, Where did you get the logo from? I skinned the portlet bridge graphic yesterday and I had to modify some of the white-space to make it look right. Right now the bridge is using it's own logo, but I can certainly pull that from skin if you want me to. One reason we may NOT want to pull these from the skin is that although the MyFaces logo will be needed by the sub-project, the other graphics won't. Yet putting these in the skin will make them available to all projects on their builds. Scott On Tue, Mar 25, 2008 at 4:19 AM, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello, just added the logo of the portlet bridge to the myfaces-site-skin. Is a trinidad logo available? And I would suggest following header Apache|MyFaces|Core|Trinidad|Tobago|Tomahawk|Orchestra|Portlet Bridge (no Sandbox every project has a sandbox no JSF 1.1-1.2) or Apache|MyFaces|Download|Mailing Lists (News archive makes no sense in the header) for the subprojects for example Tobago Apache|MyFaces|Tobago|Download|Mailing Lists I would suggest following banner on the main page MyFaces Logo| Apache Logo for the subprojects Subproject Logo or Name | MyFaces Logo We should include the conference banner on every page. I would like to place the banner on the left site of the Apache/MyFaces Logo. Regards Bernd Bruno Aranda schrieb: Yes, it is really cool :) Thanks! Bruno On 25/03/2008, Matthias Wessendorf [EMAIL PROTECTED] wrote: really sexy looking website! thanks!!! -Matthias On Sat, Mar 22, 2008 at 2:05 PM, Gerald Müllan [EMAIL PROTECTED] wrote: It is online! Very well done guys; looks really great. cheers, Gerald On 3/22/08, Catalin Kormos [EMAIL PROTECTED] wrote: Hi Bernd, Thanks, i guess it will take some time until we see any change on the myfaces site. regards, Catalin On Sat, Mar 22, 2008 at 1:54 PM, Bernd Bohmann [EMAIL PROTECTED]
Re: redeploy myfaces website
Hello Scott, just checked the generated html of the site. The site plugin creates the correct relative reference to the graphic. Should I remove the portlet bridge logo from the myfaces-site-skin? Regards Bernd Scott O'Bryan schrieb: I wasn't too clear so let me explain, I have 3 top-level projects. Each of the core projects (of which there are 2) have 3 modules with the third module (the examples module) containing two more. In EACH core project I have one site.xml file. The graphic in all of the modules of each core project reference the graphic correctly because they know where they are located relative to the root project. So if Tobago had 1 core project with 40 modules, your root project could refer to your local graphic and the pages for all your modules would reference this graphic correctly. If you had multiple root projects, like the bridge does, you would need a new site.xml for each one anyway. Is this correct or am I missing something? Scott Scott O'Bryan wrote: Bernd, That isn't entirely true. The bridge has 3 modules (right now) which contribute to the site. The sub-modules just reference the graphic from the main site. In my case I'm even piecing the pieces together amongst a separate site project and core projects (the core references the site project's graphics). In the case of modules under one root, the graphic simply needs to be in your root project. If it is, I believe all the other url's will refer to it correctly because it will know how to construct the relative urls. Scott Bernd Bohmann wrote: Hello Scott, the tobago project has 30 modules. If the tobago logo isn't included in the myfaces-site-skin the tobago logo must be included in 30 resource dirs of the site or I have to create 30 site.xml files to reference the logo. The portlet bridge has 3 site modules now. For every new module you must create a new site.xml to reference the logo. I don't like to maintain to many files with the same content. But we waste some space on myfaces.apache.org. Regards Bernd Scott O'Bryan schrieb: Well that was kind of my point. Why should the bridge logo be in the skin? If it is in the skin then every project gets a copy when it's deployed. IMO the myfaces logo should be in the skin and the project logos should be with the project. That said, I'll certainly abide by what everyone else thinks is best because I too can appreciate consistency. Scott Bernd Bohmann wrote:d Hello Scott, I just checked in the logo from the bridge site project to the myfaces-site-skin. The myfaces-site-skin contains already the tobago logo. The tobago logo has the path images/tobagoLogo.png, the bridge logo has the path images/portlet_bridge_logo.png und the myfaces logo has the path images/myfaces-logo.png in the myfaces-site-skin. I think if other subprojects or the master myfaces site are using a logo from a subproject, it should be used from the site-skin. I don't like to duplicate the graphics in the repository. Regards Bernd Scott O'Bryan schrieb: Hey Bernd, Where did you get the logo from? I skinned the portlet bridge graphic yesterday and I had to modify some of the white-space to make it look right. Right now the bridge is using it's own logo, but I can certainly pull that from skin if you want me to. One reason we may NOT want to pull these from the skin is that although the MyFaces logo will be needed by the sub-project, the other graphics won't. Yet putting these in the skin will make them available to all projects on their builds. Scott On Tue, Mar 25, 2008 at 4:19 AM, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello, just added the logo of the portlet bridge to the myfaces-site-skin. Is a trinidad logo available? And I would suggest following header Apache|MyFaces|Core|Trinidad|Tobago|Tomahawk|Orchestra|Portlet Bridge (no Sandbox every project has a sandbox no JSF 1.1-1.2) or Apache|MyFaces|Download|Mailing Lists (News archive makes no sense in the header) for the subprojects for example Tobago Apache|MyFaces|Tobago|Download|Mailing Lists I would suggest following banner on the main page MyFaces Logo| Apache Logo for the subprojects Subproject Logo or Name | MyFaces Logo We should include the conference banner on every page. I would like to place the banner on the left site of the Apache/MyFaces Logo. Regards Bernd Bruno Aranda schrieb: Yes, it is really cool :) Thanks! Bruno On 25/03/2008, Matthias Wessendorf [EMAIL PROTECTED] wrote: really sexy looking website! thanks!!! -Matthias On Sat, Mar 22, 2008 at 2:05 PM, Gerald Müllan [EMAIL PROTECTED] wrote: It is online! Very well done guys; looks really great. cheers, Gerald On 3/22/08, Catalin Kormos [EMAIL
Re: redeploy myfaces website
The only question would be IMO, if you keep the logos for example in the root project's site, what happens when you generate the site just for a module of that subproject? will it have the resources copied from the root? no problem there when you move the sites, root and modules, into a common context, but in this case when you check your module's site locally, the resources from the root won't be there...what do you think, can we leave with that? regards, Catalin On Wed, Mar 26, 2008 at 12:18 AM, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello Scott, just checked the generated html of the site. The site plugin creates the correct relative reference to the graphic. Should I remove the portlet bridge logo from the myfaces-site-skin? Regards Bernd Scott O'Bryan schrieb: I wasn't too clear so let me explain, I have 3 top-level projects. Each of the core projects (of which there are 2) have 3 modules with the third module (the examples module) containing two more. In EACH core project I have one site.xml file. The graphic in all of the modules of each core project reference the graphic correctly because they know where they are located relative to the root project. So if Tobago had 1 core project with 40 modules, your root project could refer to your local graphic and the pages for all your modules would reference this graphic correctly. If you had multiple root projects, like the bridge does, you would need a new site.xml for each one anyway. Is this correct or am I missing something? Scott Scott O'Bryan wrote: Bernd, That isn't entirely true. The bridge has 3 modules (right now) which contribute to the site. The sub-modules just reference the graphic from the main site. In my case I'm even piecing the pieces together amongst a separate site project and core projects (the core references the site project's graphics). In the case of modules under one root, the graphic simply needs to be in your root project. If it is, I believe all the other url's will refer to it correctly because it will know how to construct the relative urls. Scott Bernd Bohmann wrote: Hello Scott, the tobago project has 30 modules. If the tobago logo isn't included in the myfaces-site-skin the tobago logo must be included in 30 resource dirs of the site or I have to create 30 site.xml files to reference the logo. The portlet bridge has 3 site modules now. For every new module you must create a new site.xml to reference the logo. I don't like to maintain to many files with the same content. But we waste some space on myfaces.apache.org. Regards Bernd Scott O'Bryan schrieb: Well that was kind of my point. Why should the bridge logo be in the skin? If it is in the skin then every project gets a copy when it's deployed. IMO the myfaces logo should be in the skin and the project logos should be with the project. That said, I'll certainly abide by what everyone else thinks is best because I too can appreciate consistency. Scott Bernd Bohmann wrote:d Hello Scott, I just checked in the logo from the bridge site project to the myfaces-site-skin. The myfaces-site-skin contains already the tobago logo. The tobago logo has the path images/tobagoLogo.png, the bridge logo has the path images/portlet_bridge_logo.png und the myfaces logo has the path images/myfaces-logo.png in the myfaces-site-skin. I think if other subprojects or the master myfaces site are using a logo from a subproject, it should be used from the site-skin. I don't like to duplicate the graphics in the repository. Regards Bernd Scott O'Bryan schrieb: Hey Bernd, Where did you get the logo from? I skinned the portlet bridge graphic yesterday and I had to modify some of the white-space to make it look right. Right now the bridge is using it's own logo, but I can certainly pull that from skin if you want me to. One reason we may NOT want to pull these from the skin is that although the MyFaces logo will be needed by the sub-project, the other graphics won't. Yet putting these in the skin will make them available to all projects on their builds. Scott On Tue, Mar 25, 2008 at 4:19 AM, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello, just added the logo of the portlet bridge to the myfaces-site-skin. Is a trinidad logo available? And I would suggest following header Apache|MyFaces|Core|Trinidad|Tobago|Tomahawk|Orchestra|Portlet Bridge (no Sandbox every project has a sandbox no JSF 1.1-1.2) or Apache|MyFaces|Download|Mailing Lists (News archive makes no sense in the header) for the subprojects for example Tobago Apache|MyFaces|Tobago|Download|Mailing Lists I would suggest following banner on the main page MyFaces Logo| Apache Logo for the subprojects Subproject Logo or Name | MyFaces
[VOTE] Release of myfaces buildtools archetypes 1.0.1
Hi, I was running the needed tasks to get the 1.0.1 release of Apache MyFaces Build Tools Archetypes out. This release has fixes using jetty plugins and includes a myfaces-archetype-helloworld-portlets. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.buildtools v1.0.1 (only archetypes) [1] The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.0.1 artifacts and vote! For run the archetypes just do the following: mvn archetype:generate -DarchetypeCatalog= http://people.apache.org/~lu4242/m2-archetypes-101 Choose the archetype you want, and give the groupId, artifactId and other properties. Then on the path of the generated archetype mvn clean jetty:run For portlets plugin: mvn clean -PjettyConfig jetty:run Then look to http://localhost:8080 and that's all. Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] http://people.apache.org/~lu4242/m2-archetypes-101 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
Re: renderedIfEmpty parameter for t:messages (for message-updates by AJAX requests)
Hi, I like the idea of making that the default behavior. I think for t:messages it should be save to do so. As for h:messages I'm not sure how detailed the spec is there. I'll better check that before touching h:messages. I also don't know what mojarra does, but I would guess that they do the same thing as we do at the moment. forceSpan would also work for me I guess. But if there it is ok to ajust the default behavior of t:messages I'd prefer that solution because its one parameter less the user needs to know and think about. thanks for your ideas guys Ernst On Tue, Mar 25, 2008 at 10:27 PM, Cagatay Civici [EMAIL PROTECTED] wrote: Hi, For t:message and t:messages, there's already a forceSpan attribute, will it work for you Ernst? Cagatay On Tue, Mar 25, 2008 at 11:17 PM, simon [EMAIL PROTECTED] wrote: On Tue, 2008-03-25 at 21:45 +0100, simon wrote: On Tue, 2008-03-25 at 20:50 +0100, Ernst Fastl wrote: Hi, I would like to add renderedIfEmpty to the t:messages component which per default is false (current behaviour) The reason for that: To update/append FacesMessages to a messages-component after AJAX requests (e.g. PPR) it has to be possible to locate a DOM element to which this messages can be appended. One could also think of automatically adding a CSS-style display:none if the empty table/list is rendered which is reset by any JavaScript updates to the messages. Alternatively we could create a new messages-component which supports that. If anybody can think of reasons why this parameter should not be added please tell. Otherwise I'll file a JIRA issue and start implementing on thursday evening. Does your second suggestion (CSS-style display:none) mean to always render the div, but when there are no messages do: div id=.. style=display:none/ and let javascript modify the style if messages need to be added to it after a ppr request? If so, I think that is nicer. Logically, it makes sense too; the h:messages has not been marked with rendered=false, it just happens to have no messages. So the div should be present, but hidden. And it means that no extra attribute is needed. I cannot imagine any application that would break because of the introduction of a div with display:none set. BTW, I was thinking about making this change in h:messages, not just in t:messages. However even if the change is done in core, the same functionality would still be needed in t:messages unless Sun Mojarra's h:messages component also renders a hidden div when empty. Any idea what Mojarra does here? Regards, Simon
Re: renderedIfEmpty parameter for t:messages (for message-updates by AJAX requests)
I would not recommend forceSpan as an attribute as the use of a span is renderer specific, not component specific. The component should not care how the renderer works On Tue, Mar 25, 2008 at 4:41 PM, Ernst Fastl [EMAIL PROTECTED] wrote: Hi, I like the idea of making that the default behavior. I think for t:messages it should be save to do so. As for h:messages I'm not sure how detailed the spec is there. I'll better check that before touching h:messages. I also don't know what mojarra does, but I would guess that they do the same thing as we do at the moment. forceSpan would also work for me I guess. But if there it is ok to ajust the default behavior of t:messages I'd prefer that solution because its one parameter less the user needs to know and think about. thanks for your ideas guys Ernst On Tue, Mar 25, 2008 at 10:27 PM, Cagatay Civici [EMAIL PROTECTED] wrote: Hi, For t:message and t:messages, there's already a forceSpan attribute, will it work for you Ernst? Cagatay On Tue, Mar 25, 2008 at 11:17 PM, simon [EMAIL PROTECTED] wrote: On Tue, 2008-03-25 at 21:45 +0100, simon wrote: On Tue, 2008-03-25 at 20:50 +0100, Ernst Fastl wrote: Hi, I would like to add renderedIfEmpty to the t:messages component which per default is false (current behaviour) The reason for that: To update/append FacesMessages to a messages-component after AJAX requests (e.g. PPR) it has to be possible to locate a DOM element to which this messages can be appended. One could also think of automatically adding a CSS-style display:none if the empty table/list is rendered which is reset by any JavaScript updates to the messages. Alternatively we could create a new messages-component which supports that. If anybody can think of reasons why this parameter should not be added please tell. Otherwise I'll file a JIRA issue and start implementing on thursday evening. Does your second suggestion (CSS-style display:none) mean to always render the div, but when there are no messages do: div id=.. style=display:none/ and let javascript modify the style if messages need to be added to it after a ppr request? If so, I think that is nicer. Logically, it makes sense too; the h:messages has not been marked with rendered=false, it just happens to have no messages. So the div should be present, but hidden. And it means that no extra attribute is needed. I cannot imagine any application that would break because of the introduction of a div with display:none set. BTW, I was thinking about making this change in h:messages, not just in t:messages. However even if the change is done in core, the same functionality would still be needed in t:messages unless Sun Mojarra's h:messages component also renders a hidden div when empty. Any idea what Mojarra does here? Regards, Simon
Re: redeploy myfaces website
Yeah, I think when generating the site, you generally want to generate from the root. Mostly this is done with continuum, but if you generate the site on a subproject, things get wonkey -- Yes, that's the technical term :) As an addendum to what I said before, it seems that modules resolve correctly as long at the graphic is in the same root project. External URL's are not referenced correctly if they are relative. I fixed this for the portal site. But yeah, I think it's cleaner for everyone involved if each subproject has their own logo. Only the myfaces logo should be in the skin since it's needed by all projects... Scott Catalin Kormos wrote: The only question would be IMO, if you keep the logos for example in the root project's site, what happens when you generate the site just for a module of that subproject? will it have the resources copied from the root? no problem there when you move the sites, root and modules, into a common context, but in this case when you check your module's site locally, the resources from the root won't be there...what do you think, can we leave with that? regards, Catalin On Wed, Mar 26, 2008 at 12:18 AM, Bernd Bohmann [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hello Scott, just checked the generated html of the site. The site plugin creates the correct relative reference to the graphic. Should I remove the portlet bridge logo from the myfaces-site-skin? Regards Bernd Scott O'Bryan schrieb: I wasn't too clear so let me explain, I have 3 top-level projects. Each of the core projects (of which there are 2) have 3 modules with the third module (the examples module) containing two more. In EACH core project I have one site.xml file. The graphic in all of the modules of each core project reference the graphic correctly because they know where they are located relative to the root project. So if Tobago had 1 core project with 40 modules, your root project could refer to your local graphic and the pages for all your modules would reference this graphic correctly. If you had multiple root projects, like the bridge does, you would need a new site.xml for each one anyway. Is this correct or am I missing something? Scott Scott O'Bryan wrote: Bernd, That isn't entirely true. The bridge has 3 modules (right now) which contribute to the site. The sub-modules just reference the graphic from the main site. In my case I'm even piecing the pieces together amongst a separate site project and core projects (the core references the site project's graphics). In the case of modules under one root, the graphic simply needs to be in your root project. If it is, I believe all the other url's will refer to it correctly because it will know how to construct the relative urls. Scott Bernd Bohmann wrote: Hello Scott, the tobago project has 30 modules. If the tobago logo isn't included in the myfaces-site-skin the tobago logo must be included in 30 resource dirs of the site or I have to create 30 site.xml files to reference the logo. The portlet bridge has 3 site modules now. For every new module you must create a new site.xml to reference the logo. I don't like to maintain to many files with the same content. But we waste some space on myfaces.apache.org http://myfaces.apache.org. Regards Bernd Scott O'Bryan schrieb: Well that was kind of my point. Why should the bridge logo be in the skin? If it is in the skin then every project gets a copy when it's deployed. IMO the myfaces logo should be in the skin and the project logos should be with the project. That said, I'll certainly abide by what everyone else thinks is best because I too can appreciate consistency. Scott Bernd Bohmann wrote:d Hello Scott, I just checked in the logo from the bridge site project to the myfaces-site-skin. The myfaces-site-skin contains already the tobago logo. The tobago logo has the path images/tobagoLogo.png, the bridge logo has the path images/portlet_bridge_logo.png und the myfaces logo has the path images/myfaces-logo.png in the myfaces-site-skin. I think if other subprojects or the master myfaces site are using a logo from a subproject, it should be used from the site-skin. I don't like to duplicate the graphics in the repository. Regards Bernd Scott O'Bryan schrieb: Hey Bernd, Where did you get the logo from? I skinned the portlet bridge graphic yesterday and I had to modify some of the white-space to
Re: [VOTE] Release of myfaces buildtools archetypes 1.0.1
+1 Nice work! If you happen to run an old version of the maven archetype plugin (it was my case), just run: mvn archetype:generate -DarchetypeCatalog=http://people.apache.org/~lu4242/m2-archetypes-101 -U And Leonardo, you should vote too to make the second vote ;-) Cheers, Bruno On 25/03/2008, Leonardo Uribe [EMAIL PROTECTED] wrote: Hi, I was running the needed tasks to get the 1.0.1 release of Apache MyFaces Build Tools Archetypes out. This release has fixes using jetty plugins and includes a myfaces-archetype-helloworld-portlets. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.buildtools v1.0.1 (only archetypes) [1] The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.0.1 artifacts and vote! For run the archetypes just do the following: mvn archetype:generate -DarchetypeCatalog=http://people.apache.org/~lu4242/m2-archetypes-101 Choose the archetype you want, and give the groupId, artifactId and other properties. Then on the path of the generated archetype mvn clean jetty:run For portlets plugin: mvn clean -PjettyConfig jetty:run Then look to http://localhost:8080 and that's all. Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] http://people.apache.org/~lu4242/m2-archetypes-101 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
Re: [VOTE] Release of myfaces buildtools archetypes 1.0.1
+1 I reviewed the portlet bits. Very good work. Leonardo Uribe wrote: Hi, I was running the needed tasks to get the 1.0.1 release of Apache MyFaces Build Tools Archetypes out. This release has fixes using jetty plugins and includes a myfaces-archetype-helloworld-portlets. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.buildtools v1.0.1 (only archetypes) [1] The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.0.1 artifacts and vote! For run the archetypes just do the following: mvn archetype:generate -DarchetypeCatalog=http://people.apache.org/~lu4242/m2-archetypes-101 http://people.apache.org/%7Elu4242/m2-archetypes-101 Choose the archetype you want, and give the groupId, artifactId and other properties. Then on the path of the generated archetype mvn clean jetty:run For portlets plugin: mvn clean -PjettyConfig jetty:run Then look to http://localhost:8080 and that's all. Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] http://people.apache.org/~lu4242/m2-archetypes-101 http://people.apache.org/%7Elu4242/m2-archetypes-101 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
Re: [VOTE] Release of myfaces buildtools archetypes 1.0.1
+1
Re: renderedIfEmpty parameter for t:messages (for message-updates by AJAX requests)
that would be another advantage of the simple default behavior to render whatever (ul, table, span, ...) the component usually renders also if there are no messages wouldn't it? On Tue, Mar 25, 2008 at 11:51 PM, Andrew Robinson [EMAIL PROTECTED] wrote: I would not recommend forceSpan as an attribute as the use of a span is renderer specific, not component specific. The component should not care how the renderer works On Tue, Mar 25, 2008 at 4:41 PM, Ernst Fastl [EMAIL PROTECTED] wrote: Hi, I like the idea of making that the default behavior. I think for t:messages it should be save to do so. As for h:messages I'm not sure how detailed the spec is there. I'll better check that before touching h:messages. I also don't know what mojarra does, but I would guess that they do the same thing as we do at the moment. forceSpan would also work for me I guess. But if there it is ok to ajust the default behavior of t:messages I'd prefer that solution because its one parameter less the user needs to know and think about. thanks for your ideas guys Ernst On Tue, Mar 25, 2008 at 10:27 PM, Cagatay Civici [EMAIL PROTECTED] wrote: Hi, For t:message and t:messages, there's already a forceSpan attribute, will it work for you Ernst? Cagatay On Tue, Mar 25, 2008 at 11:17 PM, simon [EMAIL PROTECTED] wrote: On Tue, 2008-03-25 at 21:45 +0100, simon wrote: On Tue, 2008-03-25 at 20:50 +0100, Ernst Fastl wrote: Hi, I would like to add renderedIfEmpty to the t:messages component which per default is false (current behaviour) The reason for that: To update/append FacesMessages to a messages-component after AJAX requests (e.g. PPR) it has to be possible to locate a DOM element to which this messages can be appended. One could also think of automatically adding a CSS-style display:none if the empty table/list is rendered which is reset by any JavaScript updates to the messages. Alternatively we could create a new messages-component which supports that. If anybody can think of reasons why this parameter should not be added please tell. Otherwise I'll file a JIRA issue and start implementing on thursday evening. Does your second suggestion (CSS-style display:none) mean to always render the div, but when there are no messages do: div id=.. style=display:none/ and let javascript modify the style if messages need to be added to it after a ppr request? If so, I think that is nicer. Logically, it makes sense too; the h:messages has not been marked with rendered=false, it just happens to have no messages. So the div should be present, but hidden. And it means that no extra attribute is needed. I cannot imagine any application that would break because of the introduction of a div with display:none set. BTW, I was thinking about making this change in h:messages, not just in t:messages. However even if the change is done in core, the same functionality would still be needed in t:messages unless Sun Mojarra's h:messages component also renders a hidden div when empty. Any idea what Mojarra does here? Regards, Simon
Re: [VOTE] Release of myfaces buildtools archetypes 1.0.1
+1 !!! This is very nice indeed. On Tue, Mar 25, 2008 at 3:25 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: +1 -- Grant Smith
[jira] Commented: (PORTLETBRIDGE-31) BridgeImpl doesn't check for null Map values
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12582125#action_12582125 ] Kito D. Mann commented on PORTLETBRIDGE-31: --- I see what you're saying. Let me know what you think of this new patch. BridgeImpl doesn't check for null Map values Key: PORTLETBRIDGE-31 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-31 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 1.0.0-alpha-2 Environment: Windows XP, Tomcat 6, eXo portal, JSF RI Reporter: Kito D. Mann Attachments: BridgeImpl.patch When copying request values, the Bridge doesn't check for null. Specifically, the isExcludedFromBridgeRequestScope method doesn't check for null. This causes a problem with eXo portal (I suppose it puts a null value in that map). Here's the stack trace: java.lang.NullPointerException at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.isExcludedFromBridgeRequestScope(BridgeImpl.java:893) at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.copyRequestMap(BridgeImpl.java:877) at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.saveBridgeRequestScopeData(BridgeImpl.java:837) at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:267) at javax.portlet.faces.GenericFacesPortlet.doBridgeDispatch(GenericFacesPortlet.java:331) at javax.portlet.faces.GenericFacesPortlet.processAction(GenericFacesPortlet.java:189) at org.exoplatform.services.portletcontainer.plugins.pc.aop.PortletMethodCommand.processAction(PortletMethodCommand.java:67) at org.exoplatform.services.portletcontainer.plugins.pc.aop.BaseCommandUnit.execute(BaseCommandUnit.java:45) at org.exoplatform.container.component.ExecutionContext.executeNextUnit(ExecutionContext.java:38) at org.exoplatform.services.portletcontainer.plugins.pc.aop.BaseCommandUnit.processAction(BaseCommandUnit.java:61) at org.exoplatform.services.portletcontainer.plugins.pc.aop.BaseCommandUnit.execute(BaseCommandUnit.java:45) at org.exoplatform.container.component.ExecutionContext.executeNextUnit(ExecutionContext.java:38) at org.exoplatform.services.portletcontainer.plugins.pc.aop.PortletCacheCommand.processAction(PortletCacheCommand.java:220) at org.exoplatform.services.portletcontainer.plugins.pc.aop.BaseCommandUnit.execute(BaseCommandUnit.java:45) at org.exoplatform.container.component.ExecutionContext.executeNextUnit(ExecutionContext.java:38) at org.exoplatform.services.portletcontainer.plugins.pc.aop.PortletFilterCommand.processAction(PortletFilterCommand.java:71) at org.exoplatform.services.portletcontainer.plugins.pc.aop.BaseCommandUnit.execute(BaseCommandUnit.java:45) at org.exoplatform.container.component.ExecutionContext.executeNextUnit(ExecutionContext.java:38) at org.exoplatform.services.portletcontainer.plugins.pc.aop.PortletSecurityCommand.processAction(PortletSecurityCommand.java:52) at org.exoplatform.services.portletcontainer.plugins.pc.aop.BaseCommandUnit.execute(BaseCommandUnit.java:45) at org.exoplatform.container.component.ExecutionContext.executeNextUnit(ExecutionContext.java:38) at org.exoplatform.services.portletcontainer.plugins.pc.aop.BaseCommandUnit.processAction(BaseCommandUnit.java:61) at org.exoplatform.services.portletcontainer.plugins.pc.aop.BaseCommandUnit.execute(BaseCommandUnit.java:45) at org.exoplatform.container.component.ExecutionContext.execute(ExecutionContext.java:32) at org.exoplatform.services.portletcontainer.plugins.pc.aop.PortletCommandChain.doProcessAction(PortletCommandChain.java:52) at org.exoplatform.services.portletcontainer.plugins.pc.PortletApplicationHandler.process(PortletApplicationHandler.java:241) at org.exoplatform.services.portletcontainer.impl.servlet.ServletWrapper.service(ServletWrapper.java:100) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505) at org.exoplatform.services.portletcontainer.plugins.pc.PortletContainerDispatcher.dispatch(PortletContainerDispatcher.java:537) at
