You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Tim Larson <ti...@yahoo.com> on 2004/01/12 22:42:28 UTC
[cforms] Selection and apply-templates
Just tossing a few ideas at the list before going home from work.
==========================================
=== A few possible selection semantics ===
(A)
if ((boolean)expression) ... then ...
(B)
if ((boolean)expression) ... then ... else ...
(C)
if ((boolean)expression_1) ... then ...
elseif ((boolean)expression_2) ...
(D)
if ((boolean)expression_1) ... then ...
elseif ((boolean)expression_2) ... else ...
(E)
// (Optional) Fall-through to contents of next case if
// there is no "break" statement in case that matched.
switch ((String|Int|etc.)expression) {
case value_1: ...
case value_2: ...
default: ...
}
(F)
// (Optional) Fall-through to contents of next case if
// there is no "break" statement in case that matched.
select_first_true_expression {
case ((boolean)expression_1): ...
case ((boolean)expression_2): ...
default: ...
}
(G)
select_all_true_expressions {
case ((boolean)expression_1): ...
case ((boolean)expression_2): ...
default: ...
}
===
The union model currently implements semantic (E), with a
string-valued expression and no fall-through logic.
The semantic (F), without fall-through logic, has been
discussed on this list as a possible alternative.
Lets pause to choose the selection of semantics that will
most naturally support simple forms, recursive forms, and
eventually multi-forms with multiple nested and overlapping
bindings and templates:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106965619705596&w=2
=========================================
=== Templates, Navigation, Evaluation ===
Separate navigation from evaluation and expression of values,
similar to how the binding currently operates.
Example adapting the "context" idea from the binding:
<wt:context select="some-repeater-id">
<wt:label/>
<wt:context select="rows">
<wt:context select="row">
<wt:context select="first-widget-id">
<wt:label/>
<wt:value/>
</wt:context>
<wt:context select="second-widget-id">
<wt:label/>
<wt:value/>
</wt:context>
</wt:context>
</wt:context>
<wt:context>
Same semantics as above, but more expressive syntax:
(This syntax allows some type checking to be performed.)
<wt:repeater id="some-repeater-id">
<wt:label/>
<wt:apply-templates id="rows"/>
<wt:rows>
<wt:row>
<wt:widget id="first-widget-id">
<wt:label/>
<wt:value/>
</wt:widget>
<wt:widget id="second-widget-id">
<wt:label/>
<wt:value/>
</wt:widget>
</wt:row>
</wt:rows>
</wt:repeater>
Allow model, binding, and template fragments to be
associated with each other. This leads to more concise
bindings and templates by borrowing the "apply-templates"
concept from XSL.
Progressively shorter template examples:
(A similar set of examples could be created
for bindings, using "apply-bindings".)
<wt:repeater id="some-repeater-id">
<wt:label/>
<wt:apply-templates id="rows"/>
<wt:rows>
<wt:row>
<wt:apply-templates select="first-widget-id"/>
<wt:apply-templates select="second-widget-id"/>
</wt:row>
</wt:rows>
</wt:repeater>
<wt:repeater id="some-repeater-id">
<wt:label/>
<wt:apply-templates select="rows"/>
</wt:repeater>
<wt:apply-templates select="some-repeater-id"/>
<wt:apply-templates select="form"/>
<!--
One more example: No explicit template file supplied.
This would cause cforms to implicitly "apply-templates"
the whole page into existence, without the need to
create a form-specific template file.
-->
========
More ideas waiting in line for later...
--Tim Larson
__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
Re: [cforms] Selection and apply-templates
Posted by Marc Portier <mp...@outerthought.org>.
Tim Larson wrote:
> Just tossing a few ideas at the list before going home from work.
>
> ==========================================
> === A few possible selection semantics ===
>
> (A)
> if ((boolean)expression) ... then ...
>
> (B)
> if ((boolean)expression) ... then ... else ...
>
> (C)
> if ((boolean)expression_1) ... then ...
> elseif ((boolean)expression_2) ...
>
> (D)
> if ((boolean)expression_1) ... then ...
> elseif ((boolean)expression_2) ... else ...
>
> (E)
> // (Optional) Fall-through to contents of next case if
> // there is no "break" statement in case that matched.
> switch ((String|Int|etc.)expression) {
> case value_1: ...
> case value_2: ...
> default: ...
> }
>
> (F)
> // (Optional) Fall-through to contents of next case if
> // there is no "break" statement in case that matched.
> select_first_true_expression {
> case ((boolean)expression_1): ...
> case ((boolean)expression_2): ...
> default: ...
> }
>
> (G)
> select_all_true_expressions {
> case ((boolean)expression_1): ...
> case ((boolean)expression_2): ...
> default: ...
> }
>
> ===
>
> The union model currently implements semantic (E), with a
> string-valued expression and no fall-through logic.
> The semantic (F), without fall-through logic, has been
> discussed on this list as a possible alternative.
>
I tend to lean over to (D)
I've never appreciated the fall-through concept of switch/case in C and
Java, it _breaks_ heavy with the 'least surprise' IMHO (vividly
remembering my first 'forgot-to-add-break'-bugs even if they are now
more then 15 years behind me, hm that sounds troumatic :-))
> Lets pause to choose the selection of semantics that will
> most naturally support simple forms, recursive forms, and
> eventually multi-forms with multiple nested and overlapping
> bindings and templates:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106965619705596&w=2
>
honestly: I'm not sure if we should try to solve every possible form use
case _inside_ the woody-models (specially multi-forms keeps being a
wizard-like thing and thus a better match for flow then for (ore
passive) form-models IMHO)
> =========================================
> === Templates, Navigation, Evaluation ===
>
> Separate navigation from evaluation and expression of values,
> similar to how the binding currently operates.
>
> Example adapting the "context" idea from the binding:
>
> <wt:context select="some-repeater-id">
> <wt:label/>
> <wt:context select="rows">
> <wt:context select="row">
> <wt:context select="first-widget-id">
> <wt:label/>
> <wt:value/>
> </wt:context>
> <wt:context select="second-widget-id">
> <wt:label/>
> <wt:value/>
> </wt:context>
> </wt:context>
> </wt:context>
> <wt:context>
>
> Same semantics as above, but more expressive syntax:
> (This syntax allows some type checking to be performed.)
>
> <wt:repeater id="some-repeater-id">
> <wt:label/>
> <wt:apply-templates id="rows"/>
> <wt:rows>
> <wt:row>
> <wt:widget id="first-widget-id">
> <wt:label/>
> <wt:value/>
> </wt:widget>
> <wt:widget id="second-widget-id">
> <wt:label/>
> <wt:value/>
> </wt:widget>
> </wt:row>
> </wt:rows>
> </wt:repeater>
>
> Allow model, binding, and template fragments to be
> associated with each other. This leads to more concise
> bindings and templates by borrowing the "apply-templates"
> concept from XSL.
>
> Progressively shorter template examples:
> (A similar set of examples could be created
> for bindings, using "apply-bindings".)
>
> <wt:repeater id="some-repeater-id">
> <wt:label/>
> <wt:apply-templates id="rows"/>
> <wt:rows>
> <wt:row>
> <wt:apply-templates select="first-widget-id"/>
> <wt:apply-templates select="second-widget-id"/>
> </wt:row>
> </wt:rows>
> </wt:repeater>
>
> <wt:repeater id="some-repeater-id">
> <wt:label/>
> <wt:apply-templates select="rows"/>
> </wt:repeater>
>
> <wt:apply-templates select="some-repeater-id"/>
>
> <wt:apply-templates select="form"/>
>
> <!--
> One more example: No explicit template file supplied.
> This would cause cforms to implicitly "apply-templates"
> the whole page into existence, without the need to
> create a form-specific template file.
> -->
>
hm, I might be missing something here, but I'm a bit -0
it makes no sense to have the template language lean back to XSLT like
constructs
the whole (original) reason for having a template language is that
people often struglle with the concepts and processing of xslt stylesheets
for people that don't have a problem with that I think the most natural
approach is to just use the woody-generator and provide a genuine XSLT
stylesheet
Have to admit I'm looking at this from 10000ft high, so not considering
the possible technical elegance, but purely the use and usability (so
all of this IMHO)
> ========
>
> More ideas waiting in line for later...
>
pls keep 'm coming!
> --Tim Larson
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
> http://hotjobs.sweepstakes.yahoo.com/signingbonus
>
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org