Inca Nauthiz

I wouldn't recommend overusing case classes. Scala Tips mentioned inheritance ambiguities with case classes.
In my little experience case classes help in small matters, in such points, where no extensions are planned (for example, in domain model parts, to avoid equals/hashCode boilderplates). They greatly increase readability in such cases. On the other hand, using them just to save three characters from unnecessary "new" keyword may introduce other concerns. Use them wisely.

Trait is much more similar to Java interface than to abstract class. As it was mentioned before, trait does not have constructor – it implies that trait is not meant for instantiation by itself.
It is generally used to add some stuff to existing classes. And all interface-related patterns are implemented with traits, too.

I'm afraid I can't go with self-advertisement stuff. What do you expect from your web application framework? The "advanced" term appears to be pretty blur...

Sorry, I've stopped using Hibernate a couple of months ago. I mentioned some points here.

Actually, Hibernate is not the best choice for Scala:

you cannot use nested annotations (at least in Scala 2.7) => you cannot use Hibernate Annotations

Hibernate Criteria API (the O from ORM) does not use type parameters

most Hibernate-understandable collections are from java.util._ package; your code will become _very_ error-prone (or
just consist of endless Scala-to-Java-to-Scala-to... collection conversions)

Finally, Hibernate3 is for _idiomatic Java_, not for _idiomatic Scala_; Scala and Java just aren't the same things. For example, you finally relieved that you don't mess your code with getters/setters -- and then decided to use Hibernate Validator. Voila! JSR303 – write getters. No really, this stuff sucks.

Ebean is rather cool. Or you may try pure-Scala Circumflex ORM (but the latter is under active development for now).

Thank you a lot, Gregg! Appreciate your help very much!
(I've also found that <!--@elvariable ... --> works for .jspx)
Though defining lots of beans in every page happens to be a bit inconvenient... Probably next releases will be aware of DelegatingVariableResolver...

Has anyone managed to use JSF + Spring (via DelegatingVariableResolver) autocompletition in .jsp(x) with IDEA (any version)?
I end up with "Cannot resolve variable ..." (the deployed project works though).

Sample scenario:
TestBean.java
public class TestBean { private String id; private String name; ... }

TestController.java
public class TestController { private List testBeans; ... }

applicationContext.xml
... <bean id="testController" class="bz.avalanche.test.TestController" scope="session"> <property name="testBeans"> <list> <bean class="bz.avalanche.test.TestBean"> <constructor-arg index="0" value="1"/> <constructor-arg index="1" value="someName"/> </bean> <bean class="bz.avalanche.test.TestBean"> <constructor-arg index="0" value="2"/> <constructor-arg index="1" value="someOtherName"/> </bean> <bean class="bz.avalanche.test.TestBean"> <constructor-arg index="0" value="3"/> <constructor-arg index="1" value="yetAnotherName"/> </bean> </list> </property> </bean> ...

view.jspx
... <ice:form> <ice:dataTable value="#{testController.testBeans}" var="testBean"> <ice:column> <ice:outputText value="#{testBean.id}"/> </ice:column> <ice:column> <ice:outputText value="#{testBean.name}"/> </ice:column> </ice:dataTable> </ice:form> ...

faces-config.xml
... <application> <view-handler>com.icesoft.faces.facelets.D2DFaceletViewHandler</view-handler> <variable-resolver>org.springframework.web.jsf.DelegatingVariableResolver</variable-resolver> </application> ...

Everything works just as expected (I see the table with beans instantiated via Spring's IoC), but IDEA refuses to resolve testController bean from view.jspx. It results in great productivity impact as I loose all auto-complete features, model validations, etc. Please help! Or provide me with any kind of workaround possible.

TIA, Incarnate