myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Punz <werner.p...@gmail.com>
Subject Re: MyFaces Fusion
Date Tue, 27 Feb 2007 09:45:28 GMT
Ok here is a first small bite:

What we have here is a simple detail conversation
the master gets injected so that we can have work done
after update
but lives in its own conversation

what happens the user id is injected so is the master
(design decision i chose, you probably could get
the affected dataset also from the master if you set it there,
but I wanted to have clear boundaries so i pushed in the uid of the user
and have it reloaded insted of merging it in.

The entire time the form is open the conversation keeps the user and the
db connection

now if you want to save it...
 public String dosubmit() {
        flushCurrentUser();

        usermasterview.findUsers();//we refill our view dont access the
db objects there, different em
        return StdOutcome.SUCCESS;
    }


flushcurrentUser basically just goes into an entity manager flush
(the Entity Manager is injected by @PersistenceContext somewhere in the
bo layer automatically, fusion + spring takes care of that,
hence theoretically you could go for a seam like approach of injecting
the PersistenceContext directly into the conversation.

anyway, em.flush that is it or em.persist in case of a create
all the time you work on the same user object coming from the entity
manager and having it referenced there.

 usermasterview.findUsers();//

refills the master view with new data so that at a back
or go_master situation you have the updated data there

once you are done
Conversation.getCurrentInstance().invalidate();
        return "go_master";

For simple navigational use cases you can invalidate all open
conversations at once, so that you do  not have pending conversations.
If you still run into those, the conversations time out after while.





public class UserDetailView {
    UserBO userbo;
    User user = new User();
    UserMasterView usermasterview;

    int userid;
    boolean postinitialized = false;
    String viewmode = "create";


    public int getUserid() {
        return userid;
    }


    public void setUserid(int userid) {
        this.userid = userid;
        if(!postinitialized) {
            postInitialize(userid);
        }
    }



    public void setPreinitUserid(int userid) {
        postInitialize(userid);
    }
    public int getPreinitUserid() {
        return -1;
    }


    public void postInitialize(int userid) {
        postinitialized = true;
        user = userbo.loadUserById(userid);
        viewmode = "edit";
    }

    public String dosubmit() {
        flushCurrentUser();

        usermasterview.findUsers();//we refill our view dont access the
db objects there, different em
        return StdOutcome.SUCCESS;
    }

    public String dogomaster() {
        Conversation.getCurrentInstance().invalidate();
        return "go_master";
    }


    public void flushCurrentUser() {
        userbo.createUpdateUser((User)user);
    }



    public UserBO getUserbo() {
        return userbo;
    }

    public void setUserbo(UserBO userbo) {
        this.userbo = userbo;
    }


    public User getUser() {
        return user;
    }

    public void setUser(User user) {
        this.user = user;
    }

    public String getViewmode() {
        return viewmode;
    }

    public void setViewmode(String viewmode) {
        this.viewmode = viewmode;
    }

    public UserMasterView getUsermasterview() {
        return usermasterview;
    }

    public void setUsermasterview(UserMasterView usermasterview) {
        this.usermasterview = usermasterview;
    }

}



Arash Rajaeeyan schrieb:
> how can I see the result of this work?
> 
> On 2/27/07, *Werner Punz* <werner.punz@gmail.com
> <mailto:werner.punz@gmail.com>> wrote:
> 
>     Sorry to jump in here again,
>     I have been playing guinea pig the last
>     week for marios work.
>     All I can say is this thing now is highly usable
>     by now.
>     You can put a view controller under conversation scope
>     (not a shale one yet, you will lose the callbacks)
>     and simply work on the stuff now like you would do in a rich client
>     environment with an EntityManage, Hibernate Session open for the entire
>     conversation.
> 
>     once you hit a point when you want to terminate, you can have the view
>     controller/conversation invalidate itself or restart itself.
> 
>     Also binding component bindings onto such a conversation is taken care
>     of, you can push them into a separate bean which you weave in by
>     a scope of request and aop:scoped-proxy, then you basically get a fresh
>     view onto your backend component bindings at every request.
> 
>     To sum it up, I just almost finished a first full master detail crud
>     ( I have done several details forms before)
>     The master form has about 30 lines of core code, excluding the setters
>     and getters already dealting with dao calling, handling the query part
>     etc... and adding a detail was a matter of one hour of figuring out
>     which patterns work best and a few minutes of implementation
>     handling new update and delete.
>     The objects you work with always are the same the orm layer accesses,
>     so a simple update ends up normally with
> 
>     entitymanager.flush ();
> 
>     And btw. bindings for hibernate and jpa already are in place...
> 
>     All I can say is a lot of thanks to mario for this, this is a killer...
>     I think he has found the right mix of exposing the api and
>     trying to automate. Seam while being excellent and Gavin was entirely
>     correct with his approach of keeping the entitymanager open for a
>     conversation, automates and hides way too much for my taste.
>     One example is that it takes away the control how you connect
>     the master and the detail, and in the end breaks the Tomahawk table
>     that way.
> 
> 
>     Gerald Müllan schrieb:
>     > Mario,
>     >
>     > i am feeling very confident that this will be a great addition to
>     > MyFaces in the near future.
>     >
>     > Through many lessons learned, I can admit that using Spring + JSF
>     > together makes up a powerful combination. Tying the new
>     > Spring/MyFaces-Conversation scope to JSF brings us beneath a
>     > "seam-approach", but with less burden. I am quite curious about using
>     > the sample-app!
>     >
>     > As i believe, the sandbox stuff will be removed, after fusion will be
>     > quite stable.
>     >
>     > I also agree that it should have been discussed on the list, but ok it
>     > is done now. Next time
>     > devs should be informed before such a big commit takes place.
>     >
>     > cheers,
>     >
>     > Gerald
>     >
> 
> 
> 
> 
> -- 
> Arash Rajaeeyan


Mime
View raw message