renderDateTimeField Freemarker macro ignores framework date-time format settings

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

renderDateTimeField Freemarker macro ignores framework date-time format settings

Adrian Crum-3
The renderDateTimeField macro in htmlFormMacroLibrary.ftl ignores the
framework date-time format settings and formats date-time fields using
jQuery instead. Two problems with that:

1. Even when shortDateInput = true, the date and time are displayed when
the value is a Timestamp.
2. If the value is anything other than a Timestamp, (java.util.Date or
java.sql.Date) then the field content is localized, and any attempt to
pass the field content to a service fails - because there is no way to
convert the string back to the proper object type.

Why was this change made?

-Adrian

Reply | Threaded
Open this post in threaded view
|

Re: renderDateTimeField Freemarker macro ignores framework date-time format settings

Jacques Le Roux
Administrator
This change was made in the jQuery branch and merged after at http://svn.apache.org/viewvc?view=revision&revision=1044503
So I need to search in the jQuery branch. I will do as soon as I will get a chance.
My better bet would be https://issues.apache.org/jira/browse/OFBIZ-3830

Maybe it's related to this comment I made a this moment, also a bet...
 https://issues.apache.org/jira/browse/OFBIZ-3830?focusedCommentId=12882890&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12882890JacquesFrom: "Adrian Crum" <[hidden email]>> The renderDateTimeField macro in htmlFormMacroLibrary.ftl ignores the> framework date-time format settings and formats date-time fields using> jQuery instead. Two problems with that:>> 1. Even when shortDateInput = true, the date and time are displayed when> the value is a Timestamp.> 2. If the value is anything other than a Timestamp, (java.util.Date or> java.sql.Date) then the field content is localized, and any attempt to> pass the field content to a service fails - because there is no way to> convert the string back to the proper object type.>> Why was this change made?>> -Adrian>
Reply | Threaded
Open this post in threaded view
|

Re: renderDateTimeField Freemarker macro ignores framework date-time format settings

Jacques Le Roux
Administrator
In reply to this post by Adrian Crum-3
Also you might be interested by
https://fisheye6.atlassian.com/browse/ofbiz/branches/jquery/framework/widget/templates/htmlFormMacroLibrary.ftl
From where I discovered OFBIZ-3830

Jacques

From: "Jacques Le Roux" <[hidden email]>

> This change was made in the jQuery branch and merged after at http://svn.apache.org/viewvc?view=revision&revision=1044503
> So I need to search in the jQuery branch. I will do as soon as I will get a chance.
> My better bet would be https://issues.apache.org/jira/browse/OFBIZ-3830
>
> Maybe it's related to this comment I made a this moment, also a bet...
> https://issues.apache.org/jira/browse/OFBIZ-3830?focusedCommentId=12882890&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12882890JacquesFrom: 
> "Adrian Crum" <[hidden email]>> The renderDateTimeField macro in htmlFormMacroLibrary.ftl ignores the>
> framework date-time format settings and formats date-time fields using> jQuery instead. Two problems with that:>> 1. Even when
> shortDateInput = true, the date and time are displayed when> the value is a Timestamp.> 2. If the value is anything other than a
> Timestamp, (java.util.Date or> java.sql.Date) then the field content is localized, and any attempt to> pass the field content to a
> service fails - because there is no way to> convert the string back to the proper object type.>> Why was this change
> made?>> -Adrian>
Reply | Threaded
Open this post in threaded view
|

Re: renderDateTimeField Freemarker macro ignores framework date-time format settings

Adrian Crum-3
The way the OFBiz framework is set up, date-time object type conversions
need to be bidirectional. So, either the UtilDateTime methods need to be
used, or the Conversion framework needs to be used. Using a JavaScript
library for date-time object type conversion is bound to cause problems
because its conversions are not a part of the framework.

-Adrian


On 11/1/2011 10:12 PM, Jacques Le Roux wrote:

> Also you might be interested by
> https://fisheye6.atlassian.com/browse/ofbiz/branches/jquery/framework/widget/templates/htmlFormMacroLibrary.ftl 
>
> From where I discovered OFBIZ-3830
>
> Jacques
>
> From: "Jacques Le Roux" <[hidden email]>
>> This change was made in the jQuery branch and merged after at
>> http://svn.apache.org/viewvc?view=revision&revision=1044503
>> So I need to search in the jQuery branch. I will do as soon as I will
>> get a chance.
>> My better bet would be https://issues.apache.org/jira/browse/OFBIZ-3830
>>
>> Maybe it's related to this comment I made a this moment, also a bet...
>> https://issues.apache.org/jira/browse/OFBIZ-3830?focusedCommentId=12882890&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12882890JacquesFrom: 
>> "Adrian Crum" <[hidden email]>> The
>> renderDateTimeField macro in htmlFormMacroLibrary.ftl ignores the>
>> framework date-time format settings and formats date-time fields
>> using> jQuery instead. Two problems with that:>> 1. Even when
>> shortDateInput = true, the date and time are displayed when> the
>> value is a Timestamp.> 2. If the value is anything other than a
>> Timestamp, (java.util.Date or> java.sql.Date) then the field content
>> is localized, and any attempt to> pass the field content to a service
>> fails - because there is no way to> convert the string back to the
>> proper object type.>> Why was this change made?>> -Adrian>
Reply | Threaded
Open this post in threaded view
|

Re: renderDateTimeField Freemarker macro ignores framework date-time format settings

Adrian Crum-3
I located the problem and committed some notes in rev 1197028. I don't
have time right now to fix it.

The problem isn't caused by JavaScript, it's caused by the renderer. We
still need to fix the JavaScript code though.

-Adrian

On 11/1/2011 10:19 PM, Adrian Crum wrote:

> The way the OFBiz framework is set up, date-time object type
> conversions need to be bidirectional. So, either the UtilDateTime
> methods need to be used, or the Conversion framework needs to be used.
> Using a JavaScript library for date-time object type conversion is
> bound to cause problems because its conversions are not a part of the
> framework.
>
> -Adrian
>
>
> On 11/1/2011 10:12 PM, Jacques Le Roux wrote:
>> Also you might be interested by
>> https://fisheye6.atlassian.com/browse/ofbiz/branches/jquery/framework/widget/templates/htmlFormMacroLibrary.ftl 
>>
>> From where I discovered OFBIZ-3830
>>
>> Jacques
>>
>> From: "Jacques Le Roux" <[hidden email]>
>>> This change was made in the jQuery branch and merged after at
>>> http://svn.apache.org/viewvc?view=revision&revision=1044503
>>> So I need to search in the jQuery branch. I will do as soon as I
>>> will get a chance.
>>> My better bet would be https://issues.apache.org/jira/browse/OFBIZ-3830
>>>
>>> Maybe it's related to this comment I made a this moment, also a bet...
>>> https://issues.apache.org/jira/browse/OFBIZ-3830?focusedCommentId=12882890&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12882890JacquesFrom: 
>>> "Adrian Crum" <[hidden email]>> The
>>> renderDateTimeField macro in htmlFormMacroLibrary.ftl ignores the>
>>> framework date-time format settings and formats date-time fields
>>> using> jQuery instead. Two problems with that:>> 1. Even when
>>> shortDateInput = true, the date and time are displayed when> the
>>> value is a Timestamp.> 2. If the value is anything other than a
>>> Timestamp, (java.util.Date or> java.sql.Date) then the field content
>>> is localized, and any attempt to> pass the field content to a
>>> service fails - because there is no way to> convert the string back
>>> to the proper object type.>> Why was this change made?>> -Adrian>
Reply | Threaded
Open this post in threaded view
|

Re: renderDateTimeField Freemarker macro ignores framework date-time format settings

Malin Nicolas
Hi adrian, I will try to check it.

Nicolas

Adrian Crum a écrit :

> I located the problem and committed some notes in rev 1197028. I don't
> have time right now to fix it.
>
> The problem isn't caused by JavaScript, it's caused by the renderer.
> We still need to fix the JavaScript code though.
>
> -Adrian
>
> On 11/1/2011 10:19 PM, Adrian Crum wrote:
>> The way the OFBiz framework is set up, date-time object type
>> conversions need to be bidirectional. So, either the UtilDateTime
>> methods need to be used, or the Conversion framework needs to be
>> used. Using a JavaScript library for date-time object type conversion
>> is bound to cause problems because its conversions are not a part of
>> the framework.
>>
>> -Adrian
>>
>>
>> On 11/1/2011 10:12 PM, Jacques Le Roux wrote:
>>> Also you might be interested by
>>> https://fisheye6.atlassian.com/browse/ofbiz/branches/jquery/framework/widget/templates/htmlFormMacroLibrary.ftl 
>>>
>>> From where I discovered OFBIZ-3830
>>>
>>> Jacques
>>>
>>> From: "Jacques Le Roux" <[hidden email]>
>>>> This change was made in the jQuery branch and merged after at
>>>> http://svn.apache.org/viewvc?view=revision&revision=1044503
>>>> So I need to search in the jQuery branch. I will do as soon as I
>>>> will get a chance.
>>>> My better bet would be
>>>> https://issues.apache.org/jira/browse/OFBIZ-3830
>>>>
>>>> Maybe it's related to this comment I made a this moment, also a bet...
>>>> https://issues.apache.org/jira/browse/OFBIZ-3830?focusedCommentId=12882890&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12882890JacquesFrom: 
>>>> "Adrian Crum" <[hidden email]>> The
>>>> renderDateTimeField macro in htmlFormMacroLibrary.ftl ignores the>
>>>> framework date-time format settings and formats date-time fields
>>>> using> jQuery instead. Two problems with that:>> 1. Even when
>>>> shortDateInput = true, the date and time are displayed when> the
>>>> value is a Timestamp.> 2. If the value is anything other than a
>>>> Timestamp, (java.util.Date or> java.sql.Date) then the field
>>>> content is localized, and any attempt to> pass the field content to
>>>> a service fails - because there is no way to> convert the string
>>>> back to the proper object type.>> Why was this change made?>> -Adrian>