Here's some code I used when two tables share some fields and their
Mappers can share a base trait. I have Fields which have difference
Types, some of which reference lookup tables.
trait BaseLookupTable[T<:LongKeyedMapper[T]] {this: T =>
object field extends LongMappedMapper(this: T, Field)
object label extends MappedString(this: T, 100)
}
class LookupTable extends LongKeyedMapper[LookupTable] with
BaseLookupTable[LookupTable] with IdPK {
def getSingleton = LookupTable
object sort extends MappedInt(this)
}
object LookupTable extends LookupTable with LongKeyedMetaMapper[LookupTable]
class RangeLookupTable extends LongKeyedMapper[RangeLookupTable] with
BaseLookupTable[RangeLookupTable] with IdPK {
def getSingleton = RangeLookupTable
object value extends MappedInt(this)
}
object RangeLookupTable extends RangeLookupTable with
LongKeyedMetaMapper[RangeLookupTable]
And here's how I get the lookup table for a given type.
class Field extends LongKeyedMapper[Field] with IdPK {
def getSingleton = Field
...
object fieldType extends MappedEnum(this, Field.Types)
}
object Field extends Field with LongKeyedMetaMapper[Field] {
...
object Types extends Enumeration {
val Boolean = Value("Checkbox")
val Int = Value("Number")
val Lookup = Value("General Lookup")
val RangeLookup = Value("Range Lookup")
def lookupTable(v: Field.Types.Value): Option[BaseLookupTable[T]
forSome{type T <:net.liftweb.mapper.Mapper[T]}] = v match {
case Lookup => Some(LookupTable)
case RangeLookup => Some(RangeLookupTable)
case _ => None
}
}
}
On Tue, Oct 6, 2009 at 10:15 AM, Jim Barrows <[email protected]> wrote:
>
>
>
> On Oct 2, 7:55 pm, Dave <[email protected]> wrote:
>> Hi all-
>>
>> I posted this on stackoverflow but I figure its probably relevant here
>> too. I checked out the post with David and Steve Yen corresponding
>> but I am still at a loss and am curious if any progress has been made
>> in this direction. So, here goes. I am creating a website which will
>> need two types of users: students and providers. In a traditional java
>> setting I would create a user class (or interface) and then create two
>> classes which inherited from the user. Is this the best course in
>> scala too, using the "extends" and "with" modifiers? If that is indeed
>> the best way (which I suspect it is), what the best way to map this in
>> the DB? Would it be best to keep a "type" column and then have it set
>> to one or the other? Etc.
>
> A student is not a kind of user, nor is a provider. They are roles
> that a user plays in your system.
> While your business rules may state that this is not possible, it is
> possible in the real world. That's what's best to model, since
> business rules can change quite easily.
> I can even make an argument that Person has user as role, and that
> there are two types of users.
>
>>
>> The second question is how to work with the view. The display will be
>> very different depending on which type of user one is and so I figure
>> there will be some serious routing logic involved or at least logic
>> built into snippets in the view.
>
> Why not use 3 directories, one for common stuff, one for the provider
> and one for the student.
> Reduces the number of if statements that way.
>
>>
>> I guess the overarching question is: Is there a "preferred" way to go
>> about doing this (like a recipe in rails or some such), or am I kind
>> of out on my own?
>>
>> 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 at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
