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

[Dora Rajappan]

Export excel 
 can work
when the definition is
 @ViewAction("/section1/*", action="exportExcel")
How about
 @ViewAction("/section1", action="exportExcel")
On Wednesday, May 14, 2014 12:01 AM, Dora Rajappan  
wrote:
  
How will  Export excel
work when ViewAction is not defined as  
 
@ViewAction(value="/sayhello.xhtml",
                          params= {
                               @ViewParam(name="action",
expectedValue="exportExcel")
                          })
    public void method3(@ViewParam String param1,
@ViewParam("someOther") Integer param2)
    {
but  as @ViewAction("/section1/*", action="exportExcel")
Is the latter not supported now?
 
facelet function getLink for action processing is not a bad idea.
On Sunday, May 11, 2014 11:52 PM, Leonardo Uribe  wrote:
  
Hi

Ok, I think the idea about @ViewAction and @ViewParam is clear, I have
implemented a fast prototype and it works well, there is a lot of things we
can do for improvement, however we should focus the attention in other
areas so we can give the module a better structure.

The next thing we need is how to combine javascript with JSF, specifically
in cases like this:



    $('#search').autocomplete({
        source: "#{some EL that return a link to an action goes here}"
    });


The idea is provide an input box and then write some javascript lines to
make the component an autocomplete box, but the problem is we need to provide
a URL that can be used to retrieve the values to fill the box. In my opinion,
mix EL and javascript is the best in these cases, but things get complex
quickly when
 you need to provide parameters and so on. So I would like to
propose these facelet functions (better with examples):

    Export excel

and

    
        
    

    Render url from EL expression

#{ma:getLink(...)} work just like h:link but receives the outcome as parameter.
The function append the request path and the client window id, so the final
generated link will be something like this:

http://localhost:8080/myfaces-mvc-examples/sayhello.jsf?id=5&jfwid=1di8uhetf9&action=exportExcel

#{ma:getLinkFrom(...)} just inject the link from a component that works just
like h:link but it is just a wrapper, so the user can customize the parameters,
when the EL function is called, the link is rendered taking the parameters
in the definition. The outcome by default is the page itself.


Please note this proposal is something different from the one that suggest to
create the link just pointing to the method in the bean like
#{ma:getLink('mybean', 'mymethod', params)}. After thinking about it, the
problem with that approach is
 the difficulty to do the match between the link
to generate and the method. EL does not consider annotated methods, so it is
not possible to scan the annotations from the EL unless you do a bypass over
CDI.

I think the approach proposed is something simple to understand, and it has
the advantage that you can isolate the declaration of the link from the
rendering, so the final javascript code will be easier to read.

Finally we need something for the POST case, so the idea is append something
like this:

    
       
 
    

#{ma:encodeActionURL()} do what h:form does for encode the action url. Then,
it is responsibility of the user to provide the view state and client window
token in the request as data, so the postback can be processed properly.
In this case, the idea is the view scope will be available, but the component
tree state will not be updated when POST goes back to the client, so any
changes on the component tree in the action will be ignored.

JSF does not make any difference between GET and POST, so viewParam will
work just the same. What defines a postback in JSF is if the view state
field is in the request or not. Theoretically, use #{ma:getLink(...)} should
work too, but I think there are different cases.

There is a contradiction in this case. Send a POST, provide the view state
token, do not restore the view but restore the view scope bean. The problem is
after you make changes on the view scope beans you need to save those changes,
and that could mean update the view state token, even if the beans are stored
in the server (remember the beans can be serialized, for example in a cluster).

If we take a look at the proposed goals:

1) possibility to use a normal JSF lifecycle for the first GET request
2) allow action handling and custom response for POST actions
3) normal action handling like in asp.net MVC + a EL util function to
generate the action URL

we cannot really make number 2 exactly as POST actions. It doesn't
 fit because
"... JSF’s core architecture is designed to be independent of specific
protocols and markup. ...".

Really the problem proposed in number 2 is not simple and we should analyze it
carefully. In which cases do we really need that kind of action handling? If
we are thinking for example in a JSF component that defines an endpoint with a
custom response (for example a captcha component), w

[jira] [Commented] (TOBAGO-1395) Set Content Type Options header to nosniff

[Dennis Kieselhorst (JIRA)]

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

Dennis Kieselhorst commented on TOBAGO-1395:


Attached a patch for it, header is set by default and can be deactivated using 
the create-content-type-options-nosniff-header flag in the tobago-config.xml.

> Set Content Type Options header to nosniff
> --
>
> Key: TOBAGO-1395
> URL: https://issues.apache.org/jira/browse/TOBAGO-1395
> Project: MyFaces Tobago
>  Issue Type: New Feature
>  Components: Core
>Affects Versions: 2.0.0-beta-3
>Reporter: Dennis Kieselhorst
>Priority: Minor
> Fix For: 2.0.0-beta-4, 2.0.0, 3.0.0-alpha-1
>
> Attachments: TOBAGO-1395.patch
>
>
> Content sniffing allows malicious users to use polyglots (a file that is 
> valid as multiple content types). This can be used to execute XSS attacks.
> The X-Content-Type-Options should be set to nosniff by default to avoid this.



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

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

[Udo Schnurpfeil (JIRA)]

Udo Schnurpfeil created TOBAGO-1396:
---

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


Demonstration of the integration of an HTML editor.

For more information see the tobago-example-demo application.



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

[jira] [Created] (MYFACES-3892) Create a option to execute BeanValidation before JSF-Validation

[Rene O (JIRA)]

Rene O created MYFACES-3892:
---

 Summary: Create a option to execute BeanValidation before 
JSF-Validation
 Key: MYFACES-3892
 URL: https://issues.apache.org/jira/browse/MYFACES-3892
 Project: MyFaces Core
  Issue Type: Improvement
Affects Versions: 2.2.3
Reporter: Rene O


As stated in this answer: http://stackoverflow.com/a/19835645 BeanValidation is 
executed after JSF-Validation.
But it would be very useful to have a way to change this behaviour.

Now you can't decide within jsf-validator wether a component is valid or not in 
terms of BeanValidation
{code}
//My JSF-Validator
//...
UIInput input = (UIInput) component;

if (!input.isValid()) {
return;
}

//...my own jsf-validation rules...
//...
{code}



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

[jira] [Commented] (TOBAGO-1394) Avoid StringIndexOutOfBoundsException in ResourceServlet

[Dennis Kieselhorst (JIRA)]

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

Dennis Kieselhorst commented on TOBAGO-1394:


This will not happen during normal operation but maybe triggered e.g. by 
security tools when checking for directory listing.

> Avoid StringIndexOutOfBoundsException in ResourceServlet
> 
>
> Key: TOBAGO-1394
> URL: https://issues.apache.org/jira/browse/TOBAGO-1394
> Project: MyFaces Tobago
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0.0-beta-3
>Reporter: Dennis Kieselhorst
>Assignee: Udo Schnurpfeil
>Priority: Trivial
> Fix For: 2.0.0-beta-4
>
>
> May 07, 2014 3:23:12 PM org.apache.catalina.core.StandardWrapperValve invoke
> SEVERE: Servlet.service() for servlet [ResourceServlet] in context with path 
> [/intraday] threw exception
> java.lang.StringIndexOutOfBoundsException: String index out of range: 36
>   at java.lang.String.charAt(String.java:658)
>   at 
> org.apache.myfaces.tobago.servlet.ResourceServlet.doGet(ResourceServlet.java:132)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:635)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)



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

[ANNOUNCE] Enterprise Java Newscast - Episode 20 - May 2014

[Kito Mann]

Hello,

I am pleased to announce a new episode of the Enterprise Java Newscast on
JSFCentral.com.

The Enterprise Java Newscast, hosted by Kito D. Mann, Ian Hlavats, and
Daniel Hinojosa, is a monthly podcast that covers the latest headlines in
the world of Enterprise Java development.

In this episode, Kito, Ian, and Daniel discuss new releases from Spring,
JBoss, ICEsoft, PrimeFaces, Apache, IBM, and TypeSafe.  They also discuss
build tools, the future of JSF, Daniel's languagematrix project, and the
Mojarra web site.

Read the newscast here:
http://blogs.jsfcentral.com/JSFNewscast/entry/enterprise_java_newscast_episode_20#.U3UdVGBOWvE



___

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

[jira] [Commented] (MYFACES-3892) Create a option to execute BeanValidation before JSF-Validation

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-3892:
-

The warning was added intentionally. See MYFACES-2624 for details. I think you 
can disable it easily, just disabling the log of the class 
org.apache.myfaces.lifecycle.RenderResponseExecutor

> Create a option to execute BeanValidation before JSF-Validation
> ---
>
> Key: MYFACES-3892
> URL: https://issues.apache.org/jira/browse/MYFACES-3892
> Project: MyFaces Core
>  Issue Type: Improvement
>Affects Versions: 2.2.3
>Reporter: Rene O
>
> As stated in this answer: http://stackoverflow.com/a/19835645 BeanValidation 
> is executed after JSF-Validation.
> But it would be very useful to have a way to change this behaviour.
> Now you can't decide within jsf-validator wether a component is valid or not 
> in terms of BeanValidation
> {code}
> //My JSF-Validator
> //...
> UIInput input = (UIInput) component;
> if (!input.isValid()) {
> return;
> }
> //...my own jsf-validation rules...
> //...
> {code}



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

[jira] [Commented] (MYFACES-3892) Create a option to execute BeanValidation before JSF-Validation

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-3892:
-

In JSF, there is a BeanValidator class that extends from JSF Validator 
interface. JSF doesn't make any distinction, so I don't think we can do 
something in this case, specially because EditableValueHolder interface doesn't 
provide methods to manipulate the ordering how the validators are added. The 
code that usually adds BeanValidator is on ComponentTagHandlerDelegate, so 
that's the reason why that validator is the last to be executed, because it is 
the last to be added, but that's not always the case. You can control the order 
how the validation is performed just using f:validateBean in your component:



  other validators 




> Create a option to execute BeanValidation before JSF-Validation
> ---
>
> Key: MYFACES-3892
> URL: https://issues.apache.org/jira/browse/MYFACES-3892
> Project: MyFaces Core
>  Issue Type: Improvement
>Affects Versions: 2.2.3
>Reporter: Rene O
>
> As stated in this answer: http://stackoverflow.com/a/19835645 BeanValidation 
> is executed after JSF-Validation.
> But it would be very useful to have a way to change this behaviour.
> Now you can't decide within jsf-validator wether a component is valid or not 
> in terms of BeanValidation
> {code}
> //My JSF-Validator
> //...
> UIInput input = (UIInput) component;
> if (!input.isValid()) {
> return;
> }
> //...my own jsf-validation rules...
> //...
> {code}



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

Re: [Trinidad] New API addition for Trinidad's UIXCollection

[Andrew Robinson]

How is this different from just setting the current row index to -1?


On Tue, May 6, 2014 at 1:49 PM, Jing Wu  wrote:

> Thanks Blake for your comment!
>
> It's the component that is hanging onto a rowkey, the model naturally
> reacts to key change and has valid state. But UIXCollection component
> caches the key in it's internal state object which needs to be cleared out
> and recalculated. So the proposal is to simply provide a hook for module
> (e.g. a listener that listens to key change) to clear out the component's
> cache. So when next time there's need to get the current key from the
> component, since there's no cached value, the component will retrieve it
> from the model which contains the already updated key.
>
>
> Thanks,
> Jing
>
>
> On 5/5/2014 8:33 PM, Blake Sullivan wrote:
>
>> Jing,
>>
>> What is an example of a case where code external to the model
>> implementation knows that:
>> 1) The model is hanging onto a rowKey
>> 2) The key is invalid
>>
>> The model implementation is typical supposed to encapsulate this
>> information.
>>
>> -- Blake Sullivan
>>
>> On May 5, 2014, at 3:26 PM, Jing Wu wrote:
>>
>>  Hi,
>>>
>>> This is for JIRA https://issues.apache.org/jira/browse/TRINIDAD-2471.
>>>
>>> UIXCollection caches the current row key in its internal state. There
>>> are cases that the row key becomes stale / invalid in the middle of
>>> processing a row. A new API invalidateCurrentRowKey() is added to
>>> UIXCollection to clear out the cached current row key, so next time when it
>>> is requested, this current new key will be recalculated from model.
>>>
>>>
>>>   /**
>>>* Invalidate the cached current row key so it will be recalculated
>>>* from the model next time when it is requested.
>>>*/
>>>   public void invalidateCurrentRowKey()
>>>   {
>>>   }
>>>
>>> Any comment is welcome!
>>>
>>> Thanks,
>>> Jing
>>>
>>>
>

[jira] [Commented] (TOBAGO-1394) Avoid StringIndexOutOfBoundsException in ResourceServlet

[Dennis Kieselhorst (JIRA)]

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

Dennis Kieselhorst commented on TOBAGO-1394:


To reproduce just query for 
http://host/contextpath/org/apache/myfaces/tobago/renderkit

> Avoid StringIndexOutOfBoundsException in ResourceServlet
> 
>
> Key: TOBAGO-1394
> URL: https://issues.apache.org/jira/browse/TOBAGO-1394
> Project: MyFaces Tobago
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0.0-beta-3
>Reporter: Dennis Kieselhorst
>Priority: Minor
> Fix For: 2.0.0-beta-4
>
>
> May 07, 2014 3:23:12 PM org.apache.catalina.core.StandardWrapperValve invoke
> SEVERE: Servlet.service() for servlet [ResourceServlet] in context with path 
> [/intraday] threw exception
> java.lang.StringIndexOutOfBoundsException: String index out of range: 36
>   at java.lang.String.charAt(String.java:658)
>   at 
> org.apache.myfaces.tobago.servlet.ResourceServlet.doGet(ResourceServlet.java:132)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:635)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)



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

[jira] [Resolved] (TOBAGO-1394) Avoid StringIndexOutOfBoundsException in ResourceServlet

[Udo Schnurpfeil (JIRA)]

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

Udo Schnurpfeil resolved TOBAGO-1394.
-

Resolution: Fixed

> Avoid StringIndexOutOfBoundsException in ResourceServlet
> 
>
> Key: TOBAGO-1394
> URL: https://issues.apache.org/jira/browse/TOBAGO-1394
> Project: MyFaces Tobago
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0.0-beta-3
>Reporter: Dennis Kieselhorst
>Assignee: Udo Schnurpfeil
>Priority: Trivial
> Fix For: 2.0.0-beta-4
>
>
> May 07, 2014 3:23:12 PM org.apache.catalina.core.StandardWrapperValve invoke
> SEVERE: Servlet.service() for servlet [ResourceServlet] in context with path 
> [/intraday] threw exception
> java.lang.StringIndexOutOfBoundsException: String index out of range: 36
>   at java.lang.String.charAt(String.java:658)
>   at 
> org.apache.myfaces.tobago.servlet.ResourceServlet.doGet(ResourceServlet.java:132)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:635)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)



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

[jira] [Commented] (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:comment-tabpanel&focusedCommentId=13998743#comment-13998743
 ] 

Udo Schnurpfeil commented on TOBAGO-1396:
-

Also removing richTextEditor stuff from sandbox and themes.

> 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
>
> Demonstration of the integration of an HTML editor.
> For more information see the tobago-example-demo application.



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

[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=13999698#comment-13999698
 ] 

Dennis Kieselhorst commented on TOBAGO-1369:


We should wait for Selenium 2.42. It contains a bugfix for this issue 
https://code.google.com/p/selenium/issues/detail?id=6112 causing 27 test errors.

> 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-3892) Create a option to execute BeanValidation before JSF-Validation

[Rene O (JIRA)]

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

Rene O commented on MYFACES-3892:
-

A workaround is to call BeanValidation manually within JSF-Validator before 
JSF-validation is done:
{code:title=MyJsfValidatorClass.java}
//...
public void validateMyData(FacesContext context, UIComponent component, Object 
value) throws ValidatorException {
//call beanvalidation manually
Set> violationsSet = 
validator.validateValue(MyDataModel.class, "myFieldName", value, Default.class);

//if beanvalidation error exists do not validate my own jsf-validation 
rules
if(!violationsSet.isEmpty()){
return;
}

//...my own jsf-validation rules...
//...throw new ValidatorException(new FacesMessage("validation 
error",null));
}
{code}

> Create a option to execute BeanValidation before JSF-Validation
> ---
>
> Key: MYFACES-3892
> URL: https://issues.apache.org/jira/browse/MYFACES-3892
> Project: MyFaces Core
>  Issue Type: Improvement
>Affects Versions: 2.2.3
>Reporter: Rene O
>
> As stated in this answer: http://stackoverflow.com/a/19835645 BeanValidation 
> is executed after JSF-Validation.
> But it would be very useful to have a way to change this behaviour.
> Now you can't decide within jsf-validator wether a component is valid or not 
> in terms of BeanValidation
> {code}
> //My JSF-Validator
> //...
> UIInput input = (UIInput) component;
> if (!input.isValid()) {
> return;
> }
> //...my own jsf-validation rules...
> //...
> {code}



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

[jira] [Commented] (MYFACES-3789) Change default refresh period for facelets from 2 to 0 sec (=always refresh)

[Mike Kienenberger (JIRA)]

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

Mike Kienenberger commented on MYFACES-3789:


For what it's worth, we have always used a facelets refresh value of 0 in both 
development and production.  Myfaces 1.1, 1.2, 2.0, and 2.1.   


> Change default refresh period for facelets from 2 to 0 sec (=always refresh)
> 
>
> Key: MYFACES-3789
> URL: https://issues.apache.org/jira/browse/MYFACES-3789
> Project: MyFaces Core
>  Issue Type: Wish
>Reporter: Martin Kočí
>Priority: Trivial
> Attachments: MYFACES-3789.patch
>
>
> A typical developer works as follows
> 1) edits a facelets view  (template, composite component)
> 2) CTRL +S
> 3) refresh in browser (or LiveReload)
> but: from 2) to  3) takes it sometimes less as 2 secs and the programmer must 
> repeat the 3)
> We can override this behaviour with context-param:
> javax.faces.FACELETS_REFRESH_PERIOD=0
> but then is for development neccesary:
> javax.faces.PROJECT_STAGE=Development
> javax.faces.FACELETS_REFRESH_PERIOD=0
> and for Production:
> javax.faces.PROJECT_STAGE=Production
> javax.faces.FACELETS_REFRESH_PERIOD=-1
> that means a configuration of 2 params instead of one (ProjectStage) (the 
> problem is:  javax.faces.FACELETS_REFRESH_PERIOD when not default always wins 
>  and PROJECT_STAGE=Production doesn't set FACELETS_REFRESH_PERIOD to -1)
> with default refresh period = 0 makes the method 
> FaceletCacheFactoryImpl.getFaceletCache() the job and only 
> javax.faces.PROJECT_STAGE=Production is necessary.
> Does anybody know why is the default 2 seconds ?



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

[jira] [Commented] (MYFACES-3892) Create a option to execute BeanValidation before JSF-Validation

[Rene O (JIRA)]

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

Rene O commented on MYFACES-3892:
-

Your solution works, but generally mixing of Bean-Validation and JSF-Validation 
leads to another problem:
{code}





{code}
{code}
MyBean {

@NotNull
@Size(min=6,max=10)
String myField;
...
}
{code}
=> user input: 1234

If beanvalidation fails and the regex fails, then there occurs a warning from 
the regexvalidator, because messagefield is already used by 
beanvalidationmessage:
GUI:
{noformat}
muss zwischen 6 und 10 liegen 
{noformat}
Log:
{noformat}
Warnung: There are some unhandled FacesMessages, this means not every 
FacesMessage had a chance to be rendered.
These unhandled FacesMessages are: 
- myField: Der eingegebene Wert ([A-Z]) ist nicht korrekt.
{noformat}

Can I prevent this warning?

> Create a option to execute BeanValidation before JSF-Validation
> ---
>
> Key: MYFACES-3892
> URL: https://issues.apache.org/jira/browse/MYFACES-3892
> Project: MyFaces Core
>  Issue Type: Improvement
>Affects Versions: 2.2.3
>Reporter: Rene O
>
> As stated in this answer: http://stackoverflow.com/a/19835645 BeanValidation 
> is executed after JSF-Validation.
> But it would be very useful to have a way to change this behaviour.
> Now you can't decide within jsf-validator wether a component is valid or not 
> in terms of BeanValidation
> {code}
> //My JSF-Validator
> //...
> UIInput input = (UIInput) component;
> if (!input.isValid()) {
> return;
> }
> //...my own jsf-validation rules...
> //...
> {code}



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

2014-05-13 20:31 GMT+02:00 Dora Rajappan :
DR> How will  Export
DR> excel
DR> work when ViewAction is not defined as
DR>
DR> @ViewAction(value="/sayhello.xhtml",
DR>   params= {
DR>   @ViewParam(name="action",
DR> expectedValue="exportExcel")
DR>   })
DR> public void method3(@ViewParam String param1,
DR> @ViewParam("someOther") Integer param2)
DR> {
DR> but  as @ViewAction("/section1/*", action="exportExcel")
DR> Is the latter not supported now?
DR>

Good question. The idea is if you have two views on the same folder:

/section1/page1.xhtml
/section1/page2.xhtml

The action will be added to both pages so it will be valid to call

/section1/page1.xhtml?action=exportExcel or
/section1/page2.xhtml?action=exportExcel.

but if the page does not exists, the action will not be valid. So
if the user calls

/section1/nonexistentpage.xhtml?action=exportExcel

nothing will happen.

But if the user declares an action to a page that do not exists as a
file in the path, for example:

@ViewAction(value="/page_not_on_webapp_folder.xhtml",

The logic will create an blank page with the view action and the
view params declared. I have already tried it and it works well, it is
useful in some cases when you need to include some logic before
go into the real page, and with this you don't have to create it
on the webapp folder. This logic is handled by a VDL wrapper.

DR> facelet function getLink for action processing is not a bad idea.

I think so too. It is simple to understand, but in some cases getLink(...)
is not enough, for example when you have 2 or more parameters to
include in the link, and you need to add some extra logic. In that
case, a 2 step approach using a component and getLinkFrom(...)
looks more clean and flexible. Note there is no way to add variable
parameters with facelets EL functions, so an extended getLink(...)
is not possible.

regards,

Leonardo

> On Sunday, May 11, 2014 11:52 PM, Leonardo Uribe  wrote:
> Hi
>
> Ok, I think the idea about @ViewAction and @ViewParam is clear, I have
> implemented a fast prototype and it works well, there is a lot of things we
> can do for improvement, however we should focus the attention in other
> areas so we can give the module a better structure.
>
> The next thing we need is how to combine javascript with JSF, specifically
> in cases like this:
>
> 
> 
> $('#search').autocomplete({
> source: "#{some EL that return a link to an action goes here}"
> });
> 
>
> The idea is provide an input box and then write some javascript lines to
> make the component an autocomplete box, but the problem is we need to
> provide
> a URL that can be used to retrieve the values to fill the box. In my
> opinion,
> mix EL and javascript is the best in these cases, but things get complex
> quickly when you need to provide parameters and so on. So I would like to
> propose these facelet functions (better with examples):
>
> Export excel
>
> and
>
> 
> 
> 
>
> Render url from EL expression
>
> #{ma:getLink(...)} work just like h:link but receives the outcome as
> parameter.
> The function append the request path and the client window id, so the final
> generated link will be something like this:
>
> http://localhost:8080/myfaces-mvc-examples/sayhello.jsf?id=5&jfwid=1di8uhetf9&action=exportExcel
>
> #{ma:getLinkFrom(...)} just inject the link from a component that works just
> like h:link but it is just a wrapper, so the user can customize the
> parameters,
> when the EL function is called, the link is rendered taking the parameters
> in the definition. The outcome by default is the page itself.
>
>
> Please note this proposal is something different from the one that suggest
> to
> create the link just pointing to the method in the bean like
> #{ma:getLink('mybean', 'mymethod', params)}. After thinking about it, the
> problem with that approach is the difficulty to do the match between the
> link
> to generate and the method. EL does not consider annotated methods, so it is
> not possible to scan the annotations from the EL unless you do a bypass over
> CDI.
>
> I think the approach proposed is something simple to understand, and it has
> the advantage that you can isolate the declaration of the link from the
> rendering, so the final javascript code will be easier to read.
>
> Finally we need something for the POST case, so the idea is append something
> like this:
>
>method="post"
>   enctype="application/x-www-form-urlencoded">
> 
> 
>
> #{ma:encodeActionURL()} do what h:form does for encode the action url. Then,
> it is responsibility of the user to provide the view state and client window
> token in the request as data, so the postback can be processed properly.
> In this case, the idea is the view scope will be available, but the
> component
> tree state will not be updated when POST goes back to the client, so any
> cha

Re: [Trinidad] New API addition for Trinidad's UIXCollection

[Blake Sullivan]

It should be the same.

— Blake Sullivan

On May 15, 2014, at 7:58 AM, Andrew Robinson  
wrote:

> How is this different from just setting the current row index to -1?
> 
> 
> On Tue, May 6, 2014 at 1:49 PM, Jing Wu  wrote:
> Thanks Blake for your comment!
> 
> It's the component that is hanging onto a rowkey, the model naturally reacts 
> to key change and has valid state. But UIXCollection component caches the key 
> in it's internal state object which needs to be cleared out and recalculated. 
> So the proposal is to simply provide a hook for module (e.g. a listener that 
> listens to key change) to clear out the component's cache. So when next time 
> there's need to get the current key from the component, since there's no 
> cached value, the component will retrieve it from the model which contains 
> the already updated key.
> 
> 
> Thanks,
> Jing
> 
> 
> On 5/5/2014 8:33 PM, Blake Sullivan wrote:
> Jing,
> 
> What is an example of a case where code external to the model implementation 
> knows that:
> 1) The model is hanging onto a rowKey
> 2) The key is invalid
> 
> The model implementation is typical supposed to encapsulate this information.
> 
> -- Blake Sullivan
> 
> On May 5, 2014, at 3:26 PM, Jing Wu wrote:
> 
> Hi,
> 
> This is for JIRA https://issues.apache.org/jira/browse/TRINIDAD-2471.
> 
> UIXCollection caches the current row key in its internal state. There are 
> cases that the row key becomes stale / invalid in the middle of processing a 
> row. A new API invalidateCurrentRowKey() is added to UIXCollection to clear 
> out the cached current row key, so next time when it is requested, this 
> current new key will be recalculated from model.
> 
> 
>   /**
>* Invalidate the cached current row key so it will be recalculated
>* from the model next time when it is requested.
>*/
>   public void invalidateCurrentRowKey()
>   {
>   }
> 
> Any comment is welcome!
> 
> Thanks,
> Jing
> 
> 
> 

[ANNOUNCE] JSFCentral Episode 32: Shay Shmeltzer discusses Oracle's ADF Mobile and ADF Faces Rich Client

[Kito Mann]

Hello,

I'm pleased to announce a new podcast on JSFCentral.com.  In this
interview, I talk with Shay Shmeltzer about Oracle's ADF Mobile, ADF Faces
Rich Client, and Oracle's extensive use of JSF in its products.  Shay is
director of product management for Oracle's mobile and development tools
and frameworks.

Read the entire interview here:
http://content.jsfcentral.com/c/journal_articles/view_article_content?groupId=35702&articleId=171661&version=1.6#.U3Lgwq1dWDo


___

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

[jira] [Commented] (MYFACES-3789) Change default refresh period for facelets from 2 to 0 sec (=always refresh)

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-3789:
-

Recently I have been checking this part of the code. In production it is 
already set to -1. So the change could be to change it from 2 to 0 in other 
modes by default. Fortunately there is nothing in the spec that defines that 
default value.

I have experienced in the past some bugs with this stuff, specially in some 
junit tests. That's the reason why I have hesitated with this issue. The case 
was to stop the debugger by some reason and let it continue. In some cases the 
tests failed, because the facelet was refreshed. If the value is 2, there is no 
chance for the algorithm to be refreshed in the junit test.

So the big question is if the algorithm is stable setting it to 0. In theory it 
shouldn't be a problem, but we need to try, because the algorithm that do the 
refresh is something that comes from facelets 1.1.x, and since it is something 
not for production environment, it could have some bugs (one recently found in 
MYFACES-3890). Let me check the whole algorithm, and if everything is ok I'll 
change it.

> Change default refresh period for facelets from 2 to 0 sec (=always refresh)
> 
>
> Key: MYFACES-3789
> URL: https://issues.apache.org/jira/browse/MYFACES-3789
> Project: MyFaces Core
>  Issue Type: Wish
>Reporter: Martin Kočí
>Priority: Trivial
> Attachments: MYFACES-3789.patch
>
>
> A typical developer works as follows
> 1) edits a facelets view  (template, composite component)
> 2) CTRL +S
> 3) refresh in browser (or LiveReload)
> but: from 2) to  3) takes it sometimes less as 2 secs and the programmer must 
> repeat the 3)
> We can override this behaviour with context-param:
> javax.faces.FACELETS_REFRESH_PERIOD=0
> but then is for development neccesary:
> javax.faces.PROJECT_STAGE=Development
> javax.faces.FACELETS_REFRESH_PERIOD=0
> and for Production:
> javax.faces.PROJECT_STAGE=Production
> javax.faces.FACELETS_REFRESH_PERIOD=-1
> that means a configuration of 2 params instead of one (ProjectStage) (the 
> problem is:  javax.faces.FACELETS_REFRESH_PERIOD when not default always wins 
>  and PROJECT_STAGE=Production doesn't set FACELETS_REFRESH_PERIOD to -1)
> with default refresh period = 0 makes the method 
> FaceletCacheFactoryImpl.getFaceletCache() the job and only 
> javax.faces.PROJECT_STAGE=Production is necessary.
> Does anybody know why is the default 2 seconds ?



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

[jira] [Commented] (TRINIDAD-2468) FileSystemStyleCache: split style sheet concurrency issue

[Andy Schwartz (JIRA)]

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

Andy Schwartz commented on TRINIDAD-2468:
-

This is a new version of the fix:

https://issues.apache.org/jira/secure/attachment/12645030/trinidad-2468-take3.patch

That modifies the case where FileSystemStyleCache._createEntry() fails because 
there are no matching style nodes found.

Before my fix, this failed silently.

In the first two versions of my fix, this fails with a NullPointerException.

After discussing with Blake, we decided that it is best to make this case fail 
in a more obvious way.  This now fails with an IllegalStateException with a 
more useful error message.

> FileSystemStyleCache: split style sheet concurrency issue
> -
>
> Key: TRINIDAD-2468
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2468
> Project: MyFaces Trinidad
>  Issue Type: Bug
>  Components: Skinning
>Reporter: Andy Schwartz
>Assignee: Andy Schwartz
> Attachments: trinidad-2468-hack-delays-on-top-of-fix.patch, 
> trinidad-2468-hack-delays.patch, trinidad-2468-take2.patch, 
> trinidad-2468-take3.patch, trinidad-2468.patch
>
>
> Due to IE’s per-file style rule limit, documented here:
> 
> http://support.microsoft.com/kb/262161
> In particular:
> “All style rules after the first 4,095 rules are not applied.”
> Trinidad’s skinning framework breaks up large style sheets into multiple 
> files, each with a maximum of 4,095 rules.  That is, a generated style sheet 
> of the form:
> -  foo-desktop-gecko.css
> Might be result in the generation of two style sheets on IE:
> -  foo-desktop-ie.css
> -  foo-desktop-ie2.css
> We are running into thread safety problems with the current implementation of 
> this multi-file solution.
> Under certain circumstances, we see the style sheet (correctly) being split 
> across two files, but only a single style sheet link is rendered in the HTML 
> contents.  As a result, the styles from the second file are missing, which 
> typically has fatal results.
> This only happens under a somewhat unusual case: the client who is reporting 
> this behavior is running a test which upon start up immediately hits the 
> server with two concurrent requests from IE.
> This triggers the following sequence:
> - Request 1 enters FileSystemStyleCache._createEntry().
> - Request 1 generates the first of two files that make up the IE-specific 
> style sheet.
> - Request 2 arrives and, finding FileSystemStyleCache’s entry cache empty, 
> also enters _createEntry().
> - Upon entry to _createEntry(), Request 2 checks to see whether any files 
> have already been generated for the requested style sheet.
> - Request 2 finds the first of two files and assumes that the style sheet is 
> composed of a single file.
> - Request 1 finishes generating the second style sheet.
> - Request 1 populates the FileSystemStyleCache’s entry cache with an Entry 
> instance that correctly references both generated files.
> - Request 2 blows away the previously installed Entry and replaces it with a 
> bogus Entry that only references the first of two style sheet files.
> On all subsequent requests, StyleSheetRenderer retrieves data from the bogus 
> (single file) Entry, and thus only renders a single link.
> The fix is to control access to _createEntry() for individual style sheets.  
> That is, we want to allow concurrent access to _createEntry() for style 
> sheets with different variants (ie. it should be possible to generate the IE 
> style sheets and Gecko style sheets concurrently).  However, if a request is 
> in the middle of generating files for a particular style sheet, other 
> requests that want access to the same style sheet must wait until the first 
> request completes its work (instead of possibly trampling over the work of 
> the first request).



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

Adding web debug feature to include files

[Karl Trumstedt]

Hi,

I'm thinking that it would be a nice debug feature in myfaces when in
development mode if myfaces automatically could append the filename of
include files as an html comment.

We have large pages with many small includes, and when looking at the page
it would be nice to be able to use the browser development tools to quickly
inspect the html code and see which file this chunk of HTML comes from.
Instead of having to back track through XHTML pages and templates just to
locate the correct include file.

Would this be possible? Any idea where in the code I should begin to look
to implement this?

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

[Leonardo Uribe]

Hi

Finally I have found a way to handle the POST case. Take a look at this
example, written using jQuery:






$(document.getElementById("#{ma:clientId('suggest')}")).autocomplete({
source: function (request, response) {
$.post( "#{ma:sourceActionURL('renderOptions')}" ,
$(document.getElementById("#{ma:parentFormId()}")).serialize(),
response);
}
});







First there is a JSF text input component, and below there are two parts: One
is the jQuery script that enables it as an autocomplete box and then there is
a component called ma:defineAction, which has the purpose to bind the
action, in this case render some JSON with the javascript using EL.

There are some EL functions:

#{ma:sourceActionURL('renderOptions') : render the URL of the action.
#{ma:clientId('suggest') : get the client id of the input component.
#{ma:parentFormId() : get the id of the closest parent form.

There is no any additional javascript function or library, so the POST is
done by jQuery.

This strategy has the following advantages/disadvantages:

* The final code can be easily reused. The EL functions help to fill the
gaps between the component tree and the client ids with the javascript, so
you can just copy/paste or encapsulate the code inside a composite
component.

* The component  helps to deal with the lifecycle
logic. For example, the "execute" attribute helps to define which
components need to be processed by the lifecycle before perform the action.
In this case, you can just take the value from the managed bean to render
the JSON according to the needs. The idea is also add a parameter called
 to send additional parameters in the action and process
them as f:viewParam does.

* The user has complete control about which params should be send with
each action from the javascript client. This has some risk because at the
same time JSF lose control, it is more likely the user send the wrong
parameters, or that could make the code a bit unstable if a new hidden
param for the context is added in the future.

* Since the action is defined in the view, the view must be restored
in order to process the action. That means javax.faces.ViewState and
javax.faces.ClientWindow parameters must be sent with the request. But
that also means the user should ensure the javascript code send the
params as well.

* The view state is not updated on the client, so changes done in the
component tree will not be saved and restored later. This can be a
disadvantage, but if you need to change something on the component tree
the workaround is execute the POST first and once the response has been
generated, send an ajax request to do the changes in the component tree.
This is the best we can do for the moment, to do something better it
should be done at spec level.

* If the view state is not updated on the client, if the view scope
is used by first time the view state will not hold the identifier for
the new view scope and the bean will not be saved. The solution is force
the view scope creation, maybe with a parameter in the action.


I think we can do something similar to what we used for @ViewAction in
the action. For example in #{sayHelloBean.renderJSONForAutoComplete}
we can write something like this on the bean:

public ActionResponse renderJSONForAutoComplete()
{
return new TextResponse("[\"Option A\", \"Option B\"]",
 "UTF-8", "application/json");
}

or you can write it using externalContext methods if you want.

In my personal opinion, this looks good enough to continue. The next step
is write a functional prototype with some examples. It could be more ideas
to do in this part and more use cases but I consider what we have here
is enough to deal with most important or interesting cases.
Let's see what happen.

regards,

Leonardo Uribe

2014-05-15 12:43 GMT+02:00 Leonardo Uribe :
> Hi
>
> 2014-05-13 20:31 GMT+02:00 Dora Rajappan :
> DR> How will  Export
> DR> excel
> DR> work when ViewAction is not defined as
> DR>
> DR> @ViewAction(value="/sayhello.xhtml",
> DR>   params= {
> DR>   @ViewParam(name="action",
> DR> expectedValue="exportExcel")
> DR>   })
> DR> public void method3(@ViewParam String param1,
> DR> @ViewParam("someOther") Integer param2)
> DR> {
> DR> but  as @ViewAction("/section1/*", action="exportExcel")
> DR> Is the latter not supported now?
> DR>
>
> Good question. The idea is if you have two views on the same folder:
>
> /section1/page1.xhtml
> /section1/page2.xhtml
>
> The action will be added to both pages so it will be valid to call
>
> /section1/page1.xhtml?action=exportExcel or
> /section1/page2.xhtml?action=exportExcel.
>
> but if the page does not exists, the action will not be valid. So
> if the user calls
>
> /section1/nonexistentpage.xhtml?action=exportExcel
>
> nothing will happen.
>
> But if the user declares an action to 

[jira] [Created] (TOBAGO-1395) Set Content Type Options header to nosniff

[Dennis Kieselhorst (JIRA)]

Dennis Kieselhorst created TOBAGO-1395:
--

 Summary: Set Content Type Options header to nosniff
 Key: TOBAGO-1395
 URL: https://issues.apache.org/jira/browse/TOBAGO-1395
 Project: MyFaces Tobago
  Issue Type: New Feature
  Components: Core
Affects Versions: 2.0.0-beta-3
Reporter: Dennis Kieselhorst
Priority: Minor


Content sniffing allows malicious users to use polyglots (a file that is valid 
as multiple content types). This can be used to execute XSS attacks.

The X-Content-Type-Options should be set to nosniff by default to avoid this.




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

[jira] [Updated] (TOBAGO-1392) Allow different position for paging arrows in sheet

[Udo Schnurpfeil (JIRA)]

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

Udo Schnurpfeil updated TOBAGO-1392:


Resolution: Fixed
Status: Resolved  (was: Patch Available)

I've applied the patches. Thanks for contributing. 

> Allow different position for paging arrows in sheet
> ---
>
> Key: TOBAGO-1392
> URL: https://issues.apache.org/jira/browse/TOBAGO-1392
> Project: MyFaces Tobago
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.0.0-beta-2
>Reporter: Dennis Kieselhorst
>Priority: Minor
> Fix For: 2.0.0-beta-4, 2.0.0, 3.0.0-alpha-1
>
> Attachments: TOBAGO-1392-3.0.x.patch, TOBAGO-1392.patch
>
>
> Currently the paging arrows are always located near the page range. It should 
> also be possible to place them near the direct links.



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

[jira] [Updated] (TOBAGO-1395) Set Content Type Options header to nosniff

[Dennis Kieselhorst (JIRA)]

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

Dennis Kieselhorst updated TOBAGO-1395:
---

Status: Patch Available  (was: Open)

> Set Content Type Options header to nosniff
> --
>
> Key: TOBAGO-1395
> URL: https://issues.apache.org/jira/browse/TOBAGO-1395
> Project: MyFaces Tobago
>  Issue Type: New Feature
>  Components: Core
>Affects Versions: 2.0.0-beta-3
>Reporter: Dennis Kieselhorst
>Priority: Minor
> Fix For: 2.0.0-beta-4, 2.0.0, 3.0.0-alpha-1
>
> Attachments: TOBAGO-1395.patch
>
>
> Content sniffing allows malicious users to use polyglots (a file that is 
> valid as multiple content types). This can be used to execute XSS attacks.
> The X-Content-Type-Options should be set to nosniff by default to avoid this.



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