cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From d...@cocoon.apache.org
Subject [Cocoon Wiki] Updated: WoodyScratchpad
Date Thu, 07 Oct 2004 16:03:38 GMT
   Date: 2004-10-07T09:03:38
   Editor: TimLarson <tim@keow.org>
   Wiki: Cocoon Wiki
   Page: WoodyScratchpad
   URL: http://wiki.apache.org/cocoon/WoodyScratchpad

   no comment

Change Log:

------------------------------------------------------------------------------
@@ -10,54 +10,54 @@
 
 Create a widget:[[BR]]
 (Note: This is unchanged from current Woody/CForms.)
-{{{
-
-  <wd:field id="field-a">
-    <!-- validation, etc. -->
-  </wd:field>
+{{{
+
+  <wd:field id="field-a">
+    <!-- validation, etc. -->
+  </wd:field>
 }}}
 
 Create a type:
-{{{
-  <wd:field defines="type-a">
-    <!-- validation, etc. -->
-  </wd:field>
+{{{
+  <wd:field defines="type-a">
+    <!-- validation, etc. -->
+  </wd:field>
 }}}
 
 Create a widget extending a type:
-{{{
-  <wd:field id="field-b" extends="type-a">
-    <!-- validation, etc. -->
-  </wd:field>
+{{{
+  <wd:field id="field-b" extends="type-a">
+    <!-- validation, etc. -->
+  </wd:field>
 }}}
 
 Create a type extending an existing type:
-{{{
-  <wd:field defines="type-b" extends="type-a">
-    <!-- validation, etc. -->
-  </wd:field>
+{{{
+  <wd:field defines="type-b" extends="type-a">
+    <!-- validation, etc. -->
+  </wd:field>
 }}}
 
 Create a widget *and* create a new type based on this widget definition:
-{{{
-  <wd:field id="field-c" defines="type-c">
-    <!-- validation, etc. -->
-  </wd:field>
+{{{
+  <wd:field id="field-c" defines="type-c">
+    <!-- validation, etc. -->
+  </wd:field>
 }}}
 
 Create a widget extending an existing type and create a new type based on this widget definition:
-{{{
-  <wd:field id="field-d" defines="type-d" extends="type-c">
-    <!-- validation, etc. -->
-  </wd:field>
+{{{
+  <wd:field id="field-d" defines="type-d" extends="type-c">
+    <!-- validation, etc. -->
+  </wd:field>
 }}}
 
 Create a widget extending a type without knowing what kind of widget it is(e.g. Field/Repeater/etc.):[[BR]]
 (Note the use of the generic "wd:widget" element.)
-{{{
-  <wd:widget id="widget-e" extends="type-c">
-    <!-- validation, etc. (limited to aspects that do not depend on the kind of widget
represented) -->
-  </wd:widget>
+{{{
+  <wd:widget id="widget-e" extends="type-c">
+    <!-- validation, etc. (limited to aspects that do not depend on the kind of widget
represented) -->
+  </wd:widget>
 }}}
 
 
@@ -66,25 +66,25 @@
 After types are implemented (as described above), we can add type repositories to Woody/Cforms.
 A repository could simply be a Source identified by URI and given a prefix for later reference.
 This will allow us to store widget type definitions anywhere that can be referenced as a
source:
-{{{
-  cocoon://some/path/and/filename
-  context://some/other/path/and/filename
-  cvs://...
-  webdav://...
+{{{
+  cocoon://some/path/and/filename
+  context://some/other/path/and/filename
+  cvs://...
+  webdav://...
 }}}
 
 Each repository would contain a set of type definitions.
 
 A form would bring the set of types into scope via an import statement:
-{{{
-  <wd:import prefix="my-types" src="cocoon://MyOwnTypes.xml"/>
+{{{
+  <wd:import prefix="my-types" src="cocoon://MyOwnTypes.xml"/>
 }}}
 
 Type repositories may be originally be implemented for different projects.
 When they are later used together there needs to be a way to resolve the naming conflicts
that arise.
 This is the purpose of the "prefix" attribute.
-{{{
-  <wd:widget id="my-widget" extends="my-types.some-type-definition"/>
+{{{
+  <wd:widget id="my-widget" extends="my-types.some-type-definition"/>
 }}}
 
 
@@ -97,14 +97,14 @@
 ''TimLarson: I will answer this in several steps. First, the "wd:import" is meant as direct
parallel to java's "import" statement. It should not create or insert any widget definitions
on its own, but just bring widget definition types into scope. The "extends" syntax defined
in the section above is used to actually create widget definitions based on the types defined
in the imported source. Second, imports are private to the form or repository that declares
them. If a repository imports another repository and wants to make its types available, it
will have to do "<wd:widget extends="nested-ns:type" defines"type"/> for each imported
type it wants to expose, and these would then become part of its own namespace. Internally
this will just add some references, not not waste memeory on unchanged copies of the definitions.
We could also introduce a mass syntax for this. Third, could you explain further about this
crawling need?''
 
 Given the fact that this starts looking like namespaces a lot, why not also adopt the syntax
of namespaces?
-{{{
-  <wd:any-scope wdns:my-types="cocoon://MyOwnTypes.xml"
-                wdns:other-types="cocoon://OtherTypes.xml"/>
+{{{
+  <wd:any-scope wdns:my-types="cocoon://MyOwnTypes.xml"
+                wdns:other-types="cocoon://OtherTypes.xml"/>
 }}}
 
 and reference some definition in there with: (preferig the colon over the dot)
-{{{
-  <wd:widget id="my-widget" extends="my-types:some-type-definition"/>
+{{{
+  <wd:widget id="my-widget" extends="my-types:some-type-definition"/>
 }}}
 
 
@@ -165,41 +165,58 @@
 Comments:
 Please add some comments.
 
-{{{
-Syntax:
-<wd:choice expr="some-string-valued-expression-producing-a-case-id">
-  <!-- Zero or more widget definitions -->
-  <!-- One or more cases -->
-  <wd:case id="some-case-id">
-    <!-- list of inline widget definitions and/or
-         references to the widgets defined above -->
-  </wd:case>
-  <!-- Optional default case specified by empty "id" attribute: -->
-  <wd:default>
-    <!-- list of inline widget definitions and/or
-         references to the widgets defined above -->
-  </wd:default>
-</wd:choice>
-
-Example:
-<wd:choice expr="some-expression">
-  <wd:field id="field-A".../>
-  <wd:repeater id="repeater-B" .../>
-  <wd:case id="case-0">
-    <wd:ref id="field-A"/>
-  </wd:case>
-  <wd:case id="case-1">
-    <wd:ref id="field-A"/>
-    <wd:ref id="repeater-A"/>
-  </wd:case>
-  <wd:case id="case-2">
-    <wd:booleanfield id="bool-C".../>
-  </wd:case>
-  <wd:case id="">
-    <wd:ref id="field-A"/>
-    <wd:field id="field-B".../>
-  </wd:case>
-</wd:choice>
+{{{
+Form model syntax:
+<wd:choice expr="some-string-valued-expression-producing-a-case-id">
+  <!-- Zero or more widget definitions -->
+  <!-- One or more cases -->
+  <wd:case id="some-case-id">
+    <!-- list of inline widget definitions and/or
+         references to the widgets defined above -->
+  </wd:case>
+  <!-- Optional default case specified by empty "id" attribute: -->
+  <wd:default>
+    <!-- list of inline widget definitions and/or
+         references to the widgets defined above -->
+  </wd:default>
+</wd:choice>
+
+Example:
+<wd:choice expr="some-expression">
+  <wd:field id="field-A".../>
+  <wd:repeater id="repeater-B" .../>
+  <wd:case id="case-0">
+    <wd:ref id="field-A"/>
+  </wd:case>
+  <wd:case id="case-1">
+    <wd:ref id="field-A"/>
+    <wd:ref id="repeater-A"/>
+  </wd:case>
+  <wd:case id="case-2">
+    <wd:booleanfield id="bool-C".../>
+  </wd:case>
+  <wd:case id="">
+    <wd:ref id="field-A"/>
+    <wd:field id="field-B".../>
+  </wd:case>
+</wd:choice>
+
+Form template syntax:
+<ft:choose path="path-to-some-data-widget">
+  <!-- Other non-template elements -->
+  <ft:when value="some-string-value">
+    <!-- Templates and other elements -->
+  </ft:when>
+  <!-- Other non-template elements -->
+  <ft:when value="some-other-string-value">
+    <!-- Templates and other elements -->
+  </ft:when>
+  <!-- Other non-template elements -->
+</ft:choose>
+(Minor thought: Should we allow other template elements where
+it is currently marked "Other non-template elements", to allow
+for easy conditional sequencing of conditional and non-conditional
+templates?)
 }}}
 
 === Expression on each case: ===
@@ -219,39 +236,39 @@
 
 ''tim comments: when/@test would be fine with me; should we also copy the word 'choose' from
xslt, instead of using 'choice'? 'choice' seems more declarative, but I would be ok with either
word.''
 
-{{{
-<wd:choice id="some-id">
-  <!-- Zero or more widget definitions -->
-  <!-- One or more cases -->
-  <wd:case id="some-case-id" expr="some-boolean-valued-expression>
-    <!-- list of inline widget definitions and/or
-         references to the widgets defined above -->
-  </wd:case>
-  <!-- Optionally, a default case can be given like this: -->
-  <wd:case id="another-case-id" expr="some-boolean-valued-expression-that-equals-true">
-    <!-- list of inline widget definitions and/or
-         references to the widgets defined above -->
-  </wd:case>
-</wd:choice>
-
-<wd:choice id="some-id">
-  <wd:field id="field-A".../>
-  <wd:repeater id="repeater-B" .../>
-  <wd:case id="case-0" expr="case-1-expression">
-    <wd:ref id="field-A"/>
-  </wd:case>
-  <wd:case id="case-1" expr="case-1-expression">
-    <wd:ref id="field-A"/>
-    <wd:ref id="repeater-A"/>
-  </wd:case>
-  <wd:case id="case-2" expr="case-2-expression">
-    <wd:booleanfield id="bool-C".../>
-  </wd:case>
-  <wd:case id="case-3" expr="true">
-    <wd:ref id="field-A"/>
-    <wd:field id="field-B".../>
-  </wd:case>
-</wd:choice>
+{{{
+<wd:choice id="some-id">
+  <!-- Zero or more widget definitions -->
+  <!-- One or more cases -->
+  <wd:case id="some-case-id" expr="some-boolean-valued-expression>
+    <!-- list of inline widget definitions and/or
+         references to the widgets defined above -->
+  </wd:case>
+  <!-- Optionally, a default case can be given like this: -->
+  <wd:case id="another-case-id" expr="some-boolean-valued-expression-that-equals-true">
+    <!-- list of inline widget definitions and/or
+         references to the widgets defined above -->
+  </wd:case>
+</wd:choice>
+
+<wd:choice id="some-id">
+  <wd:field id="field-A".../>
+  <wd:repeater id="repeater-B" .../>
+  <wd:case id="case-0" expr="case-1-expression">
+    <wd:ref id="field-A"/>
+  </wd:case>
+  <wd:case id="case-1" expr="case-1-expression">
+    <wd:ref id="field-A"/>
+    <wd:ref id="repeater-A"/>
+  </wd:case>
+  <wd:case id="case-2" expr="case-2-expression">
+    <wd:booleanfield id="bool-C".../>
+  </wd:case>
+  <wd:case id="case-3" expr="true">
+    <wd:ref id="field-A"/>
+    <wd:field id="field-B".../>
+  </wd:case>
+</wd:choice>
 }}}
 
 
@@ -328,19 +345,19 @@
 them via a pipeline where we do our XSLT or other processing.
 Note that none of this is coded yet, this is just a proposal:
 
-{{{
-  <mask id="make-stuff-editable">
-    <!-- ...and if it does not exist yet, create it. -->
-    <widget id="someWidget" exist="true" mode="edit"/>
-    <widget id="someOtherWidget" mode="edit"/>
-  </mask>
-  <mask id="and-now-change-it-again">
-    <widget id="someWidget" exist="true" mode="read"/>
-    <!-- Don't need "exist" because this widget is static. -->
-    <widget id="someOtherWidget" mode="hide"/>
-  </mask>
-  <mask id="remove-that-widget">
-    <!-- If widgets exists, delete it, otherwise do nothing -->
-    <widget id="somewidget" exist="false"/>
-  </mask>
+{{{
+  <mask id="make-stuff-editable">
+    <!-- ...and if it does not exist yet, create it. -->
+    <widget id="someWidget" exist="true" mode="edit"/>
+    <widget id="someOtherWidget" mode="edit"/>
+  </mask>
+  <mask id="and-now-change-it-again">
+    <widget id="someWidget" exist="true" mode="read"/>
+    <!-- Don't need "exist" because this widget is static. -->
+    <widget id="someOtherWidget" mode="hide"/>
+  </mask>
+  <mask id="remove-that-widget">
+    <!-- If widgets exists, delete it, otherwise do nothing -->
+    <widget id="somewidget" exist="false"/>
+  </mask>
 }}}

Mime
View raw message