I think so because it's about user's defined rules ... it's just an "extension" of LiftRules, amd LiftRules lives in http package.
Br's, Marius On Jan 11, 6:45 pm, Naftoli Gugenheim <[email protected]> wrote: > Hmm, now this begs the question--does a ConversionRules object indeed belong > in http? > > ------------------------------------- > > Timothy Perrett<[email protected]> wrote: > > +1 > > object in the http package sounds good to me for logical ordering. > > Cheers, Tim > > On Jan 11, 8:37 am, Marius <[email protected]> wrote: > > > On Jan 11, 10:27 am, Jeppe Nejsum Madsen <[email protected]> wrote: > > > > Naftoli Gugenheim <[email protected]> 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group > athttp://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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
