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.
