Hi I am aware that it's by design that when you do invoke a <submission/> with replace="all" set, then this causes a full page submit rather than an AJAX request to take place. This is great as this makes the submit go through the doAction() method of my JSR-286 portlet.
Is this by design?
Is this like saying Orbeon forms should end the session and create a new blank instance? I've tried declaring my model as <xforms:model xxforms:state-handling="server"> I thought this might cause the Orbeon xForms processor to recall state from HTTPSession object when it creates the HTML representation of the xForm markup. However it doesn't appear to do that. Any help would be appreciated. Kind regards,
-- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help OW2 mailing lists service home page: http://www.ow2.org/wws |
Administrator
|
Stian,
In general, the semantic of replace="all" is that a new document is loaded, in the same window/tab or another window/tab. It is often not true that replace="all" closes the current document: if the new document returned by the submission opens in a new browser window/tab, or is a document to download, the original XForms document is still active. (We discussed this issue in the XForms working group fairly recently, and the spec is not very clear on the subject.) Now within portlets, it depends. How did you setup Orbeon in a portlet exactly? In separate deployment? The idea is similar anway: upon a doAction(), the portlet can handle submitted data and get ready to produce new content upon the next render request. It's then a completely different page which is sent to the browser. (xxforms:state-handling="server" is not related. Anyway that is the default setting.) -Erik On Tue, Oct 19, 2010 at 9:39 AM, Stian Sigvartsen <[hidden email]> wrote: > Hi > > I am aware that it's by design that when you do invoke a <submission/> with > replace="all" set, then this causes a full page submit rather than an AJAX > request to take place. > > This is great as this makes the submit go through the doAction() method of > my JSR-286 portlet. > But it appears that all the model instance data is lost when the xForm is > rendered through doView() method of my portlet. > > Is this by design? > I read the xForms specification which states that when you use > replace="all", then this could be considered "closing the document". > > Is this like saying Orbeon forms should end the session and create a new > blank instance? > > I've tried declaring my model as <xforms:model > xxforms:state-handling="server"> > > I thought this might cause the Orbeon xForms processor to recall state from > HTTPSession object when it creates the HTML representation of the xForm > markup. However it doesn't appear to do that. > > Any help would be appreciated. > > Kind regards, > Stian Sigvartsen > > -- > You receive this message as a subscriber of the [hidden email] mailing > list. > To unsubscribe: mailto:[hidden email] > For general help: mailto:[hidden email]?subject=help > OW2 mailing lists service home page: http://www.ow2.org/wws > > -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help OW2 mailing lists service home page: http://www.ow2.org/wws |
Hi Eric
Thanks for replying to my question. Yes, I've deployed using separate portlet app deployment so using the TrampolineServlet and all that. Having the doAction() submission (caused by replace="all") start a new document seems quite sensible. Unfortunately for me, in my case, I'm not using xForms as a "document" editing technology but rather a way to provide an application (portlet) GUI, which primarily replies on session state for rendering (this is for data security reasons). I need a doAction() submission to happen so that my composite portlet application can function with IPC events. e.g. I want to split the app into multiple portlets so that each can be designed as re-usable common solutions that our non-technical staff can make use of to build other composite portlet applications without programming. I'm sure I can work around this issue. Can I have your thoughts on a related issue, which in my opinion challenges the use of Orbeon xForms in portlets... As we all know, portlets are all about having more than one portlet on a page. The majority of portal technologies out there do not render portlet content using AJAX (Some portlets like Orbeon ones do this for themselves). Normally, whenever you do anything in any portlet, you tend to get a full page reload. Now, if one of the portlets on a portal page is an Orbeon xForm portlet, then clicking any other portlet on that page causes a doView() to be sent to the Orbeon xForm portlet, which in turn appears to create a blank document! So this is very disruptive to the user who might have been half way through completing the xForm and only wanted to check his calendar portlet (or whatever). So note, no doAction() has taken place, but a new xForms document appears to have been blanked. The same is true if you simply reload the portal page in the browser. Have I set something up incorrectly, or is this expected behaviour? Would appreciate any insight you have so I can make design decisions accordingly. - Stian -----Original Message----- From: [hidden email] on behalf of Erik Bruchez Sent: Thu 10/21/2010 05:17 To: [hidden email] Subject: [ops-users] Re: Submissions with replace="all" & portlet state question Stian, In general, the semantic of replace="all" is that a new document is loaded, in the same window/tab or another window/tab. It is often not true that replace="all" closes the current document: if the new document returned by the submission opens in a new browser window/tab, or is a document to download, the original XForms document is still active. (We discussed this issue in the XForms working group fairly recently, and the spec is not very clear on the subject.) Now within portlets, it depends. How did you setup Orbeon in a portlet exactly? In separate deployment? The idea is similar anway: upon a doAction(), the portlet can handle submitted data and get ready to produce new content upon the next render request. It's then a completely different page which is sent to the browser. (xxforms:state-handling="server" is not related. Anyway that is the default setting.) -Erik On Tue, Oct 19, 2010 at 9:39 AM, Stian Sigvartsen <[hidden email]> wrote: > Hi > > I am aware that it's by design that when you do invoke a <submission/> with > replace="all" set, then this causes a full page submit rather than an AJAX > request to take place. > > This is great as this makes the submit go through the doAction() method of > my JSR-286 portlet. > But it appears that all the model instance data is lost when the xForm is > rendered through doView() method of my portlet. > > Is this by design? > I read the xForms specification which states that when you use > replace="all", then this could be considered "closing the document". > > Is this like saying Orbeon forms should end the session and create a new > blank instance? > > I've tried declaring my model as <xforms:model > xxforms:state-handling="server"> > > I thought this might cause the Orbeon xForms processor to recall state from > HTTPSession object when it creates the HTML representation of the xForm > markup. However it doesn't appear to do that. > > Any help would be appreciated. > > Kind regards, > Stian Sigvartsen > > -- > You receive this message as a subscriber of the [hidden email] mailing > list. > To unsubscribe: mailto:[hidden email] > For general help: mailto:[hidden email]?subject=help > OW2 mailing lists service home page: http://www.ow2.org/wws > > -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help OW2 mailing lists service home page: http://www.ow2.org/wws winmail.dat (6K) Download Attachment |
Administrator
|
Stian,
I think you are right: the portlet should cache its latest rendered state and resend it upon render. This is not done right now, and it might because in the use cases we have seen so far people have tended to use a single portlet on the page. This is certainly fixable but requires a bit of work. -Erik On Thu, Oct 21, 2010 at 1:27 AM, Stian Sigvartsen <[hidden email]> wrote: > Hi Eric > > Thanks for replying to my question. > Yes, I've deployed using separate portlet app deployment so using the TrampolineServlet and all that. > > Having the doAction() submission (caused by replace="all") start a new document seems quite sensible. Unfortunately for me, in my case, I'm not using xForms as a "document" editing technology but rather a way to provide an application (portlet) GUI, which primarily replies on session state for rendering (this is for data security reasons). > > I need a doAction() submission to happen so that my composite portlet application can function with IPC events. e.g. I want to split the app into multiple portlets so that each can be designed as re-usable common solutions that our non-technical staff can make use of to build other composite portlet applications without programming. > I'm sure I can work around this issue. > > Can I have your thoughts on a related issue, which in my opinion challenges the use of Orbeon xForms in portlets... > > > As we all know, portlets are all about having more than one portlet on a page. The majority of portal technologies out there do not render portlet content using AJAX (Some portlets like Orbeon ones do this for themselves). Normally, whenever you do anything in any portlet, you tend to get a full page reload. > > Now, if one of the portlets on a portal page is an Orbeon xForm portlet, then clicking any other portlet on that page causes a doView() to be sent to the Orbeon xForm portlet, which in turn appears to create a blank document! So this is very disruptive to the user who might have been half way through completing the xForm and only wanted to check his calendar portlet (or whatever). > > So note, no doAction() has taken place, but a new xForms document appears to have been blanked. The same is true if you simply reload the portal page in the browser. > > Have I set something up incorrectly, or is this expected behaviour? > Would appreciate any insight you have so I can make design decisions accordingly. > > - Stian > > > -----Original Message----- > From: [hidden email] on behalf of Erik Bruchez > Sent: Thu 10/21/2010 05:17 > To: [hidden email] > Subject: [ops-users] Re: Submissions with replace="all" & portlet state question > > Stian, > > In general, the semantic of replace="all" is that a new document is > loaded, in the same window/tab or another window/tab. > > It is often not true that replace="all" closes the current document: > if the new document returned by the submission opens in a new browser > window/tab, or is a document to download, the original XForms document > is still active. (We discussed this issue in the XForms working group > fairly recently, and the spec is not very clear on the subject.) > > Now within portlets, it depends. How did you setup Orbeon in a portlet > exactly? In separate deployment? > > The idea is similar anway: upon a doAction(), the portlet can handle > submitted data and get ready to produce new content upon the next > render request. It's then a completely different page which is sent to > the browser. > > (xxforms:state-handling="server" is not related. Anyway that is the > default setting.) > > -Erik > > On Tue, Oct 19, 2010 at 9:39 AM, Stian Sigvartsen > <[hidden email]> wrote: >> Hi >> >> I am aware that it's by design that when you do invoke a <submission/> with >> replace="all" set, then this causes a full page submit rather than an AJAX >> request to take place. >> >> This is great as this makes the submit go through the doAction() method of >> my JSR-286 portlet. >> But it appears that all the model instance data is lost when the xForm is >> rendered through doView() method of my portlet. >> >> Is this by design? >> I read the xForms specification which states that when you use >> replace="all", then this could be considered "closing the document". >> >> Is this like saying Orbeon forms should end the session and create a new >> blank instance? >> >> I've tried declaring my model as <xforms:model >> xxforms:state-handling="server"> >> >> I thought this might cause the Orbeon xForms processor to recall state from >> HTTPSession object when it creates the HTML representation of the xForm >> markup. However it doesn't appear to do that. >> >> Any help would be appreciated. >> >> Kind regards, >> Stian Sigvartsen >> >> -- >> You receive this message as a subscriber of the [hidden email] mailing >> list. >> To unsubscribe: mailto:[hidden email] >> For general help: mailto:[hidden email]?subject=help >> OW2 mailing lists service home page: http://www.ow2.org/wws >> >> > > > > -- > You receive this message as a subscriber of the [hidden email] mailing list. > To unsubscribe: mailto:[hidden email] > For general help: mailto:[hidden email]?subject=help > OW2 mailing lists service home page: http://www.ow2.org/wws > > -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help OW2 mailing lists service home page: http://www.ow2.org/wws |
Hi Eric -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help OW2 mailing lists service home page: http://www.ow2.org/wws |
Administrator
|
Stian,
This was not implemented in earlier versions either. As far as I know, work on this is not being sponsored by anybody at this time. I have added some ideas on our wiki: http://wiki.orbeon.com/forms/projects/xforms-improved-portlet-support#TOC-Caching-of-render-portlet-output I think it would be worth exploring this, but we cannot absolutely commit on a timeline right now. Maybe we can spare some cycles in the next few weeks! -Erik On Sat, Oct 23, 2010 at 5:33 AM, Stian Sigvartsen <[hidden email]> wrote: > Hi Eric > > Thanks for getting back to me. > I guess I'm glad that this is a recognised issue which from the sounds of it > will be fixed as it impacts all Orbeon portlets, and not something I just > misconfigured. > Appreciate it might require some work. Did it work with earlier versions of > Orbeon? Is it a priority for any of your enterprise support customers at > present? > > I'm still progressing a pilot implementation of Liferay portal + Orbeon > xForms, but once that has been approved for production, it's possible I can > convince my employer to purchase an enterprise support agreement from > yourselves. At present I would struggle because of all the public sector > spending cuts that are happening in the UK :( > > -Stian > > > > > -- > You receive this message as a subscriber of the [hidden email] mailing > list. > To unsubscribe: mailto:[hidden email] > For general help: mailto:[hidden email]?subject=help > OW2 mailing lists service home page: http://www.ow2.org/wws > > -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help OW2 mailing lists service home page: http://www.ow2.org/wws |
In reply to this post by Stian Sigvartsen
Hi Eric
Appreciate all your effort to date on this. You and the others at Orbeon are a great help! It's good that all the underlying mechanisms are in place to implement this support. Judging from Orbeon mailing list questions, the Liferay + Orbeon portlets combination is a popular high level use case so this should benefit both projects greatly. I'll keep an eye on the page you provided a link to for any progress on this. If I can be of any help, please don't hesitate to ask. - Stian -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Erik Bruchez Sent: 26 October 2010 03:33 To: [hidden email] Subject: [ops-users] Re: RE: Re: RE: Re: Submissions with replace="all" & portlet state question Stian, This was not implemented in earlier versions either. As far as I know, work on this is not being sponsored by anybody at this time. I have added some ideas on our wiki: http://wiki.orbeon.com/forms/projects/xforms-improved-portlet-support#TOC-Caching-of-render-portlet-output I think it would be worth exploring this, but we cannot absolutely commit on a timeline right now. Maybe we can spare some cycles in the next few weeks! -Erik On Sat, Oct 23, 2010 at 5:33 AM, Stian Sigvartsen <[hidden email]> wrote: > Hi Eric > > Thanks for getting back to me. > I guess I'm glad that this is a recognised issue which from the sounds of it > will be fixed as it impacts all Orbeon portlets, and not something I just > misconfigured. > Appreciate it might require some work. Did it work with earlier versions of > Orbeon? Is it a priority for any of your enterprise support customers at > present? > > I'm still progressing a pilot implementation of Liferay portal + Orbeon > xForms, but once that has been approved for production, it's possible I can > convince my employer to purchase an enterprise support agreement from > yourselves. At present I would struggle because of all the public sector > spending cuts that are happening in the UK :( > > -Stian > > > > > -- > You receive this message as a subscriber of the [hidden email] mailing > list. > To unsubscribe: mailto:[hidden email] > For general help: mailto:[hidden email]?subject=help > OW2 mailing lists service home page: http://www.ow2.org/wws > > -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help OW2 mailing lists service home page: http://www.ow2.org/wws |
Hi Eric
Hope things are good with you. I was pulled off the pilot project with Orbeon for the last couple of weeks for some other priority work, but I'm now back on this. Just wondering if this improved state handling is likely to feature in the near future or if other work means this could be more of a long term feature? - Stian -----Original Message----- From: Stian Sigvartsen [mailto:[hidden email]] Sent: Tue 10/26/2010 10:37 To: [hidden email] Subject: [ops-users] RE: Re: RE: Re: RE: Re: Submissions with replace="all" & portlet state question Hi Eric Appreciate all your effort to date on this. You and the others at Orbeon are a great help! It's good that all the underlying mechanisms are in place to implement this support. Judging from Orbeon mailing list questions, the Liferay + Orbeon portlets combination is a popular high level use case so this should benefit both projects greatly. I'll keep an eye on the page you provided a link to for any progress on this. If I can be of any help, please don't hesitate to ask. - Stian -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Erik Bruchez Sent: 26 October 2010 03:33 To: [hidden email] Subject: [ops-users] Re: RE: Re: RE: Re: Submissions with replace="all" & portlet state question Stian, This was not implemented in earlier versions either. As far as I know, work on this is not being sponsored by anybody at this time. I have added some ideas on our wiki: http://wiki.orbeon.com/forms/projects/xforms-improved-portlet-support#TOC-Caching-of-render-portlet-output I think it would be worth exploring this, but we cannot absolutely commit on a timeline right now. Maybe we can spare some cycles in the next few weeks! -Erik -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help OW2 mailing lists service home page: http://www.ow2.org/wws winmail.dat (5K) Download Attachment |
Administrator
|
Stian,
Sorry about the delay (travel during the Thanksgiving period). We still would like to schedule some solid work on improved Liferay support in the relatively short term, but that hasn't happened yet due to other priorities. So at this point we are a bit uncomfortable saying it's going to be looked at in the short term. Now if somebody sponsors this work that will change our priorities. -Erik On Mon, Nov 22, 2010 at 3:51 PM, Stian Sigvartsen <[hidden email]> wrote: > Hi Eric > > Hope things are good with you. I was pulled off the pilot project with Orbeon for the last couple of weeks for some other priority work, but I'm now back on this. > Just wondering if this improved state handling is likely to feature in the near future or if other work means this could be more of a long term feature? > > - Stian > > -----Original Message----- > From: Stian Sigvartsen [mailto:[hidden email]] > Sent: Tue 10/26/2010 10:37 > To: [hidden email] > Subject: [ops-users] RE: Re: RE: Re: RE: Re: Submissions with replace="all" & portlet state question > > Hi Eric > > Appreciate all your effort to date on this. You and the others at Orbeon are a great help! > It's good that all the underlying mechanisms are in place to implement this support. Judging from Orbeon mailing list questions, the Liferay + Orbeon portlets combination is a popular high level use case so this should benefit both projects greatly. > > I'll keep an eye on the page you provided a link to for any progress on this. > If I can be of any help, please don't hesitate to ask. > > - Stian > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Erik Bruchez > Sent: 26 October 2010 03:33 > To: [hidden email] > Subject: [ops-users] Re: RE: Re: RE: Re: Submissions with replace="all" & portlet state question > > > Stian, > > This was not implemented in earlier versions either. > > As far as I know, work on this is not being sponsored by anybody at this time. > > I have added some ideas on our wiki: > > http://wiki.orbeon.com/forms/projects/xforms-improved-portlet-support#TOC-Caching-of-render-portlet-output > > I think it would be worth exploring this, but we cannot absolutely > commit on a timeline right now. Maybe we can spare some cycles in the > next few weeks! > > -Erik > > > > > -- > You receive this message as a subscriber of the [hidden email] mailing list. > To unsubscribe: mailto:[hidden email] > For general help: mailto:[hidden email]?subject=help > OW2 mailing lists service home page: http://www.ow2.org/wws > > -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help OW2 mailing lists service home page: http://www.ow2.org/wws |
Free forum by Nabble | Edit this page |