Yeah; this was my second "wow" moment... coming after the first one when I realised the awesome potential of XML... and both moments have kept on echoing with new discoveries and insights ever since.
[goes all misty-eyed for a moment. dabs with virtual hanky.] >>> [EMAIL PROTECTED] 2005/03/10 01:24:20 PM >>> The first time you realise that any of your XML files can be modified through a pipeline, there is a sort of wow moment as the true flexibility of cocoon starts to sink in. Ben Pope Derek Hohls wrote: > Arsen > > No, the form definitions are not necessarily fixed files, > as I tried to say below... they are "XML streams" > which can as readily come from a pipeline output > as from a fixed file. The form processing pipeline is > a different one from the "form definition creation" > pipeline - and *this* pipeline can readily use cinclude. > > Derek > > >>> [EMAIL PROTECTED] 2005/03/10 12:51:28 PM >>> > Thanks for quick answer, but how about DEF files? > DEF file is used by Cocoon's Form processor without ANY > transformations.... So, I can't use CINLUDE within fomr > definition file as I can't specify cinlude transformation in > sitemap for that module. > > On Thu, 2005-03-10 at 12:45 +0200, Derek Hohls wrote: > > Arsen > > > > >From a Cocoon POV this is not that difficult... you > > need to think about the form binding not as "a file" per se > but as a > > Cocoon "source"; in other words, the result of a pipeline process. > > > > Think about the components / sections of your forms: > > e.g. one might be: > > > > <fb:value id="birthday" path="birthday"> > > <fd:convertor datatype="date" type="formatting"> > > <fd:patterns> > > <fd:pattern>yyyy-MM-dd</fd:pattern> > > </fd:patterns> > > </fd:convertor> > > </fb:value> > > > > another: > > > > <fb:value id="email" path="email" direction="load"/> > > > > and a third: > > <fb:value id="number" path="number/@value"> > > <fd:convertor datatype="integer"/> > > </fb:value> > > > > Now each of these could, for example, reside in a different source > > file and be assembled, via a "master" file, for each form, > via a set > > of cincludes: > > > > <cinclude:include src="cocoon:/form-partA" /> > > <cinclude:include src="cocoon:/form-partB" /> > > > > or, in another form master file: > > > > <cinclude:include src="cocoon:/form-partB" /> > > <cinclude:include src="cocoon:/form-partC" /> > > > > (where there is a corresponding pipeline match for > > the "form-*" to retrieve all the precreated fragments.) > > > > You could, of course, make it more complex, and > > have the retrieval pipeline doing further transforms > > to "customize" each fragment for a particular form... > > > > HTH > > Derek > > > > > > >>> [EMAIL PROTECTED] 2005/03/10 12:03:02 PM >>> > > My question was how to INCLUDE some fields to form definition file > > from another form definition file. I'm not interested in RE-USING > > whole file. > > I know that's possible :) > > > > On Thu, 2005-03-10 at 11:31 +0200, Arsen A. Gutsal wrote: > > > Hello List. > > > > > > I have the problem. I have 2 forms which uses almost same fields. > > > Can I re-use form definition/binding files? It seems I can > template > > > items by using cinclude, xinclude, but what about def/bind? > > > > -- > Sincerely, > Arsen A. Gutsal > SOFTSKY Ltd CEO/Executive > SOFTSKY - Cost effective Software Development > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
