cancel
Showing results for 
Search instead for 
Did you mean: 

Freemarker locale aware in surf, not in webscripts

loftux
Star Contributor
Star Contributor
This is a problem that has surfaced using the site-blog dashlet from share-extras, using an older version that does not use client side requests, all server side.

When doing a blog post listing in the dashlet, in Share it does a remote connector request to alfresco
theUrl = '/api/blog/site/' + site + '/' + container + '/posts?pageSize=10';

This returns a json, date snippet
# modifiedOn: "May 13 2011 14:19:13 GMT+0200 (CEST)"
On the server, locale is en_US. Freemarker has formatted the date as per the locale

Now the problem.
In Share, now Freemarker has to format this for output
${msg("text.modified-on", post.createdOn?datetime("MMM dd yyyy HH:mm:ss 'GMT'Z '('zzz')'")?string("d MMM, yyyy HH:mm:ss"))}

But as it turns out, Freemarker in Surf is locale aware. So if my web browser preference locale is sv_SE, Freemarker expects the date in format
"Maj 13 2011 14:19:13 GMT+0200 (CEST)" ->Notice the different spelling for May/Maj.  Thus it cannot detect as date and fails. Switching to a web browser with en_US, and all is good again.

Now, since in surf there is a root object locale, can I pass this on to alfresco webscripts so that I get correctly formatted dates?
I've tried hitting the alfresco/s/api/blog/site/{sitename}/{container}/posts webscripts directly with different browser locales, but it always returns english formatted dates.

Can you change the locale during processing? Probably would change the msg bundle output if possible, so maybe not the best option.
4 REPLIES 4

mrogers
Star Contributor
Star Contributor
One thing we do with the server side web scripts is to try and make sure that dates in JSON are iso8601 format.    You  then know how to parse them on the share tier and format in human readable format.

loftux
Star Contributor
Star Contributor
But in this case I was using the standard /api/blog, so the formatting of dates int this API is maybe not the best
From the blogpost.lib.ftl
"modifiedOn": "${item.modifiedDate?string("MMM dd yyyy HH:mm:ss 'GMT'Z '('zzz')'")}",
I'm not sure if that is iso8601 formatting.

Found a way to make Surf Freemarker handle the locale.
First store the original locale in the model, in your js script
model.locale_original=locale

then in your freemarker template
<#setting locale="en_US">${msg("text.modified-on", post.createdOn?datetime("MMM dd yyyy HH:mm:ss 'GMT'Z '('zzz')'")?string("yyyy-MM-dd HH:mm:ss"))}<#setting locale=locale_original>

Notice that I can tell freemarker to user en_US locale when processing the date, then I set it back. Date is the processed as expected.


I've been using this site-blog dashlet since november, but the issue does not occur for most of the year, there are only 2 months, may and october where the first three characters differs in swedish and english.

loftux
Star Contributor
Star Contributor
Hitting this issue again, this time with /slingshot/search api. It is for the share-extras CKEditor Form Control, so my previous workaround ins't really suitable, since I will not have control over what locale settings tomcat server runs with.
When looking at the date formatting in the api:s, it is really inconsistent (output from a grep):
/repository/blogs/blogpost.lib.ftl:   "createdOn": "${item.createdDate?string("MMM dd yyyy HH:mm:ss 'GMT'Z '('zzz')'")}",
/repository/blogs/blogpost.lib.ftl:   "modifiedOn": "${item.modifiedDate?string("MMM dd yyyy HH:mm:ss 'GMT'Z '('zzz')'")}",
/repository/blogs/blogpost.lib.ftl:      "releasedOn": "${item.releasedDate?string("MMM dd yyyy HH:mm:ss 'GMT'Z '('zzz')'")}",
/repository/blogs/blogpost.lib.ftl:      "updatedOn": "${item.updatedDate?string("MMM dd yyyy HH:mm:ss 'GMT'Z '('zzz')'")}",
/repository/blogs/blogpost.lib.ftl:   "publishedOn": "${item.node.properties["blg:posted"]?string("MMM dd yyyy HH:mm:ss 'GMT'Z '('zzz')'")}",
/repository/blogs/blogpost.lib.ftl:   "updatedOn": "${item.node.properties["blg:lastUpdate"]?string("MMM dd yyyy HH:mm:ss 'GMT'Z '('zzz')'")}",
/repository/blogs/posts/blog-posts-per-month.get.json.ftl:            "firstPostInMonth" : "${item.firstPostInMonth?string("MMM dd yyyy HH:mm:ss 'GMT'Z '('zzz')'")}",
/repository/blogs/posts/blog-posts-per-month.get.json.ftl:            "beginOfMonth" : "${item.beginOfMonth?string("MMM dd yyyy HH:mm:ss 'GMT'Z '('zzz')'")}",
/repository/blogs/posts/blog-posts-per-month.get.json.ftl:            "endOfMonth" : "${item.endOfMonth?string("MMM dd yyyy HH:mm:ss 'GMT'Z '('zzz')'")}",
/repository/comments/comment.lib.ftl:   "createdOn": "${item.node.properties.created?string("MMM dd yyyy HH:mm:ss 'GMT'Z '('zzz')'")}",
/repository/comments/comment.lib.ftl:   "modifiedOn": "${item.node.properties.modified?string("MMM dd yyyy HH:mm:ss 'GMT'Z '('zzz')'")}",
/repository/discussions/post.lib.ftl:         "lastReplyOn": "${postData.lastReply.properties.created?string("MMM dd yyyy HH:mm:ss 'GMT'Z '('zzz')'")}",
/repository/discussions/post.lib.ftl:   "createdOn": "${post.properties.created?string("MMM dd yyyy HH:mm:ss 'GMT'Z '('zzz')'")}",
/repository/discussions/post.lib.ftl:   "modifiedOn": "${post.properties.modified?string("MMM dd yyyy HH:mm:ss 'GMT'Z '('zzz')'")}",
/repository/discussions/post.lib.ftl:   "updatedOn": "${post.properties["cm:updated"]?string("MMM dd yyyy HH:mm:ss 'GMT'Z '('zzz')'")}",
/repository/invite/invite.lib.ftl:   "sentInviteDate": "${invite.sentInviteDate?string("MMM dd yyyy HH:mm:ss 'GMT'Z '('zzz')'")}"
/repository/links/links.lib.ftl:   "createdOn": "${item.createdOn?string("MMM dd yyyy HH:mm:ss 'GMT'Z '('zzz')'")}",
/repository/rating/rating.delete.json.ftl:<#macro dateFormat date>${date?string("dd MMM yyyy HH:mm:ss 'GMT'Z '('zzz')'")}</#macro>
/repository/rating/ratings.get.json.ftl:<#macro dateFormat date>${date?string("dd MMM yyyy HH:mm:ss 'GMT'Z '('zzz')'")}</#macro>
/repository/version/version.get.json.ftl:      "createdDate": "${v.createdDate?string("dd MMM yyyy HH:mm:ss 'GMT'Z '('zzz')'")}",
/slingshot/calendar/eventList.get.calendar.ftl:<#setting time_zone="GMT">
/slingshot/dashlets/my-tasks.get.json.ftl:<#macro dateFormat date>${date?datetime?string("yyyy-MM-dd HH:mm:ss 'GMT'Z '('zzz')'")!""}</#macro>
/slingshot/profile/usercontents.get.json.ftl:<#macro dateFormat date>${date?string("dd MMM yyyy HH:mm:ss 'GMT'Z '('zzz')'")}</#macro>
/slingshot/search/search.get.json.ftl:<#macro dateFormat date>${date?string("dd MMM yyyy HH:mm:ss 'GMT'Z '('zzz')'")}</#macro>
Most use "MMM dd yyyy HH:mm:ss 'GMT'Z '('zzz')'' but the search api and some other use "dd MMM yyyy HH:mm:ss 'GMT'Z '('zzz')'"
I tried with this in my freemarker: ${image.modifiedOn?datetime("dd MMM yyyy HH:mm:ss 'GMT'Z '('zzz')'")?string.medium but that fail with the same error as previous; if a date contains "may" it gets confused with "maj".
The date format isn't a problem for Share Search since it parses the date clients side with Alfresco.util.formatDate.

tullo
Champ in-the-making
Champ in-the-making
Thanks for posting your solution  :!:
I just wish I'd seen it before was wasting the most of a working day trying to figure out why I get date parse exceptions while testing firefox and none with google chrome