Quantcast

Scala Architecture

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Scala Architecture

Mick  Delaney
Hi,
I'm just looking into scala/lift at the moment, my background is
asp.net mvc/c#, ruby/rails. i also did some java/struts stuff about 5
or 6 years ago.
what i was wondering was what are the various architectural pieces of
scala.

e.g. in rails its mvc + active record,  in aspnet mvc (for me) its mvc
+ ddd (persistence ignorance etc). they both use similar approaches to
the UI
depending on what view engine you use.

from that high level point of view how does scala/lift relate?

regards,
mick

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Scala Architecture

Marius Danciu
Lift as you know is a web framework built on top of Scala language.
Thus we leverage Scala's power to provide an expressive and concise
framework. To me, this is about:

1. Use functional programming idioms for controlling complexity by
composition (higher order functions, currying, pattern matching etc.)
For instance when you create an Ajax button via SHtml you also provide
a Scala function that will be called by Lift

2. Use OO mixin-composition for better abstraction (see Mapper, Record
etc.)

3. Use Actors (we currently have a lighter version of actors LiftActor
which is fully interoperable with Scala actors). This is great for
using parallelism. Commet support is based on this.

4. For Lift templating we use Scala's XML support (NodeSeq, Elem etc),
and of course Scala's XML literals which are incredible handy. The
template engine is entirely built-in Lift.

5. We don't use MVC, but ViewFirst approach. IMO MVC has very little
value for web because this type of separation makes UI templating
cumbersome, gives a false sense of decoupling (i.e using Map
"variables" in the template created by controller), makes dynamic
rendering much more difficult that Lift's approach. Most of Lift
committers dealt in the past with most web-frameworks out there.

Br's,
Marius

On Mar 22, 12:40 pm, Mick  Delaney <[hidden email]> wrote:

> Hi,
> I'm just looking into scala/lift at the moment, my background is
> asp.net mvc/c#, ruby/rails. i also did some java/struts stuff about 5
> or 6 years ago.
> what i was wondering was what are the various architectural pieces of
> scala.
>
> e.g. in rails its mvc + active record,  in aspnet mvc (for me) its mvc
> + ddd (persistence ignorance etc). they both use similar approaches to
> the UI
> depending on what view engine you use.
>
> from that high level point of view how does scala/lift relate?
>
> regards,
> mick

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

dpp
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Scala Architecture

dpp
In reply to this post by Mick Delaney


On Mon, Mar 22, 2010 at 3:40 AM, Mick Delaney <[hidden email]> wrote:
Hi,
I'm just looking into scala/lift at the moment, my background is
asp.net mvc/c#, ruby/rails. i also did some java/struts stuff about 5
or 6 years ago.
what i was wondering was what are the various architectural pieces of
scala.

e.g. in rails its mvc + active record,  in aspnet mvc (for me) its mvc
+ ddd (persistence ignorance etc). they both use similar approaches to
the UI
depending on what view engine you use.

from that high level point of view how does scala/lift relate?

Marius has given a great over-view of view-first.  I'll add a few other bits:
  • Lift's model is more secure by default because it's resistant to replay attacks and the developer does not have to manually unpack requests and check for permissions on unpack.
  • Lift's model lends to much, much cleaner Ajax sites because you don't have to set up a route/controller for each Ajax request.
  • Lift's model is the best for Comet because each of the dynamic (server-push) components is independent, so you can include many combinations of Comet components on a page.
If your app is just a CRUD DB app, then the likes of Rails is probably going to be better for you just based on the number of developers available to do Rails work.  If you care about security and interactivity, then Lift has a lot of advantages in its approach.
 

regards,
mick

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.




--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Loading...