cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@STJUDE.ORG>
Subject RE: [CForms] <form enctype>
Date Thu, 05 Aug 2004 16:33:12 GMT
Joerg Heinicke <joerg.heinicke@gmx.de> writes:

> On 05.08.2004 17:39, Hunsberger, Peter wrote:
> 
> >>> I suppose it may depend on the XSLT processor, but if you didn't 
> >>> have to use the descendant axes this could be ok. Not knowing the 
> >>> structure of the Cforms templates I don't know if you can avoid 
> >>> descendant, but if it maps to a regular XHTML form then shouldn't 
> >>> the fi:upload element always be a fixed number of steps away from 
> >>> the context of this test? IE; allowing for some kind of 
> grouping a 
> >>> test like:
> >>> 
> >>> test="./fi:upload or ./group/fi:upload"
> >>> 
> >>> would avoid scanning the whole tree (and in particular the
> >>> contents of things like lists)...
> 
> >> Not possible. The stylesheets work on the templates, which can 
> >> contain any markup at any depth.
> 
> > IOW, you're saying that there's no fixed hierarchy to the 
> structure of 
> > cforms?
> 
> Exactly.
> 
> > Weird; since XHTML doesn't allow forms inside forms I can't see why 
> > this would be allowed?
> 
> On the one hand there is the cforms markup like structs and repeaters 
> that deepen the structure. On the other hand there is the (X)HTML 
> markup. I don't think of nested forms, but e.g. arbitrarily 
> nested tables.

Ahh, got ya.  That was my expectation with the comment about grouping,
just hadn't expected arbitrary levels of grouping.  You could code for
some limited number of possible levels of nesting, but if there are
other solutions (as it sounds like) then the issue is moot...


Mime
View raw message