unknown
1970-01-01 00:00:00 UTC
--
Jason Porter
<http://lightguard-jp.blogspot.com>http://lightguard-jp.blogspot.com
<http://twitter.com/lightguardjp>http://twitter.com/lightguardjp
Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling
PGP key id: 926CCFF5
PGP key available at: <http://keyserver.net>keyserver.net,
<http://pgp.mit.edu>pgp.mit.edu
_______________________________________________
seam-dev mailing list
seam-***@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--e89a8f234aad62773b04b6afc6d0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable <html><body bgcolor="#FFFFFF"><div>Jason,</div><div><br></div><div>You're Right, i completely forgot about the multiple entry view approach.</div><div><br></div><div>But since Ove didnt mentioned about multiple views, I assumed JSF is the only entry point, which adding REST may be overengineering.</div> <div><br><br>Em 17/01/2012, ?s 00:00, Jason Porter <<a href="mailto:***@gmail.com">***@gmail.com</a>> escreveu:<br><br></div><div></div><blockquote type="cite"><div><div><br><br>Sent from my iPhone</div> <div><br>On Jan 16, 2012, at 18:46, George Gastaldi <<a href="mailto:***@gmail.com"><a href="mailto:***@gmail.com">***@gmail.com</a></a>> wrote:<br><br></div><div></div><blockquote type="cite"><div> <div>One solution is to have a backend store for the conversation scoped beans (Infinispan maybe ?) and never mess with the session. Probably the conversation Ids should be unique as well, so you must generate them uniquely.</div> </div></blockquote><div><br></div><div>My thoughts.?</div><br><blockquote type="cite"><div><div>Since you are using JSF, why not queueing events using the ajax support ?in JSF 2.0+? Adding REST services with JSF sounds like an action based solution which may subestimate the power of the JSF itself.</div> </div></blockquote><div><br></div><div>Not if you have multiple entries into the app. If you do it right, all the business logic ends up going through the REST classes. You could simply inject the REST classes and use them like normal POJOs in JSF backing beans, an entry into the app using HTML5, GWT, desktop client, native mobile client, etc. it's actually a very good separation if you need multiple entry points into the app. This essentially boils down to one common entry point, multiple views. I think it's quickly becoming my preferred architecture.?</div> <br><blockquote type="cite"><div><div>My two cents ;)</div><div><br></div><div>Regards,</div><div><br></div><div>George Gastaldi</div><div><br>Em 16/01/2012, �s 22:27, Jason Porter <<a href="mailto:***@gmail.com"><a href="mailto:***@gmail.com">***@gmail.com</a></a>> escreveu:<br> <br></div><div></div><blockquote type="cite"><div><div>I'll have to think on this some more.</div><br><div class="gmail_quote">On Mon, Jan 16, 2012 at 16:36, Ove Ranheim <span dir="ltr"><<a href="mailto:***@gmail.com"></a><a href="mailto:***@gmail.com"><a href="mailto:***@gmail.com">***@gmail.com</a></a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">The REST service beans are usually scoped RequestScoped. Mixing REST and JSF is really useful, just like it works with Remoting and JSF. I use the latter quite a lot when 1) JSF component doesn't do what I want it to do, and 2) I need to send some UI state info back to the server; like what tab in a tabview is selected etc. What would be the appropriate way to handle this? Since REST is REST, we don't want to mess up the session store and have the back-end operate incorrectly.<div>
<br></div><div>However, would it be possible to demote the conversion scoped beans to request scoped beans?
Jason Porter
<http://lightguard-jp.blogspot.com>http://lightguard-jp.blogspot.com
<http://twitter.com/lightguardjp>http://twitter.com/lightguardjp
Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling
PGP key id: 926CCFF5
PGP key available at: <http://keyserver.net>keyserver.net,
<http://pgp.mit.edu>pgp.mit.edu
_______________________________________________
seam-dev mailing list
seam-***@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--e89a8f234aad62773b04b6afc6d0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable <html><body bgcolor="#FFFFFF"><div>Jason,</div><div><br></div><div>You're Right, i completely forgot about the multiple entry view approach.</div><div><br></div><div>But since Ove didnt mentioned about multiple views, I assumed JSF is the only entry point, which adding REST may be overengineering.</div> <div><br><br>Em 17/01/2012, ?s 00:00, Jason Porter <<a href="mailto:***@gmail.com">***@gmail.com</a>> escreveu:<br><br></div><div></div><blockquote type="cite"><div><div><br><br>Sent from my iPhone</div> <div><br>On Jan 16, 2012, at 18:46, George Gastaldi <<a href="mailto:***@gmail.com"><a href="mailto:***@gmail.com">***@gmail.com</a></a>> wrote:<br><br></div><div></div><blockquote type="cite"><div> <div>One solution is to have a backend store for the conversation scoped beans (Infinispan maybe ?) and never mess with the session. Probably the conversation Ids should be unique as well, so you must generate them uniquely.</div> </div></blockquote><div><br></div><div>My thoughts.?</div><br><blockquote type="cite"><div><div>Since you are using JSF, why not queueing events using the ajax support ?in JSF 2.0+? Adding REST services with JSF sounds like an action based solution which may subestimate the power of the JSF itself.</div> </div></blockquote><div><br></div><div>Not if you have multiple entries into the app. If you do it right, all the business logic ends up going through the REST classes. You could simply inject the REST classes and use them like normal POJOs in JSF backing beans, an entry into the app using HTML5, GWT, desktop client, native mobile client, etc. it's actually a very good separation if you need multiple entry points into the app. This essentially boils down to one common entry point, multiple views. I think it's quickly becoming my preferred architecture.?</div> <br><blockquote type="cite"><div><div>My two cents ;)</div><div><br></div><div>Regards,</div><div><br></div><div>George Gastaldi</div><div><br>Em 16/01/2012, �s 22:27, Jason Porter <<a href="mailto:***@gmail.com"><a href="mailto:***@gmail.com">***@gmail.com</a></a>> escreveu:<br> <br></div><div></div><blockquote type="cite"><div><div>I'll have to think on this some more.</div><br><div class="gmail_quote">On Mon, Jan 16, 2012 at 16:36, Ove Ranheim <span dir="ltr"><<a href="mailto:***@gmail.com"></a><a href="mailto:***@gmail.com"><a href="mailto:***@gmail.com">***@gmail.com</a></a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">The REST service beans are usually scoped RequestScoped. Mixing REST and JSF is really useful, just like it works with Remoting and JSF. I use the latter quite a lot when 1) JSF component doesn't do what I want it to do, and 2) I need to send some UI state info back to the server; like what tab in a tabview is selected etc. What would be the appropriate way to handle this? Since REST is REST, we don't want to mess up the session store and have the back-end operate incorrectly.<div>
<br></div><div>However, would it be possible to demote the conversion scoped beans to request scoped beans?