Hi Josh,
I rather not introduce a context-param.
Can we utilize the "type" attribute and add "localDate", "localDateTime"
and so on as the type.
Then augment the existing implementation to take advantage of the JavaSE
8 corresponding types?
Thanks!
Kind regards,
Manfred Riem
On 9/3/15, 5:11 AM, Josh Juneau wrote:
> Everyone, the following is my proposed solution for the issue:
> JAVASERVERFACES_SPEC_PUBLIC-1370
> <https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1370>
>
> Main idea, load the specified Date-Time converter for a given date
> field, as per the blog post:
> http://jj-blogger.blogspot.com/2015/06/utilizing-java-8-date-time-api-with-jsf.html
>
>
> Proposal for specifying the date type for an application or UIComponent:
> Create javax.faces.DATE_TIME context parameter at the application
> level, accepting the following values:
> JDK7 (default) - this will use the java.util.Date as it is used now
> JDK8 - this will force converters and components to utilize the new
> Date-Time API
>
> [ (the following values are not my recommended approach, but also a
> possibility)
> JDK8.LocalDate - utilize the LocalDate implementation
> JDK8.LocalDateTime - utilize the LocalDateTime
> implementation only
> JDK8.LocalTime - utilize the LocalTime implementation only
> JDK8.OffsetTime- utilize the OffsetTime implementation only
> JDK8.OffsetDateTime - utilize the OffsetDateTime implementation only
> ** It is possible to include these values at the context parameter
> level to enable only the specified Date-Time classes for an
> application, but this would limit every date within the scope of the
> application to only the specified value.
> ]
>
> The preferred solution for specifying the Date-Time implementation
> within the context parameter would be to require component libraries
> to add a new attribute to the calendar component “type” to allow
> specification of the conversion type (LocalDate, LocalDateTime,
> LocalTime, OffsetTime, OffsetDateTime). An alternative possibility is
> to make use of the existing “converter” attribute on many calendar
> components (ie. PrimeFaces calendar component) to choose the preferred
> implementation. We will need to generate a FacesConverter for each of
> the converter implementations.
>
> javax.faces.convert.DateTimeConverter should have a new converter
> along side, as mentioned by Ed in the issue comments. This converter
> should be named NewDateTimeConverter to represent the “New” date-time
> API. The convertDateTime tag should contain a new attribute “type”
> that can be used to specify the implementation that will be utilized
> by the NewDateTimeConverter class. The possible values for
> type (LocalDate, LocalDateTime, LocalTime, OffsetTime, OffsetDateTime).
>
> Please review and provide feedback. Thanks for your time.
>
> Josh Juneau
> juneau001_at_gmail.com <mailto:juneau001_at_gmail.com>
> http://jj-blogger.blogspot.com
> https://www.apress.com/index.php/author/author/view/id/1866
>
>
> On Tue, Sep 1, 2015 at 9:06 AM, Josh Juneau <juneau001_at_gmail.com
> <mailto:juneau001_at_gmail.com>> wrote:
>
> Hi Manfred-
>
> To be honest, I haven't begun working on the implementation yet,
> as I've been finishing up an article for Java magazine. I am
> submitting that today, so this is next on the list. I have
> thought a lot about it and have some ideas of how we can possibly
> support 1.8 date and time as well as backwards compatibility. I
> will start there...I will send out my proposed ideas to the list
> within the next day.
>
> Main idea, add a new Faces parameter in web.xml to configure JDK
> date preference. Another option is to add an attribute to the
> calendar components that will allow for backward
> compatibility...but support JDK8 date and time by default. This
> will be the main discussion, I believe...which to make default.
> If we make JDK8 default then it will break all applications right
> away...but if we make JDK8 opt-in, then it may be easier to push
> through.
>
> Thanks
>
> Josh Juneau
> juneau001_at_gmail.com <mailto:juneau001_at_gmail.com>
> http://jj-blogger.blogspot.com
> https://www.apress.com/index.php/author/author/view/id/1866
>
>
> On Tue, Sep 1, 2015 at 8:52 AM, manfred riem
> <manfred.riem_at_oracle.com <mailto:manfred.riem_at_oracle.com>> wrote:
>
> Hi Josh,
>
> How is the issue going?
>
> Thanks!
>
> Kind regards,
> Manfred Riem
>
> On 8/24/15, 2:01 PM, Josh Juneau wrote:
>> Hi Manfred-
>>
>> Hope all is well! Certainly...please do assign it to me and
>> I'll take a crack at it.
>>
>> Thanks for your time, it is appreciated.
>>
>> Josh Juneau
>> juneau001_at_gmail.com <mailto:juneau001_at_gmail.com>
>> http://jj-blogger.blogspot.com
>> https://www.apress.com/index.php/author/author/view/id/1866
>>
>>
>> On Mon, Aug 24, 2015 at 1:42 PM, manfred riem
>> <manfred.riem_at_oracle.com <mailto:manfred.riem_at_oracle.com>> wrote:
>>
>> Hi Josh,
>>
>> Can I assign this to you?
>>
>> See
>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1370
>>
>> It should be fairly straightforward.
>>
>> Thanks!
>>
>> Kind regards,
>> Manfred Riem
>>
>> On 8/18/15, 3:51 PM, Edward Burns wrote:
>>
>> Hello Volunteers,
>>
>> Fellow EG member Josh Juneau has written a blog post
>> about this, but to
>> actually do it in the spec we need a lot more. I see
>> that Cody Lerum
>> has filed issue 1370 about it so let's use that. Can
>> someone step up
>> and make a concrete proposal about how to do this?
>>
>> Thanks,
>>
>> Ed
>>
>>
>
>