[Lift] Re: Overriding date/time formatting
OK, more nits to pick. There are two formats in TimeHelpers: hour and time.
They seem very related, so I'm not sure why there's a distinction between
the two. The default for hour is "HH:mm:ss" and for time it's "HH:mm zzz".
Derek
On Thu, Oct 15, 2009 at 1:56 PM, Derek Chen-Becker wrote:
> OK, I'm starting to dig into this and I'm finding that a lot of stuff in
> TimeHelpers essentially replicates stuff that's already in JodaTime. Does
> anyone see a problem with doing an overhaul of TimeHelpers in addition to
> the Mapper stuff? I'll keep the API the same, it should just reduce a lot of
> the actual impl code. For example, TimeHelpers.DateExtension exists purely
> to allow a Date with a time of 00:00. The code will change from:
>
> def noTime = {
> val calendar = Calendar.getInstance
> calendar.set(Calendar.HOUR_OF_DAY, 0)
> calendar.set(Calendar.MINUTE, 0)
> calendar.set(Calendar.SECOND, 0)
> calendar.set(Calendar.MILLISECOND, 0)
> calendar.getTime
> }
>
> to
>
> def noTime = new DateTime().withTime(0,0,0,0)
>
> Actually, I'm not sure that the original code is correct, either, since
> DateExtension takes a Date parameter that is never used in the original
> code.
>
> Derek
>
>
> On Fri, Oct 9, 2009 at 12:36 AM, Jeppe Nejsum Madsen wrote:
>
>>
>> Derek Chen-Becker writes:
>>
>> > I'm planning on making the formatting easier to configure and also to
>> move
>> > the Mapper stuff to Joda Time. I know I keep saying this but I hope to
>> start
>> > working on this next week :P
>>
>> Awesome!
>>
>> /Jeppe
>>
>> >>
>>
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Overriding date/time formatting
OK, I'm starting to dig into this and I'm finding that a lot of stuff in
TimeHelpers essentially replicates stuff that's already in JodaTime. Does
anyone see a problem with doing an overhaul of TimeHelpers in addition to
the Mapper stuff? I'll keep the API the same, it should just reduce a lot of
the actual impl code. For example, TimeHelpers.DateExtension exists purely
to allow a Date with a time of 00:00. The code will change from:
def noTime = {
val calendar = Calendar.getInstance
calendar.set(Calendar.HOUR_OF_DAY, 0)
calendar.set(Calendar.MINUTE, 0)
calendar.set(Calendar.SECOND, 0)
calendar.set(Calendar.MILLISECOND, 0)
calendar.getTime
}
to
def noTime = new DateTime().withTime(0,0,0,0)
Actually, I'm not sure that the original code is correct, either, since
DateExtension takes a Date parameter that is never used in the original
code.
Derek
On Fri, Oct 9, 2009 at 12:36 AM, Jeppe Nejsum Madsen wrote:
>
> Derek Chen-Becker writes:
>
> > I'm planning on making the formatting easier to configure and also to
> move
> > the Mapper stuff to Joda Time. I know I keep saying this but I hope to
> start
> > working on this next week :P
>
> Awesome!
>
> /Jeppe
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Overriding date/time formatting
Derek Chen-Becker writes: > I'm planning on making the formatting easier to configure and also to move > the Mapper stuff to Joda Time. I know I keep saying this but I hope to start > working on this next week :P Awesome! /Jeppe --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Overriding date/time formatting
I'm planning on making the formatting easier to configure and also to move the Mapper stuff to Joda Time. I know I keep saying this but I hope to start working on this next week :P Derek On Tue, Oct 6, 2009 at 6:29 PM, Naftoli Gugenheim wrote: > > Also more flexibility should be coming soon if I'm not mistaken. I > think there's a ticket and Derek is planning on working on it. > > On Tue, Oct 6, 2009 at 4:59 PM, Jeppe Nejsum Madsen > wrote: > > > > Dirk Louwers writes: > > > >> Hi, > >> > >> After having toyed around with Scala and recently Lift for a few weeks > >> I have a question. To avoid jumping to conclusions let me first > >> explain what I am trying to achieve: > >> > >> I am not happy with the way MappedDateTime parses strings and formats > >> dates by default. I want to be able to change these parsers/formatters > >> globally and/or on a per mapper field basis. > >> > >> Here is what I did: > >> > >> By looking at the sourcecode I noticed that following MappedDateTime > >> ultimately this depends on internetDateFormatter, dateFormatter and > >> toInternetDate inside TimeHelpers. Since I don't know how to change > >> the dependency of MappedDateTime on TimeHelpers to a subclass of > >> TimeHelpers I decided to break the dependency by subclassing > >> MappedDateTime and overriding _toForm and setFromAny and have my > >> setFromAny call a modified toDate that in turn depends on a custom > >> function to parse a string to a date. This function: > >> 1) Tries to use a specifically definded DateFormat on the field > >> 2) Tries to get a dateformat from a localized bundle > >> 3) Falls back to the SHORT date format of the JVM locale. > >> > >> Here is what I would like to know: > >> > >> 1) Is there a way to have Lift use a TimeHelpers subclass without > >> having to subclass stuff that depends on it? > >> 2) Does anyone have suggestions how to improve/invalidate my approach? > >> > >> Just checking to see if I am on the right path or making this > >> needlessly hard. > >> Thanks in advance for any response. > > > > Sounds like you're using 1.0? In 1.1-SNAPSHOT, date/time > > parsing/formatting is done in LiftRules.parseDate/formatDate and can be > > changed. Not quite per field flexibility though > > > > I think that this is also not locale specific (ie. per request), but > > haven't looked too closely at this yet > > > > /Jeppe > > > > > > > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Overriding date/time formatting
Here goes. I have also added the possibility to mark the field as
required. That proved to be less trivial than expected since
validators can only work on the field type and not the raw string.
class MappedLocalDateTime[T<:Mapper[T]](fieldOwner: T) extends
MappedDateTime[T](fieldOwner) {
private var rawString: String = ""
def requiredField_? = false
override def validate : List[FieldError] = {
if (rawString.trim == "" && requiredField_?) FieldError(this,
Text
(S ? "field.required")) :: Nil
else super.validate
}
override def asHtml = Text(dateFormatter.format(is))
override def _toForm: Box[NodeSeq] =
S.fmapFunc({s: List[String] => this.setFromAny(s)}){funcName =>
Full( "" case s =>
dateParser.format(s)}}/
>)
}
override def setFromAny(f : Any): Date = toDate(f).map(d =>
this.set
(d)).openOr(this.is)
def toDate(in: Any): Box[Date] = {
try {
in match {
case null => Empty
case d: Date => Full(d)
case lng: Long => Full(new Date(lng))
case lng: Number => Full(new Date(lng.longValue))
case Nil | Empty | None | Failure(_, _, _) => Empty
case Full(v) => toDate(v)
case Some(v) => toDate(v)
case v :: vs => toDate(v)
case s : String => rawString = s; parseDate(s)
case o => toDate(o.toString)
}
} catch {
case e => Log.debug("Error parsing date "+in, e); Failure("Bad
date: "+in, Full(e), Empty)
}
}
/**
* This DateFormat is used to parse incoming strings and to format
this field's date when displaying
* in a form. Override this to change the format. Default format
is DateFormat.SHORT for the
* current locale.
*/
def dateParser = shortDateFormat
/**
* This DateFormat is used to display this field's date as html.
Override to change the format. The
* default is DateFormat.DEFAULT for the current locale.
*/
def dateFormatter = defaultDateFormat
final protected def makeDateFormat(key: String, format: Int):
DateFormat = {
val formatString = S ? key
def localeFormat: DateFormat = {
try { DateFormat.getDateInstance(format, S.locale) }
catch { case e => DateFormat.getDateInstance(DateFormat.DEFAULT,
S.locale) }
}
if (formatString == key) localeFormat
else
try { new SimpleDateFormat(formatString, S.locale) }
catch { case e => localeFormat }
}
def defaultDateFormat = DateFormat.getDateInstance
(DateFormat.DEFAULT, S.locale)
def shortDateFormat = makeDateFormat("date.short.formatter",
DateFormat.SHORT)
def mediumDateFormat = makeDateFormat("date.medium.formatter",
DateFormat.MEDIUM)
def longDateFormat = makeDateFormat("date.long.formatter",
DateFormat.LONG)
def fullDateFormat = makeDateFormat("date.full.formatter",
DateFormat.FULL)
final protected def parseDate(s: String): Box[Date] = {
try {
Full(dateParser.parse(s))
} catch {
case _ => Empty
}
}
}
Have fun with it.
Dirk Louwers
On Oct 7, 9:31 am, Jeppe Nejsum Madsen wrote:
> Dirk Louwers writes:
>
> > If it would be at all usefull I'd be happy to share the code.
>
> Please do. I'll eventually have to support different locales at some
> point
>
> /Jeppe
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Overriding date/time formatting
Dirk Louwers writes: > > If it would be at all usefull I'd be happy to share the code. Please do. I'll eventually have to support different locales at some point /Jeppe --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Overriding date/time formatting
Yes, I am indeed using version. My solution is now properly working and does this as follows: 1) It has a dateParser and dateFormatter that are set to another field by default: defaultDateFormat. The dateParser will be used to parse and format the form fields. The dateFormatter is for display (used in asHtml). These two fields can be overridden to change per field behavior. This can either be done by assigning shortDateFormat, longDateFormat, mediumDateFormat or fullDateFormat to them or specifying your own DateFormat entirely. 2) The predefined fields named default, short, medium, long and fullDateFormat get their DateFormat by first checking S ? "x.date.format", otherwise they will switch to DEFAULT, SHORT, MEDIUM, LONG and FULL respectively and use the locale provided by S.locale. If it would be at all usefull I'd be happy to share the code. Best, Dirk Louwers On Oct 7, 2:29 am, Naftoli Gugenheim wrote: > Also more flexibility should be coming soon if I'm not mistaken. I > think there's a ticket and Derek is planning on working on it. > > On Tue, Oct 6, 2009 at 4:59 PM, Jeppe Nejsum Madsen wrote: > > > > > Dirk Louwers writes: > > >> Hi, > > >> After having toyed around with Scala and recently Lift for a few weeks > >> I have a question. To avoid jumping to conclusions let me first > >> explain what I am trying to achieve: > > >> I am not happy with the way MappedDateTime parses strings and formats > >> dates by default. I want to be able to change these parsers/formatters > >> globally and/or on a per mapper field basis. > > >> Here is what I did: > > >> By looking at the sourcecode I noticed that following MappedDateTime > >> ultimately this depends on internetDateFormatter, dateFormatter and > >> toInternetDate inside TimeHelpers. Since I don't know how to change > >> the dependency of MappedDateTime on TimeHelpers to a subclass of > >> TimeHelpers I decided to break the dependency by subclassing > >> MappedDateTime and overriding _toForm and setFromAny and have my > >> setFromAny call a modified toDate that in turn depends on a custom > >> function to parse a string to a date. This function: > >> 1) Tries to use a specifically definded DateFormat on the field > >> 2) Tries to get a dateformat from a localized bundle > >> 3) Falls back to the SHORT date format of the JVM locale. > > >> Here is what I would like to know: > > >> 1) Is there a way to have Lift use a TimeHelpers subclass without > >> having to subclass stuff that depends on it? > >> 2) Does anyone have suggestions how to improve/invalidate my approach? > > >> Just checking to see if I am on the right path or making this > >> needlessly hard. > >> Thanks in advance for any response. > > > Sounds like you're using 1.0? In 1.1-SNAPSHOT, date/time > > parsing/formatting is done in LiftRules.parseDate/formatDate and can be > > changed. Not quite per field flexibility though > > > I think that this is also not locale specific (ie. per request), but > > haven't looked too closely at this yet > > > /Jeppe --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Overriding date/time formatting
Also more flexibility should be coming soon if I'm not mistaken. I think there's a ticket and Derek is planning on working on it. On Tue, Oct 6, 2009 at 4:59 PM, Jeppe Nejsum Madsen wrote: > > Dirk Louwers writes: > >> Hi, >> >> After having toyed around with Scala and recently Lift for a few weeks >> I have a question. To avoid jumping to conclusions let me first >> explain what I am trying to achieve: >> >> I am not happy with the way MappedDateTime parses strings and formats >> dates by default. I want to be able to change these parsers/formatters >> globally and/or on a per mapper field basis. >> >> Here is what I did: >> >> By looking at the sourcecode I noticed that following MappedDateTime >> ultimately this depends on internetDateFormatter, dateFormatter and >> toInternetDate inside TimeHelpers. Since I don't know how to change >> the dependency of MappedDateTime on TimeHelpers to a subclass of >> TimeHelpers I decided to break the dependency by subclassing >> MappedDateTime and overriding _toForm and setFromAny and have my >> setFromAny call a modified toDate that in turn depends on a custom >> function to parse a string to a date. This function: >> 1) Tries to use a specifically definded DateFormat on the field >> 2) Tries to get a dateformat from a localized bundle >> 3) Falls back to the SHORT date format of the JVM locale. >> >> Here is what I would like to know: >> >> 1) Is there a way to have Lift use a TimeHelpers subclass without >> having to subclass stuff that depends on it? >> 2) Does anyone have suggestions how to improve/invalidate my approach? >> >> Just checking to see if I am on the right path or making this >> needlessly hard. >> Thanks in advance for any response. > > Sounds like you're using 1.0? In 1.1-SNAPSHOT, date/time > parsing/formatting is done in LiftRules.parseDate/formatDate and can be > changed. Not quite per field flexibility though > > I think that this is also not locale specific (ie. per request), but > haven't looked too closely at this yet > > /Jeppe > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Overriding date/time formatting
Dirk Louwers writes: > Hi, > > After having toyed around with Scala and recently Lift for a few weeks > I have a question. To avoid jumping to conclusions let me first > explain what I am trying to achieve: > > I am not happy with the way MappedDateTime parses strings and formats > dates by default. I want to be able to change these parsers/formatters > globally and/or on a per mapper field basis. > > Here is what I did: > > By looking at the sourcecode I noticed that following MappedDateTime > ultimately this depends on internetDateFormatter, dateFormatter and > toInternetDate inside TimeHelpers. Since I don't know how to change > the dependency of MappedDateTime on TimeHelpers to a subclass of > TimeHelpers I decided to break the dependency by subclassing > MappedDateTime and overriding _toForm and setFromAny and have my > setFromAny call a modified toDate that in turn depends on a custom > function to parse a string to a date. This function: > 1) Tries to use a specifically definded DateFormat on the field > 2) Tries to get a dateformat from a localized bundle > 3) Falls back to the SHORT date format of the JVM locale. > > Here is what I would like to know: > > 1) Is there a way to have Lift use a TimeHelpers subclass without > having to subclass stuff that depends on it? > 2) Does anyone have suggestions how to improve/invalidate my approach? > > Just checking to see if I am on the right path or making this > needlessly hard. > Thanks in advance for any response. Sounds like you're using 1.0? In 1.1-SNAPSHOT, date/time parsing/formatting is done in LiftRules.parseDate/formatDate and can be changed. Not quite per field flexibility though I think that this is also not locale specific (ie. per request), but haven't looked too closely at this yet /Jeppe --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
