Hmm, now this begs the question--does a ConversionRules object indeed belong in http?
------------------------------------- Timothy Perrett<timo...@getintheloop.eu> wrote: +1 object in the http package sounds good to me for logical ordering. Cheers, Tim On Jan 11, 8:37 am, Marius <marius.dan...@gmail.com> wrote: > On Jan 11, 10:27 am, Jeppe Nejsum Madsen <je...@ingolfs.dk> wrote: > > > > > > > Naftoli Gugenheim <naftoli...@gmail.com> writes: > > > A while ago I started working on having separate parsers and formatters > > > in LiftRules for date, date-time, and time values. These could then be > > > used by Mapped(Date)(Time). > > > Great! > > > > I would like to continue working on it, and I would appreciate feedback > > > on the following point. > > > Marius pointed out that it may be a smarter idea, that instead of putting > > > all six variables in LiftRules itself, I should group them together > > > somehow. Here are some possibilities of how to do so. I would appreciate > > > if everyone could vote on one of these ideas or suggest another way. > > > 1. Where? > > > - Put them outside of LiftRules, in a new object called something like > > > FormattingRules > > > - Create an object inside LiftRules, so you would end up writing > > > 'LiftRules.formatRules.formatDateTime ...' > > > - Stick it in TimeHelpers (XXXHelpers are usually not configuration but > > > predefined routines) > > > - Just put it in LiftRules (so what if it just keeps growing) > > > I think the rules should be in LiftRules somehow, and I can envision at > > least 12 functions (date,time,date/time,int,double,currency) I think > > some grouping is needed. But probably also with helpers in > > TimeHelpers so we don't have to type LiftRules.formatRules.format..... > > > I haven't given much thought to this, but maybe a generic trait like > > > trait Conversion[T] { > > def format(v:T) : String > > def parse(s:String): T > > > } > > > could be used? > > I'm not sure if a trait is necessary. Something like > LiftRules.conversionRules.xxx makes sense to me where conversion is in > LiftRules something like: > > val conversionRules = ConversionRules > > where: > > object ConversionRules { > > // put here conversions from LiftRules > > } > > I'd even put this in its own scala file. > > > > > > > > 2. What to call the container > > > - It includes both parsing and formatting, so neither is an accurate > > > name at first glance, but then again parsing is not formatting a a > > > verb but it deals with a particular format > > > Conversion? > > > > - Currently it only deals with java.util.Date, so one could suggest > > > DateRules, but other similar configuration could go here -- formatting > > > numbers? Any other possible future additions? > > > Currency, int (with/without thousand separator), double (with/without > > thousand separator, "," or "." as decimal sep etc) > > > > - 'Text' after java.text? > > > - Any good ideas? > > > Thanks! -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
-- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.