I've been spending some time analyzing the Recurrence Rule classes. My
goal is to add localization support so they can be used in a calendar. There are some problems with the current implementation: 1. Most of the class methods return a long data type that is supposed to be the millisecond value of a date/time. Some of those methods will return either zero or -1 to indicate an error or failure. The problem is, both of those values represent legitimate date/times: zero is Jan 1, 1970, and -1 is Dec 31, 1969. There needs to be a better way to indicate an error or failure. 2. The exception handling is spotty and used poorly. Methods that throw exceptions only throw RecurrenceRuleException - which is sometimes used to "wrap" other exceptions. In my opinion, this is a bad coding practice - the methods should throw the exception that is most appropriate for the circumstances. 3. None of the classes take into consideration locale and time zone. All date/time values are assumed to be in the server's time zone and they assume a Gregorian calendar. I'd like to work on these issues, but I wanted to mention them on the list before committing anything. If you know of any other problems or limitations with Recurrence Rules, please let me know and I will try to address them while I'm doing this work. Comments and suggestions are welcome. -Adrian |
> 3. None of the classes take into consideration locale and time zone. > All > date/time values are assumed to be in the server's time zone and they > assume a Gregorian calendar. > Hi Adrian, I have some concerns about point 3. If you take into account the user time zone, this may allow for example the user to change the time zone and "hack" happy hour promotions, which also use recurrences. Happy hour promotions are based on server time. I also have a question: Any idea where should go recurrence screens, as recurrence entities belongs to org.ofbiz.service.schedule package? May be Webtools? Bilgin |
Bilgin,
Like in many other areas of the framework, the time zone and locale are optional. If none are supplied, the system defaults are used. So, the happy hour promotion will still work the same. Regarding the location of the UI artifacts, the opinion in the past has been to put them in the common component. -Adrian Bilgin Ibryam wrote: >> 3. None of the classes take into consideration locale and time zone. >> All >> date/time values are assumed to be in the server's time zone and they >> assume a Gregorian calendar. >> > Hi Adrian, > > I have some concerns about point 3. If you take into account the user > time zone, this may allow for example the user to change the time zone > and "hack" happy hour promotions, which also use recurrences. > Happy hour promotions are based on server time. > > I also have a question: Any idea where should go recurrence screens, as > recurrence entities belongs to org.ofbiz.service.schedule package? May > be Webtools? > > Bilgin > > |
Yeah, probably good to put them in the common component and reuse them wherever needed. -David Adrian Crum wrote: > Bilgin, > > Like in many other areas of the framework, the time zone and locale are > optional. If none are supplied, the system defaults are used. So, the > happy hour promotion will still work the same. > > Regarding the location of the UI artifacts, the opinion in the past has > been to put them in the common component. > > -Adrian > > Bilgin Ibryam wrote: >>> 3. None of the classes take into consideration locale and time zone. >>> All date/time values are assumed to be in the server's time zone and >>> they assume a Gregorian calendar. >>> >> Hi Adrian, >> >> I have some concerns about point 3. If you take into account the user >> time zone, this may allow for example the user to change the time zone >> and "hack" happy hour promotions, which also use recurrences. >> Happy hour promotions are based on server time. >> >> I also have a question: Any idea where should go recurrence screens, as >> recurrence entities belongs to org.ofbiz.service.schedule package? May >> be Webtools? >> >> Bilgin >> >> |
Free forum by Nabble | Edit this page |