[jira] [Created] (TRINIDAD-2470) GenericConverterFactory needs to throw TypeConversionException in response to exceptions during conversion
Ashwin Prabhu created TRINIDAD-2470:
---
Summary: GenericConverterFactory needs to throw
TypeConversionException in response to exceptions during conversion
Key: TRINIDAD-2470
URL: https://issues.apache.org/jira/browse/TRINIDAD-2470
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.1.0-core
Environment: N/A
Reporter: Ashwin Prabhu
The convert implementation in GenericConverterFactory has the following code:
TypeConverter converter = getConverter(source.getClass(), targetType);
if (converter != null)
{
return converter.convert(source, targetType);
}
throw new TypeConversionException(source, targetType);
In addition to throwing TypeConversionException for missing converters, the
above code needs to capture and re-throw any exception resulting during the
conversion as TypeConversionException for the caller to handle them.
Currently exceptions during the type conversion stage, unless they are
ConverterExceptions remain unhandeled and cause PPR errors
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] Dora Rajappan shared MYFACES-3816: missing window-handling for initial requests with you
Dora Rajappan shared an issue with you Hi, I tried the redirect but jsf is not able to support it now. externaltContext.redirect(url) makes it response complete and ajax request will not get processed. Question is to have a new method that to makes it not response complete. If its not made response complete also jsf cannot send consecutive responses in one request lifecycle. Regards, Dora Rajappan missing window-handling for initial requests Key: MYFACES-3816 URL: https://issues.apache.org/jira/browse/MYFACES-3816 Project: MyFaces Core Issue Type: Bug Components: JSR-344 Affects Versions: 2.2.0-beta Reporter: Gerhard Petracek Assignee: Leonardo Uribe for an initial request there is no window-id added to the url. (tested with 'url' for javax.faces.CLIENT_WINDOW_MODE) - in case of a page refresh a new window-id will be created and it isn't possible to get back the original one. that can also happen with a page-refresh after multiple requests, if only ajax requests are used. that's a major issue for all scopes based on the window-id. it can be done with an initial redirect (default in codi) or js (with html5 compliant browsers) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TOBAGO-1393) Default for 'omit' attribute for command facet is TRUE instead of FALSE
Bernd Bohmann created TOBAGO-1393: - Summary: Default for 'omit' attribute for command facet is TRUE instead of FALSE Key: TOBAGO-1393 URL: https://issues.apache.org/jira/browse/TOBAGO-1393 Project: MyFaces Tobago Issue Type: Bug Components: Themes Affects Versions: 2.0.0-beta-2 Reporter: Bernd Bohmann Assignee: Bernd Bohmann -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [proposal] A new module for improved JSF-MVC inside MyFaces Project
Hi
I have done a fast prototype, just to check how things could work and how the
pieces can be grouped together, and there are some interesting ideas that are
worth to consider.
In JSF 2, when f:viewParam was added, some logic was added to create the view
in two steps: first you create the view metadata, where f:viewParam and now
f:viewAction lives and then you fill the view, executing facelets algorithm
again and in that way create the full component hierarchy.
One idea it came to my mind is create a ViewDeclarationLanguage wrapper and
override getViewMetadata(...) method to inject a f:viewAction component
according to the definition in the CDI bean. For example:
@Named(sayHelloBean)
@ActionController
@RequestScoped
public class SayHelloBean
{
@ViewAction(/section1/*)
public String method2()
{
That makes all views that match with the pattern provided to have an extra
f:viewAction component, with the existing rules that apply for them. You can
also imagine something like this:
@ViewAction(/section1/*)
public String method2(@ViewParam String param1)
What we are saying with the syntax is: ... all views that are are part of
section1 will have a ViewAction listener and will have a view param called
param1.
This approach the following advantages:
- Provide a way to define view actions without override the html markup in
every top level template page.
- It reuse the existing logic for JSF view action, so it is easy to understand
for the users.
- It can be included in JSF 2.2.
- JSF is still in control of the navigation at all times, because there is no
Front Controller.
- The context will be automatically managed by JSF.
but also has the following limitations:
- With an action source framework it is possible to define a wide range of
conditions to activate the action. For example if the request is a GET or a
POST, of if it sends some specific header, even take parameters from the path.
In this solution, the viewId is used for pattern maching and only considers
query parameters.
- It bounds the action to a view, so if there is no view, there is no action.
And we finally get to the central point of discussion: How much flexibility we
really need or the users want to define view actions?
Remember the first lines in JSF spec:
... JSF’s core architecture is designed to be independent of specific
protocols and markup. ...
Now take a look for example about what JAX-RS spec says about:
... The following are the goals of the API: POJO-based, HTTP-centric,
Format independence, Container independence, Inclusion in Java EE ...
In that sense, all other features provided by action source frameworks are
just useless for JSF, besides include a way to declare view actions into
CDI beans.
If we review the related requeriments Thomas Andraschko provided:
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
I think with the approach proposed we can comply with the requirements.
Maybe we should forget about the rest, and focus our efforts in explore
this approach.
DR +1 for the idea. Are you going to have two sets of release jars with
DR and without extensions ? Is it going to be a different project?
It is still a proposal (please read the subject of the message), so it
is too early to say something about.
DR Spring MVC beans can be configured to be accessed from the ManagedBeans.
DR You are talking about the spring beans integration in the jsf elements?
The mail is clear in this. The idea is explore how to do things like with
an action source framework, but in JSF 2.2 / CDI, probably writing a CDI
extension. There is no integration code with a third party framework, the
idea is found new ways to solve existing problems.
regards,
Leonardo Uribe
2014-04-29 18:32 GMT+02:00 Dora Rajappan dorarajap...@yahoo.com:
+1 for the idea. Are you going to have two sets of release jars with and
without extensions ? Is it going to be a different project?
Spring MVC beans can be configured to be accessed from the ManagedBeans. You
are talking about the spring beans integration in the jsf elements?
Regards,
Dora Rajappan.
On Friday, April 25, 2014 7:03 PM, Thomas Andraschko
andraschko.tho...@gmail.com wrote:
Hi,
sounds good enough for a first prototype - +1
Regards,
Thomas
2014-04-25 15:23 GMT+02:00 Leonardo Uribe lu4...@gmail.com:
Hi
There are different things we would like to include in this module. For
now, let's focus on rethink how actions should be processed in JSF.
To make things easier, let's start with a comparison between f:viewAction
and
a solution that involves a front controller and some actions defines using
annotations in a CDI bean.
In the first case, the developer defines the action in the page using a tag:
SOLUTION 1:
f:metadata
f:viewParam name=id
[jira] [Updated] (TRINIDAD-2469) trinidad date picker selects previous day when using lightweight dialogs
[ https://issues.apache.org/jira/browse/TRINIDAD-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson updated TRINIDAD-2469: -- Resolution: Fixed Fix Version/s: 2.1.1-core Status: Resolved (was: Patch Available) Patch committed trinidad date picker selects previous day when using lightweight dialogs - Key: TRINIDAD-2469 URL: https://issues.apache.org/jira/browse/TRINIDAD-2469 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.1-core Reporter: Paresh Kumar Acharya Fix For: 2.1.1-core Attachments: 18443584.patch The issue is with tr:inputDate control, when you select a date between Mar 9 and Nov 2, it keeps selecting the previous day. The issue seems to be specific around day light saving time. If the customer remove the lightweight dialogs change then it opens as a popup and works correctly without any issues. The issue occurs when the server's current date is non DST and clients date is in DST. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TRINIDAD-2469) trinidad date picker selects previous day when using lightweight dialogs
[ https://issues.apache.org/jira/browse/TRINIDAD-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13984923#comment-13984923 ] Andrew Robinson commented on TRINIDAD-2469: --- Committed revision 1591131. trinidad date picker selects previous day when using lightweight dialogs - Key: TRINIDAD-2469 URL: https://issues.apache.org/jira/browse/TRINIDAD-2469 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.1-core Reporter: Paresh Kumar Acharya Fix For: 2.1.1-core Attachments: 18443584.patch The issue is with tr:inputDate control, when you select a date between Mar 9 and Nov 2, it keeps selecting the previous day. The issue seems to be specific around day light saving time. If the customer remove the lightweight dialogs change then it opens as a popup and works correctly without any issues. The issue occurs when the server's current date is non DST and clients date is in DST. -- This message was sent by Atlassian JIRA (v6.2#6252)
