Inca Nauthiz

Greenhorn
+ Follow
since Nov 21, 2008
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by 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.
9 years ago
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.
9 years ago
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...
9 years ago
Sorry, I've stopped using Hibernate a couple of months ago. I mentioned some points here.
9 years ago
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.
    9 years ago
    Ebean is rather cool. Or you may try pure-Scala Circumflex ORM (but the latter is under active development for now).
    9 years ago
    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


    TestController.java


    applicationContext.xml


    view.jspx


    faces-config.xml


    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