How to organize Scala code in Lift project?

Question

After 1.5+ years of Ruby and Rails programming, I have finally started working on one of the new projects in Scala and Lift. Basically I'm trying to write an API for accessing information from a huge database (millions of rows). Lift should help me code the frontend of this project (the API part). But now, this also involves a module that would read from a compressed ZIP XML file to initially populate the database with rows. This module would need to run once in 3 months.

Where should I place this module code? or rather, How should I organise my Lift and Scala code? Where does the background processes go? Any pointers in this regard are welcome.

Jarman

"huge database (millions of rows)"? I see similar statements from time to time and like to pedantically point out, just for a reference, that "millions of rows" isn't a huge database (unless each row/object is > GB). I'm working with BI databases where single tables have 100s of millions of rows with working data-sets ~50GB. And this still isn't a "huge" database. The metadata alone is millions of "rows". – Volute

I think the OP is using the imperial 'Huge', whilst you are referring to the metric 'Huge'. – Lemmy

Answer 1

I'm a little uncertain if this is what you're after, but I'm using SBT (http://code.google.com/p/simple-build-tool/). It draws up a default project structure. You should especially look at sub projects (http://code.google.com/p/simple-build-tool/wiki/SubProjects).

For scheduled processes you could use an actor and the ActorPing to restart the process on regular intervals. For such long intervals as 3 months you could keep track of last invocation by touching a file and checking the date on application restart. The ActorPing need to be initiated on application startup; this can be done in the lift boot. If you need to modularise it more you could create a servlet that initiates the ActorPing on servlet init.

Newman

Well, I knew about SBT but the subprojects is something good to look at. Also the explanation about Background projects is really helpful. Thanks. – Jarman

Answer 2

Lift follows (at least the versions I use) a standard Maven 2 structure, so there is nothing special there. Just add the code in the src folder. The packages to create will depend on your design/preferences, we can't really help you with that :)

Tamikatamiko

Thats definitely helpful again. So basically there doesn't seem to be any conventional way of doing things in Lift. I don't know if that is good or bad. – Jarman

Answer 3

The "standard" Lift project using SBT as the build usually calls for the following project structure:

project
src
  main
    scala
      bootstrap
        liftweb
          Boot.scala
      project-name
        comet
        lib
        model
        snippet
        view
    resources
    webapp
      WEB-INF/web.xml
      index.html
  test
    resources
    scala
      RunWebApp.scala

If you are using the Lift Mapper ORM, you generally put your models in the src/main/scala/project-name/model directory. Likewise, any of your CometActors should go in src/main/scala/project-name/comet. Any custom Snippets you write should be in src/main/scala/project-name/snippet and any custom View components in the view directory under project-name. All of the code related to booting up your application and establishing database connectors, etc, should go in src/main/scala/bootstrap/liftweb/Boot.scala. The rest of the structure falls out like the previous answers have said, which follows the general Maven 2 structure.

This is just the general structure that is provided by the default Lift app. The only thing that is required is the bootstrap.liftweb.Boot.scala file, as the Lift Servlet looks for that class during boot.

Mainz