You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Joern Turner <jo...@web.de> on 2005/01/05 23:04:47 UTC
Chicoon XForms online demo
Hello again,
for those interested in W3C XForms there's an online demo of Chicoon under
http://81.169.173.189:8080/cocoon/chicoon/index
running the Chiba XForms processor in an Cocoon installation.
Comments welcome,
Joern Turner
-Chiba Project Admin-
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Chicoon XForms online demo
Posted by Joern Turner <jo...@web.de>.
Hello Christoph,
Christoph Hermann <christoph.hermann <at> tu-clausthal.de> writes:
>
> Joern Turner schrieb:
>
> Hello,
> and thx for your help :)
>
> > hope you get it to show at least an error and happy to help again if
> > you can gather even a tiny bit more of information. (checked the logs
> > ?)
>
> Hmm maybe that helps you (and me :)):
> I get an error in the tomcat log-file:
>
hm, strange - seems a class is not found. if you've double-checked
your setup (as it seems) and have still problems, be invited to
our mailing-list on sourceforge (http://sf.net/projects/chiba)
we'll try our very best to help you out.
Joern
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Chicoon XForms online demo
Posted by Christoph Hermann <ch...@tu-clausthal.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Joern Turner schrieb:
Hello,
and thx for your help :)
> second, did you call the prepare-cocoon target once before deploying
> Chicoon? This is necessary to update some libs in Cocoon to newer
> versions and copy another two to common/endorsed. you should take a
> close look at the output when executing 'prepare-cocoon' to see if
> maybe some of the copy operations fail. please note, that it *will*
> fail when you run 'prepare-cocoon' a second time. in that case you
> should call the opposite task 'restore-cocoon' to remove any Chicoon
> libs from your cocoon/tomcat installation again before trying again.
I did all that following hoto-install.txt from CVS and i encountered no
errors.
> at least, what prepare-cocoon does is:
> - replace the xerces and xmlapis version in common/endorsed
I have the following there:
common/endorsed# ls
dom3-xercesImpl.jar dom3-xml-apis.jar xercesImpl.orig
xmlParserAPIs.orig
> - copy chiba-libs to cocoon/WEB-INF/lib
/cocoon/WEB-INF/lib# ls chi*
chiba-0.9.9.jar
> - update JXPath in cocoon/WEB-INF/lib
cocoon/WEB-INF/lib# ls commons-jxpath-*
commons-jxpath-1.2.jar commons-jxpath-20030909.orig
> i know this procedure is far from ideal and we're working on making
> the installation easier and more generic for other
> environments/webcontainers.
NP, works fine (imho).
> hope you get it to show at least an error and happy to help again if
> you can gather even a tiny bit more of information. (checked the logs
> ?)
Hmm maybe that helps you (and me :)):
I get an error in the tomcat log-file:
java.lang.NoClassDefFoundError:
org/chiba/xml/xforms/exception/XFormsException
at java.lang.Class.getDeclaredConstructors0(Native Method)
at
java.lang.Class.privateGetDeclaredConstructors(Class.java:1590)
at java.lang.Class.getConstructor0(Class.java:1762)
at java.lang.Class.newInstance0(Class.java:276)
at java.lang.Class.newInstance(Class.java:259)
at
org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:179)
at
org.apache.avalon.excalibur.component.DefaultComponentHandler.doGet(DefaultComponentHandler.java:136)
at
org.apache.avalon.excalibur.component.ComponentHandler.get(ComponentHandler.java:381)
at
org.apache.avalon.excalibur.component.ExcaliburComponentSelector.select(ExcaliburComponentSelector.java:213)
at
org.apache.cocoon.components.ExtendedComponentSelector.select(ExtendedComponentSelector.java:267)
at
org.apache.cocoon.components.treeprocessor.SimpleSelectorProcessingNode.getThreadSafeComponent(SimpleSelectorProcessingNode.java:62)
at
org.apache.cocoon.components.treeprocessor.SimpleSelectorProcessingNode.getThreadSafeComponent(SimpleSelectorProcessingNode.java:52)
at
org.apache.cocoon.components.treeprocessor.sitemap.ActTypeNode.compose(ActTypeNode.java:80)
at
org.apache.cocoon.components.LifecycleHelper.setupComponent(LifecycleHelper.java:293)
at
org.apache.cocoon.components.LifecycleHelper.setupComponent(LifecycleHelper.java:174)
at
org.apache.cocoon.components.treeprocessor.DefaultTreeBuilder.setupNode(DefaultTreeBuilder.java:442)
at
org.apache.cocoon.components.treeprocessor.sitemap.ActNodeBuilder.buildNode(ActNodeBuilder.java:69)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder.buildChildNodesList(AbstractParentProcessingNodeBuilder.java:121)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder.buildChildNodes(AbstractParentProcessingNodeBuilder.java:136)
at
org.apache.cocoon.components.treeprocessor.sitemap.ActNodeBuilder.buildNode(ActNodeBuilder.java:71)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder.buildChildNodesList(AbstractParentProcessingNodeBuilder.java:121)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder.buildChildNodes(AbstractParentProcessingNodeBuilder.java:136)
at
org.apache.cocoon.components.treeprocessor.sitemap.MatchNodeBuilder.buildNode(MatchNodeBuilder.java:77)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNodeBuilder.buildNode(PipelineNodeBuilder.java:113)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNodeBuilder.buildNode(PipelinesNodeBuilder.java:65)
at
org.apache.cocoon.components.treeprocessor.sitemap.SitemapNodeBuilder.buildNode(SitemapNodeBuilder.java:70)
at
org.apache.cocoon.components.treeprocessor.DefaultTreeBuilder.createTree(DefaultTreeBuilder.java:325)
at
org.apache.cocoon.components.treeprocessor.DefaultTreeBuilder.build(DefaultTreeBuilder.java:395)
at
org.apache.cocoon.components.treeprocessor.DefaultTreeBuilder.build(DefaultTreeBuilder.java:357)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.setupRootNode(TreeProcessor.java:486)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:318)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:277)
at
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:103)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:49)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:126)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:101)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:336)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:277)
at org.apache.cocoon.Cocoon.process(Cocoon.java:639)
at
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1098)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:809)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:200)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:146)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:209)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:144)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2358)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:133)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:118)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:594)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:116)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:594)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:127)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948)
at
org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:152)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
at java.lang.Thread.run(Thread.java:536)
Any Ideas how to solve it?
Christoph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFB3U4pH8qhdtR4sUIRAi5tAJ9DzMuowGdIjfGYjxRGIWv+5/Z5NQCeOg/4
iPaJnyTcwp8TWg1BklwnN4Y=
=T+EN
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Chicoon XForms online demo
Posted by Joern Turner <jo...@web.de>.
Hello Christoph,
Christoph Hermann <christoph.hermann <at> tu-clausthal.de> writes:
>
> Joern Turner schrieb:
>
> Hello,
>
> > for those interested in W3C XForms there's an online demo of Chicoon
> > under http://81.169.173.189:8080/cocoon/chicoon/index
> >
> > running the Chiba XForms processor in an Cocoon installation.
>
> After looking at these examples i tried to install chicoon.
> Building works fine, but when i call
> http://localhost:8080/cocoon/chicoon/index
> simply nothing happens.
> It works fine, when i remove the generic chicoon pipeline in the
> sitemap.xmap, but then of course none of the examples is working.
> When the generic chicoon pipeline is in the sitemap tomcat (Apache
> Tomcat/4.1.31) simply closes the connection.
>
> Any help on this would really be appreciated.
ok, Chicoon was built and tested with JDK1.4.2 and tomcat 4.1.30. since nothing
happens i think it's likely a config problem.
second, did you call the prepare-cocoon target once before deploying Chicoon?
This is necessary to update some libs in Cocoon to newer versions and copy
another two to common/endorsed. you should take a close look at the output when
executing 'prepare-cocoon' to see if maybe some of the copy operations fail.
please note, that it *will* fail when you run 'prepare-cocoon' a second time. in
that case you should call the opposite task 'restore-cocoon' to remove any
Chicoon libs from your cocoon/tomcat installation again before trying again.
i know this procedure is far from ideal and we're working on making the
installation easier and more generic for other environments/webcontainers.
at least, what prepare-cocoon does is:
- replace the xerces and xmlapis version in common/endorsed
- copy chiba-libs to cocoon/WEB-INF/lib
- update JXPath in cocoon/WEB-INF/lib
hope you get it to show at least an error and happy to help again if you can
gather even a tiny bit more of information. (checked the logs ?)
Joern
> Christoph
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Chicoon XForms online demo
Posted by Christoph Hermann <ch...@tu-clausthal.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Joern Turner schrieb:
Hello,
> for those interested in W3C XForms there's an online demo of Chicoon
> under http://81.169.173.189:8080/cocoon/chicoon/index
>
> running the Chiba XForms processor in an Cocoon installation.
After looking at these examples i tried to install chicoon.
Building works fine, but when i call
http://localhost:8080/cocoon/chicoon/index
simply nothing happens.
It works fine, when i remove the generic chicoon pipeline in the
sitemap.xmap, but then of course none of the examples is working.
When the generic chicoon pipeline is in the sitemap tomcat (Apache
Tomcat/4.1.31) simply closes the connection.
Any help on this would really be appreciated.
Christoph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFB3QCMH8qhdtR4sUIRAvM9AKCH0ay2Js910/VbECqa6OH3CfS5rACg5Jf/
wuG8PK3f1YvaCdPVKKS46kw=
=Q6ww
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Chicoon XForms online demo
Posted by Joern Turner <jo...@web.de>.
Hello Paul,
Paul Joseph <pjoseph_98 <at> yahoo.com> writes:
>
> Thank you for your reply Jeorn.
>
> I really like xForms...I hear your point about the
> client being an issue for a non-server side solution.
>
> Is just the though of all that untapped client
> processing power sitting almost unused that keeps me
> thinking.
well, i understand your point - as i've said - it depends on your point of view
and requirements of your project.
>
> I proposed a client side xForms soluton to a customer
> but he balked when he heard that it would need a
> special plugin in the browser (IE6).
maybe i should have mentioned that the Chiba project also provides a pure
client-side solution called 'Convex'. It builds on the same core processor but
embeds it inside a java applet. Due to our limited development power it's still
only running in IE but generally also works with Mozilla/Firefox.
>
> If IE were to offer a version with xForm support, then
> I do think it may be he way to go - client side xForm
> processing...
not very likely to happen. MS has its own plans here -> InfoPath.
>
> and yes...some of the products I have worked on have
> required to be able to run in off-line mode so that
> busy" executives can work while they are flying in a
> plane.
sure, there's a need for that in some situations. That's why we build Convex ;)
And there are other options to come like XForms converted to pure Java apps or
applets.
lurkers of our mailinglists are welcome.
Joern
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
AW: Chicoon XForms online demo
Posted by Alexander Zirl <al...@web.de>.
Hi *,
sorry for bothering in between, but can anyone point me to a nice Tutorial
on XForms? I've started trying out the samples and introduction that's
placed here: http://cocoon.apache.org/2.1/userdocs/forms/index.html but it
seems to me that the Forms jar files have changed by now and do not match
the tutorial anymore (especially the package for the Form.js and its
internals
cocoon.load("resource://org/apache/cocoon/forms/flow/javascript/Form.js");
doesn't seem to work anymore)
Thanks for any input.
Best,
Alexander Zirl
-----Ursprüngliche Nachricht-----
Von: users-return-76004-alex.zirl=web.de@cocoon.apache.org
[mailto:users-return-76004-alex.zirl=web.de@cocoon.apache.org] Im Auftrag
von Joern Turner
Gesendet: Sunday, January 09, 2005 12:41 AM
An: users@cocoon.apache.org
Betreff: Re: Chicoon XForms online demo
Hello Paul,
Paul Joseph <pjoseph_98 <at> yahoo.com> writes:
>
> maybe a dumb question...but isn't a significant piece
> of XForm capability (Ex. the ability to work off-line)
> lost with a Server side XForm implementation...?
you're right - not all features might be available in a *pure* server-side
implementation but over 90% of the spec will still be available.
furthermore how many apps have you seen (especially in the web-app world)
that really need offline capabilities?
what i'd like to point out is this: is always depends on your concrete
requirements in a specific project how you will answer the question if
XForms is the right answer. XForms itself is defined independent of
any concrete device(which is its strength). naturally there will always be
clients that do not support the full feature set - just think of a
pda or smart phone or even a voice application (would this make sense
to work offline?).
besides offline capability is not required by the spec and not
even mentioned there.
Chiba (Chicoon) has a different approach; as server-side transcoding
engine it allows you to generate the code appropriate for any type
of client. in our proof-of-concept implementation this happens
to be a dump (script-less) browser and this is surely constrained
in some aspects. nevertheless you have the option to generate the
code that accomplishes all these features. in fact we have
another subproject that implements a full-featured client-side
XForms engine. it comes as an applet and runs in IE6 currently.
generally it's also workable in e.g. Firefox.
let me mention another thing. the fact that one or the other feature
may not work with a specific implementation or architecture was often
been used as an argument against XForms. this is IMHO this a
statement of ignorance; consider the current world of form-processing
which couldn't be worse. there are no standards, there's repeating
effort in writing scripting code to do even the easiest validations
(not to speak of dependency handling).
XForms is a big step forward. it eliminates the need for writing
script code and builds on a clearly defined markup and processing
model. its feature-richness is not even found in proprietary form
frameworks and in our work we made the experience that it's extremly
extensible and adaptable for the widest range of applications.
please allow a last remark: Chiba (Chicoon) is a server-side
reference implementation (just to proove its possible ;) - the actual
processor sitting inside the webapp is independent of its environment and
also
can be used in any other java environment (also client-side or even
distributed).
sorry if this answer was longer than you expected...
>
> Could Cocoon serve out the XForm XML(?) to the browser
> which is equipped with a XForm plugin?
sure, any simple httpd demon will do for that. - as long as you find a
fully-featured client (well, there are some but these are not open source or
free). - and your application has to define this client as standard for your
users - not always an option, especially in internet apps.
best,
Joern
>
> thx
> Paul
> --- Joern Turner <joern.turner <at> web.de> wrote:
>
> > Hello again,
> >
> > for those interested in W3C XForms there's an online
> > demo of Chicoon under
> > http://81.169.173.189:8080/cocoon/chicoon/index
> >
> > running the Chiba XForms processor in an Cocoon
> > installation.
> >
> > Comments welcome,
> >
> > Joern Turner
> > -Chiba Project Admin-
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > users-unsubscribe <at> cocoon.apache.org
> > For additional commands, e-mail:
> > users-help <at> cocoon.apache.org
> >
> >
>
> =====
> This communication, including attachments, is for the exclusive use of
> the addressee and may contain proprietary, confidential, or privileged
> information. If you are not the intended recipient, any use, copying,
> disclosure, dissemination, or distribution is strictly prohibited. If
> you are not the intended recipient, please notify the sender by return
mail
and delete this communication
> and destroy all copies.
>
>
> document.domain = 'gmane.org';
> document.title = 'Re: Chicoon XForms online demo';
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Chicoon XForms online demo
Posted by Paul Joseph <pj...@yahoo.com>.
Thank you for your reply Jeorn.
I really like xForms...I hear your point about the
client being an issue for a non-server side solution.
Is just the though of all that untapped client
processing power sitting almost unused that keeps me
thinking.
I proposed a client side xForms soluton to a customer
but he balked when he heard that it would need a
special plugin in the browser (IE6).
If IE were to offer a version with xForm support, then
I do think it may be he way to go - client side xForm
processing...
and yes...some of the products I have worked on have
required to be able to run in off-line mode so that
busy" executives can work while they are flying in a
plane.
Once again, thank you for your useful reply
thx
Paul
--- Joern Turner <jo...@web.de> wrote:
> Hello Paul,
>
> Paul Joseph <pjoseph_98 <at> yahoo.com> writes:
>
> >
> > maybe a dumb question...but isn't a significant
> piece
> > of XForm capability (Ex. the ability to work
> off-line)
> > lost with a Server side XForm implementation...?
> you're right - not all features might be available
> in a *pure* server-side
> implementation but over 90% of the spec will still
> be available.
>
> furthermore how many apps have you seen (especially
> in the web-app world)
> that really need offline capabilities?
>
> what i'd like to point out is this: is always
> depends on your concrete
> requirements in a specific project how you will
> answer the question if
> XForms is the right answer. XForms itself is defined
> independent of
> any concrete device(which is its strength).
> naturally there will always be
> clients that do not support the full feature set -
> just think of a
> pda or smart phone or even a voice application
> (would this make sense
> to work offline?).
>
> besides offline capability is not required by the
> spec and not
> even mentioned there.
>
> Chiba (Chicoon) has a different approach; as
> server-side transcoding
> engine it allows you to generate the code
> appropriate for any type
> of client. in our proof-of-concept implementation
> this happens
> to be a dump (script-less) browser and this is
> surely constrained
> in some aspects. nevertheless you have the option to
> generate the
> code that accomplishes all these features. in fact
> we have
> another subproject that implements a full-featured
> client-side
> XForms engine. it comes as an applet and runs in IE6
> currently.
> generally it's also workable in e.g. Firefox.
>
> let me mention another thing. the fact that one or
> the other feature
> may not work with a specific implementation or
> architecture was often
> been used as an argument against XForms. this is
> IMHO this a
> statement of ignorance; consider the current world
> of form-processing
> which couldn't be worse. there are no standards,
> there's repeating
> effort in writing scripting code to do even the
> easiest validations
> (not to speak of dependency handling).
>
> XForms is a big step forward. it eliminates the need
> for writing
> script code and builds on a clearly defined markup
> and processing
> model. its feature-richness is not even found in
> proprietary form
> frameworks and in our work we made the experience
> that it's extremly
> extensible and adaptable for the widest range of
> applications.
>
> please allow a last remark: Chiba (Chicoon) is a
> server-side
> reference implementation (just to proove its
> possible ;) - the actual
> processor sitting inside the webapp is independent
> of its environment and also
> can be used in any other java environment (also
> client-side or even distributed).
>
> sorry if this answer was longer than you expected...
> >
> > Could Cocoon serve out the XForm XML(?) to the
> browser
> > which is equipped with a XForm plugin?
> sure, any simple httpd demon will do for that. - as
> long as you find a
> fully-featured client (well, there are some but
> these are not open source or
> free). - and your application has to define this
> client as standard for your
> users - not always an option, especially in internet
> apps.
>
> best,
>
> Joern
>
> >
> > thx
> > Paul
> > --- Joern Turner <joern.turner <at> web.de> wrote:
> >
> > > Hello again,
> > >
> > > for those interested in W3C XForms there's an
> online
> > > demo of Chicoon under
> > > http://81.169.173.189:8080/cocoon/chicoon/index
> > >
> > > running the Chiba XForms processor in an Cocoon
> > > installation.
> > >
> > > Comments welcome,
> > >
> > > Joern Turner
> > > -Chiba Project Admin-
> > >
> > >
> > >
> > >
> >
>
---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > > users-unsubscribe <at> cocoon.apache.org
> > > For additional commands, e-mail:
> > > users-help <at> cocoon.apache.org
> > >
> > >
> >
> > =====
> > This communication, including attachments, is for
> the exclusive use of
> > the addressee and may contain proprietary,
> confidential, or privileged
> > information. If you are not the intended
> recipient, any use, copying,
> > disclosure, dissemination, or distribution is
> strictly prohibited. If
> > you are not the intended recipient, please notify
> the sender by return mail
> and delete this communication
> > and destroy all copies.
> >
> >
> > document.domain = 'gmane.org';
> > document.title = 'Re: Chicoon XForms online demo';
> >
> >
>
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail:
> users-help@cocoon.apache.org
>
>
=====
This communication, including attachments, is for the exclusive use of
the addressee and may contain proprietary, confidential, or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination, or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender by return mail and delete this communication and destroy all copies.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Chicoon XForms online demo
Posted by Paul Joseph <pj...@yahoo.com>.
Thank you for your reply Jeorn.
I really like xForms...I hear your point about the
client being an issue for a non-server side solution.
Is just the though of all that untapped client
processing power sitting almost unused that keeps me
thinking.
I proposed a client side xForms soluton to a customer
but he balked when he heard that it would need a
special plugin in the browser (IE6).
If IE were to offer a version with xForm support, then
I do think it may be he way to go - client side xForm
processing...
and yes...some of the products I have worked on have
required to be able to run in off-line mode so that
busy" executives can work while they are flying in a
plane.
Once again, thank you for your useful reply
thx
Paul
--- Joern Turner <jo...@web.de> wrote:
> Hello Paul,
>
> Paul Joseph <pjoseph_98 <at> yahoo.com> writes:
>
> >
> > maybe a dumb question...but isn't a significant
> piece
> > of XForm capability (Ex. the ability to work
> off-line)
> > lost with a Server side XForm implementation...?
> you're right - not all features might be available
> in a *pure* server-side
> implementation but over 90% of the spec will still
> be available.
>
> furthermore how many apps have you seen (especially
> in the web-app world)
> that really need offline capabilities?
>
> what i'd like to point out is this: is always
> depends on your concrete
> requirements in a specific project how you will
> answer the question if
> XForms is the right answer. XForms itself is defined
> independent of
> any concrete device(which is its strength).
> naturally there will always be
> clients that do not support the full feature set -
> just think of a
> pda or smart phone or even a voice application
> (would this make sense
> to work offline?).
>
> besides offline capability is not required by the
> spec and not
> even mentioned there.
>
> Chiba (Chicoon) has a different approach; as
> server-side transcoding
> engine it allows you to generate the code
> appropriate for any type
> of client. in our proof-of-concept implementation
> this happens
> to be a dump (script-less) browser and this is
> surely constrained
> in some aspects. nevertheless you have the option to
> generate the
> code that accomplishes all these features. in fact
> we have
> another subproject that implements a full-featured
> client-side
> XForms engine. it comes as an applet and runs in IE6
> currently.
> generally it's also workable in e.g. Firefox.
>
> let me mention another thing. the fact that one or
> the other feature
> may not work with a specific implementation or
> architecture was often
> been used as an argument against XForms. this is
> IMHO this a
> statement of ignorance; consider the current world
> of form-processing
> which couldn't be worse. there are no standards,
> there's repeating
> effort in writing scripting code to do even the
> easiest validations
> (not to speak of dependency handling).
>
> XForms is a big step forward. it eliminates the need
> for writing
> script code and builds on a clearly defined markup
> and processing
> model. its feature-richness is not even found in
> proprietary form
> frameworks and in our work we made the experience
> that it's extremly
> extensible and adaptable for the widest range of
> applications.
>
> please allow a last remark: Chiba (Chicoon) is a
> server-side
> reference implementation (just to proove its
> possible ;) - the actual
> processor sitting inside the webapp is independent
> of its environment and also
> can be used in any other java environment (also
> client-side or even distributed).
>
> sorry if this answer was longer than you expected...
> >
> > Could Cocoon serve out the XForm XML(?) to the
> browser
> > which is equipped with a XForm plugin?
> sure, any simple httpd demon will do for that. - as
> long as you find a
> fully-featured client (well, there are some but
> these are not open source or
> free). - and your application has to define this
> client as standard for your
> users - not always an option, especially in internet
> apps.
>
> best,
>
> Joern
>
> >
> > thx
> > Paul
> > --- Joern Turner <joern.turner <at> web.de> wrote:
> >
> > > Hello again,
> > >
> > > for those interested in W3C XForms there's an
> online
> > > demo of Chicoon under
> > > http://81.169.173.189:8080/cocoon/chicoon/index
> > >
> > > running the Chiba XForms processor in an Cocoon
> > > installation.
> > >
> > > Comments welcome,
> > >
> > > Joern Turner
> > > -Chiba Project Admin-
> > >
> > >
> > >
> > >
> >
>
---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > > users-unsubscribe <at> cocoon.apache.org
> > > For additional commands, e-mail:
> > > users-help <at> cocoon.apache.org
> > >
> > >
> >
> > =====
> > This communication, including attachments, is for
> the exclusive use of
> > the addressee and may contain proprietary,
> confidential, or privileged
> > information. If you are not the intended
> recipient, any use, copying,
> > disclosure, dissemination, or distribution is
> strictly prohibited. If
> > you are not the intended recipient, please notify
> the sender by return mail
> and delete this communication
> > and destroy all copies.
> >
> >
> > document.domain = 'gmane.org';
> > document.title = 'Re: Chicoon XForms online demo';
> >
> >
>
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail:
> users-help@cocoon.apache.org
>
>
=====
This communication, including attachments, is for the exclusive use of
the addressee and may contain proprietary, confidential, or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination, or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender by return mail and delete this communication and destroy all copies.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Chicoon XForms online demo
Posted by Joern Turner <jo...@web.de>.
Hello Paul,
Paul Joseph <pjoseph_98 <at> yahoo.com> writes:
>
> maybe a dumb question...but isn't a significant piece
> of XForm capability (Ex. the ability to work off-line)
> lost with a Server side XForm implementation...?
you're right - not all features might be available in a *pure* server-side
implementation but over 90% of the spec will still be available.
furthermore how many apps have you seen (especially in the web-app world)
that really need offline capabilities?
what i'd like to point out is this: is always depends on your concrete
requirements in a specific project how you will answer the question if
XForms is the right answer. XForms itself is defined independent of
any concrete device(which is its strength). naturally there will always be
clients that do not support the full feature set - just think of a
pda or smart phone or even a voice application (would this make sense
to work offline?).
besides offline capability is not required by the spec and not
even mentioned there.
Chiba (Chicoon) has a different approach; as server-side transcoding
engine it allows you to generate the code appropriate for any type
of client. in our proof-of-concept implementation this happens
to be a dump (script-less) browser and this is surely constrained
in some aspects. nevertheless you have the option to generate the
code that accomplishes all these features. in fact we have
another subproject that implements a full-featured client-side
XForms engine. it comes as an applet and runs in IE6 currently.
generally it's also workable in e.g. Firefox.
let me mention another thing. the fact that one or the other feature
may not work with a specific implementation or architecture was often
been used as an argument against XForms. this is IMHO this a
statement of ignorance; consider the current world of form-processing
which couldn't be worse. there are no standards, there's repeating
effort in writing scripting code to do even the easiest validations
(not to speak of dependency handling).
XForms is a big step forward. it eliminates the need for writing
script code and builds on a clearly defined markup and processing
model. its feature-richness is not even found in proprietary form
frameworks and in our work we made the experience that it's extremly
extensible and adaptable for the widest range of applications.
please allow a last remark: Chiba (Chicoon) is a server-side
reference implementation (just to proove its possible ;) - the actual
processor sitting inside the webapp is independent of its environment and also
can be used in any other java environment (also client-side or even distributed).
sorry if this answer was longer than you expected...
>
> Could Cocoon serve out the XForm XML(?) to the browser
> which is equipped with a XForm plugin?
sure, any simple httpd demon will do for that. - as long as you find a
fully-featured client (well, there are some but these are not open source or
free). - and your application has to define this client as standard for your
users - not always an option, especially in internet apps.
best,
Joern
>
> thx
> Paul
> --- Joern Turner <joern.turner <at> web.de> wrote:
>
> > Hello again,
> >
> > for those interested in W3C XForms there's an online
> > demo of Chicoon under
> > http://81.169.173.189:8080/cocoon/chicoon/index
> >
> > running the Chiba XForms processor in an Cocoon
> > installation.
> >
> > Comments welcome,
> >
> > Joern Turner
> > -Chiba Project Admin-
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > users-unsubscribe <at> cocoon.apache.org
> > For additional commands, e-mail:
> > users-help <at> cocoon.apache.org
> >
> >
>
> =====
> This communication, including attachments, is for the exclusive use of
> the addressee and may contain proprietary, confidential, or privileged
> information. If you are not the intended recipient, any use, copying,
> disclosure, dissemination, or distribution is strictly prohibited. If
> you are not the intended recipient, please notify the sender by return mail
and delete this communication
> and destroy all copies.
>
>
> document.domain = 'gmane.org';
> document.title = 'Re: Chicoon XForms online demo';
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Chicoon XForms online demo
Posted by Paul Joseph <pj...@yahoo.com>.
maybe a dumb question...but isn't a significant piece
of XForm capability (Ex. the ability to work off-line)
lost with a Server side XForm implementation...?
Could Cocoon serve out the XForm XML(?) to the browser
which is equipped with a XForm plugin?
thx
Paul
--- Joern Turner <jo...@web.de> wrote:
> Hello again,
>
> for those interested in W3C XForms there's an online
> demo of Chicoon under
> http://81.169.173.189:8080/cocoon/chicoon/index
>
> running the Chiba XForms processor in an Cocoon
> installation.
>
> Comments welcome,
>
> Joern Turner
> -Chiba Project Admin-
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail:
> users-help@cocoon.apache.org
>
>
=====
This communication, including attachments, is for the exclusive use of
the addressee and may contain proprietary, confidential, or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination, or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender by return mail and delete this communication and destroy all copies.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org