CODEWITHSUNDEEP
scalalift
James Black
James Black

Reputation: 41858

Whether to copy or extend megaprotouser or metaprotouser to integrate liftweb with existing database

I am working on a proof of concept to show work the benefits of lift over MS MVC, so I am working on having liftweb integrate with an existing DB.

I would like to re-use what I can, but the user object needs to be modified, as there are behavior changes and I need to add and remove some attributes.

Would it make more sense to extend Mega or meta proto user or just copy the class and modify it under a new name, and just use that in my project?

If I modified it I could just add some new traits to change the behavior, but I need to change what is used to login as email isn't used.

In java I could use an aspect (AOP) to do this, and I think there may be a similar way in scala, but I am not certain.

I am integrating with MSSQL, so I expect it would be best to use mapper instead of record for this integration.

Upvotes: 1

Views: 242

Answers (1)

leedm777
leedm777

Reputation: 24032

Scala runs on the JVM, so AOP techniques still work. But what most people find is that Scala's language features usually provide a cleaner and simpler way to accomplish their goals than AOP.

You can probably accomplish what you want by simply extending MegaProtoUser/MetaMegaProtoUser and overriding the methods you wish to change. For example, you can override def findUserByUserName(username: String) to search by a username field instead of email address. The proto classes are designed for this sort of customization.

If you find yourself wanting to change so much that you want to copy/paste the whole thing, at that point I'd recommend just writing your own user classes, or using something that better fits your needs. There's nothing magical about the proto classes; they are simply there to give you a starting point. Plus, there are things that they do that would be bad form in production code (namely putting HTML in the model code).

Tim Perret said it best in Lift in Action:

The Proto-series traits are a starting point, not an ending solution. In many ways, they’re similar to Rails’ scaffolding: they boost productivity in the short term, but in the long term you’ll outgrow them and gradually factor them out of your application, either by replacing with your own code or perhaps with code from some plugin or library.

Speaking of Tim and plugins, he wrote lift-shiro, which integrates Lift with Apache Shiro. That may also be worth checking out.

Upvotes: 4

Related Questions