[jira] [Commented] (TOBAGO-1400) Sanitize potentially malicious content in tc:textarea and tc:out

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/TOBAGO-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14011474#comment-14011474
 ] 

Hudson commented on TOBAGO-1400:


SUCCESS: Integrated in tobago-trunk #1182 (See 
[https://builds.apache.org/job/tobago-trunk/1182/])
TOBAGO-1400: Sanitize potentially malicious content in tc:textarea and tc:out 
(lofwyr: http://svn.apache.org/viewvc/?view=rev&rev=1598041)
* /myfaces/tobago/trunk/pom.xml
* /myfaces/tobago/trunk/tobago-core/pom.xml
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/config/TobagoConfig.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/config/TobagoConfigFragment.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/config/TobagoConfigImpl.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/config/TobagoConfigParser.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/config/TobagoConfigSorter.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/taglib/component/OutTagDeclaration.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/taglib/component/TextareaTagDeclaration.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/taglib/declaration/HasSanitize.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/renderkit/InputRendererBase.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/sanitizer
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/sanitizer/IgnoringSanitizer.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/sanitizer/JsoupSanitizer.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/sanitizer/Sanitizer.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/util/ComponentUtils.java
* 
/myfaces/tobago/trunk/tobago-core/src/main/resources/org/apache/myfaces/tobago/config/tobago-config-2.0.xsd
* 
/myfaces/tobago/trunk/tobago-example/tobago-example-demo/src/main/webapp/WEB-INF/tobago-config.xml
* 
/myfaces/tobago/trunk/tobago-theme/tobago-theme-standard/src/main/java/org/apache/myfaces/tobago/renderkit/html/standard/standard/tag/OutRenderer.java
* 
/myfaces/tobago/trunk/tobago-theme/tobago-theme-standard/src/main/java/org/apache/myfaces/tobago/renderkit/html/standard/standard/tag/TextareaRenderer.java


> Sanitize potentially malicious content in tc:textarea and tc:out
> 
>
> Key: TOBAGO-1400
> URL: https://issues.apache.org/jira/browse/TOBAGO-1400
> Project: MyFaces Tobago
>  Issue Type: New Feature
>  Components: Themes
>Reporter: Udo Schnurpfeil
>Assignee: Udo Schnurpfeil
> Fix For: 2.0.0-beta-4, 2.0.0
>
>
> When having 
> {code}{code}
> or 
> {code}
>   
> {code}
> the content normally is HTML. This code should be sanitized to protect 
> against XSS.
> To avoid sanitizing these content the two tags above gets a new attribute 
> "sanitize" (default value is "auto"), set the value to "never". But in most 
> cases this should not be needed.
> Sanitizing can be configured in the {{tobago-config.xml}}, and is enabled by 
> default.
> In the configuration you can define a class which is doing the job. It must 
> implement {{org.apache.myfaces.tobago.sanitizer.Sanitizer}}.
> See also: 
> https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet#RULE_.236_-_Sanitize_HTML_Markup_with_a_Library_Designed_for_the_Job
> http://jsoup.org/cookbook/cleaning-html/whitelist-sanitizer



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TOBAGO-1396) Integration of an HTML editor (WYSIWYG)

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/TOBAGO-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14011473#comment-14011473
 ] 

Hudson commented on TOBAGO-1396:


SUCCESS: Integrated in tobago-trunk #1182 (See 
[https://builds.apache.org/job/tobago-trunk/1182/])
TOBAGO-1396: Integration of an HTML editor (WYSIWYG) (lofwyr: 
http://svn.apache.org/viewvc/?view=rev&rev=1598043)
* 
/myfaces/tobago/trunk/tobago-example/tobago-example-demo/src/main/java/org/apache/myfaces/tobago/example/demo/HtmlEditor.java


> Integration of an HTML editor (WYSIWYG)
> ---
>
> Key: TOBAGO-1396
> URL: https://issues.apache.org/jira/browse/TOBAGO-1396
> Project: MyFaces Tobago
>  Issue Type: New Feature
>  Components: Demo
>Reporter: Udo Schnurpfeil
>Assignee: Udo Schnurpfeil
> Fix For: 2.0.0-beta-4, 2.0.0
>
>
> Demonstration of the integration of an HTML editor.
> You can embed an HTML editor in Tobago easily, but there is no HTML editor 
> component in Tobago.
> The reason is, there a many web-based editors in the web available, with 
> different licenses, different features (and different bugs).
> So Tobago should not implement it's own HTML editor.
> But we show how an HTML editor may be embedded in Tobago.
> For more information see the tobago-example-demo application.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TRINIDAD-2445) Prevent exceptions from propagating out of the ServletFilter

[Scott O'Bryan (JIRA)]

[ 
https://issues.apache.org/jira/browse/TRINIDAD-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14011340#comment-14011340
 ] 

Scott O'Bryan commented on TRINIDAD-2445:
-

The reason I reopened this is because this is preventing other filters from 
getting the errors if they go before the TrinidadFilter.  Please provide a 
description about what the issue is that this bug is trying to fix so that we 
can assess how to keep this fix but also provide the logic that's needed by 
another custom filter.

> Prevent exceptions from propagating out of the ServletFilter
> 
>
> Key: TRINIDAD-2445
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2445
> Project: MyFaces Trinidad
>  Issue Type: Bug
>  Components: Infrastructure
>Affects Versions: 2.1.1-core
>Reporter: Arjun Vade
>Assignee: Jeanne Waldman
> Fix For: 2.1.1-core
>
> Attachments: 17191718.patch
>
>
> Any exceptions from the Trinidad code that runs before JSF lifecycle that 
> propagates to application server layer may result in the end user not seeing 
> a meaningful error message in UI.
> Solution: Trinidad code that runs before the JSF lifecycle shouldn't allow 
> exceptions to propagate out of the ServletFilter.
> The fix is simply to add code to our various ServletFilters to trap the 
> errors at that point before the errors propagate out.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TRINIDAD-2445) Prevent exceptions from propagating out of the ServletFilter

[Scott O'Bryan (JIRA)]

[ 
https://issues.apache.org/jira/browse/TRINIDAD-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14011332#comment-14011332
 ] 

Scott O'Bryan commented on TRINIDAD-2445:
-

Silly question but I'm wondering WHY this was needed.  The bug is not very 
informative.

> Prevent exceptions from propagating out of the ServletFilter
> 
>
> Key: TRINIDAD-2445
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2445
> Project: MyFaces Trinidad
>  Issue Type: Bug
>  Components: Infrastructure
>Affects Versions: 2.1.1-core
>Reporter: Arjun Vade
>Assignee: Jeanne Waldman
> Fix For: 2.1.1-core
>
> Attachments: 17191718.patch
>
>
> Any exceptions from the Trinidad code that runs before JSF lifecycle that 
> propagates to application server layer may result in the end user not seeing 
> a meaningful error message in UI.
> Solution: Trinidad code that runs before the JSF lifecycle shouldn't allow 
> exceptions to propagate out of the ServletFilter.
> The fix is simply to add code to our various ServletFilters to trap the 
> errors at that point before the errors propagate out.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Reopened] (TRINIDAD-2445) Prevent exceptions from propagating out of the ServletFilter

[Scott O'Bryan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott O'Bryan reopened TRINIDAD-2445:
-


> Prevent exceptions from propagating out of the ServletFilter
> 
>
> Key: TRINIDAD-2445
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2445
> Project: MyFaces Trinidad
>  Issue Type: Bug
>  Components: Infrastructure
>Affects Versions: 2.1.1-core
>Reporter: Arjun Vade
>Assignee: Jeanne Waldman
> Fix For: 2.1.1-core
>
> Attachments: 17191718.patch
>
>
> Any exceptions from the Trinidad code that runs before JSF lifecycle that 
> propagates to application server layer may result in the end user not seeing 
> a meaningful error message in UI.
> Solution: Trinidad code that runs before the JSF lifecycle shouldn't allow 
> exceptions to propagate out of the ServletFilter.
> The fix is simply to add code to our various ServletFilters to trap the 
> errors at that point before the errors propagate out.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (TRINIDAD-2445) Prevent exceptions from propagating out of the ServletFilter

[Scott O'Bryan (JIRA)]

[ 
https://issues.apache.org/jira/browse/TRINIDAD-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14011332#comment-14011332
 ] 

Scott O'Bryan edited comment on TRINIDAD-2445 at 5/28/14 5:15 PM:
--

Silly question but I'm wondering WHY this was needed?  The bug is not very 
informative.


was (Author: darkarena):
Silly question but I'm wondering WHY this was needed.  The bug is not very 
informative.

> Prevent exceptions from propagating out of the ServletFilter
> 
>
> Key: TRINIDAD-2445
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2445
> Project: MyFaces Trinidad
>  Issue Type: Bug
>  Components: Infrastructure
>Affects Versions: 2.1.1-core
>Reporter: Arjun Vade
>Assignee: Jeanne Waldman
> Fix For: 2.1.1-core
>
> Attachments: 17191718.patch
>
>
> Any exceptions from the Trinidad code that runs before JSF lifecycle that 
> propagates to application server layer may result in the end user not seeing 
> a meaningful error message in UI.
> Solution: Trinidad code that runs before the JSF lifecycle shouldn't allow 
> exceptions to propagate out of the ServletFilter.
> The fix is simply to add code to our various ServletFilters to trap the 
> errors at that point before the errors propagate out.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (TOBAGO-1397) TobagoConfig should be accessible via TobagoContext

[Udo Schnurpfeil (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TOBAGO-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Udo Schnurpfeil resolved TOBAGO-1397.
-

   Resolution: Fixed
Fix Version/s: 2.0.0
   2.0.0-beta-4

> TobagoConfig should be accessible via TobagoContext
> ---
>
> Key: TOBAGO-1397
> URL: https://issues.apache.org/jira/browse/TOBAGO-1397
> Project: MyFaces Tobago
>  Issue Type: New Feature
>  Components: Core
>Reporter: Udo Schnurpfeil
>Assignee: Udo Schnurpfeil
> Fix For: 2.0.0-beta-4, 2.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [proposal] A new module for improved JSF-MVC inside MyFaces Project

[Kito Mann]

My initial response is that this looks pretty cool. Not sure how it'll fit
in with the JCP plans for JAX-RS MVC, but I like it in the JSF world.

___

Kito D. Mann | @kito99 | Author, JSF in Action
Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
http://www.JSFCentral.com | @jsfcentral
+1 203-998-0403

* Listen to the Enterprise Java Newscast: *http://w
ww.enterprisejavanews.com
*
* JSFCentral Interviews Podcast:
http://www.jsfcentral.com/resources/jsfcentralpodcasts/
* Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17


On Wed, May 28, 2014 at 10:49 AM, Leonardo Uribe  wrote:

> Hi
>
> I have finally had some time to get a functional prototype out. For
> the people interested, take a look at:
>
> https://github.com/lu4242/test-draft-actions-for-jsf
>
> The example does what we have discussed in this thread. This
> is only a draft, and the intention is give us a better idea about this.
> I have only tried it with MyFaces 2.2.3, but it should work with
> Mojarra too.
>
> I think for JSF 2.2 we cannot do anymore. It is possible to imagine
> other good tricks like a front controller and so on , but we need
> to change the spec for that.
>
> The prototype is far to be fully functional, but it is simple and
> clear enough to give the people an idea about what can be done
> and if it is worth to do it or not.
>
> To run the prototype, just download the code and type in the
> command line:
>
> mvn install
> cd examples
> mvn clean jetty:run
>
> look in localhost:8080
>
> The next step after take a look at the prototype is propose a
> vote to include it as a module for myfaces commons, but it will take
> some time before that.
>
> Please share your reactions about this. Your opinions are welcomed.
>
> regards,
>
> Leonardo Uribe
>
> 2014-05-23 14:49 GMT+02:00 Leonardo Uribe :
> > Hi
> >
> > DR>> *Regarding #{ma:sourceActionURL('renderOptions') : render the URL
> > of the action
> > DR>> How is the URL rendered? Through the RequestMapping of the method
> > as defined with the Bean?
> > DR>> And the attribute, params of the action defined are appended to the
> URL?
> >
> > Good question Dora.
> >
> > For #{ma:sourceActionURL(...)} the idea is call
> > viewHandler.getActionURL(...), append a custom query parameter called
> > 'oamva', and then call externalContext.encodeActionURL(...) , so the
> > final link could look like this:
> >
> > /myfaces-mvc-examples/sayhello.jsf?jfwid=-5tba0312z&oamva=button
> >
> > In this case we are adding a query param to a url that will be used
> > later in a POST, I think it is justified the use of a query param for
> > the command activation. The only thing to take care here is be sure
> > that the target component should fulfit some strict conditions, by
> > security reasons. Anyway, without view state the POST will not work.
> >
> > Theoretically, only the client window and the action must be append in
> > the URL, the other parameters like the view state, the input and so on
> > must be provided by the user manually. After all, this is something of
> > "low level", you want to have some flexibility at the time of define
> > the parameters, for some users that could be important.
> >
> > For ma:getLink, it uses the same logic for h:link, which is in
> > org.apache.myfaces.shared.renderkit.html.util.OutcomeTargetUtils
> > method getOutcomeTargetHref(facesContext, target).
> >
> > DR>> For $.post with this URL, when its not appended with the
> > attribute or params, execute="@form" attribute of ma:defineAction is
> > not used.
> > DR>> Purpose of this attribute out of scope of jQuery post?
> >
> > A declaration of ma:defineAction component is always, always required,
> > without exceptions. This component will always decoded and its action
> > processed.
> >
> > Most of the time
> > $(document.getElementById("#{ma:parentFormId()}")).serialize() will do
> > the job of add all input fields in the current form, so in that sense
> > it works as an f:ajax request. In JSF no matter where the f:ajax
> > request is, all the input fields of the parent form are sent, no
> > matter what the "execute" parameter says. By 2.2 spec, you know you
> > should always provide javax.faces.ViewState and
> > javax.faces.ClientWindow, so I think that's clear enough. In that
> > sense, it works just like f:ajax, but there is no render response
> > phase, instead the action defines what to render. It is responsibility
> > of the user to send the proper parameters, of the components that will
> > be processed.
> >
> > DR>> *autocomplete is transient and hence its not required to update
> viewstate
> >
> > I don't get what do you want to say. This is different from a form
> > POST, this is a javascript POST, autocomplete doesn't have sense in
> > this case.
> >
> > DR>> Script integration via jQuery with action is flowless and awesome!
> >
> > That's the idea. Something easy to use and f

[jira] [Resolved] (TOBAGO-1398) TobagoConfig should not be modifiable after initialization

[Udo Schnurpfeil (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TOBAGO-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Udo Schnurpfeil resolved TOBAGO-1398.
-

   Resolution: Fixed
Fix Version/s: 2.0.0
   2.0.0-beta-4

> TobagoConfig should not be modifiable after initialization
> --
>
> Key: TOBAGO-1398
> URL: https://issues.apache.org/jira/browse/TOBAGO-1398
> Project: MyFaces Tobago
>  Issue Type: Improvement
>  Components: Core
>Reporter: Udo Schnurpfeil
>Assignee: Udo Schnurpfeil
> Fix For: 2.0.0-beta-4, 2.0.0
>
>
> This should not be possible, because of security reasons. 
> Especially because of the new access via the TobagoContext.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Reopened] (TOBAGO-1396) Integration of an HTML editor (WYSIWYG)

[Udo Schnurpfeil (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TOBAGO-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Udo Schnurpfeil reopened TOBAGO-1396:
-


> Integration of an HTML editor (WYSIWYG)
> ---
>
> Key: TOBAGO-1396
> URL: https://issues.apache.org/jira/browse/TOBAGO-1396
> Project: MyFaces Tobago
>  Issue Type: New Feature
>  Components: Demo
>Reporter: Udo Schnurpfeil
>Assignee: Udo Schnurpfeil
> Fix For: 2.0.0-beta-4, 2.0.0
>
>
> Demonstration of the integration of an HTML editor.
> You can embed an HTML editor in Tobago easily, but there is no HTML editor 
> component in Tobago.
> The reason is, there a many web-based editors in the web available, with 
> different licenses, different features (and different bugs).
> So Tobago should not implement it's own HTML editor.
> But we show how an HTML editor may be embedded in Tobago.
> For more information see the tobago-example-demo application.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (TOBAGO-1400) Sanitize potentially malicious content in tc:textarea and tc:out

[Udo Schnurpfeil (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TOBAGO-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Udo Schnurpfeil resolved TOBAGO-1400.
-

Resolution: Fixed

> Sanitize potentially malicious content in tc:textarea and tc:out
> 
>
> Key: TOBAGO-1400
> URL: https://issues.apache.org/jira/browse/TOBAGO-1400
> Project: MyFaces Tobago
>  Issue Type: New Feature
>  Components: Themes
>Reporter: Udo Schnurpfeil
>Assignee: Udo Schnurpfeil
> Fix For: 2.0.0-beta-4, 2.0.0
>
>
> When having 
> {code}{code}
> or 
> {code}
>   
> {code}
> the content normally is HTML. This code should be sanitized to protect 
> against XSS.
> To avoid sanitizing these content the two tags above gets a new attribute 
> "sanitize" (default value is "auto"), set the value to "never". But in most 
> cases this should not be needed.
> Sanitizing can be configured in the {{tobago-config.xml}}, and is enabled by 
> default.
> In the configuration you can define a class which is doing the job. It must 
> implement {{org.apache.myfaces.tobago.sanitizer.Sanitizer}}.
> See also: 
> https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet#RULE_.236_-_Sanitize_HTML_Markup_with_a_Library_Designed_for_the_Job
> http://jsoup.org/cookbook/cleaning-html/whitelist-sanitizer



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (TOBAGO-1396) Integration of an HTML editor (WYSIWYG)

[Udo Schnurpfeil (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TOBAGO-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Udo Schnurpfeil resolved TOBAGO-1396.
-

Resolution: Fixed

> Integration of an HTML editor (WYSIWYG)
> ---
>
> Key: TOBAGO-1396
> URL: https://issues.apache.org/jira/browse/TOBAGO-1396
> Project: MyFaces Tobago
>  Issue Type: New Feature
>  Components: Demo
>Reporter: Udo Schnurpfeil
>Assignee: Udo Schnurpfeil
> Fix For: 2.0.0-beta-4, 2.0.0
>
>
> Demonstration of the integration of an HTML editor.
> You can embed an HTML editor in Tobago easily, but there is no HTML editor 
> component in Tobago.
> The reason is, there a many web-based editors in the web available, with 
> different licenses, different features (and different bugs).
> So Tobago should not implement it's own HTML editor.
> But we show how an HTML editor may be embedded in Tobago.
> For more information see the tobago-example-demo application.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (TOBAGO-1400) Sanitize potentially malicious content in tc:textarea and tc:out

[Udo Schnurpfeil (JIRA)]

Udo Schnurpfeil created TOBAGO-1400:
---

 Summary: Sanitize potentially malicious content in tc:textarea and 
tc:out
 Key: TOBAGO-1400
 URL: https://issues.apache.org/jira/browse/TOBAGO-1400
 Project: MyFaces Tobago
  Issue Type: New Feature
  Components: Themes
Affects Versions: 2.0.0-beta-4
Reporter: Udo Schnurpfeil
Assignee: Udo Schnurpfeil


When having 

or 

  

the content normally is HTML. This code should be sanitized to protect against 
XSS.
Sanitizing can be configured in the tobago-config.xml, and should be enabled by 
default.

See also: 
https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet#RULE_.236_-_Sanitize_HTML_Markup_with_a_Library_Designed_for_the_Job
http://jsoup.org/cookbook/cleaning-html/whitelist-sanitizer



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [proposal] A new module for improved JSF-MVC inside MyFaces Project

[Leonardo Uribe]

Hi

I have finally had some time to get a functional prototype out. For
the people interested, take a look at:

https://github.com/lu4242/test-draft-actions-for-jsf

The example does what we have discussed in this thread. This
is only a draft, and the intention is give us a better idea about this.
I have only tried it with MyFaces 2.2.3, but it should work with
Mojarra too.

I think for JSF 2.2 we cannot do anymore. It is possible to imagine
other good tricks like a front controller and so on , but we need
to change the spec for that.

The prototype is far to be fully functional, but it is simple and
clear enough to give the people an idea about what can be done
and if it is worth to do it or not.

To run the prototype, just download the code and type in the
command line:

mvn install
cd examples
mvn clean jetty:run

look in localhost:8080

The next step after take a look at the prototype is propose a
vote to include it as a module for myfaces commons, but it will take
some time before that.

Please share your reactions about this. Your opinions are welcomed.

regards,

Leonardo Uribe

2014-05-23 14:49 GMT+02:00 Leonardo Uribe :
> Hi
>
> DR>> *Regarding #{ma:sourceActionURL('renderOptions') : render the URL
> of the action
> DR>> How is the URL rendered? Through the RequestMapping of the method
> as defined with the Bean?
> DR>> And the attribute, params of the action defined are appended to the URL?
>
> Good question Dora.
>
> For #{ma:sourceActionURL(...)} the idea is call
> viewHandler.getActionURL(...), append a custom query parameter called
> 'oamva', and then call externalContext.encodeActionURL(...) , so the
> final link could look like this:
>
> /myfaces-mvc-examples/sayhello.jsf?jfwid=-5tba0312z&oamva=button
>
> In this case we are adding a query param to a url that will be used
> later in a POST, I think it is justified the use of a query param for
> the command activation. The only thing to take care here is be sure
> that the target component should fulfit some strict conditions, by
> security reasons. Anyway, without view state the POST will not work.
>
> Theoretically, only the client window and the action must be append in
> the URL, the other parameters like the view state, the input and so on
> must be provided by the user manually. After all, this is something of
> "low level", you want to have some flexibility at the time of define
> the parameters, for some users that could be important.
>
> For ma:getLink, it uses the same logic for h:link, which is in
> org.apache.myfaces.shared.renderkit.html.util.OutcomeTargetUtils
> method getOutcomeTargetHref(facesContext, target).
>
> DR>> For $.post with this URL, when its not appended with the
> attribute or params, execute="@form" attribute of ma:defineAction is
> not used.
> DR>> Purpose of this attribute out of scope of jQuery post?
>
> A declaration of ma:defineAction component is always, always required,
> without exceptions. This component will always decoded and its action
> processed.
>
> Most of the time
> $(document.getElementById("#{ma:parentFormId()}")).serialize() will do
> the job of add all input fields in the current form, so in that sense
> it works as an f:ajax request. In JSF no matter where the f:ajax
> request is, all the input fields of the parent form are sent, no
> matter what the "execute" parameter says. By 2.2 spec, you know you
> should always provide javax.faces.ViewState and
> javax.faces.ClientWindow, so I think that's clear enough. In that
> sense, it works just like f:ajax, but there is no render response
> phase, instead the action defines what to render. It is responsibility
> of the user to send the proper parameters, of the components that will
> be processed.
>
> DR>> *autocomplete is transient and hence its not required to update viewstate
>
> I don't get what do you want to say. This is different from a form
> POST, this is a javascript POST, autocomplete doesn't have sense in
> this case.
>
> DR>> Script integration via jQuery with action is flowless and awesome!
>
> That's the idea. Something easy to use and flexible enough to cover
> those rare cases where you need to get your hands dirty with
> javascript, but without break the nice part of JSF abstraction, which
> is be independent of protocols.
>
> These days I haven't had enough time to get it done, but I hope in
> this weekend to get something out and publish a draft on my Github
> account, so the people interested can take a look and see if these
> ideas are good enough and later vote for create a new module, with
> something clear in mind. This is trial and error, and nothing is
> certain, so no matter if something looks fancy or cool, a community
> vote is required to move forward from that point.
>
> regards,
>
> Leonardo Uribe
>
> 2014-05-21 18:34 GMT+02:00 Dora Rajappan :
>>
>> *Regarding #{ma:sourceActionURL('renderOptions') : render the URL of the
>> action
>> How is the URL rendered? Through the RequestMapping of the method as defined
>> 

[jira] [Commented] (TOBAGO-1369) Update to Selenium 2

[Dennis Kieselhorst (JIRA)]

[ 
https://issues.apache.org/jira/browse/TOBAGO-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010916#comment-14010916
 ] 

Dennis Kieselhorst commented on TOBAGO-1369:


Selenium 2.42 is released but still causing errors: 
https://groups.google.com/forum/#!topic/selenium-users/ZLbzGeafQu4

> Update to Selenium 2
> 
>
> Key: TOBAGO-1369
> URL: https://issues.apache.org/jira/browse/TOBAGO-1369
> Project: MyFaces Tobago
>  Issue Type: Improvement
>  Components: Demo
>Affects Versions: 2.0.0-alpha-3
>Reporter: Dennis Kieselhorst
> Fix For: 2.0.0-beta-4, 2.0.0
>
> Attachments: TOBAGO-1369.patch
>
>
> tobago-example-test still uses the old Selenium 1 version. The integration 
> tests doesn't run with the latest browser versions.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (MYFACES-3897) AttributeHandler does not work for composite:implementation

[Leonardo Uribe (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010899#comment-14010899
 ] 

Leonardo Uribe commented on MYFACES-3897:
-

It is not supposed to work that way. f:attribute is a component that comes from 
JSF 1.1 and it just set the attribute of the parent component:





In a composite component, you can define the attribute in the interface 
definition using "default" property of cc:attribute 








f:event is a different tag. I'll close this issue as invalid, because things 
works as supposed to be.

> AttributeHandler does not work for composite:implementation
> ---
>
> Key: MYFACES-3897
> URL: https://issues.apache.org/jira/browse/MYFACES-3897
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: Sven Linstaedt
>Priority: Minor
>
> I am not totally sure, but according to 
> javax.faces.view.facelets.ComponentHandler.isNew(UIComponent) something like 
> {code}
> 
>
> 
> {code}
> should work. Actually f:attribute (and probably f:attributes) does not work 
> this way, because it does not use the isNew function, but checks nullness of 
> the parent of the component itself, not taking composite components into 
> account. So
> {code}
> 
> 
>
> 
> {code}
> for initializing the component does not work.



--
This message was sent by Atlassian JIRA
(v6.2#6252)