+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.
