Hi Mark, This was just the clarification I needed.
Thanks Peter Lerche http://easyspeedy.com On Monday 29 March 2004 19:30, Mark Lundquist wrote: > On Mar 29, 2004, at 3:17 AM, Peter Lerche wrote: > > Hi, > > > > I need to have something clarified. > > I am migrating from jxForm to Woody but which Woody version should I > > use in a > > production environment. I know that it is under heavy development but > > I need > > it. > > > > cocoon.load("resource://org/apache/cocoon/woody/flow/javascript/ > > woody2.js") > > or > > cocoon.load("resource://org/apache/cocoon/woody/flow/javascript/v2/ > > Form.js") > > > > I have also read that Woody changes into Cocoon Forms > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg11802.html > > Hi, > > I've seen the other answers, but it seems like there might still be a > need for more clarification... > > (Joerg or someone please confirm/correct...) > > Woody vs. CForms > > • Cocoon Forms (CForms for short) is the new name for what was called > "Woody", and it's available in the CVS build of Cocoon which will > become the 2.1.5 release. > > • CForms isn't in 2.1.4; to get it, you need to build from CVS or a CVS > snapshot (either that or wait for 2.1.5). > > • However, the Woody block will still be included in 2.1.5 to smooth > the migration path, so that people can upgrade to 2.1.5 w/o being > forced to change all the Woody stuff to CForms just to get off the > ground (mostly you have a bunch of name changes to deal with, and > there's a script or something to automate the translation for you... > but for you that's not an issue, since you are coming from jxForm). > > • Since "Woody" in 2.1.5 is a back-compatibility feature, CForms I > think has begun to diverge away from it already. (I'm not sure I know > the technical definition of "deprecated" in Cocoon, but it wouldn't > surprise me if fixes start going into CForms that don't make it into > Woody...). > > • CForms, like Woody, is also a block (not part of the Cocoon core); > > v2 (woody.js) vs. "v1" (Form.js) > > • These are not versions of Woody/CForms per se. What they are: two > different treatments or approaches to integrating CForms/Woody with > flowscript (this includes dealing with continuations, the form > validation/redisplay loop, getting values into and out of the widgets, > etc.). They are really the flowscript API for CForms/Woody. > > • As the name suggests, "v2" represents revised thinking about > forms+flow. > > • (As you might have noticed, there's no "v1" anywhere in the naming of > what we are calling "v1"... v2 exists as a subdirectory (in the src > tree and in the samples directory) of the directories that contain the > "original stuff", a.k.a. "v1". > > • Both v2 and "v1" are available in both CForms and Woody. > > • Note, your whole application has to use either "v1" or v2. If you > have some flowscripts that try to load woody.js and others that try to > load Form.js, watch out... Bad Things Happen. > > > My takes: > > If you want to convert from jxForm now, use CForms if at all possible. > That means working against a CVS build of Cocoon. If you switch to > Woody now, you'll just be stuck on a legacy path, and eventually you'll > want/need to convert a second time later on. The other OK option would > be to wait until the 2.1.5 release to upgrade from jxForm (once again, > so that you can target CForms instead of Woody). > > Re: "v1 vs. V2", my suggestion would be to use v2. I've switched to v2 > for everything. Why wait until you run into something that you need v2 > for, and then have a whole bunch of stuff to switch over and a new way > to have to learn? Just learn the v2 way and go with it. > > I think most v1 flowscripts will work with v2 with minor modifications > (but the reverse is not true!) The main difference is that in v2 there > is no "bizdata" parameter to Form.showForm(). In v1, the widget tree > was attached to the bizdata object passed to cocoon.SendPageAndWait(). > In v2, the widget tree itself is passed as the bizdata, and you supply > any additional data (typically for JXTemplate) by attaching it to the > widget root as a property. For example: > > v1 Way: > > form.showForm ( > "URI/for/the/form/display/pipeline", > // bizdata > { > foo: something, > bar: whatever > } > ); > > v2 Way: > > var wid = form.getWidget; // I usually call this right after the > call > to the Form constructor; IIRC, the samples do it that way... > . > . > . > wid.foo = something; > wid.bar = whatever; > form.showForm ("URI/for/the/form/display/pipeline"); > > > Hope this helps, > mark -- Med venlig hilsen / Yours sincerely Peter Lerche EasySpeedy ApS _______________________________________ European Dedicated Server Hosting Extremely low prices, secure, and reliable Linux and BSD distributions only _______________________________________ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
