Posted by
Stian Sigvartsen on
URL: https://discuss.orbeon.com/Orbeon-Form-Builder-Form-Runner-for-a-regular-web-site-tp2552615p3000363.html
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-Form-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