You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Oleg Dulin <du...@olegdulin.com> on 2003/10/26 22:35:51 UTC
JXForms vs. Woody vs. KISS
Dear Fellow Cocoon Users:
I am frequently asked by my peers at work about possible uses for
JXForms and Woody. I've evaluated both and I found that neither is
standards compliant (and please, don't flame me yet, hear me out),
JXForms is deprecated and Woody will not be stable at least until C2.2 .
XForms compliance, at least partial, is very important because we can't
ask the developers to learn a yet another XML grammar when one form
processing grammar is already in the works at W3C. For that matter, I
think it is not a good idea to ask developers in general to learn a yet
another form processing grammar.
So, what is a Cocoon advocate to do ? I was able to achieve adequate
form processing functionality using RequestGenerator,
FormValidatorAction, XSLT, XSLT extensions in Java and very very very
minimal XSP actions. The advantage is that no new XML grammar was
involved except for XSP and the output of RequestGenerator, both of
which are perfectly reasonable as they are very specific to their own
very narrow "areas of expertise."
Another approach is http://sourceforge.net/projects/chiba which I have
looked at briefly, but found the same flaw as with JXForms and Woody --
a requirement that server side code is written. IMO, the amount of
server side code should be minimized, which once again is possible for
most simple flows using RequestGenerator,Form Validator and XSLT.
Anyway, I am not criticizing woody or JXForms. I am simply seeking
opinions on the subject other than my own. Any input is greatly appreciated.
Kind regards,
Oleg
http://www.olegdulin.com/
Personal Software Practices Wiki - http://www.dulinresearch.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: JXForms vs. Woody vs. KISS
Posted by Oleg Dulin <du...@olegdulin.com>.
>> I'm not convinced, Ugo. I'm sure it's possible to have a declarative
>> flow approach. Only the interpreter or generator must be intelligent
>> enough. Of course a declarative approach is always somewhat restricting,
>
> > but isn't this desired? It works for the sitemap itself. And there are
> > also workflow markup languages on the run. But such an XML based flow
> > interpreter engine might be a big thing and independent of Cocoon.
>
> Of course it's possible. It's just that XML syntax is so horribly
> verbose with respect to any decent programming language that it makes my
> skin cringe. I've seen (well, not seen, but heard of) Cocoon sitemaps
It makes my skin cringe too, but for simple flows I still would like to
use XML for flow script.
As soon as I find some spare time I am writing a Cocoon component that
will transform FlowScript-XML into FlowScript-Rhino and call for the end
of this debate. Something like that would certainly be very useful to me
at work.
Regards,
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: JXForms vs. Woody vs. KISS
Posted by Ugo Cei <u....@cbim.it>.
Joerg Heinicke wrote:
> On 28.10.2003 21:23, Ugo Cei wrote:
> I'm not convinced, Ugo. I'm sure it's possible to have a declarative
> flow approach. Only the interpreter or generator must be intelligent
> enough. Of course a declarative approach is always somewhat restricting,
> but isn't this desired? It works for the sitemap itself. And there are
> also workflow markup languages on the run. But such an XML based flow
> interpreter engine might be a big thing and independent of Cocoon.
Of course it's possible. It's just that XML syntax is so horribly
verbose with respect to any decent programming language that it makes my
skin cringe. I've seen (well, not seen, but heard of) Cocoon sitemaps
growing to be a horrible mess of nested actions, matchers and selectors
just because people didn't want to write any Java server-side code.
Fortunately, flowscript blows all of this away. Does it require that
more than a minimum of server-side code be written? Well, yes, so what?
My opinion is that continuation-based flowscript is the greatest thing
since sliced bread. It's a revolutionary way to write web apps and we've
just started scratching the surface of what can be accomplished with it.
It's simply natural that whatever forms framework Cocoon ends up with be
intimately tied with the flowscript. After all, most web apps are
nothing more than lots and lots of forms.
Ugo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: JXForms vs. Woody vs. KISS
Posted by Joerg Heinicke <jh...@virbus.de>.
On 28.10.2003 21:23, Ugo Cei wrote:
>> The point is not whether the user can write a flow script in
>> JAvaScript or XML. I don't want to use XML as a scripting language
>> either. All that is needed is ability to define basic flows that
>> don't involve significant logic beyond what can be done using JXPath
>> using XML. Is that possible ?
>
>
> I don't know. If we're talkin web "applications" here, sooner or later
> the logic driving page flow is going to be so complex as to require a
> real programming language to express it clearly. If what we're talkin
> about is web "sites", then maybe Cocoon's sitemap and core components
> can be all you're going to need.
I'm not convinced, Ugo. I'm sure it's possible to have a declarative
flow approach. Only the interpreter or generator must be intelligent
enough. Of course a declarative approach is always somewhat restricting,
but isn't this desired? It works for the sitemap itself. And there are
also workflow markup languages on the run. But such an XML based flow
interpreter engine might be a big thing and independent of Cocoon.
>> There are currently XForms books on the market (correct me if I am
>> wrong, I believe an O'Reilly one just came out). Woody is not ready to
>> be documented by a publisher yet.
>>
>> XForms is more likely to be accepted by an XYZ MegaCorp in the U.S.
>> than Woody/Cocoon Forms.
>
>
> The problem with XForms, at present, is that we have to transform XForms
> markup to HTML, if we want to support the current browsers. And since
> XForms wasn't designed for this, transforming XForms to HTML is a PITA,
> at least IMHO. Better use something that is designed from the start to
> support server-side processing of HTML forms.
>
> When (and if) XYZ Megacorp intends to support an XForms-capable user
> agent, all the infrastructure you put in place to support XForms
> server-side isn't going to be worth a penny. What is going to be
> worthwhile is your knowledge of XForms, but applied in a totally
> different context. Well, when (and if) that happens, I think I can reach
> your level of proficiency in a few days.
+1
>> Antonio pointed out earlier that "From mid last year to today I needed
>> to learn: Java, HTML, XHTML, CSS, XML, XSLT, POI, FOP, SVG, SITEMAP,
>> XSP, XPATH, Javascript, OJB, JDO, Original DB Actions, Modular DB
>> Actions, Forrest." There is a limit to how much a single person can
>> learn, and the amount of time one is allowed to spend learning on the
>> job is finite. The less to learn the better and more productive
>> developers can be.
The need for learning much is not a point in this time. Time goes by and
much is developed. The question is not, if it is something new or not,
if you have something to learn or not. It is about worthiness of the
invention/development, it's about (not only) technical progress. This
means you have not always to invent the wheel as we didn't for Woody, we
made it only a bit rounder.
(Did I wrote all these pathetic sentences?? :-) )
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: JXForms vs. Woody vs. KISS
Posted by Ugo Cei <u....@cbim.it>.
Oleg Dulin wrote:
>> I sincerely hope it never does. XML isn't worth "a pile of fetid dingo
>> kidney" (TM) as a scripting language ;-).
> What about XSLT, which has been proven to be Turing-compatible ?
Same as above ;-).
> The point is not whether the user can write a flow script in JAvaScript
> or XML. I don't want to use XML as a scripting language either. All that
> is needed is ability to define basic flows that don't involve
> significant logic beyond what can be done using JXPath using XML. Is
> that possible ?
I don't know. If we're talkin web "applications" here, sooner or later
the logic driving page flow is going to be so complex as to require a
real programming language to express it clearly. If what we're talkin
about is web "sites", then maybe Cocoon's sitemap and core components
can be all you're going to need.
> There are currently XForms books on the market (correct me if I am
> wrong, I believe an O'Reilly one just came out). Woody is not ready to
> be documented by a publisher yet.
>
> XForms is more likely to be accepted by an XYZ MegaCorp in the U.S. than
> Woody/Cocoon Forms.
The problem with XForms, at present, is that we have to transform XForms
markup to HTML, if we want to support the current browsers. And since
XForms wasn't designed for this, transforming XForms to HTML is a PITA,
at least IMHO. Better use something that is designed from the start to
support server-side processing of HTML forms.
When (and if) XYZ Megacorp intends to support an XForms-capable user
agent, all the infrastructure you put in place to support XForms
server-side isn't going to be worth a penny. What is going to be
worthwhile is your knowledge of XForms, but applied in a totally
different context. Well, when (and if) that happens, I think I can reach
your level of proficiency in a few days.
> Antonio pointed out earlier that "From mid last year to today I needed
> to learn: Java, HTML, XHTML, CSS, XML, XSLT, POI, FOP, SVG, SITEMAP,
> XSP, XPATH, Javascript, OJB, JDO, Original DB Actions, Modular DB
> Actions, Forrest." There is a limit to how much a single person can
> learn, and the amount of time one is allowed to spend learning on the
> job is finite. The less to learn the better and more productive
> developers can be.
You may have a point here. The problem is, whether you choose Woody of
XForms, you have to learn yet another XML grammar. You're betting on
XForms for the future, I'm betting on Woody for the present. Time will
tell who wins ;-).
Ugo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: JXForms vs. Woody vs. KISS
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Sylvain Wallez dijo:
> Oleg Dulin wrote:
>> XForms is more likely to be accepted by an XYZ MegaCorp in the U.S.
>> than Woody/Cocoon Forms.
>
>
> Well, not later than this afternoon, I had a meeting with MVC zealots
> that were only speaking of "pure" MVC, Struts, "pure" JSP (no code),
> etc. I demonstrated them flowscript and woody (using my GT presentation
> which you can find in the cocoon downloads) and we ended the meeting
> with them saying "wow, this is a really clean MVC with strong separation
> of concerns, and looks very easy to use".
>
> This how people can be convinced: just show them something that works
> instead of the next-generation bloated spec.
YES!!!!!! :-DDDD
Same here in the micro, nano, and pico Corps land :-DDD
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: JXForms vs. Woody vs. KISS
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Oleg Dulin wrote:
>> I sincerely hope it never does. XML isn't worth "a pile of fetid
>> dingo kidney" (TM) as a scripting language ;-).
>
>
> What about XSLT, which has been proven to be Turing-compatible ?
>
> The point is not whether the user can write a flow script in
> JAvaScript or XML. I don't want to use XML as a scripting language
> either. All that is needed is ability to define basic flows that
> don't involve significant logic beyond what can be done using JXPath
> using XML. Is that possible ?
>
>> Do you really think that any moron can script logic in XML using
>> XMLSpy? Why not in Javascript, then?
>
>
> Not any moron; only people who are fairly comfortable with things like
> XSLT.
>
>> you really find lots of developers familiar with it? Will you be able
>> in the future? Learning the Woody markup can be done in a few hours, so
>
>
> All right.
>
> There are currently XForms books on the market (correct me if I am
> wrong, I believe an O'Reilly one just came out). Woody is not ready to
> be documented by a publisher yet.
The reason is simple: Woody is not complex enough to need a book ;-)
Woody takes a pragmatic approach to form handling problems where XForms
started by the initial requirement to build an XML document associated
to an XML Schema in the browser.
> XForms is more likely to be accepted by an XYZ MegaCorp in the U.S.
> than Woody/Cocoon Forms.
Well, not later than this afternoon, I had a meeting with MVC zealots
that were only speaking of "pure" MVC, Struts, "pure" JSP (no code),
etc. I demonstrated them flowscript and woody (using my GT presentation
which you can find in the cocoon downloads) and we ended the meeting
with them saying "wow, this is a really clean MVC with strong separation
of concerns, and looks very easy to use".
This how people can be convinced: just show them something that works
instead of the next-generation bloated spec.
>> it's not that big deal, isn't it?
>
>
> It is not a big deal to me personally. However, I had a hard time
> advocating XML at my previous project last year. The client was one of
> those American XYZ MegaBanks. 90% of the developers did not want to
> deal with learning more XML grammars than they should. They didn't
> even want to learn how to use custom JSP taglibs that I've written.
You really should go to ABC SuperBanks: they love XML and Cocoon ;-)
> Antonio pointed out earlier that "From mid last year to today I needed
> to learn: Java, HTML, XHTML, CSS, XML, XSLT, POI, FOP, SVG, SITEMAP,
> XSP, XPATH, Javascript, OJB, JDO, Original DB Actions, Modular DB
> Actions, Forrest." There is a limit to how much a single person can
> learn, and the amount of time one is allowed to spend learning on the
> job is finite. The less to learn the better and more productive
> developers can be.
I found by experience that using Woody + Flowscript involves really few
technologies: Javascript for the flow (but don't you already know it if
you know HTML and/or Java?) and a lightweight declarative markup (the
woody form definition). Not more than that.
Ah yes, you also need to learn a bunch of "wt:" elements for the form
template. But even this can be avoided: before the abovementioned
meeting, I hacked a 20-lines XSL that turns a plain old HTML page
(without any single additional attribute) into a woody template.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: JXForms vs. Woody vs. KISS
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Oleg Dulin dijo:
>> it's not that big deal, isn't it?
>
> It is not a big deal to me personally. However, I had a hard time
> advocating XML at my previous project last year. The client was one of
> those American XYZ MegaBanks. 90% of the developers did not want to deal
> with learning more XML grammars than they should. They didn't even want
> to learn how to use custom JSP taglibs that I've written.
>
> Antonio pointed out earlier that "From mid last year to today I needed
> to learn: Java, HTML, XHTML, CSS, XML, XSLT, POI, FOP, SVG, SITEMAP,
> XSP, XPATH, Javascript, OJB, JDO, Original DB Actions, Modular DB
> Actions, Forrest." There is a limit to how much a single person can
> learn, and the amount of time one is allowed to spend learning on the
> job is finite. The less to learn the better and more productive
> developers can be.
Yep. You are right. This is the price to get in the top of the techno. And
for me, learning new techno is fun. I really enjoy it. :-D
But woody is very easy. I guess easier than XForms.
Cocoon by itself means a "change of programming mentality" and once you
"get in", you will see woody is a nice piece inside Cocoon. It was
developed not in an laboratory where some people think what can be good.
Woody was developed by developers to solve problems in the real life.
I am using Woody+Flow+OJB+JDO and this is really cool.
Best Regards,
Antonio Gallardo.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Compile errors when building latest cvs-head
Posted by Joerg Heinicke <jh...@virbus.de>.
In the cocoon-2.2 CVS module there are no blocks. We included only the
Cocoon core in this module and this is refactored. The most recent block
source code is in the cocoon-2.1 module.
Joerg
On 28.10.2003 23:40, Gunter D'Hondt wrote:
> I always worked with the latest cvs-head and wanted to get the
> Woody-stuff that Sylvain already put into. Are there any specific
> blocks that I can exclude during the build or is that refactoring
> part the one of the cocoon true blocks refactoring?
>
> Gunter.
>
>
>>> Hi,
>>>
>>> I've just did a checkout of the latest cocoon-2.2 cvs-head and
>>> did a build but got lotsa compile erros (see below).
>>
>> Please, Gunter, don't use Cocoon 2.2. It's in a strong refactoring
>> phase and not usable as you experienced. The most recent usable
>> Cocoon can be found in the cocoon-2.1 module.
>>
>> Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Re: Compile errors when building latest cvs-head
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Gunter D'Hondt dijo:
>
> I always worked with the latest cvs-head and wanted to get the
> Woody-stuff that Sylvain already put into. Are there any specific blocks
> that I can exclude during the build or is that refactoring part the one
> of the cocoon true blocks refactoring?
Yep. Now is core shaking as part of the refactoring of the true blocks.
This is why Joerg said that does not recommend you to use it.
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Re: Compile errors when building latest cvs-head
Posted by Gunter D'Hondt <gu...@sofico.be>.
I always worked with the latest cvs-head and wanted to get the Woody-stuff that Sylvain already put into. Are there any specific blocks that I can exclude during the build or is that refactoring part the one of the cocoon true blocks refactoring?
Gunter.
> On 28.10.2003 16:03, Gunter D'Hondt wrote:
>
> > Hi,
> >
> > I've just did a checkout of the latest cocoon-2.2 cvs-head and did a
> > build but got lotsa compile erros (see below).
>
> Please, Gunter, don't use Cocoon 2.2. It's in a strong refactoring phase
> and not usable as you experienced. The most recent usable Cocoon can be
> found in the cocoon-2.1 module.
>
> Joerg
>
>
> ---------------------------------------------------------------------
> 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: Compile errors when building latest cvs-head
Posted by Joerg Heinicke <jh...@virbus.de>.
On 28.10.2003 16:03, Gunter D'Hondt wrote:
> Hi,
>
> I've just did a checkout of the latest cocoon-2.2 cvs-head and did a
> build but got lotsa compile erros (see below).
Please, Gunter, don't use Cocoon 2.2. It's in a strong refactoring phase
and not usable as you experienced. The most recent usable Cocoon can be
found in the cocoon-2.1 module.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Compile errors when building latest cvs-head
Posted by Gunter D'Hondt <gu...@sofico.be>.
Hi,
I've just did a checkout of the latest cocoon-2.2 cvs-head and did a
build but got lotsa compile erros (see below).
Any help is welcome!
Gunter D'Hondt
Sofico NV
LOGGING=>
---------
Buildfile: build.xml
-cocoon.init:
-cocoon.oscheck:
-cocoon.bat:
[echo] Building batch files for support on windows OS
-cocoon.sh:
-cocoon.shbat:
cocoon.get:
[exec] Using Java from C:\Java\j2sdk1.4.2
[exec] Buildfile: build.xml
[exec] clean-cocoon:
[exec] Deleting directory C:\WF\cocoon-2.2\build\cocoon-2.2-dev
[exec] prepare:
[exec]
+-----------------------------------------------------------+
[exec] Apache Cocoon 2.2-dev [1999-2003]
[exec]
+-----------------------------------------------------------+
[exec] Building with Apache Ant version 1.5.4 compiled on August
12 2003
[exec] using build file C:\WF\cocoon-2.2\build.xml
[exec] Compiling with debug on, optimize on, deprecation off
[exec] +--------------------| W A R N I N G
|----------------------+
[exec] This build is targeted for use with JVM 1.4
[exec] Using this build on a virtual machine other than the one
[exec] it is targeted for may result in runtime errors.
[exec]
+-----------------------------------------------------------+
[exec] Created dir: C:\WF\cocoon-2.2\build\cocoon-2.2-dev
[exec] compile-core:
[exec] Copying 40 files to
C:\WF\cocoon-2.2\build\cocoon-2.2-dev\classes
[exec] Copied 37 empty directories to
C:\WF\cocoon-2.2\build\cocoon-2.2-dev\classes
[exec] Created dir: C:\WF\cocoon-2.2\build\cocoon-2.2-dev\mocks
[exec] Compiling 1 source file to
C:\WF\cocoon-2.2\build\cocoon-2.2-dev\mocks
[exec] Compiling 548 source files to
C:\WF\cocoon-2.2\build\cocoon-2.2-dev\classes
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\AbstractInte
rpreter.java:60: org.apache.cocoon.components.RequestLifecycleHelper is
not public in org.apache.cocoon.components; cannot be accessed from
outside package
[exec] import org.apache.cocoon.components.RequestLifecycleHelper;
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:70: cannot resolve symbol
[exec] symbol : class CompilingInterpreter
[exec] location: package flow
[exec] import
org.apache.cocoon.components.flow.CompilingInterpreter;
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:97: cannot resolve symbol
[exec] symbol : class CompilingInterpreter
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] public class FOM_JavaScriptInterpreter extends
CompilingInterpreter
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\J
avaScriptInterpreter.java:64: cannot resolve symbol
[exec] symbol : class CompilingInterpreter
[exec] location: package flow
[exec] import
org.apache.cocoon.components.flow.CompilingInterpreter;
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\J
avaScriptInterpreter.java:86: cannot resolve symbol
[exec] symbol : class CompilingInterpreter
[exec] location: class
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
[exec] public class JavaScriptInterpreter extends
CompilingInterpreter
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\language\generato
r\GeneratorSelector.java:79: cannot resolve symbol
[exec] symbol : class ExcaliburComponentSelector
[exec] location: class
org.apache.cocoon.components.language.generator.GeneratorSelector
[exec] public class GeneratorSelector extends
ExcaliburComponentSelector implements Disposable {
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\language\generato
r\GeneratorSelector.java:88: cannot resolve symbol
[exec] symbol : class LogkitLoggerManager
[exec] location: class
org.apache.cocoon.components.language.generator.GeneratorSelector
[exec] private LogkitLoggerManager logKitManager;
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\language\generato
r\GeneratorSelector.java:92: cannot resolve symbol
[exec] symbol : class RoleManager
[exec] location: class
org.apache.cocoon.components.language.generator.GeneratorSelector
[exec] protected RoleManager roles;
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\language\generato
r\GeneratorSelector.java:105: cannot resolve symbol
[exec] symbol : class RoleManager
[exec] location: class
org.apache.cocoon.components.language.generator.GeneratorSelector
[exec] public void setRoleManager(RoleManager roleMgr) {
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\treeprocessor\Tre
eProcessor.java:59: package org.apache.avalon.excalibur.component does
not exist
[exec] import org.apache.avalon.excalibur.component.RoleManageable;
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\treeprocessor\Tre
eProcessor.java:60: package org.apache.avalon.excalibur.component does
not exist
[exec] import org.apache.avalon.excalibur.component.RoleManager;
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\treeprocessor\Tre
eProcessor.java:82: cannot resolve symbol
[exec] symbol : class ExtendedComponentSelector
[exec] location: package components
[exec] import
org.apache.cocoon.components.ExtendedComponentSelector;
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\treeprocessor\Tre
eProcessor.java:107: cannot resolve symbol
[exec] symbol : class RoleManageable
[exec] location: class
org.apache.cocoon.components.treeprocessor.TreeProcessor
[exec] RoleManageable,
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\treeprocessor\Tre
eProcessor.java:126: cannot resolve symbol
[exec] symbol : class RoleManager
[exec] location: class
org.apache.cocoon.components.treeprocessor.TreeProcessor
[exec] protected RoleManager roleManager;
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\treeprocessor\Tre
eProcessor.java:132: cannot resolve symbol
[exec] symbol : class ExtendedComponentSelector
[exec] location: class
org.apache.cocoon.components.treeprocessor.TreeProcessor
[exec] protected ExtendedComponentSelector builderSelector;
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\treeprocessor\Tre
eProcessor.java:242: cannot resolve symbol
[exec] symbol : class RoleManager
[exec] location: class
org.apache.cocoon.components.treeprocessor.TreeProcessor
[exec] public void setRoleManager(RoleManager rm) {
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\treeprocessor\Def
aultTreeBuilder.java:53: package org.apache.avalon.excalibur.component
does not exist
[exec] import
org.apache.avalon.excalibur.component.DefaultRoleManager;
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\treeprocessor\Def
aultTreeBuilder.java:54: package org.apache.avalon.excalibur.component
does not exist
[exec] import
org.apache.avalon.excalibur.component.ExcaliburComponentSelector;
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\treeprocessor\Def
aultTreeBuilder.java:55: package org.apache.avalon.excalibur.component
does not exist
[exec] import org.apache.avalon.excalibur.component.RoleManageable;
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\treeprocessor\Def
aultTreeBuilder.java:56: package org.apache.avalon.excalibur.component
does not exist
[exec] import org.apache.avalon.excalibur.component.RoleManager;
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\treeprocessor\Def
aultTreeBuilder.java:73: cannot resolve symbol
[exec] symbol : class ExtendedComponentSelector
[exec] location: package components
[exec] import
org.apache.cocoon.components.ExtendedComponentSelector;
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\treeprocessor\Def
aultTreeBuilder.java:93: cannot resolve symbol
[exec] symbol : class RoleManageable
[exec] location: class
org.apache.cocoon.components.treeprocessor.DefaultTreeBuilder
[exec] Recomposable, Configurable, Contextualizable,
RoleManageable, Recyclable, Disposable {
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\treeprocessor\Def
aultTreeBuilder.java:115: cannot resolve symbol
[exec] symbol : class RoleManager
[exec] location: class
org.apache.cocoon.components.treeprocessor.DefaultTreeBuilder
[exec] protected RoleManager parentRoleManager;
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\treeprocessor\Def
aultTreeBuilder.java:128: cannot resolve symbol
[exec] symbol : class RoleManager
[exec] location: class
org.apache.cocoon.components.treeprocessor.DefaultTreeBuilder
[exec] protected RoleManager roleManager;
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\treeprocessor\Def
aultTreeBuilder.java:171: cannot resolve symbol
[exec] symbol : class RoleManager
[exec] location: class
org.apache.cocoon.components.treeprocessor.DefaultTreeBuilder
[exec] public void setRoleManager(RoleManager rm) {
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\treeprocessor\Def
aultTreeBuilder.java:211: cannot resolve symbol
[exec] symbol : class RoleManager
[exec] location: class
org.apache.cocoon.components.treeprocessor.DefaultTreeBuilder
[exec] protected RoleManager createRoleManager() throws
Exception
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\treeprocessor\sit
emap\ComponentsSelector.java:65: cannot resolve symbol
[exec] symbol : class ExtendedComponentSelector
[exec] location: package components
[exec] import
org.apache.cocoon.components.ExtendedComponentSelector;
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\treeprocessor\sit
emap\ComponentsSelector.java:85: cannot resolve symbol
[exec] symbol : class ExtendedComponentSelector
[exec] location: class
org.apache.cocoon.components.treeprocessor.sitemap.ComponentsSelector
[exec] public class ComponentsSelector extends
ExtendedComponentSelector
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\treeprocessor\sit
emap\ContinueNode.java:58: cannot resolve symbol
[exec] symbol : class InterpreterSelector
[exec] location: package flow
[exec] import
org.apache.cocoon.components.flow.InterpreterSelector;
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\AbstractInte
rpreter.java:201: org.apache.cocoon.components.RequestLifecycleHelper is
not public in org.apache.cocoon.components; cannot be accessed from
outside package
[exec] Object key =
RequestLifecycleHelper.startProcessing(wrapper);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\AbstractInte
rpreter.java:201:
startProcessing(org.apache.cocoon.environment.Environment) is not public
in org.apache.cocoon.components.RequestLifecycleHelper; cannot be
accessed from outside package
[exec] Object key =
RequestLifecycleHelper.startProcessing(wrapper);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\AbstractInte
rpreter.java:210: org.apache.cocoon.components.RequestLifecycleHelper is
not public in org.apache.cocoon.components; cannot be accessed from
outside package
[exec] RequestLifecycleHelper.enterEnvironment(wrapper,
this.manager, processor);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\AbstractInte
rpreter.java:210:
enterEnvironment(org.apache.cocoon.environment.Environment,org.apache.av
alon.fortress.impl.handler.ComponentHandler,org.apache.cocoon.Processor)
in org.apache.cocoon.components.RequestLifecycleHelper cannot be applied
to
(org.apache.cocoon.environment.wrapper.EnvironmentWrapper,org.apache.ava
lon.framework.service.ServiceManager,org.apache.cocoon.Processor)
[exec] RequestLifecycleHelper.enterEnvironment(wrapper,
this.manager, processor);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\AbstractInte
rpreter.java:226: org.apache.cocoon.components.RequestLifecycleHelper is
not public in org.apache.cocoon.components; cannot be accessed from
outside package
[exec] RequestLifecycleHelper.leaveEnvironment();
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\AbstractInte
rpreter.java:226: leaveEnvironment() is not public in
org.apache.cocoon.components.RequestLifecycleHelper; cannot be accessed
from outside package
[exec] RequestLifecycleHelper.leaveEnvironment();
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\AbstractInte
rpreter.java:228: org.apache.cocoon.components.RequestLifecycleHelper is
not public in org.apache.cocoon.components; cannot be accessed from
outside package
[exec] RequestLifecycleHelper.endProcessing(wrapper,
key);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\AbstractInte
rpreter.java:228:
endProcessing(org.apache.cocoon.environment.Environment,java.lang.Object
) is not public in org.apache.cocoon.components.RequestLifecycleHelper;
cannot be accessed from outside package
[exec] RequestLifecycleHelper.endProcessing(wrapper,
key);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:172: cannot resolve symbol
[exec] symbol : variable super
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] super.configure(config);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:177: cannot resolve symbol
[exec] symbol : method register (java.lang.String)
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] register(loadOnStartup);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:191: cannot resolve symbol
[exec] symbol : method getLogger ()
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] if (getLogger().isDebugEnabled()) {
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:192: cannot resolve symbol
[exec] symbol : method getLogger ()
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] getLogger().debug("Flow debugger enabled,
creating");
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:209: cannot resolve symbol
[exec] symbol : method getLogger ()
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] errorReporter = new
JSErrorReporter(getLogger());
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:367: cannot resolve symbol
[exec] symbol : variable manager
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] cocoon.setup(this, environment, manager,
getLogger());
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:367: cannot resolve symbol
[exec] symbol : method getLogger ()
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] cocoon.setup(this, environment, manager,
getLogger());
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:370: cannot resolve symbol
[exec] symbol : variable compiledScripts
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] synchronized (compiledScripts) {
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:373: cannot resolve symbol
[exec] symbol : variable reloadScripts
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] if (reloadScripts) {
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:375: cannot resolve symbol
[exec] symbol : variable checkTime
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] if (now >= lastTimeCheck + checkTime) {
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:375: operator >= cannot be applied to
long,java.lang.String
[exec] if (now >= lastTimeCheck + checkTime) {
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:384: cannot resolve symbol
[exec] symbol : variable needResolve
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] if (lastExecTime == 0 || needsRefresh ||
needResolve.size() > 0) {
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:385: cannot resolve symbol
[exec] symbol : variable needResolve
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] topLevelScripts.addAll(needResolve);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:387: cannot resolve symbol
[exec] symbol : variable needResolve
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] execList.addAll(needResolve);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:391: cannot resolve symbol
[exec] symbol : variable needResolve
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] needResolve.clear();
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:397: cannot resolve symbol
[exec] symbol : class ScriptSourceEntry
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] ScriptSourceEntry entry =
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:398: cannot resolve symbol
[exec] symbol : class ScriptSourceEntry
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec]
(ScriptSourceEntry)compiledScripts.get(sourceURI);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:398: cannot resolve symbol
[exec] symbol : variable compiledScripts
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec]
(ScriptSourceEntry)compiledScripts.get(sourceURI);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:400: cannot resolve symbol
[exec] symbol : variable sourceresolver
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] Source src =
this.sourceresolver.resolveURI(sourceURI);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:401: cannot resolve symbol
[exec] symbol : class ScriptSourceEntry
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] entry = new ScriptSourceEntry(src);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:402: cannot resolve symbol
[exec] symbol : variable compiledScripts
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] compiledScripts.put(sourceURI, entry);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:410: cannot resolve symbol
[exec] symbol : class ScriptSourceEntry
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] ScriptSourceEntry entry =
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:411: cannot resolve symbol
[exec] symbol : class ScriptSourceEntry
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec]
(ScriptSourceEntry)compiledScripts.get(sourceURI);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:411: cannot resolve symbol
[exec] symbol : variable compiledScripts
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec]
(ScriptSourceEntry)compiledScripts.get(sourceURI);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:435: cannot resolve symbol
[exec] symbol : variable sourceresolver
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] Source src =
this.sourceresolver.resolveURI(fileName);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:439: cannot resolve symbol
[exec] symbol : variable compiledScripts
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] synchronized (compiledScripts) {
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:440: cannot resolve symbol
[exec] symbol : class ScriptSourceEntry
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] ScriptSourceEntry entry =
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:441: cannot resolve symbol
[exec] symbol : class ScriptSourceEntry
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec]
(ScriptSourceEntry)compiledScripts.get(src.getURI());
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:441: cannot resolve symbol
[exec] symbol : variable compiledScripts
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec]
(ScriptSourceEntry)compiledScripts.get(src.getURI());
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:445: cannot resolve symbol
[exec] symbol : class ScriptSourceEntry
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] entry = new
ScriptSourceEntry(src));
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:444: cannot resolve symbol
[exec] symbol : variable compiledScripts
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] compiledScripts.put(src.getURI(),
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:447: cannot resolve symbol
[exec] symbol : variable sourceresolver
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] this.sourceresolver.release(src);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:558: cannot resolve symbol
[exec] symbol : variable continuationsMgr
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] WebContinuation wk =
continuationsMgr.lookupWebContinuation(id);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:581: cannot resolve symbol
[exec] symbol : variable manager
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] cocoon.setup(this, environment, manager,
getLogger());
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:581: cannot resolve symbol
[exec] symbol : method getLogger ()
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] cocoon.setup(this, environment, manager,
getLogger());
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:656: cannot resolve symbol
[exec] symbol : variable super
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] super.forwardTo(uri, bizData,
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\f
om\FOM_JavaScriptInterpreter.java:668: cannot resolve symbol
[exec] symbol : variable super
[exec] location: class
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret
er
[exec] return super.process(uri, bizData, out,
environment);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\J
avaScriptInterpreter.java:159: cannot resolve symbol
[exec] symbol : variable super
[exec] location: class
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
[exec] super.configure(config);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\J
avaScriptInterpreter.java:164: cannot resolve symbol
[exec] symbol : method register (java.lang.String)
[exec] location: class
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
[exec] register(loadOnStartup);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\J
avaScriptInterpreter.java:178: cannot resolve symbol
[exec] symbol : method getLogger ()
[exec] location: class
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
[exec] if (getLogger().isDebugEnabled()) {
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\J
avaScriptInterpreter.java:179: cannot resolve symbol
[exec] symbol : method getLogger ()
[exec] location: class
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
[exec] getLogger().debug("Flow debugger enabled,
creating");
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\J
avaScriptInterpreter.java:219: cannot resolve symbol
[exec] symbol : method getLogger ()
[exec] location: class
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
[exec] ((JSLog)log).enableLogging(getLogger());
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\J
avaScriptInterpreter.java:221: cannot resolve symbol
[exec] symbol : method getLogger ()
[exec] location: class
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
[exec] errorReporter = new
JSErrorReporter(getLogger());
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\J
avaScriptInterpreter.java:370: cannot resolve symbol
[exec] symbol : variable manager
[exec] location: class
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
[exec] cocoon.setContext(manager, environment);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\J
avaScriptInterpreter.java:373: cannot resolve symbol
[exec] symbol : variable compiledScripts
[exec] location: class
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
[exec] synchronized (compiledScripts) {
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\J
avaScriptInterpreter.java:376: cannot resolve symbol
[exec] symbol : variable reloadScripts
[exec] location: class
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
[exec] if (reloadScripts) {
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\J
avaScriptInterpreter.java:378: cannot resolve symbol
[exec] symbol : variable checkTime
[exec] location: class
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
[exec] if (now >= lastTimeCheck + checkTime) {
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\J
avaScriptInterpreter.java:378: operator >= cannot be applied to
long,java.lang.String
[exec] if (now >= lastTimeCheck + checkTime) {
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\J
avaScriptInterpreter.java:387: cannot resolve symbol
[exec] symbol : variable needResolve
[exec] location: class
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
[exec] if (lastExecTime == 0 || needsRefresh ||
needResolve.size() > 0) {
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\J
avaScriptInterpreter.java:388: cannot resolve symbol
[exec] symbol : variable needResolve
[exec] location: class
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
[exec] topLevelScripts.addAll(needResolve);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\J
avaScriptInterpreter.java:390: cannot resolve symbol
[exec] symbol : variable needResolve
[exec] location: class
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
[exec] execList.addAll(needResolve);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\J
avaScriptInterpreter.java:394: cannot resolve symbol
[exec] symbol : variable needResolve
[exec] location: class
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
[exec] needResolve.clear();
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\J
avaScriptInterpreter.java:402: cannot resolve symbol
[exec] symbol : class ScriptSourceEntry
[exec] location: class
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
[exec] ScriptSourceEntry entry =
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\J
avaScriptInterpreter.java:403: cannot resolve symbol
[exec] symbol : class ScriptSourceEntry
[exec] location: class
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
[exec]
(ScriptSourceEntry)compiledScripts.get(sourceURI);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\J
avaScriptInterpreter.java:403: cannot resolve symbol
[exec] symbol : variable compiledScripts
[exec] location: class
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
[exec]
(ScriptSourceEntry)compiledScripts.get(sourceURI);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\J
avaScriptInterpreter.java:405: cannot resolve symbol
[exec] symbol : variable sourceresolver
[exec] location: class
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
[exec] Source src =
this.sourceresolver.resolveURI(sourceURI);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\J
avaScriptInterpreter.java:406: cannot resolve symbol
[exec] symbol : class ScriptSourceEntry
[exec] location: class
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
[exec] entry = new ScriptSourceEntry(src);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\J
avaScriptInterpreter.java:407: cannot resolve symbol
[exec] symbol : variable compiledScripts
[exec] location: class
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
[exec] compiledScripts.put(sourceURI, entry);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\J
avaScriptInterpreter.java:415: cannot resolve symbol
[exec] symbol : class ScriptSourceEntry
[exec] location: class
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
[exec] ScriptSourceEntry entry =
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\J
avaScriptInterpreter.java:416: cannot resolve symbol
[exec] symbol : class ScriptSourceEntry
[exec] location: class
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
[exec]
(ScriptSourceEntry)compiledScripts.get(sourceURI);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\J
avaScriptInterpreter.java:416: cannot resolve symbol
[exec] symbol : variable compiledScripts
[exec] location: class
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
[exec]
(ScriptSourceEntry)compiledScripts.get(sourceURI);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\J
avaScriptInterpreter.java:454: cannot resolve symbol
[exec] symbol : variable sourceresolver
[exec] location: class
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
[exec] Source src =
this.sourceresolver.resolveURI(fileName);
[exec] ^
[exec]
C:\WF\cocoon-2.2\src\java\org\apache\cocoon\components\flow\javascript\J
avaScriptInterpreter.java:458: cannot resolve symbol
[exec] symbol : variable compiledScripts
[exec] location: class
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
[exec] synchronized (compiledScripts) {
[exec] ^
[exec] 100 errors
[exec] BUILD FAILED
[exec] file:C:/WF/cocoon-2.2/src/targets/compile-build.xml:39:
Compile failed; see the compiler error output for details.
[exec] Total time: 22 seconds
BUILD SUCCESSFUL
Total time: 25 seconds
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: JXForms vs. Woody vs. KISS
Posted by Oleg Dulin <du...@olegdulin.com>.
> I sincerely hope it never does. XML isn't worth "a pile of fetid dingo
> kidney" (TM) as a scripting language ;-).
What about XSLT, which has been proven to be Turing-compatible ?
The point is not whether the user can write a flow script in JAvaScript
or XML. I don't want to use XML as a scripting language either. All that
is needed is ability to define basic flows that don't involve
significant logic beyond what can be done using JXPath using XML. Is
that possible ?
> Do you really think that any moron can script logic in XML using XMLSpy?
> Why not in Javascript, then?
Not any moron; only people who are fairly comfortable with things like XSLT.
> you really find lots of developers familiar with it? Will you be able in
> the future? Learning the Woody markup can be done in a few hours, so
All right.
There are currently XForms books on the market (correct me if I am
wrong, I believe an O'Reilly one just came out). Woody is not ready to
be documented by a publisher yet.
XForms is more likely to be accepted by an XYZ MegaCorp in the U.S. than
Woody/Cocoon Forms.
> it's not that big deal, isn't it?
It is not a big deal to me personally. However, I had a hard time
advocating XML at my previous project last year. The client was one of
those American XYZ MegaBanks. 90% of the developers did not want to deal
with learning more XML grammars than they should. They didn't even want
to learn how to use custom JSP taglibs that I've written.
Antonio pointed out earlier that "From mid last year to today I needed
to learn: Java, HTML, XHTML, CSS, XML, XSLT, POI, FOP, SVG, SITEMAP,
XSP, XPATH, Javascript, OJB, JDO, Original DB Actions, Modular DB
Actions, Forrest." There is a limit to how much a single person can
learn, and the amount of time one is allowed to spend learning on the
job is finite. The less to learn the better and more productive
developers can be.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: OT: Was: JXForms vs. Woody vs. KISS
Posted by Gianluca Sartori <g....@elis.org>.
Il gio, 2003-10-30 alle 14:10, Ugo Cei ha scritto:
> Sorry but this approach has never worked in practice for me. Programming
> is hard and I don't think adding another level of abstraction is going
> to change this any time soon. Class diagrams may be cool, if used as a
> tool for communicating design between designers and programmers, but
> they tend to promote a top-down approach whereby coding is seen as a
> purely mechanical activity. Realizing that it isn't so is one of the
> greatest insights of the Agile movement.
UML was only an example. I stronlgy believe in the human nature of
software development. I understand your point and I agree with you when
you say that adding a new abstraction layer to the business logic is not
a solution to the problem.
In some cases, anyway, when the problem domain is clear (made clear by
the experence), abstraction could be usefull because it really reduce
the effort to accomplish a task in a defined set. So I'm not talking
about general solutions, or developing a paradigm starting from this
assumption.
UML based CASE Tools tend to be general, for this reason they usually
add complexity instead of reducing it. A database ER Diagram instead, is
very usefull and very easy to be built because it is specific to a
domain. This way its syntax and semantic is human sized.
> Besides, Cocoon flowscript should be really only used for implementing
> the flow between pages of your web application, whereas business logic
> should be nicely tucked away inside a domain model. In other words,
> flowscripts should be *very* simple, in which case I don't think you can
> simplify them further by using a model.
Here is the point. They're simple and a model could really be written.
This is my point of view: Models are usefull in well known
contexts/domains. By saying "well known" I mean we already have a
conceptual model (or a pattern) get from our experience in that domain.
Of course, if you are a developer you usually go with "patterns" to
describe abstractions, but if you are a user? And by "user" I mean in
therms of cocoon developers and users.
Gianluca
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: OT: Was: JXForms vs. Woody vs. KISS
Posted by Andrzej Jan Taramina <an...@chaeron.com>.
Ugo said:
> Sorry but this approach has never worked in practice for me. Programming
> is hard and I don't think adding another level of abstraction is going to
> change this any time soon. Class diagrams may be cool, if used as a tool for
> communicating design between designers and programmers, but they tend to
> promote a top-down approach whereby coding is seen as a purely mechanical
> activity. Realizing that it isn't so is one of the greatest insights of the
> Agile movement.
>
> Besides, Cocoon flowscript should be really only used for implementing the
> flow between pages of your web application, whereas business logic should be
> nicely tucked away inside a domain model. In other words, flowscripts should
> be *very* simple, in which case I don't think you can simplify them further by
> using a model.
Hmmm....if the flow is that simple (and I agree that it should be) then
specifying it declaratively using and XML vocabulary should not be a big
deal, since it won't be "hard programming".
Business logic, on the other hand, is the "harder" stuff, and thus does not
lend itself to declarative approaches.
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: OT: Was: JXForms vs. Woody vs. KISS
Posted by Ugo Cei <u....@cbim.it>.
Gianluca Sartori wrote:
> A Model. One can use XML tu build Models which are independent from the
> specific implementation. An example could be a UML Class Diagrams. You
> have a model (The Class Diagram Model) which is then converted in
> something concrete (ie. some .java files)
Sorry but this approach has never worked in practice for me. Programming
is hard and I don't think adding another level of abstraction is going
to change this any time soon. Class diagrams may be cool, if used as a
tool for communicating design between designers and programmers, but
they tend to promote a top-down approach whereby coding is seen as a
purely mechanical activity. Realizing that it isn't so is one of the
greatest insights of the Agile movement.
Besides, Cocoon flowscript should be really only used for implementing
the flow between pages of your web application, whereas business logic
should be nicely tucked away inside a domain model. In other words,
flowscripts should be *very* simple, in which case I don't think you can
simplify them further by using a model.
> Thank you! If we would have thought all the same way, the world
> "progress" will be never invented ;)
;-)
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: OT: Was: JXForms vs. Woody vs. KISS
Posted by Alain Javier Guarnieri del Gesu <ja...@ajgdg.com>.
* Gianluca Sartori <g....@elis.org> [2003-10-30 07:11]:
> Il mar, 2003-10-28 alle 21:34, Ugo Cei ha scritto:
> A Model. One can use XML tu build Models which are independent from the
> specific implementation. An example could be a UML Class Diagrams. You
> have a model (The Class Diagram Model) which is then converted in
> something concrete (ie. some .java files)
>
> We do it with Class Diagram, we could do the same with Logic Flows
>
> > > the future will be cool to design your application with WISIWYG tools
> > > instead of writing code :)
> >
> > Visual programming is The Next Big Thing. Sure. It's been for almost
> > twenty years ;-).
> The fact we still don't have it is not sufficient to exclude it, don't
> you think? Dennis Ritchie invented the C language to implement the
> concept of portability raising the programming level to un upper
> abstraction level. Today we don't have a 100% portability solution. The
> problem is not the technology itself. The problem is to find an
> agreement on how to to things. Standards are important for this reason
> (the problem here is the time standards require to be defined)
>
> I don't want to say that we are going to use visual tools for al kind of
> programming needs. I say that we could use conceptual models for well
> knonw patterns. Of couse well known means we have experience in the
> field, and this requires time.
At first blush, it sounds far fetched to me, too. Upon reflection,
it merely seems to be far reaching.
Along the way to the day when the PHB can drag and drop his own
logistics software (shudder), XML provides for visualization
tools and reporting tools. Underneath all this is an XML model
of that workflow. Before graphical user interface creates that
model, the model can create graphical representations that are
the basis of a future user interface.
You might have a look at Together J, or Embarcadaro (are they still
independant?), to get a picture of how a visual programming
paradigm, given a few decades, can really pan out. They are good
examples of visual programming using the URL and ER models,
respectively.
I've used ER-Win to create relational databases. I cound never
imagine why someone would deign to write DDL by hand.
(Note: This comes from a fellow who does alost all his work in vi.
I don't really work with visual tools.)
--
Alain Javier Guarnieri del Gesu - javi@ajgdg.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
OT: Was: JXForms vs. Woody vs. KISS
Posted by Gianluca Sartori <g....@elis.org>.
Il mar, 2003-10-28 alle 21:34, Ugo Cei ha scritto:
> > Because XML let us build a Model Representation of the Logic Flow.
>
> A what?
A Model. One can use XML tu build Models which are independent from the
specific implementation. An example could be a UML Class Diagrams. You
have a model (The Class Diagram Model) which is then converted in
something concrete (ie. some .java files)
We do it with Class Diagram, we could do the same with Logic Flows
> > the future will be cool to design your application with WISIWYG tools
> > instead of writing code :)
>
> Visual programming is The Next Big Thing. Sure. It's been for almost
> twenty years ;-).
The fact we still don't have it is not sufficient to exclude it, don't
you think? Dennis Ritchie invented the C language to implement the
concept of portability raising the programming level to un upper
abstraction level. Today we don't have a 100% portability solution. The
problem is not the technology itself. The problem is to find an
agreement on how to to things. Standards are important for this reason
(the problem here is the time standards require to be defined)
I don't want to say that we are going to use visual tools for al kind of
programming needs. I say that we could use conceptual models for well
knonw patterns. Of couse well known means we have experience in the
field, and this requires time.
The good thing with XML is that can represent and model an abstraction
which can than be processed to create the concrete thing. Which, BTW is
what coccon does. (Im talking about XML, but any other semantic definion
language could be used. XML is important because it is standard, not
because it is XML. As you know, the idea behind is quite ancient)
> > Of course, we cannot eliminate coding for all
> > kind of logic. I think, anyway, that for well known patterns we could
> > use XML. And the Form case is one of this.
>
> Sorry but I don't agree with you.
Thank you! If we would have thought all the same way, the world
"progress" will be never invented ;)
BTW, actually we could build conceptal modes on top of cocoon. We could
have a visual sitemap editor (it already exists, a kind of, at least), a
visual query editor for ESQL, a visual content editor for forrest
documets and so on. The problems are, as always, time and agreements.
Gianluca
> Ugo
>
>
> ---------------------------------------------------------------------
> 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: JXForms vs. Woody vs. KISS
Posted by Ugo Cei <u....@cbim.it>.
Gianluca Sartori wrote:
> Il lun, 2003-10-27 alle 23:42, Ugo Cei ha scritto:
>>Do you really think that any moron can script logic in XML using XMLSpy?
>>Why not in Javascript, then?
> Because XML let us build a Model Representation of the Logic Flow.
A what?
>This
> is very important for (user targeted) development tools to grew up. In
> the future will be cool to design your application with WISIWYG tools
> instead of writing code :)
Visual programming is The Next Big Thing. Sure. It's been for almost
twenty years ;-).
> Of course, we cannot eliminate coding for all
> kind of logic. I think, anyway, that for well known patterns we could
> use XML. And the Form case is one of this.
Sorry but I don't agree with you.
Ugo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: JXForms vs. Woody vs. KISS
Posted by Gianluca Sartori <g....@elis.org>.
Il lun, 2003-10-27 alle 23:42, Ugo Cei ha scritto:
> Do you really think that any moron can script logic in XML using XMLSpy?
> Why not in Javascript, then?
Because XML let us build a Model Representation of the Logic Flow. This
is very important for (user targeted) development tools to grew up. In
the future will be cool to design your application with WISIWYG tools
instead of writing code :) Of course, we cannot eliminate coding for all
kind of logic. I think, anyway, that for well known patterns we could
use XML. And the Form case is one of this.
Gianluca
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Link Livesites: Cocoon 2.1
Posted by Joerg Heinicke <jh...@virbus.de>.
On 29.10.2003 09:57, Hassan Abolhassani wrote:
> Hi Joerg,
>
> Thanks for the reply. Actually on our staging server we already moved to
> Cocoo 2.1, but the change is not reflecte to our live server. I
> understand that I need to send the change request when we update the
> live site. Am I right?
This would be the easiest thing. It will be updated on our website then.
Joerg
>>Hi
>>
>>Could you please add the following site:
>>
>>Url: Http://www.razorfish.co.jp
>>Cocoon version: 2.1
>>Short description:
>> Razorfish Japan provides web services
>> that help organizations generate competitive
>> advantage by leveraging the power of technology
>> and strategy.
>>
>>Regards,
>>Hassan
>
>
> Hello Hassan,
>
> your URL is already added to the live sites list. But not to 2.1 as you
> may expect it, but to 2.0.4
> (http://cocoon.apache.org/link/livesites-2.0.html), because the header
> says that.
>
> Regards,
>
> Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Link Livesites: Cocoon 2.1
Posted by Hassan Abolhassani <Ha...@razorfish.co.jp>.
Hi Joerg,
Thanks for the reply. Actually on our staging server we already moved to
Cocoo 2.1, but the change is not reflecte to our live server. I
understand that I need to send the change request when we update the
live site. Am I right?
Regards,
Hassan
> Hi
>
> Could you please add the following site:
>
> Url: Http://www.razorfish.co.jp
> Cocoon version: 2.1
> Short description:
> Razorfish Japan provides web services
> that help organizations generate competitive
> advantage by leveraging the power of technology
> and strategy.
>
> Regards,
> Hassan
Hello Hassan,
your URL is already added to the live sites list. But not to 2.1 as you
may expect it, but to 2.0.4
(http://cocoon.apache.org/link/livesites-2.0.html), because the header
says that.
Regards,
Joerg
___
Razorfish Japan, Inc.
アボルハッサニ ハッサン Hassan Abolhassani [Technology network]
株式会社 レーザーフィッシュ・ジャパン
Hassan.Abolhassani@razorfish.co.jp
Tel:03-5436-9980 Fax:03-5436-9126
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Link Livesites: Cocoon 2.1
Posted by Joerg Heinicke <jh...@virbus.de>.
On 29.10.2003 05:36, Hassan Abolhassani wrote:
> Hi
>
> Could you please add the following site:
>
> Url: Http://www.razorfish.co.jp
> Cocoon version: 2.1
> Short description:
> Razorfish Japan provides web services
> that help organizations generate competitive
> advantage by leveraging the power of technology
> and strategy.
>
> Regards,
> Hassan
Hello Hassan,
your URL is already added to the live sites list. But not to 2.1 as you
may expect it, but to 2.0.4
(http://cocoon.apache.org/link/livesites-2.0.html), because the header
says that.
Regards,
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Link Livesites: Cocoon 2.1
Posted by Hassan Abolhassani <Ha...@razorfish.co.jp>.
Hi
Could you please add the following site:
Url: Http://www.razorfish.co.jp
Cocoon version: 2.1
Short description:
Razorfish Japan provides web services
that help organizations generate competitive
advantage by leveraging the power of technology
and strategy.
Regards,
Hassan
___
Razorfish Japan, Inc.
アボルハッサニ ハッサン Hassan Abolhassani [Technology network]
株式会社 レーザーフィッシュ・ジャパン
Hassan.Abolhassani@razorfish.co.jp
Tel:03-5436-9980 Fax:03-5436-9126
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: JXForms vs. Woody vs. KISS
Posted by joern turner <jo...@web.de>.
Bruno Dumon wrote:
> On Tue, 2003-10-28 at 01:00, joern turner wrote:
> <snip/>
>
>>i think there already have been lots of discussions on this topic but
>>could you nevertheless summarize why XForms is not a good solution for
>>the server-side? - ok, it defines things in terms of DOM and i
>>understand and respect the history of Cocoon and its preferral for SAX
>>based processing. but IMO this might get problematic if it narrows your
>>perception for possible solutions.
>>
>>are there other arguments beside that?
>
>
> DOM vs SAX isn't even an issue, if you need a data model, of course
> you'll use DOM and not SAX.
>
> Some time ago Sylvain Wallez made a comparison between Woody and XML
> Form (the "XForm implementation" of Cocoon), which you can find here:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105881304808076&w=2
>
> (BTW, don't expect any further reactions from my side if you start
> rehashing the things said there)
thanks for the pointer - i'll see if theres anything for us.
>
> Note that it doesn't make much sense IMO to compare Woody to XForms.
> Woody is about how incoming requests are handled on the server side,
> what programming interfaces are provided, etc. It would make much more
> sense to ask why we didn't use JSF.
but all of these have similar goals: to process forms - it would be good
to know the strength and weaknesses of each to know when to use the one
or the other tool.
as already stated: form processing is too complex to find a 'one size
fits all' solution when it comes to practice. but it would be a big
improvement to establish a standarized markup authors can rely on and a
well-defined and accepted logical processing model (however this might
be realized).
>
> I'd also like to point out that Woody *is* based on standards: it uses
> XML where sensible, uses XSLT for publishing, produces standard HTML
> forms (and could handle other ones as well). It also integrates nicely
> in Cocoon and Avalon.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: JXForms vs. Woody vs. KISS
Posted by Reinhard Poetz <re...@apache.org>.
> It would make much more sense to ask why we didn't use JSF.
Goody question :-)
Why?
Cheers,
Reinhard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: JXForms vs. Woody vs. KISS
Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2003-10-28 at 01:00, joern turner wrote:
<snip/>
>
> i think there already have been lots of discussions on this topic but
> could you nevertheless summarize why XForms is not a good solution for
> the server-side? - ok, it defines things in terms of DOM and i
> understand and respect the history of Cocoon and its preferral for SAX
> based processing. but IMO this might get problematic if it narrows your
> perception for possible solutions.
>
> are there other arguments beside that?
DOM vs SAX isn't even an issue, if you need a data model, of course
you'll use DOM and not SAX.
Some time ago Sylvain Wallez made a comparison between Woody and XML
Form (the "XForm implementation" of Cocoon), which you can find here:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105881304808076&w=2
(BTW, don't expect any further reactions from my side if you start
rehashing the things said there)
Note that it doesn't make much sense IMO to compare Woody to XForms.
Woody is about how incoming requests are handled on the server side,
what programming interfaces are provided, etc. It would make much more
sense to ask why we didn't use JSF.
I'd also like to point out that Woody *is* based on standards: it uses
XML where sensible, uses XSLT for publishing, produces standard HTML
forms (and could handle other ones as well). It also integrates nicely
in Cocoon and Avalon.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: JXForms vs. Woody vs. KISS
Posted by joern turner <jo...@web.de>.
Ugo,
Ugo Cei wrote:
> Oleg Dulin wrote:
>
>> Now, I understand it is difficult to come up with a way to define a
>> scripted flow of web pages w/o actually writing some sort of a script.
>> Can this be XML ? Does Cocoon Forms support using XML for flow script
>> instead of JavaScript ?
>
>
> I sincerely hope it never does. XML isn't worth "a pile of fetid dingo
> kidney" (TM) as a scripting language ;-).
>
>> Yes, easy solution with minimal code such that someone with XMLSpy can
>> configure and minimal developer involvement is needed.
>
>
> Do you really think that any moron can script logic in XML using XMLSpy?
> Why not in Javascript, then?
>
> Anyway, if "RequestGenerator, FormValidatorAction, XSLT, XSLT extensions
> in Java and very very very minimal XSP actions" satisfy your needs, just
> use them. Nobody is taking them away from you. But if you want to stay
> on top of the current trends, as Bertrand said, then Cocoon Forms
> (Woody) is the way to go.
>
> As far as W3C XForms is concerned, as Stefano said at the GetTogether
> (paraphrasing): we are fond of standards, but we are not afraid to
> invent our own when the existing ones do not fit. Many of us don't think
> XForms is a good standard for server-side form processing. Besides, can
> you really find lots of developers familiar with it? Will you be able in
> the future? Learning the Woody markup can be done in a few hours, so
> it's not that big deal, isn't it?
i think there already have been lots of discussions on this topic but
could you nevertheless summarize why XForms is not a good solution for
the server-side? - ok, it defines things in terms of DOM and i
understand and respect the history of Cocoon and its preferral for SAX
based processing. but IMO this might get problematic if it narrows your
perception for possible solutions.
are there other arguments beside that?
and, how many programmer will you find that are familiar with Woody? How
far will this knowledge take you? - don't get this wrong; i don't want
to argue against Woody at all! i'm not familiar with it but there may be
the danger of re-inventing wheels or exploring dead-ends that others
already detected. - that applies to both: Woody and XForms.
btw, even if XForms was started with a strong client-side approach
there's a growing part of the community that believes in server-side
processing. but even this view is still implementation centric; its
simply not relevant where the XForms processor lives, if on the server,
the client or even distributed between them.
it would be nice if experiences made by Woody would once be submitted to
the XForms working group and give it a chance to consider these.
form processing can get a terrible complex beast when starting with
interdependent validations and calculations, typing and stuff that users
might want and many good efforts crashed or died silently cause they
tried to tame the beast all alone. an open-minded exchange of ideas
between these concepts would help both to improve instead of making it a
side by side race. (that's why i'm reading this list)
Joern
>
> Just my 0.02€.
>
> Ugo
>
>
> ---------------------------------------------------------------------
> 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: JXForms vs. Woody vs. KISS
Posted by Ugo Cei <u....@cbim.it>.
Oleg Dulin wrote:
> Now, I understand it is difficult to come up with a way to define a
> scripted flow of web pages w/o actually writing some sort of a script.
> Can this be XML ? Does Cocoon Forms support using XML for flow script
> instead of JavaScript ?
I sincerely hope it never does. XML isn't worth "a pile of fetid dingo
kidney" (TM) as a scripting language ;-).
> Yes, easy solution with minimal code such that someone with XMLSpy can
> configure and minimal developer involvement is needed.
Do you really think that any moron can script logic in XML using XMLSpy?
Why not in Javascript, then?
Anyway, if "RequestGenerator, FormValidatorAction, XSLT, XSLT extensions
in Java and very very very minimal XSP actions" satisfy your needs, just
use them. Nobody is taking them away from you. But if you want to stay
on top of the current trends, as Bertrand said, then Cocoon Forms
(Woody) is the way to go.
As far as W3C XForms is concerned, as Stefano said at the GetTogether
(paraphrasing): we are fond of standards, but we are not afraid to
invent our own when the existing ones do not fit. Many of us don't think
XForms is a good standard for server-side form processing. Besides, can
you really find lots of developers familiar with it? Will you be able in
the future? Learning the Woody markup can be done in a few hours, so
it's not that big deal, isn't it?
Just my 0.02€.
Ugo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: JXForms vs. Woody vs. KISS
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Oleg Dulin dijo:
>>
>> what do you mean by 'a requirement that server side code is written'?
>
> Actually, I should rephrase it -- any code, not just server side.
>
> Take flow definition for example -- in Woody it looks like you have to
> use FlowScript (JavaScript) and continuations. Chiba has a Java
> framework of its own.
You can use Woody without flow at all. Check the examples in Cocoon.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: JXForms vs. Woody vs. KISS
Posted by Andrzej Jan Taramina <an...@chaeron.com>.
> Take flow definition for example -- in Woody it looks like you have to
> use FlowScript (JavaScript) and continuations. Chiba has a Java
> framework of its own.
If you use Chicoon, then you don't need to use the Chiba Java framework.
> Yes, easy solution with minimal code such that someone with XMLSpy can
> configure and minimal developer involvement is needed.
I doubt most users, even power users, would be able to do this with XMLSpy
and any of the available tools. I think it would still require a programmer,
even with a non-programming solution like Chiba/Chicoon/Cocoon. At least not
without a lot of handholding, solid documentation and lots of examples.
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: JXForms vs. Woody vs. KISS
Posted by Oleg Dulin <du...@olegdulin.com>.
>
> what do you mean by 'a requirement that server side code is written'?
>
Actually, I should rephrase it -- any code, not just server side.
Take flow definition for example -- in Woody it looks like you have to
use FlowScript (JavaScript) and continuations. Chiba has a Java
framework of its own.
Now, I understand it is difficult to come up with a way to define a
scripted flow of web pages w/o actually writing some sort of a script.
Can this be XML ? Does Cocoon Forms support using XML for flow script
instead of JavaScript ?
> i'm still having problems understanding what you're exactly looking for.
> - a XForms-like but easy solution with minimal server-side code? why do
Yes, easy solution with minimal code such that someone with XMLSpy can
configure and minimal developer involvement is needed.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: JXForms vs. Woody vs. KISS
Posted by joern turner <jo...@web.de>.
Oleg,
Oleg Dulin wrote:
> Dear Fellow Cocoon Users:
>
> I am frequently asked by my peers at work about possible uses for
> JXForms and Woody. I've evaluated both and I found that neither is
> standards compliant (and please, don't flame me yet, hear me out),
> JXForms is deprecated and Woody will not be stable at least until C2.2 .
>
> XForms compliance, at least partial, is very important because we can't
> ask the developers to learn a yet another XML grammar when one form
> processing grammar is already in the works at W3C. For that matter, I
> think it is not a good idea to ask developers in general to learn a yet
> another form processing grammar.
XForms is a W3C Recommendation already. - and i would agree with you
here - standards conformance *is* an important thing.
>
> So, what is a Cocoon advocate to do ? I was able to achieve adequate
> form processing functionality using RequestGenerator,
> FormValidatorAction, XSLT, XSLT extensions in Java and very very very
> minimal XSP actions. The advantage is that no new XML grammar was
> involved except for XSP and the output of RequestGenerator, both of
> which are perfectly reasonable as they are very specific to their own
> very narrow "areas of expertise."
>
> Another approach is http://sourceforge.net/projects/chiba which I have
> looked at briefly, but found the same flaw as with JXForms and Woody --
> a requirement that server side code is written. IMO, the amount of
> server side code should be minimized, which once again is possible for
> most simple flows using RequestGenerator,Form Validator and XSLT.
what do you mean by 'a requirement that server side code is written'?
all you have to write is the form itself - Chiba is a generic form
processing engine.
Chicoon - the Cocoon integration of Chiba - is a Cocoon Action and can
be used anywhere in your pipelines. a new version of it which integrates
the latest Chiba version is on the way. if you're really looking for
standards you should maybe have a closer look at it.
i'm still having problems understanding what you're exactly looking for.
- a XForms-like but easy solution with minimal server-side code? why do
you care *where* the code is executed as long as its done correctly?
just trying to understand your needs to improve our solution.
Joern Turner
>
> Anyway, I am not criticizing woody or JXForms. I am simply seeking
> opinions on the subject other than my own. Any input is greatly
> appreciated.
>
> Kind regards,
> Oleg
> http://www.olegdulin.com/
> Personal Software Practices Wiki - http://www.dulinresearch.com/
>
>
>
>
> ---------------------------------------------------------------------
> 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: JXForms vs. Woody vs. KISS
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
It depends on the size and complexity of your project. At the end maybe
the complexity is the key role in the choose.
>From my own experience (a little more than a year with cocoon), I prefer
to use woody for any size, because since this is true about a new grammar,
but there are many grammar you any way soon or later will need to learn.
>From mid last year to today I needed to learn:
Java, HTML, XHTML, CSS, XML, XSLT, POI, FOP, SVG, SITEMAP, XSP, XPATH,
Javascript, OJB, JDO, Original DB Actions, Modular DB Actions, Forrest and
others than right now does not come to my mind.
So adding woody is not a problem of "just add a new grammar" Then plus for
using woody is to get the so claimed "Separation of Concerns". So the new
woody grammars:
definition, binding and template + flow are good enough to acomplish the
"promised land" :-D
BTW, Woody will be renamed to Cocoon forms. I think this cleary explain
the way cocoon is going right now.
So I think: "stop thinking in what is the best that and come to woody! :-D
This is just my opinion. ;)
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: JXForms vs. Woody vs. KISS
Posted by Joerg Heinicke <jh...@virbus.de>.
On 27.10.2003 18:43, Oleg Dulin wrote:
> If the requirement is simply to show a form based on an XML file, let
> the user edit it, validate it, and then save the updates, then this can
> be easier done with a simple pipeline and I see no reason to deal with a
> yet another framework outside of Cocoon.
>
> Here is an example:
>
> - I have an XML document
> - I want to prepopulate an HTML form and present it to ther user based
> on the values in document
> - The user edits the form and clicks "Save"
> - The values are extracted out of POST parameters and saved back to the
> original document.
>
> First two points are trivial, because all one needs to do is transform
> original document into an HTML form.
>
> The remainder is tricky. I accomplished this by setting up an internal
> pipeline that uses RequestGenerator to create an XSL transform called
> "update.xsl" that applies the changes to the original document. To know
> which form values go to which places in the original document I used
> xpaths of the original elements and attributes as names for input
> fields. So, an XSL can be generated that applies the changes to the
> original doc and wraps it in something that SOurceWritingTransformer can
> understand.
>
> Is there a Cocoon solution that would let me easily set up a form that
> essentially edit XML w/o all of the aforementioned convoluted XSLTs ? To
> rephrase -- is there a way to map XML document onto an HTML form and
> then apply the changes back to the original document other than what I
> mentioned ? Would Chicoon or Woody be helpful ?
Of course! This is exactly what Woody can do for you. Have a look on the
binding sample which changes an XML file.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: JXForms vs. Woody vs. KISS
Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2003-10-28 at 10:40, joern turner wrote:
> Bruno Dumon wrote:
> > On Mon, 2003-10-27 at 22:24, joern turner wrote:
> >
> >>Oleg Dulin wrote:
> >
> > <snip/>
> >
> >>>The remainder is tricky. I accomplished this by setting up an internal
> >>>pipeline that uses RequestGenerator to create an XSL transform called
> >>>"update.xsl" that applies the changes to the original document. To know
> >>>which form values go to which places in the original document I used
> >>>xpaths of the original elements and attributes as names for input
> >>>fields. So, an XSL can be generated that applies the changes to the
> >>>original doc and wraps it in something that SOurceWritingTransformer can
> >>>understand.
> >>
> >>Chiba has a similar concept but without exposing xpathes of the instance
> >>(for security reasons). it uses a mapping between xpathes and internally
> >>generated ids.
> >
> >
> > You're pointing out two things here already people might not like about
> > Chiba:
> > - it assumes stateful operation (most of Woody also works stateless,
> > thus without keeping any state on the server, which can be useful in
> > some cases).
> ok, that's right. Chiba uses sessions. but that has nothing to do with
> the XForms functionality. we can also decide to move it to a stateless
> model if this might turn out to be more adequate. this is not an issue
> of the XForms engine but of the embedding application.
>
> but anyway, thanks for the point - maybe we should evaluate the idea to
> move to a stateless model.
Note that I didn't say stateless is better, in some cases it is (simple
forms combined with high traffic) and in others not.
>
> > - it uses meaningless id's as request parameter names
> well you don't have to. you *can* use e.g. the xpathes for parameter
> names but we considered this a bit too much transparency.
Agreed, and xpath expressions encoded as request parameter names look
very ugly. Anyhow, the point is that Woody doesn't have this problem at
all.
> this should be
> hidden from a user (even if a developer might like to see it). you just
> have the choice to expose as parameter name whatever you like by
> implementing an interface.
>
> but for us - we've been there and tried working with the xpathes for
> quite a while - security is obviously one reason to dislike it and it
> also bloats the output code with very long xpathes if you have a deeply
> nested instance data structure. this significantly increases the
> document size if you're editing medium size xml documents.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: JXForms vs. Woody vs. KISS
Posted by joern turner <jo...@web.de>.
Bruno Dumon wrote:
> On Mon, 2003-10-27 at 22:24, joern turner wrote:
>
>>Oleg Dulin wrote:
>
> <snip/>
>
>>>The remainder is tricky. I accomplished this by setting up an internal
>>>pipeline that uses RequestGenerator to create an XSL transform called
>>>"update.xsl" that applies the changes to the original document. To know
>>>which form values go to which places in the original document I used
>>>xpaths of the original elements and attributes as names for input
>>>fields. So, an XSL can be generated that applies the changes to the
>>>original doc and wraps it in something that SOurceWritingTransformer can
>>>understand.
>>
>>Chiba has a similar concept but without exposing xpathes of the instance
>>(for security reasons). it uses a mapping between xpathes and internally
>>generated ids.
>
>
> You're pointing out two things here already people might not like about
> Chiba:
> - it assumes stateful operation (most of Woody also works stateless,
> thus without keeping any state on the server, which can be useful in
> some cases).
ok, that's right. Chiba uses sessions. but that has nothing to do with
the XForms functionality. we can also decide to move it to a stateless
model if this might turn out to be more adequate. this is not an issue
of the XForms engine but of the embedding application.
but anyway, thanks for the point - maybe we should evaluate the idea to
move to a stateless model.
> - it uses meaningless id's as request parameter names
well you don't have to. you *can* use e.g. the xpathes for parameter
names but we considered this a bit too much transparency. this should be
hidden from a user (even if a developer might like to see it). you just
have the choice to expose as parameter name whatever you like by
implementing an interface.
but for us - we've been there and tried working with the xpathes for
quite a while - security is obviously one reason to dislike it and it
also bloats the output code with very long xpathes if you have a deeply
nested instance data structure. this significantly increases the
document size if you're editing medium size xml documents.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: JXForms vs. Woody vs. KISS
Posted by Bruno Dumon <br...@outerthought.org>.
On Mon, 2003-10-27 at 22:24, joern turner wrote:
> Oleg Dulin wrote:
<snip/>
> > The remainder is tricky. I accomplished this by setting up an internal
> > pipeline that uses RequestGenerator to create an XSL transform called
> > "update.xsl" that applies the changes to the original document. To know
> > which form values go to which places in the original document I used
> > xpaths of the original elements and attributes as names for input
> > fields. So, an XSL can be generated that applies the changes to the
> > original doc and wraps it in something that SOurceWritingTransformer can
> > understand.
> Chiba has a similar concept but without exposing xpathes of the instance
> (for security reasons). it uses a mapping between xpathes and internally
> generated ids.
You're pointing out two things here already people might not like about
Chiba:
- it assumes stateful operation (most of Woody also works stateless,
thus without keeping any state on the server, which can be useful in
some cases).
- it uses meaningless id's as request parameter names
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: JXForms vs. Woody vs. KISS
Posted by joern turner <jo...@web.de>.
Oleg Dulin wrote:
> > I've been using Chiba (and a pre-release version of Chicoon which
> integrates Chiba with Cocoon) quite extensively on a client project, but
> I have not had to write any server-side code yet. Some XSL transforms.
> Some declarative XML files which specify the form definition (using a
> mix of XForms and XHTML)...but no code.
> >
>
> Has Chicoon been updated to work with Cocoon 2.1 ? I noticed the
> released archive is from April, 2003 , older than Cocoon 2.1 .
>
> > So I'm a bit puzzled as to why you think Chiba XForms needs server
> side code added since this is contrary to my recent experiences.
>
>
> If the requirement is simply to show a form based on an XML file, let
> the user edit it, validate it, and then save the updates, then this can
> be easier done with a simple pipeline and I see no reason to deal with a
> yet another framework outside of Cocoon.
but didn't you mentioned standard conformance on your wishlist? sure,
there are many form frameworks out there with more or less functionality
or elegance but if you want to go for a standard you'll hardly escape
XForms. with xhtml2 it will be part of the standard and replace the html
forms.
>
> Here is an example:
>
> - I have an XML document
> - I want to prepopulate an HTML form and present it to ther user based
> on the values in document
> - The user edits the form and clicks "Save"
> - The values are extracted out of POST parameters and saved back to the
> original document.
this is exactly what Chiba does for you. and, of course you don't have
to care about the mapping of request to document and back - this is
handled automatically.
>
> First two points are trivial, because all one needs to do is transform
> original document into an HTML form.
>
> The remainder is tricky. I accomplished this by setting up an internal
> pipeline that uses RequestGenerator to create an XSL transform called
> "update.xsl" that applies the changes to the original document. To know
> which form values go to which places in the original document I used
> xpaths of the original elements and attributes as names for input
> fields. So, an XSL can be generated that applies the changes to the
> original doc and wraps it in something that SOurceWritingTransformer can
> understand.
Chiba has a similar concept but without exposing xpathes of the instance
(for security reasons). it uses a mapping between xpathes and internally
generated ids.
>
> Is there a Cocoon solution that would let me easily set up a form that
> essentially edit XML w/o all of the aforementioned convoluted XSLTs ? To
> rephrase -- is there a way to map XML document onto an HTML form and
> then apply the changes back to the original document other than what I
> mentioned ? Would Chicoon or Woody be helpful ?
Chicoon is soon available as a integration of the latest Chiba code
(0.9.2) and therefore providing all the additional functionality added
since Chiba 0.8.
Joern
>
> Kind regards,
> Oleg
>
>
>
> ---------------------------------------------------------------------
> 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: JXForms vs. Woody vs. KISS
Posted by Oleg Dulin <du...@olegdulin.com>.
> I've been using Chiba (and a pre-release version of Chicoon which
integrates Chiba with Cocoon) quite extensively on a client project, but
I have not had to write any server-side code yet. Some XSL transforms.
Some declarative XML files which specify the form definition (using a
mix of XForms and XHTML)...but no code.
>
Has Chicoon been updated to work with Cocoon 2.1 ? I noticed the
released archive is from April, 2003 , older than Cocoon 2.1 .
> So I'm a bit puzzled as to why you think Chiba XForms needs server
side code added since this is contrary to my recent experiences.
If the requirement is simply to show a form based on an XML file, let
the user edit it, validate it, and then save the updates, then this can
be easier done with a simple pipeline and I see no reason to deal with a
yet another framework outside of Cocoon.
Here is an example:
- I have an XML document
- I want to prepopulate an HTML form and present it to ther user based
on the values in document
- The user edits the form and clicks "Save"
- The values are extracted out of POST parameters and saved back to the
original document.
First two points are trivial, because all one needs to do is transform
original document into an HTML form.
The remainder is tricky. I accomplished this by setting up an internal
pipeline that uses RequestGenerator to create an XSL transform called
"update.xsl" that applies the changes to the original document. To know
which form values go to which places in the original document I used
xpaths of the original elements and attributes as names for input
fields. So, an XSL can be generated that applies the changes to the
original doc and wraps it in something that SOurceWritingTransformer can
understand.
Is there a Cocoon solution that would let me easily set up a form that
essentially edit XML w/o all of the aforementioned convoluted XSLTs ? To
rephrase -- is there a way to map XML document onto an HTML form and
then apply the changes back to the original document other than what I
mentioned ? Would Chicoon or Woody be helpful ?
Kind regards,
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: JXForms vs. Woody vs. KISS
Posted by Andrzej Jan Taramina <an...@chaeron.com>.
> Has Chicoon been updated to work with Cocoon 2.1 ? I noticed the
> released archive is from April, 2003 , older than Cocoon 2.1 .
There is a pre-release version of Chicoon that I have been working on that
works with Cocoon 2.1.2 and Chiba 0.9.2. I hope to be able to post it in a
week or so.
> If the requirement is simply to show a form based on an XML file, let
> the user edit it, validate it, and then save the updates, then this can
> be easier done with a simple pipeline and I see no reason to deal with a yet
> another framework outside of Cocoon.
That's exactly what I am doing with Cocoon, Chiba and Chicoon for my current
project, and I haven't written a line of code yet (XSL transforms not
included).
> Here is an example:
>
> - I have an XML document
> - I want to prepopulate an HTML form and present it to ther user based
> on the values in document
> - The user edits the form and clicks "Save"
> - The values are extracted out of POST parameters and saved back to the
> original document.
Exactly what I am doing. Actually, what I am doing is a bit more complicated
than your requirement.
> The remainder is tricky. I accomplished this by setting up an internal
> pipeline that uses RequestGenerator to create an XSL transform called
> "update.xsl" that applies the changes to the original document. To know
> which form values go to which places in the original document I used
> xpaths of the original elements and attributes as names for input
> fields. So, an XSL can be generated that applies the changes to the
> original doc and wraps it in something that SOurceWritingTransformer can
> understand.
It was easy with Chiba/Chicoon.
> Is there a Cocoon solution that would let me easily set up a form that
> essentially edit XML w/o all of the aforementioned convoluted XSLTs ? To
> rephrase -- is there a way to map XML document onto an HTML form and then
> apply the changes back to the original document other than what I mentioned ?
> Would Chicoon or Woody be helpful ?
Chicoon/Chiba does this admirably, and has the added advantage that it is
based on the XForms standard, with all the benefits that implies.
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: JXForms vs. Woody vs. KISS
Posted by Andrzej Jan Taramina <an...@chaeron.com>.
Oleg said:
> Another approach is http://sourceforge.net/projects/chiba which I have
> looked at briefly, but found the same flaw as with JXForms and Woody --
> a requirement that server side code is written. IMO, the amount of
> server side code should be minimized, which once again is possible for
> most simple flows using RequestGenerator,Form Validator and XSLT.
I've been using Chiba (and a pre-release version of Chicoon which integrates
Chiba with Cocoon) quite extensively on a client project, but I have not had
to write any server-side code yet. Some XSL transforms. Some declarative XML
files which specify the form definition (using a mix of XForms and
XHTML)...but no code.
So I'm a bit puzzled as to why you think Chiba XForms needs server side code
added since this is contrary to my recent experiences.
You might want to take a closer look at Chiba....and Chicoon.
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: JXForms vs. Woody vs. KISS
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Dimanche, 26 oct 2003, à 22:35 Europe/Zurich, Oleg Dulin a écrit :
> ...So, what is a Cocoon advocate to do ? I was able to achieve
> adequate form processing functionality using RequestGenerator,
> FormValidatorAction, XSLT, XSLT extensions in Java and very very very
> minimal XSP actions. The advantage is that no new XML grammar was
> involved except for XSP and the output of RequestGenerator, both of
> which are perfectly reasonable as they are very specific to their own
> very narrow "areas of expertise."...
I think part of the beauty of Cocoon is that it doesn't force you into
a specific way of doing things.
If the above works for you and matches your team's skills, why not?
OTOH, learning Woody will allow you to take advantage of the
community's progress, bug fixes, examples, documentation, etc., which
might bring a lot more to your team and will certainly make the initial
learning curve worth the effort.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org