Comments on: Building a smart EntityModel

By: ivaynberg

ivaynberg — Mon, 15 Dec 2008 18:49:09 +0000

@Paul: I had to do a lot of refactoring in 1.4 to get this working correctly. Unfortunately I cannot port this back to 1.3 because it has production apps running on it that might depend on the functionality this changed.

It is pretty easy to set up a single-transaction-per-request pattern in wicket. It is not as granular as a transaction for the form submit, but it should still work.

public class WicketRequestCycle extends WebRequestCycle
{
    private TransactionStatus txn;
 
    @Dependency
    private PlatformTransactionManager txm;
 
    public WicketRequestCycle(WebApplication application, WebRequest request, Response response)
    {
        super(application, request, response);
    }
 
    @Override
    protected void onBeginRequest()
    {
        txn = txm.getTransaction(new DefaultTransactionDefinition());
        super.onBeginRequest();
    }
 
    @Override
    protected void onEndRequest()
    {
        super.onEndRequest();
        if (txn != null)
        {
            txm.commit(txn);
            txn = null;
        }
    }
 
    @Override
    public Page onRuntimeException(Page page, RuntimeException e)
    {
        if (txn != null)
        {
            txm.rollback(txn);
            txn = null;
        }
        return super.onRuntimeException(page, e);
    }
}

By: Paul Mogren

Paul Mogren — Mon, 15 Dec 2008 16:42:29 +0000

@Igor
In reference to comment #18,
I’m trying to find a way to achieve this in Wicket 1.3, and having a hard time. It appears that onSubmit() is not called within form.process(), and a lot of the methods I might try to override for this are declared final. Can you (or anyone) suggest where I can begin and end the transaction? THanks

By: Persistenz für den Feedreader - rattlab.net

Persistenz für den Feedreader - rattlab.net — Tue, 28 Oct 2008 20:01:43 +0000

[...] Das NewsModel ist nicht von LoadableDetachableModel abgeleitet, da wir keinen schreibenden Zugriff auf das zu speichernde Objekt hätten, sondern dieses immer über load() geladen werden müsste. Dennoch ist die Model-Klasse recht einfach und übersichtlich. Es speichert die ID und die News selbst, beim Speichern in der Session wird die News aber nicht serialisiert. Werden die Daten wieder aus der Session geholt (z.B. durch ein Neu Laden der Seite), so wird die News anhand der ID erneut aus der Datenbank geladen. Eine allgemein gehaltenere Version eines solchen Models beschreibt Igor Vaynberg, einer der Wicket-Mitentwickler, im Blogeintrag “Building a smart EntityModel”. [...]

By: Jörn Zaefferer

Jörn Zaefferer — Mon, 06 Oct 2008 13:33:29 +0000

Okay, that makes sense. Thanks for clarifying.

By: ivaynberg

ivaynberg — Mon, 06 Oct 2008 04:19:11 +0000

@Jörn: We want the entity loaded, updated, and saved all in the same transaction. onSubmit() is called after wicket has already applied user inputs to the model object, at that point you would have to session.merge() your changes instead of having them transparently persisted.

By: Jörn Zaefferer

Jörn Zaefferer — Sun, 05 Oct 2008 21:38:15 +0000

Whats the adavantage of overriding process and doing a rollback when super.process returns false, instead of just overriding submit? Submit gets called only when the submit is valid, so no transaction gets started unless the submit is actually valid.

By: ivaynberg

ivaynberg — Sat, 04 Oct 2008 16:27:24 +0000

@Marcell: Sure. I can do the same thing with the Session and a uuid token stored in the model. The big advantage of just using the model is that it is its own conversational scope. Eg, the user does whatever they need and the conversation ends, then the user presses back button 4 times and tries to do something - error because conversation has already been closed. This wouldnt happen with the model because it would be stored with the page and retrieved again.

By: Marcell

Marcell — Sat, 04 Oct 2008 09:36:38 +0000

@Igor: When I mean to use the conversational context you wouldn’t store the transient Model in the EntityModel. You probably would do at detach and attach:

if (entity != null) {
if (if (entity.getId() != null) {
…
} else {
Context.getConversationContext().set(this.getClass().getName()+”#entity”,entity);
}
}

And at getObject():

if (entity == null) {
if (id != null) {
…
} else {
entity = (T) Context.getConversationContext().get(this.getClass().getName()+”#entity”);
}
}

By: ivaynberg

ivaynberg — Sat, 04 Oct 2008 04:31:15 +0000

@Iman: its not really a workaround, more of a way you build your app. The problem here is that the model is shared between multiple pages, so the solution is to eliminate multiple pages. Instead of navigation consisting of going from page to page you can instead keep the user on the same page and accomplish the same navigation by swapping out the “content” panel.

class ViewUserPanel extends Panel {
  public ViewUserPanel(String id, IModel user) {
      add(new Link("edit") {
         onclick() {
             onEditUser(getModel());
         }
      });
   }
 
   private void onEditUser() {
        replaceWith(new EditUserPanel(getId(), getModel()));
   }
}

So, instead of calling setResponsePage(new EditUserPage()) you swap the panel…

By: Iman Rahmatizadeh

Iman Rahmatizadeh — Sat, 04 Oct 2008 04:22:56 +0000

@Igor: I wasn’t aware of any workaround with panels. As I use panels extensively in my app, would you care to elaborate how it would help in this scenario ?