Hi, David,

I can give you a good example of a class hierarchy that I use in my
application (via JPA). In fact, it is a pair of coupled model
hierarchies.

The primary hierarchy is based in a class PaymentSource which has
subclasses such as CreditCard, CheckingAcct, and PayPalAcct. This is
then related to a class hierarchy PaymentSourceTransaction[T <:
PaymentSource]. There is an appropriate subclass
(CreditCardTransaction extends PaymentSourceTransaction[CreditCard])
for each type of payment source, and then interfaces AuthTransaction,
CaptureTransaction, CreditTransaction, and VoidTransaction with
subclass implementations for each type of payment source.

The model hierarchy ends up looking like this:

PaymentSource
     -> CreditCard
     -> CheckingAcct
     -> PayPalAcct

PaymentSourceTransaction[T <: PaymentSource]
    -> CreditCardTransaction extends PaymentSourceTransaction[CreditCard]
        -> CCAuthTransaction extends CreditCardTransaction with AuthTransaction
            ...
    -> CheckingAcctTransaction extends PaymentSourceTransaction[CheckingAcct]
        -> CheckingAuthTransaction extends CheckingAcctTransaction
with AuthTransaction

and so forth.

Kris


On Wed, Apr 1, 2009 at 8:17 AM, David Pollak
<[email protected]> wrote:
> Wow.  Awesome answer!
> A couple of things.  Some of the Mapper code is my earliest Scala attempts
> and other code is desperate attempts on my part to work around Scala's type
> system.  Some of it is instructive, but other parts are just wrong and ugly.
>  I'd suggest running in horror from any code that has asInstanceOf in it.
> I think there's also a lurking pattern in there someplace for a lazy val on
> the model instances that vends the "manipulator & logic" instance that can
> be one of many subclasses of a base class (or trait) and that implements
> logic based on the contents of the model.
> I'd like to see some examples of class hierarchies for model objects... that
> might help me understand how to build such a pattern into Lift.
> Thanks,
> David
> On Wed, Apr 1, 2009 at 6:18 AM, Giuseppe Fogliazza <[email protected]>
> wrote:
>>
>> Hi Tobias.
>> I am a newbie too, Hence wait for more solid support. Nevertheless I
>> made some investigate on how to describe a complex object model using
>> Mapper.
>> The short answer is that Mapper does not support inheritance and hence
>> you cannot specilized the ToDo class. Period.
>> Moreover in some topics in this group there were indication on
>> limiting the use of Mapper for simple object models, preferring JPA
>> integration for more complex structures or waiting for Record (Lift
>> 1.1) to get the best from both world.
>> After running throuh some examples I became addicted to some of
>> Mapper's functionalities such as CRUDify and .toForm that at the
>> beginning I was a little bit suspicious about (you know MVC purity and
>> all this stuff).
>> If limitations on relationship management could be easily overcome by
>> manually developed helper functions, inheritance is definitely a
>> different beast. But using traits it seems possible (even if a little
>> bit tricky at the beginning) to build hierarchies (and with multiple
>> inheritance too!). I suggest you to have a look to how the trait IdPK
>> is implemented in Mapper.scala (and in general look at the scala code
>> lift is made of, it is very insightful to both scala and lift).
>> The "only" limitation is that when you arrive to concretize a class
>> (and the related metaclass singleton) you cannot procede further with
>> inheritance (it should be a leaf in your hierarchy tree). I posted an
>> example some weeks ago you can have a look at just to understand what
>> I am talking about (tht topic was : Using Traits in complex domain
>> models )ards
>>
>> Regards
>> beppe
>>
>> On Apr 1, 11:21 am, Tobias Daub <[email protected]> wrote:
>> > Hi There,
>> >
>> > I'm new to Scala and Lift and still feeling a little bit lost.
>> >
>> > In case of the ToDo example from the Getting started guide: Would it be
>> > possible to make a more specialized version of a ToDo item that inherits
>> > from the existing one?
>> >
>> > This is more a general question about inheritance from Lift models,
>> > because I've to design some more complex class hierarchy, where its
>> > really necessary to have "stupid" classes that can be specialized later
>> > on.
>> >
>> > Apply the same rules about inheritance, traits, etc. to Lift models,
>> > too. Can I do all the stuff that I can do with "normal" classes?
>> >
>> > Thanks alot!
>> > Tobias
>>
>>
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to