Orbeon Form Builder/Form Runner for a regular web site?

Really a broad newbie question here so I apologize, but I wanted to ask if Orbeon Form Builder/Form Runner is intended as a better/faster way to incorporate XForms on general web sites, or is it better thought of *specifically* as an analog to something like InfoPath with the whole idea being that an enterprise creates forms using Form Builder and their people use the forms only through Form Runner as a "form application program".

e.g. Let's say I'm building an ecommerce oriented site where the general navigation and look and feel for the site is already/separately defined and implemented (but let's say it will read from eXist for it's product catalog), but let's say Orbeon Forms were used just for the forms to allow products to be added in the product catalog.

And let's say these product entry screens are required to have the look and feel of the rest of the site, and the same authentication, i.e. it's not acceptible for me to just run Orbeon separately on the side as an admin tool, it has to be integrated.

Specifically, I'm wondering:

a.  If the navigation/branding for the rest of the site were already done, using some templating scheme (tiles, sitemesh, whatever), could forms built with Orbeon Form Builder be deployed such that they could have their headers/footers/nav bar stuff applied with these other technologies?  So the form built with form builder appears inside the page whose navigation and branding around the edges comes from the other site (ideally without using a frame though I didn't think of that till now :).

b.  When I publish forms from Form Builder, the default Form Runner includes buttons in the button bar like the preview button and the PDF button that I wouldn't want.  Ideally I'd want to define my own button bar and control what buttons appear, what their labels are, and even the look and behavior of them (e.g. to match the buttons on the rest of the site).

I did notice the section on configuration which explains how e.g. to omit buttons on the "button bar" that form runner displays...  and how to override CSS style sheets...

But I didn't see anything about adding a completely custom button with custom behavior to the button bar of form runner.  Can this be done?  Could/would you omit all the standard buttons and maybe use Form Builders buttons to create an alternative button bar above the (now blank except for the status/error icon on the left) standard button bar area?

c.  I notice the docs mention using portlets to integrate things e.g. if the overall site were built on LifeRay Portal so the branding and navigation could be LifeRay and even use it's "themes".  

Anybody have experience with this?  Does form runner play forms built with for builder okay in Liferay portlets?  Any gotchas?

Thanks,

Darren

Hi Darren

Great question. Did you get any feedback or new findings?

Thanks!
Sam




--
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

Darren,

a. Clearly the use case we have been focusing on right now is the
first one: i.e. you run Form Runner separately and you integrate it
with your app by liking in and out of Form Runner and customizing the
L&F if needed.

This said, embedding is requested fairly often and has been achieved
in the past. For example, we embedded Form Runner within a PHP CMS
called TYPO3, though an extension which implements proxying, see:

http://wiki.orbeon.com/forms/doc/developer-guide/form-runner/typo3-extension

You could replicate that in Java, although we don't have such a
component out of the box.

We also have an "Ajax portlet" mode which, to be fair, we haven't
tested recently, but did something similar although 100% based on
Ajax:

http://wiki.orbeon.com/forms/doc/contributor-guide/xforms-ajax-portlet

So it is doable and the code has quite a bit of support for this, but
there might be a bit of customization work needed to adapt to your
scenario.

b. The buttons bar is customizable in that you can add/remove buttons
using properties, and you can probably override the CSS to match the
L&F of your buttons.

c. In nightly builds, Form Runner works again within Liferay (it was
broken in 3.8.0). So that might be an option as well, if a heavier one
- and, in our experience, maintaining code for Liferay and other
portals has shown a bit painful due to the extra complexity of the
setup.

I hope this helps,

-Erik

On Thu, Sep 23, 2010 at 1:00 PM, darrencruse <[hidden email]> wrote:

--
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

Dear 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

Hi Erik (and Sam),

Thanks for the info I just today saw your comments.

FWIW yesterday I'd tried the built-in LifeRay Web Proxy Portlet to play an Orbeon Form running through Form Runner and it presents the new/update page pretty good (with the exception of the CSS or something being off on that YUI rich text editor).

But if I try and do anything (even just click in a field) errors occur.  It appears there's a point where javascript tries to parse the url context to use in ajax calls directly out of the browser address line and winds up with "undefined" and otherwise I think it was a relative url anyway that wouldn't have gotten back to orbeon (i.e. it was pointing back at the "7cogs" page I was testing on).  Plus there's some reference to a "formID" variable that's undefined.  So anyway it looked promising if I knew more it seems like probably this could be made to work(?)

I'm curious was the Ajax Portlet approach significantly different than this Web Proxy Portlet approach?  I'm a little unclear (and was there truly an "Ajax Portlet" i.e. that you deploy into LifeRay which talks AJAX to Orbeon I presume?).

I hadn't pursued the Ajax Portlet approach btw mainly just because I didn't see too much about it and I had a feeling it wasn't supported anymore since that page - the one you gave the link to - makes reference to an "Ajax Portlet section of the Developer Guide" which appears to no longer exist?

Also I did try the nightly Orbeon-CE.war deployment to the latest Liferay 6.0.5 (on Tomcat), following those instructions where you drop it in LifeRay's deploy directory, and I did see the Orbeon Portlet and I dropped that on a portal page.  It did display the main Orbeon page with those examples and form builder.  The XForms Controls sampler seems to work well but I do get errors at various places otherwise.

e.g. If I try and choose to configure Preferences on the portlet itself, it gives the error:

      Cannot load "/apps/portlet-welcome/page-flow-edit.xml" with webapp loader

With other examples, like the Contacts one etc. the "list" page appears pretty good, but clicking "New" gives:

22:08:21,443 ERROR [SerializableSessionAttributeListener:39] org.apache.commons.httpclient.HttpState is not serializable and will prevent this session from being replicated
22:08:21,456 ERROR [PortletServlet:96] javax.portlet.PortletException: java.lang.IllegalArgumentException: Content type cannot be null
javax.portlet.PortletException: java.lang.IllegalArgumentException: Content type cannot be null
        at org.orbeon.oxf.portlet.OrbeonPortlet2Delegate.render(OrbeonPortlet2Delegate.java:240)
        at com.liferay.portlet.FilterChainImpl.doFilter(FilterChainImpl.java:101)

(and a little further down)

t22:10:12,696 ERROR [jsp:154] java.lang.IllegalArgumentException: Content type cannot be null
        at com.liferay.portlet.MimeResponseImpl.setContentType(MimeResponseImpl.java:133)

The DMV form gives a different error:

      java.lang.UnsupportedOperationException
     <xforms:instance src=""> with relative path within a portlet

Anyway don't know if this is helpful. (Erik) I think you wrote that the problems with deploying to LifeRay were fixed in the latest nightly build but that's what I was trying maybe there's something else I have to do?

Truthfully if it had worked that would exciting, though I wasn't clear even then how I would have had the portlet skip past that examples page and start directly displaying my own portlet that I want to present.  But if that were possible I would have been encouraged...
   

Darren,

I will try to give Liferay a try again tomorrow and see if these
errors happen for me and/or are new.

The Ajax portlet is documented here:

http://wiki.orbeon.com/forms/doc/developer-guide/configuration-properties/configuration-properties-xforms#TOC-Ajax-portlet

A related topic is Remote Portlets:

http://wiki.orbeon.com/forms/doc/developer-guide/xforms-remote-portlet-deployment

I moved another page with a couple of implementation notes on this here:

http://wiki.orbeon.com/forms/projects/xforms-ajax-portlet

(Please keep reporting broken links. Also in general a search will
return the relevant wiki pages.)

-Erik

On Tue, Oct 5, 2010 at 8:17 PM, darrencruse <[hidden email]> wrote:

--
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

Sam,

Hard to tell for sure. The PHP one is a simple proxy. It is definitely
in production and it is a simpler beast than the Java portlet
implementation.

-Erik

On Tue, Sep 28, 2010 at 3:12 AM, samuel home <[hidden email]> wrote:

--
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 Erik

I've just replaced my Orbeon forms implementation with yesterday's nightly build and the portlet which comes with it still doesn't function with Liferay portal.

For example, still getting an error when clicking on the "Controls form" (which states it uses Form Runner which you mentioned was fixed in nightly builds after it broke with the release of v3.8.0).

javax.portlet.PortletException: java.lang.IllegalArgumentException: Content type cannot be null
        at org.orbeon.oxf.portlet.OrbeonPortlet2Delegate.render(OrbeonPortlet2Delegate.java:240)
        at com.liferay.portlet.FilterChainImpl.doFilter(FilterChainImpl.java:101)
      ...
Caused by: java.lang.IllegalArgumentException: Content type cannot be null
        at com.liferay.portlet.MimeResponseImpl.setContentType(MimeResponseImpl.java:133)
        at org.orbeon.oxf.portlet.OrbeonPortlet2Delegate.render(OrbeonPortlet2Delegate.java:235)
        ... 190 more

Kind regards,
Stian Sigvartsen

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Erik Bruchez
Sent: 07 October 2010 23:09
To: [hidden email]
Subject: [ops-users] Re: Re: Re: Orbeon Form Builder/Form Runner for a regular web site?


Sam,

Hard to tell for sure. The PHP one is a simple proxy. It is definitely
in production and it is a simpler beast than the Java portlet
implementation.

-Erik

On Tue, Sep 28, 2010 at 3:12 AM, samuel home <[hidden email]> wrote:

--
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

Tried some things this past weekend including using the LifeRay Web Proxy with Orbeon as well as writing my own portlet to use with the "separate deployment" approach.  Had various degrees of success but nothing 100% so this morning I went back to try the simple Orbeon bundled portlet approach once again with the latest nightly build (noticed there's been a change to the orbeon servlet filter).  But I'm getting exactly the same exceptions as before as reported by Stian above.  Where a null pointer exception results from the calls to setContentType getting passed null apparently because getContentType is returning null in this code:

    public void render(RenderRequest request, RenderResponse response) throws PortletException, IOException {
        try {
            final Portlet2ExternalContext.BufferedResponse bufferedResponse
                    = (Portlet2ExternalContext.BufferedResponse) request.getPortletSession().getAttribute(OXF_PORTLET_OUTPUT);
            final Map bufferedResponseParameters
                    = (Map) request.getPortletSession().getAttribute(OXF_PORTLET_OUTPUT_PARAMS);

            // NOTE: Compare for deep equality as it seems that portlet containers may copy/update the parameter Map
                        if (bufferedResponse != null && deepEquals(request.getParameterMap(), bufferedResponseParameters)) {
                // The result of an action with the current parameters was a
                // stream that we cached. Replay that stream and replace URLs.
                // CHECK: what about mode / state? If they change, we ignore them totally.
                response.setContentType(bufferedResponse.getContentType());
                response.setTitle(bufferedResponse.getTitle() != null ? bufferedResponse.getTitle() : getTitle(request));
                bufferedResponse.write(response);
            } else {
                final // Call service
                PipelineContext pipelineContext = new PipelineContext();
                pipelineContext.setAttribute(PORTLET_CONFIG, getPortletConfig());
                final ExternalContext externalContext = new Portlet2ExternalContext(processorService, pipelineContext, getPortletContext(), contextInitParameters, request, response);
                processorService.service(externalContext, pipelineContext);
                // TEMP: The response is also buffered, because our
                // rewriting algorithm only operates on Strings for now.
                final Portlet2ExternalContext.DirectResponseTemp directResponse
                        = (Portlet2ExternalContext.DirectResponseTemp) externalContext.getResponse();
                response.setContentType(directResponse.getContentType());
                response.setTitle(directResponse.getTitle() != null ? directResponse.getTitle() : getTitle(request));
                directResponse.write(response);
            }
        } catch (Exception e) {
            throw new PortletException(OXFException.getRootThrowable(e));
        }
    }

Maybe it's wishful thinking but I remembered reading setContentType is no longer required under the JSR 286 portlet standard, as noted in this article

So I actually tried to patch my orbeon.jar with a version of Orbeon2Portlet.java where I'd commented the two lines I bolded above.  Unfortunately I think I goofed something up in building my patch though (maybe I used the wrong version of java?) - as the portlet would not even deploy when I did that (or do you think me removing those lines really did break it that badly?).

I don't know Erik maybe you're thinking these exceptions are just a symptom of that other problem you were talking about with getting content i.e. that bug you said you reported on the LifeRay forums...

Certainly we should not call setContentType(null). I fixed this:

http://github.com/orbeon/orbeon-forms/commit/50dc5931637666faf3d9c408e542322277c84547

Now as you say that might not be the actual source of the problem!

-Erik

On Tue, Oct 12, 2010 at 6:20 AM, darrencruse <[hidden email]> wrote:

--
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

Thanks for trying Erik it's still blowing up just in a different place.  The exceptions are now:

[GC 224999K->198874K(319040K), 0.0292890 secs]
07:45:35,343 ERROR [PortletServlet:96] javax.portlet.PortletException: java.lang.IllegalStateException: Processor execution did not return content.
javax.portlet.PortletException: java.lang.IllegalStateException: Processor execution did not return content.
        at org.orbeon.oxf.portlet.OrbeonPortlet2Delegate.render(OrbeonPortlet2Delegate.java:242)
        at com.liferay.portlet.FilterChainImpl.doFilter(FilterChainImpl.java:101)

To be honest I think I'm at my pain threshold with the whole LifeRay/Orbeon integration thing I think it's time I move on.

The question (honestly) is whether I move on without LifeRay or without Orbeon.

The main thing LifeRay was bringing was the nice drag and drop portal page layouts with so many portlets including ones I might have used like the web CMS stuff, shopping cart, forums, etc.  And the role based user admin with the user registration and logon and stuff all built in without coding so much as just configuring.

I know you guys mentioned you do have good integration working with TYPO3 - I honestly don't know anything about it.  I'm mainly a java guy though I have done a tiny bit of PHP recently...

Is TYPO3 the only other system along these lines you guys have integrated with? (to be honest I googled TYPO3 and stumbled on some pretty harsh critiques but you know how the web can be :)  

Not Drupal? Joomla?  Anything else along those lines?

FWIW I think something was said about these integrations not being high on the Orbeon priority list but for me it would really be killer.  

In particular I think Form Builder is wonderful in terms of empowering less technical types to be able to participate in the design/development of forms.  In addition to being a programmer I have a UI Design/User Centered Design background and this is a big thing with me - getting us technical types out of the way of people who know the business and/or are better communicators/technical writers/UI designers.  I think you guys have really got something great in Form Builder from that point of view.  And even just from the pure productivity standpoint.  I think it's wonderful.

The frustration for me over LifeRay and Orbeon not being able to work together is mainly that LifeRay has similar strengths that you have with FormBuilder, in the broader realms of being able to interactively layout a general web site and configure and setup a lot of stuff without coding.

Yet they don't have what you have in Form Builder they don't have any slick interactive way of creating forms and having them stored as simple XML (which I also love - the reason I stumbled on you guys was I've been using eXist for a project at work and loving the whole XML/XQuery/NoSQL philosophy).

So it feels to my like you guys could really complement one another as a high productivity web development toolset if you simply had the ability to do the Form Runner stuff in a portlet.  I really needed a way to drop a portlet and configure it with that application name/form name you have people enter in Form Builder, and have that display the Form Runner summary/list thing in the portlet for that specified form.  So the surrounding navigation would have been LifeRay Portal Pages and you guys would have been doing the forms, with things like LifeRay's XSL Portlet or CMS Portlets etc. hitting the eXist RESTful interface for other types of presentation of the data the forms had entered.  

Or just doing XQuery directly in eXist against the data to return HTML to LifeRay using it's Web Proxy portlet (I'd done examples of these different approaches and they'd worked fine).

So displaying the list/detail for a certain type of form in a portlet would have been huge.  That, plus the option to actually go around the Form Runner summary/list page thingie and instead go straight to the specified form's Create or Edit mode.  To me those would haved opened a world of opportunities for you guys that I personally don't see in Form Builder/Form Runner standalone.

(this last option being for cases where the Form Runner summary/list isn't desired or sufficient, e.g. where there might be a more customer facing presentation of the managed list of "data" e.g. an ecommerce catalog showing thumbnail images and things like that, so I would have wanted to go around the Form Runner summary/list page in some cases, though it would have been fine for a pure administrative use that wasn't customer facing).

Oh well - maybe in 5 years and 5 million dollars right. :)

We'll see I haven't given up yet but I'm definitely close.  

I forgot to mentioned the very first thing I'd done was just use an IframePortlet in LifeRay pointed at Orbeon running separately.  That actually hadn't been awful but I just could never make it seamless - e.g. in several of the browsers for the life of me I could't get it to hide the iframe it wanted to leave these blank areas where a scrollbar would have been (hard to describe basically it just looked odd and I couldn't seem to fix it in certain browsers).  I'd ended up feeling the iframe approach was a hack and thought the portlet approach was the right one.

So in the next attempt I'd actually gotten LifeRay's Web Proxy portlet looking pretty dang good for doing what I described, it was of course the AJAX calls back to Orbeon e.g. when you'd search and stuff that wouldn't get processed through the proxy stuff and wind up either blowing up or not working or jumping out of the portal page etc.  

At the time I thought I might pursue it further, but my fear now is that wouldn't the enhanced solution require the same kind of OrbeonProxyPorlet/TrampolineServlet kind of thing that's causing problems for these other approaches.  I don't think I have the energy to go down another dead end...

In the end, I kind of feel like the best most seamless reliable approach would be a true portlet invoking Orbeon java code to do all the magic you guys do under LifeRay, without it trying to proxy out to Orbeon running separately.  

But this isn't an approach you guys have pre-packaged up to make easy, nor even an approach you guys advocate right...  That one page says you guys advocate the separate deployment approach but that doesn't seem to work at least not with LifeRay...

Oh well wrote too much (sorry).

Thanks for the help regardless.

Hi Darren

I couldn't agree more with everything that you said in your email.  Like
I've said before, we appear to have identical objectives.
For example involving non-technical staff in developing forms.

I would recommend that you try the approach I have got to work.
Although I can't claim to be an expert in Orbeon technology.  So my
approach might come back to bite me later!

It appears to be a very good approach for enabling non-technical staff
to develop forms using Orbeon form builder whilst at the same time,
enable those forms to participate in a JSR-286 IPC (inter portlet
communications) scenario in Liferay.

You can in fact even create an architecture that ensures all forms are
submitted through a standard process.  Just implement a JSR-286 portlet
class which implements the processAction() method and then subclass this
class for individual forms you want to display as individual portlets in
Liferay.

So the tech stack is as follows:

1) Liferay
2) JSR-286 portlet(s) developed through Liferay IDE 1.1 plug-ins for
Eclipse 3.5.
3) Orbeon xForms processor (e.g. only the standards compliant aspect of
Orbeon and not their page flow technology)

The approach works on the same premise as the documented Orbeon separate
portlet deployment strategy, but instead of request dispatching to .JSPs
in your portlet application, you simply read the xForm file in using a
simple FileReader object.

The only issue I can see with this approach at present is that you
cannot create xForm markup dynamically using .JSP.
However, since the same xForm markup is sent to the OrbeonXFormFilter
every time, performance is great because Orbeon can cache lots of stuff!

I'm currently looking at a way of initialising xForms with instance data
by including a callback to my portlet application which gets processed
when the Orbeon xForms processor interprets the markup (hence allowing
more caching).  I'm hoping this will work fine, and I can see it working
if Orbeon and my portlet app share the same session.  E.g. the callback
could be to a .jsp which responds with an XML document held in the
session.

Kind regards,
Stian Sigvartsen


-----Original Message-----
From: darrencruse [mailto:[hidden email]]
Sent: 18 October 2010 15:06
To: [hidden email]
Subject: [ops-users] Re: RE: Re: Re: Re: Orbeon Form Builder/Form Runner
for a regular web site?



Thanks for trying Erik it's still blowing up just in a different place.
The
exceptions are now:

[GC 224999K->198874K(319040K), 0.0292890 secs]
07:45:35,343 ERROR [PortletServlet:96] javax.portlet.PortletException:
java.lang.IllegalStateException: Processor execution did not return
content.
javax.portlet.PortletException: java.lang.IllegalStateException:
Processor
execution did not return content.
        at
org.orbeon.oxf.portlet.OrbeonPortlet2Delegate.render(OrbeonPortlet2Deleg
ate.java:242)
        at
com.liferay.portlet.FilterChainImpl.doFilter(FilterChainImpl.java:101)

To be honest I think I'm at my pain threshold with the whole
LifeRay/Orbeon
integration thing I think it's time I move on.

The question (honestly) is whether I move on without LifeRay or without
Orbeon.

The main thing LifeRay was bringing was the nice drag and drop portal
page
layouts with so many portlets including ones I might have used like the
web
CMS stuff, shopping cart, forums, etc.  And the role based user admin
with
the user registration and logon and stuff all built in without coding so
much as just configuring.

I know you guys mentioned you do have good integration working with
TYPO3 -
I honestly don't know anything about it.  I'm mainly a java guy though I
have done a tiny bit of PHP recently...

Is TYPO3 the only other system along these lines you guys have
integrated
with? (to be honest I googled TYPO3 and stumbled on some pretty harsh
critiques but you know how the web can be :)  

Not Drupal? Joomla?  Anything else along those lines?

FWIW I think something was said about these integrations not being high
on
the Orbeon priority list but for me it would really be killer.  

In particular I think Form Builder is wonderful in terms of empowering
less
technical types to be able to participate in the design/development of
forms.  In addition to being a programmer I have a UI Design/User
Centered
Design background and this is a big thing with me - getting us technical
types out of the way of people who know the business and/or are better
communicators/technical writers/UI designers.  I think you guys have
really
got something great in Form Builder from that point of view.  And even
just
from the pure productivity standpoint.  I think it's wonderful.

The frustration for me over LifeRay and Orbeon not being able to work
together is mainly that LifeRay has similar strengths that you have with
FormBuilder, in the broader realms of being able to interactively layout
a
general web site and configure and setup a lot of stuff without coding.

Yet they don't have what you have in Form Builder they don't have any
slick
interactive way of creating forms and having them stored as simple XML
(which I also love - the reason I stumbled on you guys was I've been
using
eXist for a project at work and loving the whole XML/XQuery/NoSQL
philosophy).

So it feels to my like you guys could really complement one another as a
high productivity web development toolset if you simply had the ability
to
do the Form Runner stuff in a portlet.  I really needed a way to drop a
portlet and configure it with that application name/form name you have
people enter in Form Builder, and have that display the Form Runner
summary/list thing in the portlet for that specified form.  So the
surrounding navigation would have been LifeRay Portal Pages and you guys
would have been doing the forms, with things like LifeRay's XSL Portlet
or
CMS Portlets etc. hitting the eXist RESTful interface for other types of
presentation of the data the forms had entered.  

Or just doing XQuery directly in eXist against the data to return HTML
to
LifeRay using it's Web Proxy portlet (I'd done examples of these
different
approaches and they'd worked fine).

So displaying the list/detail for a certain type of form in a portlet
would
have been huge.  That, plus the option to actually go around the Form
Runner
summary/list page thingie and instead go straight to the specified
form's
Create or Edit mode.  To me those would haved opened a world of
opportunities for you guys that I personally don't see in Form
Builder/Form
Runner standalone.

(this last option being for cases where the Form Runner summary/list
isn't
desired or sufficient, e.g. where there might be a more customer facing
presentation of the managed list of "data" e.g. an ecommerce catalog
showing
thumbnail images and things like that, so I would have wanted to go
around
the Form Runner summary/list page in some cases, though it would have
been
fine for a pure administrative use that wasn't customer facing).

Oh well - maybe in 5 years and 5 million dollars right. :)

We'll see I haven't given up yet but I'm definitely close.  

I forgot to mentioned the very first thing I'd done was just use an
IframePortlet in LifeRay pointed at Orbeon running separately.  That
actually hadn't been awful but I just could never make it seamless -
e.g. in
several of the browsers for the life of me I could't get it to hide the
iframe it wanted to leave these blank areas where a scrollbar would have
been (hard to describe basically it just looked odd and I couldn't seem
to
fix it in certain browsers).  I'd ended up feeling the iframe approach
was a
hack and thought the portlet approach was the right one.

So in the next attempt I'd actually gotten LifeRay's Web Proxy portlet
looking pretty dang good for doing what I described, it was of course
the
AJAX calls back to Orbeon e.g. when you'd search and stuff that wouldn't
get
processed through the proxy stuff and wind up either blowing up or not
working or jumping out of the portal page etc.  

At the time I thought I might pursue it further, but my fear now is that
wouldn't the enhanced solution require the same kind of
OrbeonProxyPorlet/TrampolineServlet kind of thing that's causing
problems
for these other approaches.  I don't think I have the energy to go down
another dead end...

In the end, I kind of feel like the best most seamless reliable approach
would be a true portlet invoking Orbeon java code to do all the magic
you
guys do under LifeRay, without it trying to proxy out to Orbeon running
separately.  

But this isn't an approach you guys have pre-packaged up to make easy,
nor
even an approach you guys advocate right...  That one page says you guys
advocate the separate deployment approach but that doesn't seem to work
at
least not with LifeRay...

Oh well wrote too much (sorry).

Thanks for the help regardless.
--
View this message in context:
http://orbeon-forms-ops-users.24843.n4.nabble.com/Orbeon-Form-Builder-Fo
rm-Runner-for-a-regular-web-site-tp2552615p3000318.html
Sent from the Orbeon Forms (ops-users) mailing list archive at
Nabble.com.


--
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 Stian,

I saw your reply this morning but I wanted to go back and look at my notes from when I tried the separate deployment approach to refresh my memory on the problems I'd had.  I was wondering how you got it to work because I'd seen your exchange with Erik in the other thread and I'd known about not using JSPs - I hadn't I'd only read the xform xml directly from a file like you said.  But it still hadn't worked for me.  Or I should say it hadn't worked for me for anything but the simplest hello world kind of example.

Are you saying you've even gotten it to work with Form Builder created/Form Runner forms?  That would be awesome if so.

OTOH I just noticed someone (I assume Erik) had updated the wiki page at:  xforms-separate-deployment-with-portlets

I hadn't seen that till now I guess I should double check what I'd done against the example code he's got there.  And I guess you're saying this example code matches what you're doing?  I wasn't sure at first reading your description above - but I guess so?

I should confess btw that I'm still pretty new both to XForms and to Portlet programming so maybe I'm not doing something right or not understanding something I need to do - e.g. you mentioned inter-portlet communication I was confused that's not a part of the solution described on the wiki page so I'm not 100% sure it's what you were describing or not...

Also you called out that you were using the "Orbeon xForms processor (e.g. only the standards compliant aspect of Orbeon and not their page flow technology)".

I honestly don't know what that means (I haven't dug deep enough yet to know about their "page flow technology" :).  Does this basically mean you're focusing on simpler hand coded XForms and not trying to use the Form Builder/Form Runner XForms?

Also the wiki page mentions the idea of submitting back to the portlet.  I think maybe I'd overlooked that the first time I'd read that.  Is the idea that we'd write our own portlet method to receive the POSTed xml and store it ourselves rather than like with Form Runner it automatically storing that into eXist?  But that section near the end says "The filter also intercepts action requests. For requests targeted at Orbeon, namely for a form post to /xforms-server-submit [...]" which makes it sound like maybe you can leave the handling to Orbeon still if you want.

Actually I should compliment you that you sound like you've got a handle on this I'm still feeling confused - and a little dumbfounded that you've gotten things to work and that the wiki page now indicates that "it's been tested under LifeRay 6.0.5".  Looking at my notes here's some of what I'd run into when I tried this weekend before last:

-----------------------------

*  Got class loader errors in the provided OrbeonXFormsProxyServlet.  Moved the orbeon-xforms-servlet.jar file into the Tomcat ext (extensions library) folder and out of the WEB-INF/lib for my portlet and they went away.

* Ultimately using complicated forms (like our "auto" form) was giving errors and seemed too ambitious for a first step.  Saved the Orbeon hello world example for a first effort.

* I could see the XForm was being translated to html, but Firefox showed the urls back to get the CSS and javascript files were breaking.  I put everything behind Apache and added proxy pass rules to pass these back to "/orbeon".  

(maybe this was my big mistake?  did this make it so the ProxyServlet missed doing it's magic on these files?  But that doesn't actually modify the contents of javascript files or does it?  But I shouldn't have had to do this right so I guess I had something wrong that these urls weren't automatically being resolved)

* This got the hello world working but even something as simple as the bookshelf tutorial portlet still has problems (it doesn't save and the "Add One" doesn't work).

* Regarding the form runner forms, those don't even get as far as the bookshelf.  They have errors saying there's references to undefined xforms variables e.g. $form-resources" and "$fr-resources".  Apparently these are normally defined outside the form itself, e.g. it appears $form-resources is set to point at the proper language resources (french, english, etc).  

I tried an experiment to set those variables explicitly myself in the form, but that didn't seem to be a good idea it was still giving errors.

-----------------------------
 
Maybe I should give this one more shot looking at the example code on the updated wiki page.  Otherwise Stian if your approach is different than what they've posted there would you consider sharing a stripped down version of the basic approach you've followed?

Thanks a lot for your help/thoughts,

Darren

Darren,

Great analisys. I think you described incredibly well the point where
part of the effort of Orbeon guys should head to, IMHO.

Using Orbeon Builder/Runner standalone is great, but not necessarilly
for everyone. I think there are many people out there, like you and me
(I guess), looking forward to seamlessly integrating Obeon Forms into
their applications/products, whether those be Life Ray or a Struts or
Spring-based JEE development.

Orbeon forms would definately be the "king of the web forms world" if it
gave the proper artifacts (or whatever) to let it seamlessly integrate
into widely used JEE frameworks like Struts or Spring, or into widely
used portal solutions, like Life Ray.

It's such a pitty and so frustrating finding out that trying (not
getting) to integrate Orbeon forms into those
technologies/frameworks/products is such a pain.

Darren, I'm also just about giving up trying the Struts/Orbeon
integration. Really sad and painful.

Thanks for all,
Potele

--
José de la Herrán Núñez
Ayuntamiento de Vitoria-Gasteiz
Departamento de Tecnologías de la Información
Responsable de Coordinación Técnica
Pintor Vera Fajardo, 5 bajo, 01008 Vitoria-Gasteiz
Tlf: +34 945 16 16 14
Fax: +34 945 16 16 00
mailto:[hidden email]




El 18/10/2010 16:05, darrencruse escribió:

--
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

Darren,

I'm sure you've been checking on the thread called "Deploying Orbeon
Forms in Liferay", haven't you?

http://orbeon-forms-ops-users.24843.n4.nabble.com/Deploying-Orbeon-Forms-in-Liferay-td2994930.html#a2994930

Best regards,
Potele

--
José de la Herrán Núñez
Ayuntamiento de Vitoria-Gasteiz
Departamento de Tecnologías de la Información
Responsable de Coordinación Técnica
Pintor Vera Fajardo, 5 bajo, 01008 Vitoria-Gasteiz
Tlf: +34 945 16 16 14
Fax: +34 945 16 16 00
mailto:[hidden email]



El 18/10/2010 16:05, darrencruse escribió:

--
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 all,

I need to have nested <xforms:repeat> control in my xform.

For ex. As per the below template, the form should enable the multiple 'appointments' entries. Also for each 'appointment' multiple 'prescriptions' entry is required.

        <appointment>
                <date />
                <diagnosis />
                <prescription>
                        <drug />
                        <noOfDays>
                        <dosage>
                </prescription>
        </appointment>

The outer repeat is working as expected but inner repeat on prescriptions is not working fine.

Here is the problem:
1. Suppose I have an 'appointment' node in the beginning say 'app-a'.
2. Now I add 'app-b'.
3. Both 'app-a' and 'app-b' have one 'prescription' node each by default.
4. Now, when I add a 'prescription' node or delete a 'prescription' node in 'app-a', the 'prescription' node in 'app-b' get       added/deleted.

Kindly help me resolve this problem. Please find attached the code (index5.jsp) I am using.

Would highly appreciate your help.

P.S. In the orbeon architecture I have placed the file "index5.jsp" at WebContent/xforms-jsp/<new-folder>

Thanks and Regards,
Somya


--
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

Somya,

You were almost there. The only issue I noticed was that the
prescription insert was always adding a new prescription to the last
appointment, instead of the current appointment. For this, that button
needs to be:

<xforms:trigger appearance="minimal">
    <xforms:label>Add One</xforms:label>
    <xforms:insert ev:event="DOMActivate"
                   nodeset="prescriptions"
                   at="1" position="before"
                   origin="instance('prescriptions-template')"/>
</xforms:trigger>

I removed the "context" attribute, and notice how there is just
nodeset="prescriptions". The current context is a <vistits>, since you
are inside a <xforms:repeat nodeset="/patient/visits">, so just
referring to nodeset="prescriptions" references the <prescriptions>
element inside the current node. If there are cases where you can have
zero prescriptions, then you still need to have context=".", otherwise
the <xforms:insert> won't know where to do the insertion.

For reference, I attached the full example with the above update.

Alex


On Wed, Oct 20, 2010 at 12:19 AM, Somya Rajesh Agarwal
<[hidden email]> wrote:

--
Orbeon Forms - Web forms, open-source, for the Enterprise -
http://www.orbeon.com/
My Twitter: http://twitter.com/avernet


--
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

Too bad that's not working either :-( I understand your frustration!

Recently (in August) Form Runner was doing pretty well in Liferay.
Here is a big commit that contained major fixes related to this
feature:

http://github.com/orbeon/orbeon-forms/commit/f9f0f553e4f07be62e5eee366bc6da2f4ad4cf2c

Now we haven't yet had time to look at how the latest nightly builds
behave, but it shouldn't be too hard to fix issues. It's a matter of
finding some spare cycles on our side.

Liferay is clearly quite popular, but it is also a complex, heavy, and
often frustrating piece of software to work with. Fixing anything
related to Orbeon and Liferay always turns out to be pretty costly in
time on our side.

But we keep at it and hopefully the remaining issues will be fixed in
the short-term future, although we cannot commit to a specific date.

-Erik

On Mon, Oct 18, 2010 at 7:05 AM, darrencruse <[hidden email]> wrote:

--
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

> Darren, I'm also just about giving up trying the Struts/Orbeon integration.
> Really sad and painful.

We don't have a specific Struts integration, but separate deployment
with Orbeon should work pretty well.

-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

Hi Alex,

Thank you for your reply. I made the changes suggested by you. The insert is now working fine :)

However I tried similar changes on the delete trigger for deleting the prescription node.
1. If I change the nodeset attribute from "/patient/visits/prescriptions" to "prescriptions" the delete trigger is not working at all.
2. I could not see any change in the behavior of delete trigger on setting the context attribute to "." or   context="instance('instance_patientRecord')" or removing it all together.
3. On setting nodeset="/patient/visits/prescriptions" the previous problem persisits

Please provide a solution for this.

Thanks and Regards,
Somya

-----Original Message-----
From: Alessandro Vernet [mailto:[hidden email]]
Sent: Thursday, October 21, 2010 3:25 AM
To: [hidden email]
Subject: [ops-users] Re: Issue on Working with nested <xforms:repeat>

Somya,

You were almost there. The only issue I noticed was that the prescription insert was always adding a new prescription to the last appointment, instead of the current appointment. For this, that button needs to be:

<xforms:trigger appearance="minimal">
    <xforms:label>Add One</xforms:label>
    <xforms:insert ev:event="DOMActivate"
                   nodeset="prescriptions"
                   at="1" position="before"
                   origin="instance('prescriptions-template')"/>
</xforms:trigger>

I removed the "context" attribute, and notice how there is just nodeset="prescriptions". The current context is a <vistits>, since you are inside a <xforms:repeat nodeset="/patient/visits">, so just referring to nodeset="prescriptions" references the <prescriptions> element inside the current node. If there are cases where you can have zero prescriptions, then you still need to have context=".", otherwise the <xforms:insert> won't know where to do the insertion.

For reference, I attached the full example with the above update.

Alex


On Wed, Oct 20, 2010 at 12:19 AM, Somya Rajesh Agarwal <[hidden email]> wrote:

--
Orbeon Forms - Web forms, open-source, for the Enterprise - http://www.orbeon.com/ My Twitter: http://twitter.com/avernet


--
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