classOf[Entity with SurrogateIntId]

[Peter Hancox]

I am using Vaadin as the UI framework for web application and one of the container classes for working 

with display of database entities expects the entity class as a parameter to the constructor.

new BeanContainer[Int, Person](classOf[Person]) {

    setBeanIdProperty("id")

    ...

}

The code fails at run time when it can't locate the "id" property in the Person entity.  I've tried "classOf[Person with SurrogateIntId]"

but the compiler doesn't like having a mixin passed to "classOf".

Is there a way to reference a class derived directly from the entity that includes the surrogate key?

[Peter Hancox]

The following code seems to work but a bit messy.  Would be nice if there was something similar already 

available within the mapperdao framework.

    abstract class PersonX extends Person with SurrogateIntId

    container = new BeanContainer[Int, PersonX](classOf[PersonX]) {

[Konstantinos Kougios]

Hi Peter, if you debug your Person with SurrogateIntId, what is the real id field like? Is it

1.    id

2.    something like $person$surrogate$id ?

--
You received this message because you are subscribed to the Google Groups "mapperdao" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapperdao+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Peter Hancox]

The "id" field is probably fine but wouldn't exist in "Person" class.  It looks as if the Vaadin code builds a map

of the properties of the class passed in via the constructor.  Hence requires the mixin with SurrogateIntId

BTW the approach of using the abstract class didn't work in the end because the Vaadin code to add

the bean doesn't like it when the object being added doesn't match the class passed in the constructor.

Even though the abstract class and the bean being added are "Person with SurrogateIntId" they are

seen as different classes.

Anyway the following code works without having to solve my original issue and at the moment seems 

sufficiently robust and minimal that, other than for academic interest, I won't bother pursuing how to

achieve "classOf[Person with SurrogateIntId]"

    p.setContainerDataSource(new BeanContainer[Int, Person](classOf[Person]) {

      import com.googlecode.mapperdao.Query.{ select => dbselect }

      val p = personEntity

      val query = dbselect from p orderBy p.surname

      val persons = queryDao.query(query)

      persons foreach { person =>

        addItem(person.id, person)

      }

    })

The Vaadin "addItem()" as opposed to "addBean()" allows manual specification of the "id" and avoids the

original problem.

BTW would be interested if you know a better way to solve the problem causing me to use "dbselect"

instead of "select" in the query.  Had me stumped for a while as to why "select" wouldn't work.  Turns out

that this code is in a subclass of Vaadin's ComboBox that has a "select" method defined.  Without doing

the mapperdao import again (it was already done at the start of the file) then scala assumes this to be the 

ComboBox select method.  If I just reimport mapperdao without the rename then scala complains about

an ambiguous reference.

Renaming the mapperdao select as in the code above works. But in this particular code I'm not likely to use

the ComboBox "select" method and would prefer "select" to  be the mapperdao one.  Any idea how I would

force scala to interpret "select" as the mapperdao one rather than the method from a superclass?  Just using

"import com.googlecode.mapperdao.Query.select" still complains of ambiguous reference.

REGARDS

Peter

[Konstantinos Kougios]

Hi Peter,

    Regarding the import issue, I don't know if there is a way to sort this out, what I normally do is have all dao code in dao classes (using also the mixin traits , https://code.google.com/p/mapperdao/wiki/CRUDDaos?ts=1371286264&updated=CRUDDaos )

So you could have this dao:

class PersonDao(mapperDao: MapperDao, queryDao: QueryDao) extends TransactionalSurrogateIntIdCRUD[Person] {
    protected val entity=PersonEntity
    private val p = entity

    def bySurname = queryDao.query(select from p orderBy p.surname).toList(queryDao)
}

this way you don't get the "select" conflict and you gain also the CRUD methods (transactional) and you can add all queries there. But then again you need a way to inject it into your vaadin class.


About vaadin, which version are you on? Are you using scaladin with it?

Cheers

[Peter Hancox]

I already have DAO classes as you describe.  Still figuring out "best practices" as I go while attempting to port some existing 

code.  The query was in a Java anonymous function which is why it ended up where it is at the moment.  Putting it in the

DAO class makes a lot of sense particularly because this query should be a good candidate for frequent reuse.  Thanks for

that suggestion.

I'm using Vaadin 7.0.7 with Scaladin 3.x built locally.  Just noticed you had an issue on the scaladin github wiki.  Are you

working much with scaladin yourself?  At the moment I'm doing some R&D on the next generation of our technical framework

which includes re-evaluating our entire technology stack.

• replace Java with Scala (very high likelyhood)
• replace custom ORM with mapperdao (high likelyhood)
• replace PHP with Vaadin (very high likelyhood)
• lots of other 3rd party libraries

Having a few problems with scaladin and the BeanContainer at the moment.  Thankfully most scaladin issues can be 

worked around by falling back to plain Vaadin API.

[Konstantinos Kougios]

I'm using scaladin v2 at one of our main projects at work with vaadin 6.8. It works nicely for some admin UI's but we had issues when migrating from scala 2.9.2 to 2.10 as there was no build for scala 2.10 of scaladin. I had to manually migrate and build it. I was hoping they had a scala version support policy, it makes sense to support at least 2 scala versions like mapperdao does.

Vaadin v7 looks fantastic, I wonder if migration from 6 is easy.

Best of luck with your R&D

[Peter Hancox]

I've been a bit lucky with my timing :-)

Did a proof of concept with Vaadin 6 about a year ago.  It only had a couple of screens so moving to 

Vaadin 7 was reasonably straight forward.  About the time I started working with Scala, version 3 of

scaladin was firming up.  So although I'm close to the bleeding edge, I don't have many legacy code 

issues and it's only R&D so no production maintenance issues.

Interested in your feedback on Vaadin in production deployment?  I'm looking for rich functionality 

in the UI rather than high-volume.  Main projects are emulating our Java Swing applications so I'm

seeing Vaadin as a viable framework.

CHEERS

[Konstantinos Kougios]

We've been using it for an admin interface (internal so very low traffic) and I am very happy with it. We build the UI without a web designer, a tree control on one side, a menu bar on top and tabs in the main content area. We got scala scripts that are listed on the tree. We run those scripts (and update them on the fly using my other lib, https://code.google.com/p/scalascriptengine/ ). The scripts does bits of work or even contribute with UI forms, tabs and menus and the look and feel is great considering no web designer person was involved. The coding is a bit java-ish but scala and scaladin helps a lot. And it is easy to build rich UI.

Cheers