Return-Path: 
 <dev-return-45740-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 2217 invoked by uid 500); 31 Jul 2003 17:15:24 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
list-post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 2197 invoked from network); 31 Jul 2003 17:15:23 -0000
Received: from gate3.stjude.org (192.55.208.13)
  by daedalus.apache.org with SMTP; 31 Jul 2003 17:15:23 -0000
Received: by gate3.stjude.org; (8.9.3/1.3/10May95) id MAA1574846;
 Thu, 31 Jul 2003 12:15:27 -0500 (CDT)
Received: from somewhere by smtpxd
Received: from somewhere by smtpxd
Message-ID: 
 <1E0CC447E59C974CA5C7160D2A2854EC0983AA@SJMEMXMB04.stjude.sjcrh.local>
From: "Hunsberger, Peter" <Peter.Hunsberger@stjude.org>
To: <dev@cocoon.apache.org>
Date: Thu, 31 Jul 2003 12:15:25 -0500
Subject: RE: Woody complex multipaged form
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-OriginalArrivalTime: 31 Jul 2003 17:15:25.0859 (UTC)
 FILETIME=[553A4730:01C35787]
content-class: urn:content-classes:message
Thread-Topic: Woody complex multipaged form
Thread-Index: AcNXhIyh67hNamK9SGGDgDrASsFSKQAAiIOQ
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Leszek Gawron <ouzo@wlkp.org> observes:

> On Thu, Jul 31, 2003 at 10:33:24AM -0600, Antonio Gallardo wrote:
> > Hi:
> >=20
> > Your idea is very important. And I think currently Woody=20
> does not have=20
> > something like that. I think the "picker" is in database=20
> applications=20
> > terminology is called "browser".
> >=20
> > It would be cool to integrate this idea.
> It would be the best if more than one woody form instance=20
> could be present in the session at the same time. This way=20
> you can separate the picker/browser implementation from the=20
> form main itself so it can be reused (for example in reports=20
> you reuse customer/product/representative picker a lot)
> 	LG

If you don't mind a restriction (don't know how big?) on what browsers
you can use the easiest way to do this is with <iframe>.  Each iframe
becomes a separate request back to Cocoon (and can have it's own model).
You can use this to implement "popup" widgets that don't require a
separate window if you're willing to use JavaScript.  For compatibility
you can then fall back to new windows for browsers that don't support
iframe.  But for any of this to work I think you need JavaScript?

We also use iframes to support types of composition of widgets, in
particular, forms within forms...