[ 
https://issues.apache.org/jira/browse/COCOON-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12706843#action_12706843
 ] 

Thomas ERNEST commented on COCOON-2137:
---------------------------------------

This is a very good job to have produced and provided this content. Bravo & 
Thank You.

1/ Nevertheless it seems that the "fd:pattern" element inside a "fd:patterns" 
element is authorized to have an attribute named "locale" according to 
http://cocoon.apache.org/2.1/userdocs/widgetconcepts/datatypes.html
On the same web page, it is written that it could be sevral "fd:pattern" element
s inside a same "fd:patterns" element.
To correct this two little mistakes you have to replace the line 738:
<xs:element ref="fd:pattern"/>
with :
<xs:element ref="fd:pattern" maxOccurs="unbounded"/>

AND

line 742 :
  <xs:element name="pattern" type="xs:string"/>
with :
  <xs:element name="pattern">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="xs:string">
          <xs:attribute name="locale">
            <!--+ this type try to represents all possible local values like 
lang-COUNTRY
                + It might be global to be use in other circumstances ?
                + It might be correct oder better coded.
                +-->
            <xs:simpleType>
              <xs:restriction base="xs:string">
                <xs:pattern value="[a-z]{2,3}\-[A-Z]{2,3}"/>
              </xs:restriction>
            </xs:simpleType>
          </xs:attribute>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>
Note : I have tried to provide a filter on localization values, but I'm not 
sure to consider about all possible localisation values... If somebody know a 
better way ? :)

2/ It was not possible to have "fd:failmessage" element inside a "fd:email" and 
a "fd:assert". According to the preceding web page, I have correct it for 
"fd:assert", but I'm no sure to have to correct it for "fd:email".
If required just add (inside email element (to find it search ' name="email" ' 
)) :
<xs:complexType>
  <xs:sequence>
    <xs:element minOccurs="0" ref="fd:failmessage"/>
  </xs:sequence>
</xs:complexType>

Finaly it is a very good job and I'm very happy to use it. Thank You.

++
Tom

> XSD Schemas for CForms Development
> ----------------------------------
>
>                 Key: COCOON-2137
>                 URL: https://issues.apache.org/jira/browse/COCOON-2137
>             Project: Cocoon
>          Issue Type: New Feature
>          Components: Blocks: Forms
>            Reporter: Gabriel Gruber
>            Priority: Minor
>         Attachments: clean-xsd-public.zip
>
>
> A common pitfall in developing cforms applications is the misuse of certain 
> cforms tags.
> A schema for the forms files (definition, binding, template) would greatly 
> help in writing forms code faster and more accurate and minimizing syntax 
> errors in the first place.
> I have started writing such schemas for the binding and definition files and 
> added notations out of the current (2.1.10) cforms documentation.  those 
> schemas are quite completet (well almost).
> I also added starting points for this schemas:
> - i18n transformer
> - jx template generator
> furthermore form template generator (and form instance) would be interesting. 
> the major problem with the template is that we are heavily mixing different 
> xml gramars here and state-of-the-art xml editors (like oxygen) have their 
> problems with providing auto-complete features here.
> the code-completion (assistance) feature for the form-definition and 
> form-binding works quite well. it also has the added benefit, that the 
> important bits of the cocoon forms docs are being displayed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to