[jira] Resolved: (MYFACES-2372) h:commandButton should render UIParameter children

[Leonardo Uribe (JIRA)]

 [ 
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.

[jira] Created: (MYFACES-2377) Include global config parameters javadoc on myfaces-metadata using some myfaces builder plugin annotation

[Leonardo Uribe (JIRA)]

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] Commented: (MYFACES-2014) Implement ResponseStateManager.getViewState(FacesContext, Object) and update state saving field on client when ajax response is processed

[Leonardo Uribe (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] Commented: (MYFACES-2323) Implement tag handler

[Leonardo Uribe (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-2323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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  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.

[Trinidad] Build Broken?

[Mamallan Uthaman]

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-2014) Implement ResponseStateManager.getViewState(FacesContext, Object)

[Leonardo Uribe (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.

[jira] Resolved: (MYFACES-2365) DefaultRestoreViewSupport.calculateViewId should not call ViewHandler.deriveViewId, it should be called later from ViewHandler.createView and ViewHandler.restoreView

[Leonardo Uribe (JIRA)]

 [ 
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] Created: (MYFACES-2376) h:outputScript should force type="text/javascript"

[Leonardo Uribe (JIRA)]

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-2376) h:outputScript should force type="text/javascript"

[Leonardo Uribe (JIRA)]

 [ 
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] Resolved: (EXTSCRIPT-25) create an artefact changed event system so that the loading strategies on the core level can adjust

[Werner Punz (JIRA)]

 [ 
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.

Re: [VOTE] use of jul or commons logging on myfaces core 2.0

[Mike Kienenberger]

+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  wrote:
> +1 java.util.logging.Logger
>
> On Thu, Oct 1, 2009 at 9:14 AM, Michael Concini  wrote:
>> +1 for JUL
>>
>> Antonio Petrelli wrote:
>>>
>>> 2009/10/1 Werner Punz :
>>>
>
> 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

[Grant Smith]

+1 java.util.logging.Logger

On Thu, Oct 1, 2009 at 9:14 AM, Michael Concini  wrote:
> +1 for JUL
>
> Antonio Petrelli wrote:
>>
>> 2009/10/1 Werner Punz :
>>

 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

[Gerhard Petracek]

+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 

> 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

[Michael Concini]

+1 for JUL

Antonio Petrelli wrote:

2009/10/1 Werner Punz :
  

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

[Antonio Petrelli]

2009/10/1 Werner Punz :
>> 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

[Werner Punz]

Antonio Petrelli schrieb:

2009/10/1 Leonardo Uribe :

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

[Antonio Petrelli]

2009/10/1 Leonardo Uribe :
> 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

Screencast of what is cooking up in ext-scripting

[Werner Punz]

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=vUCCTCMjTPE&feature=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

[Mario Ivankovits]

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 
mailto: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

Re: [VOTE] use of jul or commons logging on myfaces core 2.0

[Werner Punz]

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

[jira] Commented: (TOBAGO-695) Theme Scarborough missing right border off tc:box in IE 6

[Helmut Swaczinna (JIRA)]

[ 
https://issues.apache.org/jira/browse/TOBAGO-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Simon Lessard]

+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  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] Resolved: (TOBAGO-799) pass ajax request parameter infos to clientside onSubmit function

[Volker Weber (JIRA)]

 [ 
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.