Re: Ochestra Site
any news? On 3/25/07, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: fine w/ me... On 3/25/07, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > Hi! > > I saw some xdocs files are included in Ochestra; > > anyone volunteering to get it added to the site build? > > I managed to make orchestra/core build a site, though, I had to apply > the following patch to the master-pom: > > Index: master-pom/pom.xml > === > --- master-pom/pom.xml (Revision 522170) > +++ master-pom/pom.xml (Arbeitskopie) > @@ -462,8 +462,8 @@ > maven-checkstyle-plugin > 2.1 > > - > config/myfaces-checks.xml > - > config/myfaces-header.txt > + > http://svn.apache.org/repos/asf/myfaces/maven/trunk/build-tools/src/main/resources/config/myfaces-checks.xml > + > http://svn.apache.org/repos/asf/myfaces/maven/trunk/build-tools/src/main/resources/config/myfaces-header.txt > > > > @@ -522,8 +522,8 @@ > org.apache.maven.plugins > maven-checkstyle-plugin > > - > config/myfaces-checks.xml > - > config/myfaces-header.txt > + > http://svn.apache.org/repos/asf/myfaces/maven/trunk/build-tools/src/main/resources/config/myfaces-checks.xml > + > http://svn.apache.org/repos/asf/myfaces/maven/trunk/build-tools/src/main/resources/config/myfaces-header.txt > > 2.1 > > > > Any objection to commit it? Or is there any other way to tell maven > where to search the config files? > And then, how to move on? > What needs to be done to publish the site? > > Any help will be really appreciated. > Ciao, > Mario > > -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
[jira] Commented: (MYFACES-1561) Validators, Converters are not recognized
[ https://issues.apache.org/jira/browse/MYFACES-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484751 ] Christoph Ebner commented on MYFACES-1561: -- I created the patch for UIComponentClassicTagBase now as martin suggested . i realized, that while reverting the code-formatters changes, i must have also undone the changes i made manually. anyhow, the new patch (V2) should definitely work! regards, christoph > Validators, Converters are not recognized > - > > Key: MYFACES-1561 > URL: https://issues.apache.org/jira/browse/MYFACES-1561 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-252 >Affects Versions: 1.2.0-SNAPSHOT > Environment: Tomcat 6.0.10 >Reporter: Cagatay Civici > Assigned To: Christoph Ebner > Attachments: ConverterTag.java, ConverterTag.patch, > UIComponentClassicTagBase.java, UIComponentClassicTagBase.patch, > UIComponentClassicTagBase_V2.patch > > > For a component like; > > > > > Both validators and converters specified for the input text are ignored. > UIInput getValidators.length returns 0 and getConverter is always null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1561) Validators, Converters are not recognized
[ https://issues.apache.org/jira/browse/MYFACES-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484733 ] Martin Marinschek commented on MYFACES-1561: Hi Christoph, you should make sure that you don't create patches which are splattered with formatting changes - remember your changes first, than do an svn-revert, then do the changes on a clean file from the repository. @Dennis: I think the difference is this line: UIComponentClassicTagBase componentTag = UIComponentClassicTagBase.getParentUIComponentClassicTagBase(pageContext); regards, Martin > Validators, Converters are not recognized > - > > Key: MYFACES-1561 > URL: https://issues.apache.org/jira/browse/MYFACES-1561 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-252 >Affects Versions: 1.2.0-SNAPSHOT > Environment: Tomcat 6.0.10 >Reporter: Cagatay Civici > Assigned To: Christoph Ebner > Attachments: ConverterTag.java, ConverterTag.patch, > UIComponentClassicTagBase.java, UIComponentClassicTagBase.patch > > > For a component like; > > > > > Both validators and converters specified for the input text are ignored. > UIInput getValidators.length returns 0 and getConverter is always null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-339) Add "align" attribute to tc:cell
Add "align" attribute to tc:cell Key: TOBAGO-339 URL: https://issues.apache.org/jira/browse/TOBAGO-339 Project: MyFaces Tobago Issue Type: Improvement Affects Versions: 1.0.11 Environment: No matter Reporter: Boris Kovalenko Hello! Is this possible to add "align" attribute for tc:cell? Or this is prohibited by Tobago design? I see no obstacles as tc:column already has this one. With respect, Boris -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1572) getFirst() and getRows() methods in UIData don't return correct values
[ https://issues.apache.org/jira/browse/MYFACES-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484691 ] Paul McMahan commented on MYFACES-1572: --- correction -- I meant to say the patch moves assignment of _rowsSet to the *setRows()* method > getFirst() and getRows() methods in UIData don't return correct values > -- > > Key: MYFACES-1572 > URL: https://issues.apache.org/jira/browse/MYFACES-1572 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-252 >Affects Versions: 1.2.0-SNAPSHOT >Reporter: Paul McMahan > Assigned To: Matthias Weßendorf >Priority: Critical > Fix For: 1.2.0-SNAPSHOT > > Attachments: MYFACES-1572.2.patch > > > UIData data = new UIData(); > data.setFirst(1); > data.getFirst(); // returns 0 > data.setRows(1); > data.getRows(); // returns 0 > Looks like there may be a bug in the code generator. The setFirst() and > setRows() methods should be assigning _firstSet=true and _rowsSet=true. > Maybe there is some way to influence this behavior in UIData's template? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1578) WebXml class has thread-safety issue (AddResourceFactory reports ExtensionFilter not mapped)
WebXml class has thread-safety issue (AddResourceFactory reports ExtensionFilter not mapped) Key: MYFACES-1578 URL: https://issues.apache.org/jira/browse/MYFACES-1578 Project: MyFaces Core Issue Type: Bug Reporter: Simon Kitching In trunk of shared module, class o.a.m.shared.webapp.webxml.WebXml is a singleton (instance placed in the application map) but it does not synchronize access to its members. For example, when the object is first created and stored into the application map on startup, member _facesExtensionsFilterMappings is null. When a later call comes in to method getFacesExtensionsFilterMappings() on the singleton instance and it is discovered that the value is null a new array is created and populated. However this method does not protect against race condtions in any way, so two requests that pass through the ExtensionsFilter can be executing this code concurrently, with potentially nasty effects. We have a load test that is actually experiencing intermittent exceptions when run against a freshly-started webapp. The exception is actually in AddResourceFactory.checkEnvironment, where it complains that there is no mapping for the ExtensionFilter, and the thread-race above could well be the cause. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1577) PropertyResolver should throw PropertyNotFoundException
[ https://issues.apache.org/jira/browse/MYFACES-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan updated MYFACES-1577: -- Status: Patch Available (was: Open) > PropertyResolver should throw PropertyNotFoundException > --- > > Key: MYFACES-1577 > URL: https://issues.apache.org/jira/browse/MYFACES-1577 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-252 >Affects Versions: 1.2.0-SNAPSHOT >Reporter: Paul McMahan > Attachments: MYFACES-1577.patch > > > According to the spec several methods in PropertyResolver should throw > PropertyNotFoundException in the following circumstances: > getValue(Object base, int index) > PropertyNotFoundException - if the index is out of bounds or if base is > null > setValue(Object base, int index, Object value) > PropertyNotFoundException - if the index is out of bounds or if base is > null > setValue(Object base, Object property, Object value) > PropertyNotFoundException - if the specified bean base object property > does not exist or if base or property is null > BTW, MYFACES-1576 already addressed these two cases: > getType(Object base, int index) > PropertyNotFoundException - if the index is out of bounds or if base is > null > getType(Object base, Object property) > PropertyNotFoundException - if the specified bean base object property > does not exist or if base or property is null -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1577) PropertyResolver should throw PropertyNotFoundException
PropertyResolver should throw PropertyNotFoundException --- Key: MYFACES-1577 URL: https://issues.apache.org/jira/browse/MYFACES-1577 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan According to the spec several methods in PropertyResolver should throw PropertyNotFoundException in the following circumstances: getValue(Object base, int index) PropertyNotFoundException - if the index is out of bounds or if base is null setValue(Object base, int index, Object value) PropertyNotFoundException - if the index is out of bounds or if base is null setValue(Object base, Object property, Object value) PropertyNotFoundException - if the specified bean base object property does not exist or if base or property is null BTW, MYFACES-1576 already addressed these two cases: getType(Object base, int index) PropertyNotFoundException - if the index is out of bounds or if base is null getType(Object base, Object property) PropertyNotFoundException - if the specified bean base object property does not exist or if base or property is null -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1561) Validators, Converters are not recognized
[ https://issues.apache.org/jira/browse/MYFACES-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484648 ] Dennis Byrne commented on MYFACES-1561: --- Hi Christoph, I appreciate your interest here but can you please look at the patch files? It looks like a formatter was run on them and not much else. The UIComponentClassicTagBase patch does have one null check in it. Please advise > Validators, Converters are not recognized > - > > Key: MYFACES-1561 > URL: https://issues.apache.org/jira/browse/MYFACES-1561 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-252 >Affects Versions: 1.2.0-SNAPSHOT > Environment: Tomcat 6.0.10 >Reporter: Cagatay Civici > Assigned To: Christoph Ebner > Attachments: ConverterTag.java, ConverterTag.patch, > UIComponentClassicTagBase.java, UIComponentClassicTagBase.patch > > > For a component like; > > > > > Both validators and converters specified for the input text are ignored. > UIInput getValidators.length returns 0 and getConverter is always null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1561) Validators, Converters are not recognized
[ https://issues.apache.org/jira/browse/MYFACES-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484606 ] Christoph Ebner commented on MYFACES-1561: -- Sorry, yes they were fixes. I added them as patches now. > Validators, Converters are not recognized > - > > Key: MYFACES-1561 > URL: https://issues.apache.org/jira/browse/MYFACES-1561 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-252 >Affects Versions: 1.2.0-SNAPSHOT > Environment: Tomcat 6.0.10 >Reporter: Cagatay Civici > Assigned To: Christoph Ebner > Attachments: ConverterTag.java, ConverterTag.patch, > UIComponentClassicTagBase.java, UIComponentClassicTagBase.patch > > > For a component like; > > > > > Both validators and converters specified for the input text are ignored. > UIInput getValidators.length returns 0 and getConverter is always null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-942) Renderer set in extended html component jsp tag handler rather than in component class
Renderer set in extended html component jsp tag handler rather than in component class -- Key: TOMAHAWK-942 URL: https://issues.apache.org/jira/browse/TOMAHAWK-942 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.6-SNAPSHOT Reporter: Mike Kienenberger Priority: Minor A number of the extended html components simply inherit the renderer specified in shared, and then set a different renderer inside of the jsp tag handler. This can break non-jsp viewhandlers (like Facelets and Shale/Clay) since the components have the incorrect renderer specified. Setting the correct default renderer type should be done in the component. I'll add a list of affected components later, but I recall that this seemed to be the design pattern for all of the extended components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1572) getFirst() and getRows() methods in UIData don't return correct values
[ https://issues.apache.org/jira/browse/MYFACES-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan updated MYFACES-1572: -- Status: Patch Available (was: Reopened) > getFirst() and getRows() methods in UIData don't return correct values > -- > > Key: MYFACES-1572 > URL: https://issues.apache.org/jira/browse/MYFACES-1572 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-252 >Affects Versions: 1.2.0-SNAPSHOT >Reporter: Paul McMahan > Assigned To: Matthias Weßendorf >Priority: Critical > Fix For: 1.2.0-SNAPSHOT > > Attachments: MYFACES-1572.2.patch > > > UIData data = new UIData(); > data.setFirst(1); > data.getFirst(); // returns 0 > data.setRows(1); > data.getRows(); // returns 0 > Looks like there may be a bug in the code generator. The setFirst() and > setRows() methods should be assigning _firstSet=true and _rowsSet=true. > Maybe there is some way to influence this behavior in UIData's template? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (MYFACES-1572) getFirst() and getRows() methods in UIData don't return correct values
[ https://issues.apache.org/jira/browse/MYFACES-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan reopened MYFACES-1572: --- still seeing the problem with getRows in generated UIData class. seems that _rowsSet assignment needs to be in setRows() method in the template. > getFirst() and getRows() methods in UIData don't return correct values > -- > > Key: MYFACES-1572 > URL: https://issues.apache.org/jira/browse/MYFACES-1572 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-252 >Affects Versions: 1.2.0-SNAPSHOT >Reporter: Paul McMahan > Assigned To: Matthias Weßendorf >Priority: Critical > Fix For: 1.2.0-SNAPSHOT > > > UIData data = new UIData(); > data.setFirst(1); > data.getFirst(); // returns 0 > data.setRows(1); > data.getRows(); // returns 0 > Looks like there may be a bug in the code generator. The setFirst() and > setRows() methods should be assigning _firstSet=true and _rowsSet=true. > Maybe there is some way to influence this behavior in UIData's template? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Request to remove some of the attachments in a specific new component, Jira TOMAHAWK-829
I deleted what you requested. I tried to keep the latest versions of the attachments below, but I don't know if I succeeded. This was a time-consuming task -- please don't do that again :-) On 3/26/07, Jihoon Kim <[EMAIL PROTECTED]> wrote: Hi, I was wondering if someone can clean up a specific Jira issue for me. The issue Key is "TOMAHAWK-829". I was hoping that everything EXCEPT the following attachments can be removed from "File Attachments". The attachments NOT to remove are : FilesToExtractFromRoot.zip noDirectoryPatch.patch dynamicTable.jpg Thank You!
Re: TOMAHAWK-872
No, 1.1.6-SNAPSHOT should already start to show up. Damn. Our continuum build seems to have some troubles. Will check this. --Manfred On 3/27/07, Dennis Gesker <[EMAIL PROTECTED]> wrote: Thanks Manfred Is it safe to guess that when Tomahawk 1.1.5 is released 1.1.6-SNAPSHOT will start to show up under the the MyFaces nightly build link? Has an ETA been set for Tomahawk's 1.1.5 release? Also, thanks for looking at the patch. I'm grateful to both you and Ryan for getting it fixed. Thanks Dennis On 3/26/07, Manfred Geiler < [EMAIL PROTECTED]> wrote: > Just scheduled it for 1.1.6-SNAPSHOT > Digging deeper after the 1.1.5 is out. > --Manfred > > On 3/26/07, Dennis Gesker <[EMAIL PROTECTED]> wrote: > > https://issues.apache.org/jira/browse/TOMAHAWK-872 > > > > A patch was posted for this issue a few weeks ago. Any chance (or ETA?) on > > this patch being accepted? > > > > Dennis > > > > > > > -- > http://www.irian.at > Your JSF powerhouse - JSF Consulting, > Development and Courses in English and > German > > Professional Support for Apache MyFaces > -- Dennis R. Gesker email: [EMAIL PROTECTED] Key Id: 0xEFA10A51 -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Updated: (TOMAHAWK-941) Make ExcelExport work for suffixes other than *.jsf, for example when using *.faces or *.xhtml
[ https://issues.apache.org/jira/browse/TOMAHAWK-941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Poehler updated TOMAHAWK-941: --- Status: Patch Available (was: Open) > Make ExcelExport work for suffixes other than *.jsf, for example when using > *.faces or *.xhtml > -- > > Key: TOMAHAWK-941 > URL: https://issues.apache.org/jira/browse/TOMAHAWK-941 > Project: MyFaces Tomahawk > Issue Type: Improvement >Reporter: Marco Poehler >Priority: Minor > Attachments: patch.txt > > > The sandbox Excelexport forwards to the current view and write the excelfile > in the response using a PhaseListener. The Link build in the renderer uses a > hardcoded '.jsf'. So it doesn't work if you use another suffix in your > web.xml like .faces or .xhtml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-941) Make ExcelExport work for suffixes other than *.jsf, for example when using *.faces or *.xhtml
Make ExcelExport work for suffixes other than *.jsf, for example when using *.faces or *.xhtml -- Key: TOMAHAWK-941 URL: https://issues.apache.org/jira/browse/TOMAHAWK-941 Project: MyFaces Tomahawk Issue Type: Improvement Reporter: Marco Poehler Priority: Minor The sandbox Excelexport forwards to the current view and write the excelfile in the response using a PhaseListener. The Link build in the renderer uses a hardcoded '.jsf'. So it doesn't work if you use another suffix in your web.xml like .faces or .xhtml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TOMAHAWK-941) Make ExcelExport work for suffixes other than *.jsf, for example when using *.faces or *.xhtml
[ https://issues.apache.org/jira/browse/TOMAHAWK-941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Poehler updated TOMAHAWK-941: --- Status: Patch Available (was: Open) > Make ExcelExport work for suffixes other than *.jsf, for example when using > *.faces or *.xhtml > -- > > Key: TOMAHAWK-941 > URL: https://issues.apache.org/jira/browse/TOMAHAWK-941 > Project: MyFaces Tomahawk > Issue Type: Improvement >Reporter: Marco Poehler >Priority: Minor > > The sandbox Excelexport forwards to the current view and write the excelfile > in the response using a PhaseListener. The Link build in the renderer uses a > hardcoded '.jsf'. So it doesn't work if you use another suffix in your > web.xml like .faces or .xhtml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TOMAHAWK-941) Make ExcelExport work for suffixes other than *.jsf, for example when using *.faces or *.xhtml
[ https://issues.apache.org/jira/browse/TOMAHAWK-941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Poehler updated TOMAHAWK-941: --- Status: Open (was: Patch Available) > Make ExcelExport work for suffixes other than *.jsf, for example when using > *.faces or *.xhtml > -- > > Key: TOMAHAWK-941 > URL: https://issues.apache.org/jira/browse/TOMAHAWK-941 > Project: MyFaces Tomahawk > Issue Type: Improvement >Reporter: Marco Poehler >Priority: Minor > > The sandbox Excelexport forwards to the current view and write the excelfile > in the response using a PhaseListener. The Link build in the renderer uses a > hardcoded '.jsf'. So it doesn't work if you use another suffix in your > web.xml like .faces or .xhtml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOBAGO-337) field value can't be setted or cleared if state changes from enabled to disabeld
[ https://issues.apache.org/jira/browse/TOBAGO-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Volker Weber resolved TOBAGO-337. - Resolution: Invalid Fix Version/s: 1.0.11 Closing this because this is no bug, but application missbehavior > field value can't be setted or cleared if state changes from enabled to > disabeld > > > Key: TOBAGO-337 > URL: https://issues.apache.org/jira/browse/TOBAGO-337 > Project: MyFaces Tobago > Issue Type: Bug > Components: Core >Affects Versions: 1.0.10 > Environment: winxp prof, tomcat 5.5.20, myfaces 1.1.6 snap > (23.03.2007), tobago 1.0.11 snap (17.03.2007) >Reporter: Guido Dubois > Fix For: 1.0.11 > > Attachments: disabled.war > > > if field state changes from enabled to disabled it is not possible to set or > clear the fields content -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOBAGO-337) field value can't be setted or cleared if state changes from enabled to disabeld
[ https://issues.apache.org/jira/browse/TOBAGO-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484351 ] Volker Weber commented on TOBAGO-337: - I'm not fully sure what you are talking about, but if you are changing the evaluated value of a disabled (or readonly) expression during the jsf lifecycle (exept between after updateModel and before renderResponse) you will get such unexpected behavior. if (i guess) in your case the value of field1 updates (in updateModel) to less than 100 the other fields are disabled and not updated. The submited values stays in the component and are rerendered to the client, even if the model has another value. I'm closing this because ther is no bug, please reopen if you still think this is a bug in tobago. > field value can't be setted or cleared if state changes from enabled to > disabeld > > > Key: TOBAGO-337 > URL: https://issues.apache.org/jira/browse/TOBAGO-337 > Project: MyFaces Tobago > Issue Type: Bug > Components: Core >Affects Versions: 1.0.10 > Environment: winxp prof, tomcat 5.5.20, myfaces 1.1.6 snap > (23.03.2007), tobago 1.0.11 snap (17.03.2007) >Reporter: Guido Dubois > Fix For: 1.0.11 > > Attachments: disabled.war > > > if field state changes from enabled to disabled it is not possible to set or > clear the fields content -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ExcelExport
Marco,
Thanks for playing a part in the community. Please open an issue in the
issue tracker
http://issues.apache.org/jira/secure/BrowseProject.jspa?id=10600 , along
with your patch.
Dennis Byrne
On 3/27/07, Marco Pöhler <[EMAIL PROTECTED]> wrote:
Hi,
I have two minor changes made to the Excelexport to make it work with
facelets (or more exacly to work with other suffixes as .jsf) and to
avoid hints in new Excel-Versions if you have Numbers in Text-Cells.
This is my first try to contribute, I hope everything is okay. Don't
hesitate to correct me.
best regards
Marco
Index:
/myfaces-current/tomahawk/sandbox/core/src/main/java/org/apache/myfaces/custom/excelexport/ExcelExportRenderer.java
===
---
/myfaces-current/tomahawk/sandbox/core/src/main/java/org/apache/myfaces/custom/excelexport/ExcelExportRenderer.java
(revision 522807)
+++
/myfaces-current/tomahawk/sandbox/core/src/main/java/org/apache/myfaces/custom/excelexport/ExcelExportRenderer.java
(working copy)
@@ -67,8 +67,10 @@
private String getJSCall(FacesContext facesContext, String tableId) {
String viewId = StringUtils.split(
facesContext.getViewRoot().getViewId() , "\\.")[0];
-String contextPath =
facesContext.getExternalContext().getRequestContextPath();
-return "window.open('" + contextPath + viewId +
".jsf?excelExportTableId=" + tableId + "');return false;";
+return "window.open('"
++
facesContext.getApplication().getViewHandler().getActionURL(
+facesContext, viewId) + "?excelExportTableId="
++ tableId + "');return false;";
}
Index:
/myfaces-current/tomahawk/sandbox/core/src/main/java/org/apache/myfaces/custom/excelexport/ExcelExportPhaseListener.java
===
---
/myfaces-current/tomahawk/sandbox/core/src/main/java/org/apache/myfaces/custom/excelexport/ExcelExportPhaseListener.java
(revision 522807)
+++
/myfaces-current/tomahawk/sandbox/core/src/main/java/org/apache/myfaces/custom/excelexport/ExcelExportPhaseListener.java
(working copy)
@@ -117,6 +117,18 @@
cell.setEncoding(HSSFCell.ENCODING_UTF_16);
if(component instanceof ValueHolder) {
String stringValue =
RendererUtils.getStringValue(FacesContext.getCurrentInstance(),
component);
+// try some parsings
+try {
+cell.setCellValue(Double.parseDouble(stringValue));
+return;
+} catch (NumberFormatException nfe) {
+}
+try {
+cell.setCellNum(Short.parseShort(stringValue));
+return;
+} catch (NumberFormatException nfe) {
+}
+// default to string value
cell.setCellValue(stringValue);
}
}
--
Dennis Byrne
ExcelExport
Hi,
I have two minor changes made to the Excelexport to make it work with
facelets (or more exacly to work with other suffixes as .jsf) and to
avoid hints in new Excel-Versions if you have Numbers in Text-Cells.
This is my first try to contribute, I hope everything is okay. Don't
hesitate to correct me.
best regards
Marco
Index:
/myfaces-current/tomahawk/sandbox/core/src/main/java/org/apache/myfaces/custom/excelexport/ExcelExportRenderer.java
===
---
/myfaces-current/tomahawk/sandbox/core/src/main/java/org/apache/myfaces/custom/excelexport/ExcelExportRenderer.java
(revision 522807)
+++
/myfaces-current/tomahawk/sandbox/core/src/main/java/org/apache/myfaces/custom/excelexport/ExcelExportRenderer.java
(working copy)
@@ -67,8 +67,10 @@
private String getJSCall(FacesContext facesContext, String tableId) {
String viewId = StringUtils.split(
facesContext.getViewRoot().getViewId() , "\\.")[0];
-String contextPath =
facesContext.getExternalContext().getRequestContextPath();
-return "window.open('" + contextPath + viewId +
".jsf?excelExportTableId=" + tableId + "');return false;";
+return "window.open('"
++
facesContext.getApplication().getViewHandler().getActionURL(
+facesContext, viewId) + "?excelExportTableId="
++ tableId + "');return false;";
}
Index:
/myfaces-current/tomahawk/sandbox/core/src/main/java/org/apache/myfaces/custom/excelexport/ExcelExportPhaseListener.java
===
---
/myfaces-current/tomahawk/sandbox/core/src/main/java/org/apache/myfaces/custom/excelexport/ExcelExportPhaseListener.java
(revision 522807)
+++
/myfaces-current/tomahawk/sandbox/core/src/main/java/org/apache/myfaces/custom/excelexport/ExcelExportPhaseListener.java
(working copy)
@@ -117,6 +117,18 @@
cell.setEncoding(HSSFCell.ENCODING_UTF_16);
if(component instanceof ValueHolder) {
String stringValue =
RendererUtils.getStringValue(FacesContext.getCurrentInstance(), component);
+// try some parsings
+try {
+cell.setCellValue(Double.parseDouble(stringValue));
+return;
+} catch (NumberFormatException nfe) {
+}
+try {
+cell.setCellNum(Short.parseShort(stringValue));
+return;
+} catch (NumberFormatException nfe) {
+}
+// default to string value
cell.setCellValue(stringValue);
}
}
Re: TOMAHAWK-872
Thanks Manfred Is it safe to guess that when Tomahawk 1.1.5 is released 1.1.6-SNAPSHOT will start to show up under the the MyFaces nightly build link? Has an ETA been set for Tomahawk's 1.1.5 release? Also, thanks for looking at the patch. I'm grateful to both you and Ryan for getting it fixed. Thanks Dennis On 3/26/07, Manfred Geiler <[EMAIL PROTECTED]> wrote: Just scheduled it for 1.1.6-SNAPSHOT Digging deeper after the 1.1.5 is out. --Manfred On 3/26/07, Dennis Gesker <[EMAIL PROTECTED]> wrote: > https://issues.apache.org/jira/browse/TOMAHAWK-872 > > A patch was posted for this issue a few weeks ago. Any chance (or ETA?) on > this patch being accepted? > > Dennis > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Dennis R. Gesker email: [EMAIL PROTECTED] Key Id: 0xEFA10A51
Request to remove some of the attachments in a specific new component, Jira TOMAHAWK-829
Hi, I was wondering if someone can clean up a specific Jira issue for me. The issue Key is "TOMAHAWK-829". I was hoping that everything EXCEPT the following attachments can be removed from "File Attachments". The attachments NOT to remove are : FilesToExtractFromRoot.zip noDirectoryPatch.patch dynamicTable.jpg Thank You!
