[jira] Resolved: (TOBAGO-799) pass ajax request parameter infos to clientside onSubmit function
[ https://issues.apache.org/jira/browse/TOBAGO-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Volker Weber resolved TOBAGO-799. - Resolution: Fixed Fix Version/s: 1.0.24 pass ajax request parameter infos to clientside onSubmit function - Key: TOBAGO-799 URL: https://issues.apache.org/jira/browse/TOBAGO-799 Project: MyFaces Tobago Issue Type: New Feature Components: Themes Reporter: Volker Weber Assignee: Volker Weber Fix For: 1.0.24 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] use of jul or commons logging on myfaces core 2.0
+1 for jul. However, I think we should add an utility class (ServletContextListnener? This is the easiest way I know of, if it qualifies for easiest at all) in myfaces-shared or extension to make it easier to configure the logger because it's way more annoying to configure than commons-logging backed with log4j imho. Regards, ~ Simon On Thu, Oct 1, 2009 at 1:25 AM, Mario Ivankovits ma...@ops.co.at wrote: +1 for jul reduces dependencies - and sun also use it, no? *Von:* Leonardo Uribe [mailto:lu4...@gmail.com] *Gesendet:* Donnerstag, 01. Oktober 2009 04:06 *An:* MyFaces Development *Betreff:* [VOTE] use of jul or commons logging on myfaces core 2.0 Hi Right now, facelets code added to myfaces core 2.0.x branch uses jul in this form: protected final static Logger log = Logger.getLogger(facelets.viewhandler); But the original myfaces code uses commons logging, (so if there is no agreement about use jul, we should unify logging code using commons-logging). It is necessary to unify in one way or another the code of 2.0.x branch, but before that, it is necessary to ask the community about this issue. So, please vote in this way: +1 for jul +1 for commons-logging +0 -1 and let the code as is (and a reason why). regards, Leonardo Uribe
[jira] Commented: (TOBAGO-695) Theme Scarborough missing right border off tc:box in IE 6
[ https://issues.apache.org/jira/browse/TOBAGO-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12761235#action_12761235 ] Helmut Swaczinna commented on TOBAGO-695: - Seems, you're not supporting Theme Scarborough anymore? Please have a look on the online demo with IE 6 and 7. Mostly all components are truncated on the right. Theme Scarborough missing right border off tc:box in IE 6 - Key: TOBAGO-695 URL: https://issues.apache.org/jira/browse/TOBAGO-695 Project: MyFaces Tobago Issue Type: Bug Components: Themes Affects Versions: 1.0.18 Environment: IE 6, online demo Reporter: Helmut Swaczinna You can the this at the online demo on every page -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] use of jul or commons logging on myfaces core 2.0
Again +1 for jul... One dependency less is always a good thing. Werner Leonardo Uribe schrieb: Hi Right now, facelets code added to myfaces core 2.0.x branch uses jul in this form: protected final static Logger log = Logger.getLogger(facelets.viewhandler); But the original myfaces code uses commons logging, (so if there is no agreement about use jul, we should unify logging code using commons-logging). It is necessary to unify in one way or another the code of 2.0.x branch, but before that, it is necessary to ask the community about this issue. So, please vote in this way: +1 for jul +1 for commons-logging +0 -1 and let the code as is (and a reason why). regards, Leonardo Uribe
RE: [VOTE] use of jul or commons logging on myfaces core 2.0
IMHO configuring the logger has to be solved by the used container. Ciao, Mario Von: Simon Lessard [mailto:simon.lessar...@gmail.com] Gesendet: Donnerstag, 01. Oktober 2009 16:57 An: MyFaces Development Betreff: Re: [VOTE] use of jul or commons logging on myfaces core 2.0 +1 for jul. However, I think we should add an utility class (ServletContextListnener? This is the easiest way I know of, if it qualifies for easiest at all) in myfaces-shared or extension to make it easier to configure the logger because it's way more annoying to configure than commons-logging backed with log4j imho. Regards, ~ Simon On Thu, Oct 1, 2009 at 1:25 AM, Mario Ivankovits ma...@ops.co.atmailto:ma...@ops.co.at wrote: +1 for jul reduces dependencies - and sun also use it, no? Von: Leonardo Uribe [mailto:lu4...@gmail.commailto:lu4...@gmail.com] Gesendet: Donnerstag, 01. Oktober 2009 04:06 An: MyFaces Development Betreff: [VOTE] use of jul or commons logging on myfaces core 2.0 Hi Right now, facelets code added to myfaces core 2.0.x branch uses jul in this form: protected final static Logger log = Logger.getLogger(facelets.viewhandler); But the original myfaces code uses commons logging, (so if there is no agreement about use jul, we should unify logging code using commons-logging). It is necessary to unify in one way or another the code of 2.0.x branch, but before that, it is necessary to ask the community about this issue. So, please vote in this way: +1 for jul +1 for commons-logging +0 -1 and let the code as is (and a reason why). regards, Leonardo Uribe
Screencast of what is cooking up in ext-scripting
Hello everyone I have made a small screencast of what is cooking up in ext-scriping. Have in mind that I am still not done with the MyFaces 2.0 integration but my personal deadline is the JSFDays 2010 to get a 1.0 out. http://www.youtube.com/watch?v=vUCCTCMjTPEfeature=youtube_gdata Anyway it just shows what I am working on in regards to myfaces 2.0. It does not show how you can add methods and remove them on the fly ;-) Werner
Re: [VOTE] use of jul or commons logging on myfaces core 2.0
2009/10/1 Leonardo Uribe lu4...@gmail.com: Right now, facelets code added to myfaces core 2.0.x branch uses jul in this form: protected final static Logger log = Logger.getLogger(facelets.viewhandler); But the original myfaces code uses commons logging, (so if there is no agreement about use jul, we should unify logging code using commons-logging). Why don't you consider using SLF4J? Probably it is the same question asked over and over again, but I try anyway :-D Antonio
Re: [VOTE] use of jul or commons logging on myfaces core 2.0
Antonio Petrelli schrieb: 2009/10/1 Leonardo Uribe lu4...@gmail.com: Right now, facelets code added to myfaces core 2.0.x branch uses jul in this form: protected final static Logger log = Logger.getLogger(facelets.viewhandler); But the original myfaces code uses commons logging, (so if there is no agreement about use jul, we should unify logging code using commons-logging). Why don't you consider using SLF4J? Probably it is the same question asked over and over again, but I try anyway :-D That would be a dependency replacement with another. Just my personal opinion regarding SLF4J ;-)
Re: [VOTE] use of jul or commons logging on myfaces core 2.0
2009/10/1 Werner Punz werner.p...@gmail.com: Why don't you consider using SLF4J? Probably it is the same question asked over and over again, but I try anyway :-D That would be a dependency replacement with another. Just my personal opinion regarding SLF4J Don't bother, I noticed that there is a bridge with which you can use JUL messages with SLF4J: http://www.slf4j.org/legacy.html For a library like MyFaces makes perfectly sense. Antonio
Re: [VOTE] use of jul or commons logging on myfaces core 2.0
+1 for JUL Antonio Petrelli wrote: 2009/10/1 Werner Punz werner.p...@gmail.com: Why don't you consider using SLF4J? Probably it is the same question asked over and over again, but I try anyway :-D That would be a dependency replacement with another. Just my personal opinion regarding SLF4J Don't bother, I noticed that there is a bridge with which you can use JUL messages with SLF4J: http://www.slf4j.org/legacy.html For a library like MyFaces makes perfectly sense. Antonio
Re: [VOTE] use of jul or commons logging on myfaces core 2.0
+1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2009/10/1 Werner Punz werner.p...@gmail.com Again +1 for jul... One dependency less is always a good thing. Werner Leonardo Uribe schrieb: Hi Right now, facelets code added to myfaces core 2.0.x branch uses jul in this form: protected final static Logger log = Logger.getLogger(facelets.viewhandler); But the original myfaces code uses commons logging, (so if there is no agreement about use jul, we should unify logging code using commons-logging). It is necessary to unify in one way or another the code of 2.0.x branch, but before that, it is necessary to ask the community about this issue. So, please vote in this way: +1 for jul +1 for commons-logging +0 -1 and let the code as is (and a reason why). regards, Leonardo Uribe
Re: [VOTE] use of jul or commons logging on myfaces core 2.0
+1 java.util.logging.Logger On Thu, Oct 1, 2009 at 9:14 AM, Michael Concini mconc...@gmail.com wrote: +1 for JUL Antonio Petrelli wrote: 2009/10/1 Werner Punz werner.p...@gmail.com: Why don't you consider using SLF4J? Probably it is the same question asked over and over again, but I try anyway :-D That would be a dependency replacement with another. Just my personal opinion regarding SLF4J Don't bother, I noticed that there is a bridge with which you can use JUL messages with SLF4J: http://www.slf4j.org/legacy.html For a library like MyFaces makes perfectly sense. Antonio -- Grant Smith
Re: [VOTE] use of jul or commons logging on myfaces core 2.0
+1 for jul -- it's not ideal, but it's the standard and doesn't require any dependencies. On Thu, Oct 1, 2009 at 12:22 PM, Grant Smith work.gr...@gmail.com wrote: +1 java.util.logging.Logger On Thu, Oct 1, 2009 at 9:14 AM, Michael Concini mconc...@gmail.com wrote: +1 for JUL Antonio Petrelli wrote: 2009/10/1 Werner Punz werner.p...@gmail.com: Why don't you consider using SLF4J? Probably it is the same question asked over and over again, but I try anyway :-D That would be a dependency replacement with another. Just my personal opinion regarding SLF4J Don't bother, I noticed that there is a bridge with which you can use JUL messages with SLF4J: http://www.slf4j.org/legacy.html For a library like MyFaces makes perfectly sense. Antonio -- Grant Smith
[jira] Resolved: (EXTSCRIPT-25) create an artefact changed event system so that the loading strategies on the core level can adjust
[ https://issues.apache.org/jira/browse/EXTSCRIPT-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-25. -- Resolution: Fixed Assignee: Werner Punz create an artefact changed event system so that the loading strategies on the core level can adjust Key: EXTSCRIPT-25 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-25 Project: MyFaces Extensions Scripting Issue Type: Sub-task Reporter: Werner Punz Assignee: Werner Punz -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2376) h:outputScript should force type=text/javascript
[ https://issues.apache.org/jira/browse/MYFACES-2376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-2376. - Resolution: Fixed Fix Version/s: 2.0.0-alpha h:outputScript should force type=text/javascript -- Key: MYFACES-2376 URL: https://issues.apache.org/jira/browse/MYFACES-2376 Project: MyFaces Core Issue Type: Task Components: JSR-314 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.0-alpha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2376) h:outputScript should force type=text/javascript
h:outputScript should force type=text/javascript -- Key: MYFACES-2376 URL: https://issues.apache.org/jira/browse/MYFACES-2376 Project: MyFaces Core Issue Type: Task Components: JSR-314 Reporter: Leonardo Uribe Assignee: Leonardo Uribe -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2365) DefaultRestoreViewSupport.calculateViewId should not call ViewHandler.deriveViewId, it should be called later from ViewHandler.createView and ViewHandler.restoreView
[ https://issues.apache.org/jira/browse/MYFACES-2365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-2365. - Resolution: Fixed Fix Version/s: 2.0.0-alpha Assignee: Leonardo Uribe After check again the code, ViewHandler.getViewDeclarationLanguage(FacesContext context, String viewId) receive as viewId the one after ViewHandler.deriveViewId(), but does not call it internally. DefaultRestoreViewSupport.calculateViewId should not call ViewHandler.deriveViewId, it should be called later from ViewHandler.createView and ViewHandler.restoreView - Key: MYFACES-2365 URL: https://issues.apache.org/jira/browse/MYFACES-2365 Project: MyFaces Core Issue Type: Task Components: JSR-314 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.0-alpha See jsf 2.0 spec section 2.2.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2014) Implement ResponseStateManager.getViewState(FacesContext, Object)
[ https://issues.apache.org/jira/browse/MYFACES-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12761444#action_12761444 ] Leonardo Uribe commented on MYFACES-2014: - I have added an implementation for this method, but it seems this is only the tip of the iceberg. The intention of this method and StateManager.getViewState(FacesContext context) is be called when render the ajax response and update the state saving field on client, to keep in sync the component tree. Implement ResponseStateManager.getViewState(FacesContext, Object) - Key: MYFACES-2014 URL: https://issues.apache.org/jira/browse/MYFACES-2014 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Simon Lessard Priority: Minor Implement ResponseStateManager.getViewState(FacesContext, Object) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[Trinidad] Build Broken?
Hi, I am getting golden-file mismatch errors (refer below) while building the Trinidad trunk. is the build broken? *Tests run: 821, Failures: 106, Errors: 0, Skipped: 0 *Branch-1.2.12.2 build seems ok.* *Thanks Mamallan
[jira] Commented: (MYFACES-2323) Implement f:ajax tag handler
[ https://issues.apache.org/jira/browse/MYFACES-2323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12761458#action_12761458 ] Leonardo Uribe commented on MYFACES-2323: - There is still some pending stuff on f:ajax, related to its behavior when it has child components. Right now this one only works when it is inside components. See jsf spec 2.0 section 10.4.1.1 Implement f:ajax tag handler -- Key: MYFACES-2323 URL: https://issues.apache.org/jira/browse/MYFACES-2323 Project: MyFaces Core Issue Type: Task Components: JSR-314 Reporter: Leonardo Uribe Attachments: clientBehaviorHolderRendersIdAndName.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2014) Implement ResponseStateManager.getViewState(FacesContext, Object) and update state saving field on client when ajax response is processed
[ https://issues.apache.org/jira/browse/MYFACES-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12761464#action_12761464 ] Leonardo Uribe commented on MYFACES-2014: - See jsf 2.0 spec section 14.1 for information about this issue Implement ResponseStateManager.getViewState(FacesContext, Object) and update state saving field on client when ajax response is processed - Key: MYFACES-2014 URL: https://issues.apache.org/jira/browse/MYFACES-2014 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Simon Lessard Priority: Minor Implement ResponseStateManager.getViewState(FacesContext, Object) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2377) Include global config parameters javadoc on myfaces-metadata using some myfaces builder plugin annotation
Include global config parameters javadoc on myfaces-metadata using some myfaces builder plugin annotation - Key: MYFACES-2377 URL: https://issues.apache.org/jira/browse/MYFACES-2377 Project: MyFaces Core Issue Type: Improvement Components: build process Reporter: Leonardo Uribe Actually we don't have a page with information about config params used on web.xml. It is not useful to maintain this in a separate page, because code continuously evolves and add new params or details. In theory, these param are tied to a model id, so myfaces-api has ones, myfaces-impl has others ... If we have this included on myfaces-metadata.xml, it is very easy to create a file with all this information when site generation is triggered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2372) h:commandButton should render UIParameter children
[ https://issues.apache.org/jira/browse/MYFACES-2372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-2372. - Resolution: Fixed Fix Version/s: 2.0.0-alpha Assignee: Leonardo Uribe Thanks to Jakob Korherr for provide this patch. h:commandButton should render UIParameter children -- Key: MYFACES-2372 URL: https://issues.apache.org/jira/browse/MYFACES-2372 Project: MyFaces Core Issue Type: New Feature Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Jakob Korherr Assignee: Leonardo Uribe Fix For: 2.0.0-alpha Attachments: commandButton-uiparameter.patch Copied from jsf-spec facelets javadoc. If the component being rendered by this renderer has any UIParameter children, each one of them must be rendered using the renderer for component-family: javax.faces.Input and renderer-type: javax.faces.Hidden. For discussion, this is called the hiddenRenderer. A component with component-type javax.faces.Input must be created for local use in rendering each UIParameter child. The id property of the temporary component must be set to the name of the UIParameter. The value property of the temporary component must be set to the value of the UIParameter. For each UIParameter child, the hiddenRenderer must have its encodeBegin(), encodeChildren(), and encodeEnd() methods called, in order, passing the temporary component as the second argument. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
