You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by "Todor Spasov (JIRA)" <ji...@apache.org> on 2009/12/01 16:05:20 UTC

[jira] Commented: (OFBIZ-1825) Colors and localisation for the calendar

    [ https://issues.apache.org/jira/browse/OFBIZ-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784257#action_12784257 ] 

Todor Spasov commented on OFBIZ-1825:
-------------------------------------

Hello Sascha and Jacques,
When i was reviewing the previous calendar localisation of Marco Ruocco i saw that two things must be done. The first one is, as Sascha says now, the js part and the second is the service engine part.
The implementation was simple js and a complex rendering code in the form widget and ObjectType's simpleTypeConvert(). The latter is used to let services correctly parse localised date/time to java object (Timestamp).
Using Adrian Crum's latest addition - the converter this part could easily be completed. But there is one con to following this approach - you have to change all java events and groovies because they have to deal with the unparsed
localised string for the date/time that arrives as a String there. Services use ObjectType.simpleTypeConvert().

If we make the form widget render one hidden field (with our original field name e.g. fromDate) that holds the returned date from the js calendar in the standard format and another that is used to display the date in the locale format then it could be possible not to touch ofbiz code (apart from the date-time renderer and *all ftls :D to render both fields ). It has a disadvantage since we only show a display string with the date that is not editable, so the user can't just type the date he wants, instead he must always use the calendar.

WDYT?

Thanks,
Todor

> Colors and localisation for the calendar
> ----------------------------------------
>
>                 Key: OFBIZ-1825
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-1825
>             Project: OFBiz
>          Issue Type: Improvement
>          Components: ALL COMPONENTS
>    Affects Versions: SVN trunk
>            Reporter: Jacques Le Roux
>            Assignee: Jacques Le Roux
>            Priority: Minor
>             Fix For: Release Branch 9.04
>
>         Attachments: calendar.patch, calendar_sequence.patch, calendarDateSelectColor.patch, calendarDateSelectColor.patch, calendarModified.patch, CommonScreens.patch, Existing.jpg, LocalizedDate_it.patch, Proposition.jpg, WE_CAL.gif
>
>
> I tried to change the calendar colors, to be more "in the OFBiz way". Please let me you know what you think.
> I also changed some colors to respect our CSS best practices (no color names).
> Here are some remarks :
> Colors
> *  I kept the 3 chars scheme when it's was obvious. For instance we don't need to set #000000 or #ffffff when actually #000 or #fff is sufficient. 
> * I used Wikipedia as reference http://en.wikipedia.org/wiki/Web_colors for choising colors. While doing this change I wondered if we could not authorise and even recommend to use sandard names for colors as shown in Wikipedia page. I found it easier to recall a color by its names than by an hexa number...! As long as we would use this Wikipedia reference I think it could be possible to use names instead of hexa, WDYT ?
> * The days initials are not centered but at left (It's late and I did not found the reason)
> We need to provide a localisation mean. From http://electronicholas.com/calendar?style=default&format=natural it should not be too hard. I propose a simple way, maybe we can do better
> * More calendar formats in a calendar.properties file (like the euro or american ones)
> * For the moment I think all string are harcoded in calendar_date_select.js
>     Date.weekdays = $w("S M T W T F S");
>     Date.first_day_of_week = 0;
>     Date.months = $w("January February March April May June July August September October November December" );
>     _translations = {
>       "OK": "OK",
>       "Now": "Now",
>       "Today": "Today"
>     }
> A very simple way (but not very clever I must admit) could be to set a property for the language to use in calendar.properties file and use it in a switch statement with "hardcoded" strings in  calendar_date_select.js. Is anybody aware of better ways to do that in Javascript or Prototype ?
> BTW I think we should delete calendarstyles.css and calendarTable.css. If it's ok, I will do it when I will upate the attached patch later.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.