lib.web

[sjcarroll6]

I like the idea of keeping it minimal. I'm a beginner with Scala and
have looked at Play but it doesn't use the servlet api, instead it
uses Apache 's Mina. Lift is so big I don't really know where to get
started. I saw some of your earlier posts and it looks like you want
to use scalaQL for persistence. I have used twitter's querulous (on
github) and got it to work quickly. I did have a problem with
inserting nulls. I posted a question for them about that but never got
an answer.

For beginner's it might help to provide jars instead of using maven.
Play does not use Maven and it appears to be popular with many people.
Good luck.

[Dmitry Grigoriev]

Welcome,

For now I'm using Squeryl. ScalaQL and its target language Ferry
arrived to be interesting and promising (guys who created Ferry do
really serious work about it), but there's a lot of work to be done
before it all would be practically useful. DSL arrived to be more
convenient to use with IDE than typing LINQ inside string literal. So
I'll return to it when I have a bit more time, but not right now.

Considering Maven, yes it's confusing for the first time (to me, for
the second time too :))), but there's no alternative to its dependency
versioning mechanism. So I'm sure it worths troubling with it for a
while, for the sake of future convenience. In fact, without using it
you'll get to "jar hell" very soon. By the way, you don't need to do
anything but just install it, to get lib.web examples working. And
there is a maven project template subdirectory in lib.web distribution
so you can just take it and just edit project group and artifact names
there if you don't want to bore yourself with configuration.

Good luck to you, too. :)

[sjcarroll6]

Just a few more questions if you have time.

Is your framework dependent on Squeryl or can you use other
persistence frameworks like Twitter's Querulous?
If I understand correctly you plan on using Scala functions to write
the markup and not use snippets or templates.
I personally like the idea and think it's great for small dynamic web
sites developed by one or a few individuals.
Other frameworks like lift think it's a really bad idea as you
mention.My question is won't this approach require
development of lot's of widgets. For example will you develop widets
for charts, tables for paging thru data, etc?

Thanks for any comments. Next weekend I will give it a try and
download it and see how it works.

Thanks,

> > Good luck.- Hide quoted text -
>
> - Show quoted text -

[Dmitry Grigoriev]

> Just a few more questions if you have time.

Sure.:)

> Is your framework dependent on Squeryl or can you use other
> persistence frameworks like Twitter's Querulous?

It does not depend on anything but Scala and Servlet API. It's purely
web layer only, while DB-related stuff is somewhat closer to
application business logic layer. Well, it uses few Apache Commons
libs inside, but that's not visible to programmer.

> If I understand correctly you plan on using Scala functions to write
> the markup and not use snippets or templates.
> I personally like the idea and think it's great for small dynamic web
> sites developed by one or a few individuals.
> Other frameworks like lift think it's a really bad idea as you
> mention.My question is won't this approach require
> development of lot's of widgets. For example will you develop widets
> for charts, tables for paging thru data, etc?

Well, I think that it's up to programmers how they would decompose
their HTML pages to reusable components (and if they would decompose
at all). There are no restrictions in pure functional approach, and no
interference from lib.web, in fact.

The only area where I used explicit (though very simple) widget
classes is HTML form fields for forms module. But forms are always a
headache, so I don't consider a big problem to have separate support
for them. By the way, the second forms version I'm now developing is
*much* more complex than current one. It supports ajax, complex inter-
dependencies among fields, reloading all dependent fields in one HTTP
request when dependency field changes its value... And currently I'm
working on fully dynamic child form repeaters (e.g. for invoice
positions list). "It's hell out there". Making it all easy to use
naturally requires non-easy to create. C'est la vie.

> Thanks for any comments. Next weekend I will give it a try and
> download it and see how it works.

Waiting to hear about your impressions. :) And ready to help, of
course.