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/ [EMAIL PROTECTED] [EMAIL PROTECTED]
