Details

    • Type: Improvement
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: Trunk
    • Fix Version/s: 16.11.01, Upcoming Release
    • Component/s: framework
    • Labels:
      None

      Description

      I am trying to enable auto-completion when coding compound widget.
      My plan as follows:
      1. The following xsd will be modified to use namespace
      site-conf.xsd
      widget-form.xsd
      widget-screen.xsd
      widget-menu.xsd
      simple-methods.xsd
      For example, in site-conf.xsd, we add the following document level attribute

      xmlns="http://ofbiz.apache.org/sc" targetNamespace="http://ofbiz.apache.org/sc"
      

      2. Import the above schema into compound-widgets.xsd so that compound widgets use only one consolidated schema.

      3. Update ExampleCompoundWidgets.xml to use the new compound-widgets.xsd. For example

      <compound-widgets xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
              xmlns:sc="http://ofbiz.apache.org/sc"
              xmlns:m="http://ofbiz.apache.org/m"
              xmlns:s="http://ofbiz.apache.org/s"
              xmlns:f="http://ofbiz.apache.org/f"
              xmlns:sm="http://ofbiz.apache.org/sm"
              xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/compound-widgets.xsd">
      
          <site-conf>
              <sc:request-map uri="CompoundWidgets1">
                  <sc:security https="true" auth="true"/>
                  <sc:event type="simple" invoke="CompoundWidgetsFunc" path="component://example/widget/example/ExampleCompoundWidgets.xml"/>
                  <sc:response name="success" type="view" value="CompoundWidgets1"/>
              </sc:request-map>
              <sc:request-map uri="CompoundWidgets2"><sc:security https="true" auth="true"/><sc:response name="success" type="view" value="CompoundWidgets2"/></sc:request-map>
              
              <sc:view-map name="CompoundWidgets1" type="screen" page="component://example/widget/example/ExampleCompoundWidgets.xml#CompoundWidgets1"/>
              <sc:view-map name="CompoundWidgets2" type="screen" page="component://example/widget/example/ExampleCompoundWidgets.xml#CompoundWidgets2"/>
          </site-conf>
      ...... the rest
      

      4. Change java code to support reading xml with namespace (i.e. xml for compound widgets)

      5. Update the attributes at document level for rest of the controllers, menus, forms, simple methods and screens. Current setting will not work for schema with a namespace. For example, in controller.xml, we will change

      xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/site-conf.xsd”
      

      to

      xmlns="http://ofbiz.apache.org/sc” xsi:schemaLocation="http://ofbiz.apache.org/dtds/site-conf-ns.xsd”>
      
      1. OFBIZ-7061.patch
        473 kB
        James Yong
      2. OFBIZ-7061.patch
        457 kB
        Jacques Le Roux
      3. OFBIZ-7061.patch
        459 kB
        James Yong
      4. OFBIZ-7061-minilang-schema.patch
        55 kB
        James Yong

        Issue Links

          Activity

          Hide
          jacques.le.roux Jacques Le Roux added a comment - - edited

          Without answer from Jacopo for a month, I suppose it's OK and close this issue.

          Show
          jacques.le.roux Jacques Le Roux added a comment - - edited Without answer from Jacopo for a month, I suppose it's OK and close this issue.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Hi Jacopo,
          Please if you agree with my comment above close the issue, else explain why it's not sufficient for you, thanks!

          Show
          jacques.le.roux Jacques Le Roux added a comment - Hi Jacopo, Please if you agree with my comment above close the issue, else explain why it's not sufficient for you, thanks!
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Hi Jacopo Cappellato when you look at the dtd folders which contain the XSDs above you can see the history before and after the commits done for this issues. Is that not sufficient? I understand in the case of the widgets it mixes several files, but I think it's still usable, isn't ?

          Show
          jacques.le.roux Jacques Le Roux added a comment - Hi Jacopo Cappellato when you look at the dtd folders which contain the XSDs above you can see the history before and after the commits done for this issues. Is that not sufficient? I understand in the case of the widgets it mixes several files, but I think it's still usable, isn't ?
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Are concerned
          site-conf.xsd
          widget-form.xsd
          widget-screen.xsd
          widget-menu.xsd
          simple-methods.xsd

          Show
          jacques.le.roux Jacques Le Roux added a comment - Are concerned site-conf.xsd widget-form.xsd widget-screen.xsd widget-menu.xsd simple-methods.xsd
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Ah I see what you mean, a bit harder than what I thought. I just wanted to copy the current state under the reverted version. I'll check what we could miss then, if any and if important value (for instance I'll not muck around with trivial changes)

          Show
          jacques.le.roux Jacques Le Roux added a comment - Ah I see what you mean, a bit harder than what I thought. I just wanted to copy the current state under the reverted version. I'll check what we could miss then, if any and if important value (for instance I'll not muck around with trivial changes)
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Reopen to create a correct history

          Show
          jacques.le.roux Jacques Le Roux added a comment - Reopen to create a correct history
          Hide
          jacopoc Jacopo Cappellato added a comment -

          I just wanted to mention that you should also take care of including all the changes (if any) to the modified files that happened after the 9 commits (as part of other unrelated modifications).

          Show
          jacopoc Jacopo Cappellato added a comment - I just wanted to mention that you should also take care of including all the changes (if any) to the modified files that happened after the 9 commits (as part of other unrelated modifications).
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          I'm not quite sure of what you mean by

          changes done to the files after this ticket.

          Maybe you speak about the intermediate changes but I guess you know they will still be there in the intermediate commits for those possibly interested.

          So what is it? If you mean changes done after the last commit (the one after reverting the 9 ones, to restart and to put the current content in, in place) I can't see what we could miss.

          To summarize: we will revert to the situation which prevailed before changes done for this Jira, in order to create an history beginning before changes done for this Jira. The history will continue with all the functional changes done in the 9 commits but done once and directly on the initial files. Then I can't see what the problem could be.

          Agreed?

          Show
          jacques.le.roux Jacques Le Roux added a comment - I'm not quite sure of what you mean by changes done to the files after this ticket. Maybe you speak about the intermediate changes but I guess you know they will still be there in the intermediate commits for those possibly interested. So what is it? If you mean changes done after the last commit (the one after reverting the 9 ones, to restart and to put the current content in, in place) I can't see what we could miss. To summarize: we will revert to the situation which prevailed before changes done for this Jira, in order to create an history beginning before changes done for this Jira. The history will continue with all the functional changes done in the 9 commits but done once and directly on the initial files. Then I can't see what the problem could be. Agreed?
          Hide
          jacopoc Jacopo Cappellato added a comment -

          ok, I am fine with it.
          My only concern is that we may miss any changes done to the files after this ticket.
          If you are going to implement what you have proposed please consider the above.

          Show
          jacopoc Jacopo Cappellato added a comment - ok, I am fine with it. My only concern is that we may miss any changes done to the files after this ticket. If you are going to implement what you have proposed please consider the above.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Yes, and put the current files content then and commit again. If you don't need the between changes it should be OK.

          Show
          jacques.le.roux Jacques Le Roux added a comment - Yes, and put the current files content then and commit again. If you don't need the between changes it should be OK.
          Hide
          jacopoc Jacopo Cappellato added a comment -

          Are you suggesting to revert the 9 commits?

          Show
          jacopoc Jacopo Cappellato added a comment - Are you suggesting to revert the 9 commits?
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Are you looking for something specific between the start and the end of this task? If you don't we could revert to start and put end contents in.

          Show
          jacques.le.roux Jacques Le Roux added a comment - Are you looking for something specific between the start and the end of this task? If you don't we could revert to start and put end contents in.
          Hide
          jacopoc Jacopo Cappellato added a comment -

          It is annoying that because of the disordered way in which this task has been managed we have lost the history of changes to most of the OFBiz widget xsd files: thru a series of commits files like widget-screen.xsd have been copied and renamed (without using the svn copy command) then the originals have been deleted, then their copies have been renamed back to the original names.

          Show
          jacopoc Jacopo Cappellato added a comment - It is annoying that because of the disordered way in which this task has been managed we have lost the history of changes to most of the OFBiz widget xsd files: thru a series of commits files like widget-screen.xsd have been copied and renamed (without using the svn copy command) then the originals have been deleted, then their copies have been renamed back to the original names.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Thanks for the good work James

          Show
          jacques.le.roux Jacques Le Roux added a comment - Thanks for the good work James
          Hide
          jamesyong James Yong added a comment -

          Thanks Jacques Le Roux for the followup. Glad this jira issue is completed

          Show
          jamesyong James Yong added a comment - Thanks Jacques Le Roux for the followup. Glad this jira issue is completed
          Hide
          jacques.le.roux Jacques Le Roux added a comment - - edited

          It should be noted that changing the XML headers (aka namespaces declarations), as we did here, has an impact on custom projects if they use copies of OOTB XML files or use XML files generated by the create-component Ant target before the changes.

          Show
          jacques.le.roux Jacques Le Roux added a comment - - edited It should be noted that changing the XML headers (aka namespaces declarations), as we did here, has an impact on custom projects if they use copies of OOTB XML files or use XML files generated by the create-component Ant target before the changes.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Thanks James,

          We are finally done \o/

          Your last slightly modified patch is committed in trunk at revision: 1750647

          I found a small issue (not minilang related) in ExampleCompoundWidgets.xml

          -            <sm:log message="CompoundWidgetsFunc runs" sm:level="info"/>
          +            <sm:log message="CompoundWidgetsFunc runs" level="info"/>
          
          Show
          jacques.le.roux Jacques Le Roux added a comment - Thanks James, We are finally done \o/ Your last slightly modified patch is committed in trunk at revision: 1750647 I found a small issue (not minilang related) in ExampleCompoundWidgets.xml - <sm:log message= "CompoundWidgetsFunc runs" sm:level= "info" /> + <sm:log message= "CompoundWidgetsFunc runs" level= "info" />
          Hide
          jamesyong James Yong added a comment -

          Hi Jacques Le Roux,

          In the simple-method.xsd, can you find 2 occurence of

          <xs:element name="field" type="fieldType”/> 
          

          and change back to

          <xs:element ref="field”/>
          

          I mistaken them for attributes.

          Thanks!

          Show
          jamesyong James Yong added a comment - Hi Jacques Le Roux , In the simple-method.xsd, can you find 2 occurence of <xs:element name= "field" type="fieldType”/> and change back to <xs:element ref="field”/> I mistaken them for attributes. Thanks!
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Hi James,

          After reverting r1749938, and applying your patch, the tests pass and though when I manually run, for instance, the getCountryList or getAssociatedStateList services they work well, we have small issues when validating. They mostly concern the "<call-..." elements. The validation says

          cvc-type.3.1.1: Element 'field' is a simple type, so it cannot have attributes, excepting those whose namespace  name is identical to 'http://www.w3.org/2001/XMLSchema-instance' and whose [local name] is one of 'type',  'nil', 'schemaLocation' or 'noNamespaceSchemaLocation'. However, the attribute, 'field' was found.
          

          same for field attribute

          So we are almost ready, I hope with this fixed we can commit...

          Show
          jacques.le.roux Jacques Le Roux added a comment - Hi James, After reverting r1749938, and applying your patch, the tests pass and though when I manually run, for instance, the getCountryList or getAssociatedStateList services they work well, we have small issues when validating. They mostly concern the "<call-..." elements. The validation says cvc-type.3.1.1: Element 'field' is a simple type, so it cannot have attributes, excepting those whose namespace name is identical to 'http: //www.w3.org/2001/XMLSchema-instance' and whose [local name] is one of 'type', 'nil', 'schemaLocation' or 'noNamespaceSchemaLocation'. However, the attribute, 'field' was found. same for field attribute So we are almost ready, I hope with this fixed we can commit...
          Hide
          jamesyong James Yong added a comment -

          I have uploaded a patch for the simple methods schema.

          In general, the top level attributes are converted to simpleType, and attributeGroups to complexType.

          Changed the following attribute name
          1. ‘field’ to ‘fieldType’
          2. ‘level’ to ‘levelType'

          Denormalize the following attributeGroups
          1. attlist.compare
          2. attlist.compare-field

          Left attributeGroup ‘typeDefaultString’ unchanged, cos it doesn’t matter. Not in use, it seem.

          Show
          jamesyong James Yong added a comment - I have uploaded a patch for the simple methods schema. In general, the top level attributes are converted to simpleType, and attributeGroups to complexType. Changed the following attribute name 1. ‘field’ to ‘fieldType’ 2. ‘level’ to ‘levelType' Denormalize the following attributeGroups 1. attlist.compare 2. attlist.compare-field Left attributeGroup ‘typeDefaultString’ unchanged, cos it doesn’t matter. Not in use, it seem.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Fixed at revision: 1750050 .It was the only case like that (checked in Eclipse using validate, there are tons of other minor issues BTW)

          Show
          jacques.le.roux Jacques Le Roux added a comment - Fixed at revision: 1750050 .It was the only case like that (checked in Eclipse using validate, there are tons of other minor issues BTW)
          Hide
          swapnilmmane Swapnil M Mane added a comment -
          Show
          swapnilmmane Swapnil M Mane added a comment - Thanks Jacques Le Roux !
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Thanks Swapnil,

          Actually this was lost earlier in r1749488

          I will check that there are no other cases like that!

          Show
          jacques.le.roux Jacques Le Roux added a comment - Thanks Swapnil, Actually this was lost earlier in r1749488 I will check that there are no other cases like that!
          Hide
          swapnilmmane Swapnil M Mane added a comment -

          Dear Jacques Le Roux,

          Preferences screen under in 'My Portal' component is broken (https://localhost:8443/myportal/control/ManagePortalPages?parentPortalPageId=MYPORTAL_EMPLOYEE), it is because of missing

          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          

          in framework/common/widget/PortalPageForms.xml
          Might be it is missed under the commit at rev #1749634

          http://svn.apache.org/viewvc/ofbiz/trunk/framework/common/widget/PortalPageForms.xml?limit_changes=0&r1=1749634&r2=1749633&pathrev=1749634

          Thanks!

          Show
          swapnilmmane Swapnil M Mane added a comment - Dear Jacques Le Roux , Preferences screen under in 'My Portal' component is broken ( https://localhost:8443/myportal/control/ManagePortalPages?parentPortalPageId=MYPORTAL_EMPLOYEE ), it is because of missing xmlns:xsi= "http: //www.w3.org/2001/XMLSchema-instance" in framework/common/widget/PortalPageForms.xml Might be it is missed under the commit at rev #1749634 http://svn.apache.org/viewvc/ofbiz/trunk/framework/common/widget/PortalPageForms.xml?limit_changes=0&r1=1749634&r2=1749633&pathrev=1749634 Thanks!
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Done at revision: 1749938

          For myself: when we will do the 3rd more elegant option (no schema duplication), have been changed also:
          minilang-catalog.xml
          compound-widgets.xsd

          Show
          jacques.le.roux Jacques Le Roux added a comment - Done at revision: 1749938 For myself: when we will do the 3rd more elegant option (no schema duplication), have been changed also: minilang-catalog.xml compound-widgets.xsd
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Thanks James,

          I have anyway decided to go with 2nd in the meantime, I'll certainly do it today...

          Show
          jacques.le.roux Jacques Le Roux added a comment - Thanks James, I have anyway decided to go with 2nd in the meantime, I'll certainly do it today...
          Hide
          jamesyong James Yong added a comment -

          I am in favor of the 3rd one too, but can only look into it this weekend.

          Show
          jamesyong James Yong added a comment - I am in favor of the 3rd one too, but can only look into it this weekend.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          I don't like 1, 2 seems simple and 3 more elegant and brings consistency, but not that much because we have still a bunch of other XSDs which are not using namespaces.

          For the sake of simplicity and remembering, here are the necessary changes for option 2

          XSD

          Index: framework/minilang/dtd/simple-methods.xsd
          ===================================================================
          --- framework/minilang/dtd/simple-methods.xsd	(revision 1749654)
          +++ framework/minilang/dtd/simple-methods.xsd	(working copy)
          @@ -17,7 +17,7 @@
           specific language governing permissions and limitations
           under the License.
           -->
          -<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" xmlns="http://ofbiz.apache.org/Simple-Method" targetNamespace="http://ofbiz.apache.org/Simple-Method">
          +<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
           <!--
               ==================================================
               ========== The Simple Methods Section ==========
          

          An example for XML

          Index: applications/party/minilang/communication/CommunicationEventServices.xml
          ===================================================================
          --- applications/party/minilang/communication/CommunicationEventServices.xml	(revision 1749654)
          +++ applications/party/minilang/communication/CommunicationEventServices.xml	(working copy)
          @@ -19,9 +19,8 @@
           -->
          
           <simple-methods xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          -       xmlns="http://ofbiz.apache.org/Simple-Method" xsi:schemaLocation="http://ofbiz.apache.org/Simple-Method http://ofbiz.apache.org/dtds/simple-methods.xsd">
          +              xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/simple-methods.xsd">
          

          But then we still need to "duplicate" simple-methods.xsd in simple-methods-ns.xsd as we did, to get the simple-method namespace for compound-widgets

          So I'd try 3 first and if it's really too hard, then 2, at least temporary, other opinions?

          Show
          jacques.le.roux Jacques Le Roux added a comment - I don't like 1, 2 seems simple and 3 more elegant and brings consistency, but not that much because we have still a bunch of other XSDs which are not using namespaces. For the sake of simplicity and remembering, here are the necessary changes for option 2 XSD Index: framework/minilang/dtd/simple-methods.xsd =================================================================== --- framework/minilang/dtd/simple-methods.xsd (revision 1749654) +++ framework/minilang/dtd/simple-methods.xsd (working copy) @@ -17,7 +17,7 @@ specific language governing permissions and limitations under the License. --> -<xs:schema xmlns:xs= "http: //www.w3.org/2001/XMLSchema" elementFormDefault= "qualified" xmlns= "http://ofbiz.apache.org/Simple-Method" targetNamespace= "http://ofbiz.apache.org/Simple-Method" > +<xs:schema xmlns:xs= "http: //www.w3.org/2001/XMLSchema" elementFormDefault= "qualified" > <!-- ================================================== ========== The Simple Methods Section ========== An example for XML Index: applications/party/minilang/communication/CommunicationEventServices.xml =================================================================== --- applications/party/minilang/communication/CommunicationEventServices.xml (revision 1749654) +++ applications/party/minilang/communication/CommunicationEventServices.xml (working copy) @@ -19,9 +19,8 @@ --> <simple-methods xmlns:xsi= "http: //www.w3.org/2001/XMLSchema-instance" - xmlns= "http: //ofbiz.apache.org/Simple-Method" xsi:schemaLocation= "http://ofbiz.apache.org/Simple-Method http://ofbiz.apache.org/dtds/simple-methods.xsd" > + xsi:noNamespaceSchemaLocation= "http: //ofbiz.apache.org/dtds/simple-methods.xsd" > But then we still need to "duplicate" simple-methods.xsd in simple-methods-ns.xsd as we did, to get the simple-method namespace for compound-widgets So I'd try 3 first and if it's really too hard, then 2, at least temporary, other opinions?
          Hide
          jamesyong James Yong added a comment -

          A 3rd possible solution is to change simple-methods.xsd to avoid using top-level attributes. I am not sure if attribute groups are also affected.

          Show
          jamesyong James Yong added a comment - A 3rd possible solution is to change simple-methods.xsd to avoid using top-level attributes. I am not sure if attribute groups are also affected.
          Hide
          jamesyong James Yong added a comment -

          Hi Jacques Le Roux,

          Was also looking at this issue. The "field" attribute is actually a tag directly under the schema tag in the xsd. Such kind of attribute needs to be prefixed in the xml. For example, from ExampleCompoundWidgets.xml, we have on line 117

          <sm:log message="CompoundWidgetsFunc runs" sm:level="info"/>
          

          The 'level' attribute is also a direct tag under the schema tag in the xsd.

          So the proposed change from

          xsi:schemaLocation="http://ofbiz.apache.org/Simple-Method http://ofbiz.apache.org/dtds/simple-methods.xsd"
          

          to

          xsi:schemaLocation="http://ofbiz.apache.org/dtds/simple-methods.xsd"
          

          circumvents the prefix requirement, but introduce another problem

          I found that the proposed change will result in the default value not being recognised. For example, in

          <simple-method method-name="validateCustomerInfo" ...
          ...
          <validate-method method="isEmail">...
          

          the validate-method tag has a default value for the 'class' attribute.
          If we go to Party module and create a customer. The email field will fail after form submission because the default value for 'class' attribute is not found.

          I see there are now 2 possible solutions:
          1) Add the prefix to the affected attributes in the simple methods. But the change is great.
          2) Revert the simple method to use the original schema without namespace

          Show
          jamesyong James Yong added a comment - Hi Jacques Le Roux , Was also looking at this issue. The "field" attribute is actually a tag directly under the schema tag in the xsd. Such kind of attribute needs to be prefixed in the xml. For example, from ExampleCompoundWidgets.xml, we have on line 117 <sm:log message= "CompoundWidgetsFunc runs" sm:level= "info" /> The 'level' attribute is also a direct tag under the schema tag in the xsd. So the proposed change from xsi:schemaLocation= "http: //ofbiz.apache.org/Simple-Method http://ofbiz.apache.org/dtds/simple-methods.xsd" to xsi:schemaLocation= "http: //ofbiz.apache.org/dtds/simple-methods.xsd" circumvents the prefix requirement, but introduce another problem I found that the proposed change will result in the default value not being recognised. For example, in <simple-method method-name= "validateCustomerInfo" ... ... <validate-method method= "isEmail" >... the validate-method tag has a default value for the 'class' attribute. If we go to Party module and create a customer. The email field will fail after form submission because the default value for 'class' attribute is not found. I see there are now 2 possible solutions: 1) Add the prefix to the affected attributes in the simple methods. But the change is great. 2) Revert the simple method to use the original schema without namespace
          Hide
          jamesyong James Yong added a comment -

          hmm...i am not sure how autocompletion is affected; the feature is still working on my side.

          Show
          jamesyong James Yong added a comment - hmm...i am not sure how autocompletion is affected; the feature is still working on my side.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          And then we also lose the autocompletion. OK I must go, will see later...

          Show
          jacques.le.roux Jacques Le Roux added a comment - And then we also lose the autocompletion. OK I must go, will see later...
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Mmm, but why does it not exist for controller then? weird...

          Show
          jacques.le.roux Jacques Le Roux added a comment - Mmm, but why does it not exist for controller then? weird...
          Hide
          jacques.le.roux Jacques Le Roux added a comment - - edited

          Ha, maybe because of the prefix we had to put there for widget-common.xsd?

          <xs:include schemaLocation="http://ofbiz.apache.org/dtds/widget-common.xsd" />

          Hence the attributes are qualified?

          Show
          jacques.le.roux Jacques Le Roux added a comment - - edited Ha, maybe because of the prefix we had to put there for widget-common.xsd? <xs:include schemaLocation="http://ofbiz.apache.org/dtds/widget-common.xsd" /> Hence the attributes are qualified?
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Thanks, it works. But why do we need something different than in form and other XSDs?

          Show
          jacques.le.roux Jacques Le Roux added a comment - Thanks, it works. But why do we need something different than in form and other XSDs?
          Hide
          jamesyong James Yong added a comment -

          I got the error too after updating from SVN.

          Can you try replacing in the minilangs

          xsi:schemaLocation="http://ofbiz.apache.org/Simple-Method http://ofbiz.apache.org/dtds/simple-methods.xsd"
          

          with

          xsi:schemaLocation="http://ofbiz.apache.org/dtds/simple-methods.xsd"
          

          ?

          Show
          jamesyong James Yong added a comment - I got the error too after updating from SVN. Can you try replacing in the minilangs xsi:schemaLocation= "http: //ofbiz.apache.org/Simple-Method http://ofbiz.apache.org/dtds/simple-methods.xsd" with xsi:schemaLocation= "http: //ofbiz.apache.org/dtds/simple-methods.xsd" ?
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Reopening, BTW it's also in Eclipse but only in minilang files it seems.

          Show
          jacques.le.roux Jacques Le Roux added a comment - Reopening, BTW it's also in Eclipse but only in minilang files it seems.
          Hide
          jacques.le.roux Jacques Le Roux added a comment - - edited

          I confirm I reproduce locally with trunk HEAD after doing an "ant clean build start" and getting to a webapp (same catalog link than on demos)

          Show
          jacques.le.roux Jacques Le Roux added a comment - - edited I confirm I reproduce locally with trunk HEAD after doing an "ant clean build start" and getting to a webapp (same catalog link than on demos)
          Hide
          jamesyong James Yong added a comment -

          Hi Mohammad Kathawala,

          I am not able to reproduce the error message. Can you provide a url that I can try on?

          Regards,
          James

          Show
          jamesyong James Yong added a comment - Hi Mohammad Kathawala , I am not able to reproduce the error message. Can you provide a url that I can try on? Regards, James
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Thanks for report, checking...

          Show
          jacques.le.roux Jacques Le Roux added a comment - Thanks for report, checking...
          Hide
          Mohammad K Mohammad Kathawala added a comment - - edited

          Getting following or similar errors on console while going through any application.

          Error message: cvc-complex-type.3.2.2: Attribute 'field' is not allowed to appear in element 'set'.

          Show
          Mohammad K Mohammad Kathawala added a comment - - edited Getting following or similar errors on console while going through any application. Error message: cvc-complex-type.3.2.2: Attribute 'field' is not allowed to appear in element 'set'.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Thanks James,

          I did not spot it as well, we should indeed not have used targetNamespace (should only be used in schema) instead of xsi:schemaLocation. BTW all files were concerned, not only menu.

          Fixed at r1749634.

          Show
          jacques.le.roux Jacques Le Roux added a comment - Thanks James, I did not spot it as well, we should indeed not have used targetNamespace (should only be used in schema) instead of xsi:schemaLocation. BTW all files were concerned, not only menu. Fixed at r1749634.
          Hide
          jamesyong James Yong added a comment -

          'targetNamespace' should have been 'xsi:schemaLocation'.

          Sorry for not testing the previous code change.

          Show
          jamesyong James Yong added a comment - 'targetNamespace' should have been 'xsi:schemaLocation'. Sorry for not testing the previous code change.
          Hide
          jamesyong James Yong added a comment - - edited

          Hi Jacques Le Roux,

          There are problems in my previous code change proposal; I didn't test it
          For example in menu,

          Originally

          xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/widget-menu.xsd"
          to
          xmlns="http://ofbiz.apache.org/Widget-Menu" targetNamespace="http://ofbiz.apache.org/Widget-Menu http://ofbiz.apache.org/dtds/widget-menu-ns.xsd"
          

          But should be

          xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/widget-menu.xsd"
          to
          xmlns="http://ofbiz.apache.org/Widget-Menu" xsi:schemaLocation="http://ofbiz.apache.org/Widget-Menu http://ofbiz.apache.org/dtds/widget-menu.xsd"
          

          Note the change from 'targetNamespace' from 'xsi:schemaLocation'.

          The rest (e.g screen, form) should be the same, but I can only test it later.

          Regards,
          James

          Show
          jamesyong James Yong added a comment - - edited Hi Jacques Le Roux , There are problems in my previous code change proposal; I didn't test it For example in menu, Originally xsi:noNamespaceSchemaLocation= "http: //ofbiz.apache.org/dtds/widget-menu.xsd" to xmlns= "http: //ofbiz.apache.org/Widget-Menu" targetNamespace= "http://ofbiz.apache.org/Widget-Menu http://ofbiz.apache.org/dtds/widget-menu-ns.xsd" But should be xsi:noNamespaceSchemaLocation= "http: //ofbiz.apache.org/dtds/widget-menu.xsd" to xmlns= "http: //ofbiz.apache.org/Widget-Menu" xsi:schemaLocation= "http://ofbiz.apache.org/Widget-Menu http://ofbiz.apache.org/dtds/widget-menu.xsd" Note the change from 'targetNamespace' from 'xsi:schemaLocation'. The rest (e.g screen, form) should be the same, but I can only test it later. Regards, James
          Hide
          jamesyong James Yong added a comment -

          In ExampleCompoundWidgets.xml, 'compound-widget.xsd' should be 'compound-widgets.xsd'

          Show
          jamesyong James Yong added a comment - In ExampleCompoundWidgets.xml, 'compound-widget.xsd' should be 'compound-widgets.xsd'
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Website up to date at revision: 1749490.

          I wondered about removing simple-methods-v2.xsd and regions.xsd which are no longer used, and for a moment, but could be that old custom projects still need them. I will ask about it on dev ML and about all XSD files actually.

          Show
          jacques.le.roux Jacques Le Roux added a comment - Website up to date at revision: 1749490. I wondered about removing simple-methods-v2.xsd and regions.xsd which are no longer used, and for a moment, but could be that old custom projects still need them. I will ask about it on dev ML and about all XSD files actually.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Eventually done at revision: 1749489. I hope I did not break anything (should not) quite a large (but straighforward) set of changes

          Thanks James for your continued work on this!

          Show
          jacques.le.roux Jacques Le Roux added a comment - Eventually done at revision: 1749489. I hope I did not break anything (should not) quite a large (but straighforward) set of changes Thanks James for your continued work on this!
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          First step done at revision: 1749488.

          Show
          jacques.le.roux Jacques Le Roux added a comment - First step done at revision: 1749488.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          OK, I thought about something while working on this and especially widget-catalog.xml. Since we will get rid of the "old" xsd files in favour of the "-ns.xsd", we can rename the "-ns.xsd" using the old names. I'll do that in 2 steps in order to no miss anything.

          Show
          jacques.le.roux Jacques Le Roux added a comment - OK, I thought about something while working on this and especially widget-catalog.xml. Since we will get rid of the "old" xsd files in favour of the " -ns.xsd", we can rename the " -ns.xsd" using the old names. I'll do that in 2 steps in order to no miss anything.
          Hide
          jamesyong James Yong added a comment -
          Show
          jamesyong James Yong added a comment - Thanks Jacques Le Roux !
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          The files are committed in http://ofbiz.apache.org/ at revision: 1749415

          Show
          jacques.le.roux Jacques Le Roux added a comment - The files are committed in http://ofbiz.apache.org/ at revision: 1749415
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          I have actually the files ready for a while now. Just forgot to commit them after your comment from 01/Jun/16 17:52. I will check that tomorrow and close this issue, thanks for the reminder James!

          Show
          jacques.le.roux Jacques Le Roux added a comment - I have actually the files ready for a while now. Just forgot to commit them after your comment from 01/Jun/16 17:52. I will check that tomorrow and close this issue, thanks for the reminder James!
          Hide
          jamesyong James Yong added a comment - - edited

          Assuming the above namespace schemas are made available, we can change

          xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/site-conf.xsd"
          to
          xmlns="http://ofbiz.apache.org/Site-Conf" targetNamespace="http://ofbiz.apache.org/Site-Conf http://ofbiz.apache.org/dtds/site-conf-ns.xsd"
          
          xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/simple-methods.xsd"
          to
          xmlns="http://ofbiz.apache.org/Simple-Method" targetNamespace="http://ofbiz.apache.org/Simple-Method http://ofbiz.apache.org/dtds/simple-methods-ns.xsd"
          
          xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/widget-screen.xsd"
          to
          xmlns="http://ofbiz.apache.org/Widget-Screen" targetNamespace="http://ofbiz.apache.org/Widget-Screen http://ofbiz.apache.org/dtds/widget-screen-ns.xsd"
          
          xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/widget-form.xsd"
          to
          xmlns="http://ofbiz.apache.org/Widget-Form" targetNamespace="http://ofbiz.apache.org/Widget-Form http://ofbiz.apache.org/dtds/widget-form-ns.xsd"
          
          xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/widget-menu.xsd"
          to
          xmlns="http://ofbiz.apache.org/Widget-Menu" targetNamespace="http://ofbiz.apache.org/Widget-Menu http://ofbiz.apache.org/dtds/widget-menu-ns.xsd"
          
          xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/widget-tree.xsd"
          to
          xmlns="http://ofbiz.apache.org/Widget-Tree" targetNamespace="http://ofbiz.apache.org/Widget-Tree http://ofbiz.apache.org/dtds/widget-tree-ns.xsd"
          
          Show
          jamesyong James Yong added a comment - - edited Assuming the above namespace schemas are made available, we can change xsi:noNamespaceSchemaLocation= "http: //ofbiz.apache.org/dtds/site-conf.xsd" to xmlns= "http: //ofbiz.apache.org/Site-Conf" targetNamespace= "http://ofbiz.apache.org/Site-Conf http://ofbiz.apache.org/dtds/site-conf-ns.xsd" xsi:noNamespaceSchemaLocation= "http: //ofbiz.apache.org/dtds/simple-methods.xsd" to xmlns= "http: //ofbiz.apache.org/Simple-Method" targetNamespace= "http://ofbiz.apache.org/Simple-Method http://ofbiz.apache.org/dtds/simple-methods-ns.xsd" xsi:noNamespaceSchemaLocation= "http: //ofbiz.apache.org/dtds/widget-screen.xsd" to xmlns= "http: //ofbiz.apache.org/Widget-Screen" targetNamespace= "http://ofbiz.apache.org/Widget-Screen http://ofbiz.apache.org/dtds/widget-screen-ns.xsd" xsi:noNamespaceSchemaLocation= "http: //ofbiz.apache.org/dtds/widget-form.xsd" to xmlns= "http: //ofbiz.apache.org/Widget-Form" targetNamespace= "http://ofbiz.apache.org/Widget-Form http://ofbiz.apache.org/dtds/widget-form-ns.xsd" xsi:noNamespaceSchemaLocation= "http: //ofbiz.apache.org/dtds/widget-menu.xsd" to xmlns= "http: //ofbiz.apache.org/Widget-Menu" targetNamespace= "http://ofbiz.apache.org/Widget-Menu http://ofbiz.apache.org/dtds/widget-menu-ns.xsd" xsi:noNamespaceSchemaLocation= "http: //ofbiz.apache.org/dtds/widget-tree.xsd" to xmlns= "http: //ofbiz.apache.org/Widget-Tree" targetNamespace= "http://ofbiz.apache.org/Widget-Tree http://ofbiz.apache.org/dtds/widget-tree-ns.xsd"
          Show
          jamesyong James Yong added a comment - To make the change at step 5 easier, we can make the namespace schemas be accessible from a public URL. Examples: http://ofbiz.apache.org/dtds/simple-methods-ns.xsd http://ofbiz.apache.org/dtds/site-conf-ns.xsd http://ofbiz.apache.org/dtds/widget-form-ns.xsd http://ofbiz.apache.org/dtds/widget-menu-ns.xsd http://ofbiz.apache.org/dtds/widget-screen-ns.xsd http://ofbiz.apache.org/dtds/widget-tree-ns.xsd
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Thanks James!

          Show
          jacques.le.roux Jacques Le Roux added a comment - Thanks James!
          Hide
          jamesyong James Yong added a comment - - edited

          Some clarifications:
          1. For controller.xml files, we do something like the following:
          Change

          xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/site-conf.xsd"
          

          to

          xmlns="http://ofbiz.apache.org/Site-Conf" targetNamespace="http://ofbiz.apache.org/Site-Conf ../../../../../framework/webapp/dtd/site-conf-ns.xsd">
          

          2. This file location can be changed from relative path to a url if it exists

          ../../../../../framework/webapp/dtd/site-conf-ns.xsd
          

          3. Existing custom projects are using the noNamespaceSchemaLocation and can choose not to use schema with namespace.

          Show
          jamesyong James Yong added a comment - - edited Some clarifications: 1. For controller.xml files, we do something like the following: Change xsi:noNamespaceSchemaLocation= "http: //ofbiz.apache.org/dtds/site-conf.xsd" to xmlns= "http: //ofbiz.apache.org/Site-Conf" targetNamespace= "http://ofbiz.apache.org/Site-Conf ../../../../../framework/webapp/dtd/site-conf-ns.xsd" > 2. This file location can be changed from relative path to a url if it exists ../../../../../framework/webapp/dtd/site-conf-ns.xsd 3. Existing custom projects are using the noNamespaceSchemaLocation and can choose not to use schema with namespace.
          Hide
          jamesyong James Yong added a comment -

          I am fine if updating the root attributes is overwhelming. Whether we update the root attributes or not, there is no need to use prefixes in existing (non-compound) xml files.

          Show
          jamesyong James Yong added a comment - I am fine if updating the root attributes is overwhelming. Whether we update the root attributes or not, there is no need to use prefixes in existing (non-compound) xml files.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          I finally decided to not ask. Having to put namespaces prefixes everywhere is overwhelming. If someone thinks otherwise please chime in...

          Show
          jacques.le.roux Jacques Le Roux added a comment - I finally decided to not ask. Having to put namespaces prefixes everywhere is overwhelming. If someone thinks otherwise please chime in...
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          I will ask opinions on the dev ML...

          Show
          jacques.le.roux Jacques Le Roux added a comment - I will ask opinions on the dev ML...
          Hide
          jacques.le.roux Jacques Le Roux added a comment - - edited

          Thanks James,

          Your patch is in trunk at r1746302

          Good work (but the tabs ), I simply replaced tabs by spaces in Java files and removed this commented out line

            <compound-widgets xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/compound-widgets.xsd">
            

          in ExampleCompoundWidgets.xml

          I mentionned that we decided to duplicate the simple-methods.xsd rather than updating all concerned files. Else we would have to update the attributes at document level for rest of the controllers, menus, forms, simple methods and screens. For example, in controller.xml, we would have to change

            xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/site-conf.xsd"
            

          to

            xmlns="http://ofbiz.apache.org/sc" xsi:schemaLocation="http://ofbiz.apache.org/dtds/site-conf-ns.xsd">
            

          But especially we would have to use the same syntax with namespaces prefixes than in ExampleCompoundWidgets.xml (see example above). This can be discussed because with auto-completion it's not a big deal, but could be overwhelming for existing custom projects...

          Show
          jacques.le.roux Jacques Le Roux added a comment - - edited Thanks James, Your patch is in trunk at r1746302 Good work (but the tabs ), I simply replaced tabs by spaces in Java files and removed this commented out line <compound-widgets xmlns:xsi= "http: //www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation= "http://ofbiz.apache.org/dtds/compound-widgets.xsd" > in ExampleCompoundWidgets.xml I mentionned that we decided to duplicate the simple-methods.xsd rather than updating all concerned files. Else we would have to update the attributes at document level for rest of the controllers, menus, forms, simple methods and screens. For example, in controller.xml, we would have to change xsi:noNamespaceSchemaLocation= "http: //ofbiz.apache.org/dtds/site-conf.xsd" to xmlns= "http: //ofbiz.apache.org/sc" xsi:schemaLocation= "http://ofbiz.apache.org/dtds/site-conf-ns.xsd" > But especially we would have to use the same syntax with namespaces prefixes than in ExampleCompoundWidgets.xml (see example above). This can be discussed because with auto-completion it's not a big deal, but could be overwhelming for existing custom projects...
          Hide
          jamesyong James Yong added a comment -

          Sorry, I missed your patch after submitting again.

          Show
          jamesyong James Yong added a comment - Sorry, I missed your patch after submitting again.
          Hide
          jamesyong James Yong added a comment -

          Thanks for the feedback, Jacques Le Roux]. Here is an updated patch to constrain autocompletion.

          Show
          jamesyong James Yong added a comment - Thanks for the feedback, Jacques Le Roux ]. Here is an updated patch to constrain autocompletion.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Hi James,

          Here is your patch w/o tabs in Java files, looks good and works well

          Do you think it would be possible to constrain in autocompletion to the relevant elements? I mean for instance when in form you are proposed elements from controller, etc.

          Show
          jacques.le.roux Jacques Le Roux added a comment - Hi James, Here is your patch w/o tabs in Java files, looks good and works well Do you think it would be possible to constrain in autocompletion to the relevant elements? I mean for instance when in form you are proposed elements from controller, etc.
          Hide
          jamesyong James Yong added a comment -

          Note that for the given patch, the schema location at compound-widgets.xsd is relative to the project for testing purposes. Also the same for ExampleCompoundWidgets.xml

          Show
          jamesyong James Yong added a comment - Note that for the given patch, the schema location at compound-widgets.xsd is relative to the project for testing purposes. Also the same for ExampleCompoundWidgets.xml
          Hide
          jamesyong James Yong added a comment -

          Hi Jacques Le Roux,
          I agree with your points regarding the naming of the targetNamespace. Will also leave out step 5.

          Show
          jamesyong James Yong added a comment - Hi Jacques Le Roux , I agree with your points regarding the naming of the targetNamespace. Will also leave out step 5.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          I was not familiar with targetNamespace attribute, so I read https://www.liquid-technologies.com/xml-schema-tutorial/xsd-namespaces and http://www.w3schools.com/xml/el_schema.asp
          Since targetNamespaces values are just names why not use (eg)

          targetNamespace="http://ofbiz.apache.org/site-conf.xsd"
          

          instead of

          targetNamespace="http://ofbiz.apache.org/sc"
          

          ? This would be clearer. Is there something blocking this possibility (recursivity or/and xmlns value)? We could keep the shorcut for the xmlns prefixes.

          This said, it does not change your question about step 5, and I'm more to have it optional (ie separate copies of the schemas at step 1). Then of course we would use (eg)

          targetNamespace="http://ofbiz.apache.org/site-conf.xsd"
          

          for the current files, and

          targetNamespace="http://ofbiz.apache.org/sc"
          

          for the modified copy

          I have though still to see how this would affect autocompletion, notably using catalogs, but that seems not to be a problem.

          Show
          jacques.le.roux Jacques Le Roux added a comment - I was not familiar with targetNamespace attribute, so I read https://www.liquid-technologies.com/xml-schema-tutorial/xsd-namespaces and http://www.w3schools.com/xml/el_schema.asp Since targetNamespaces values are just names why not use (eg) targetNamespace= "http: //ofbiz.apache.org/site-conf.xsd" instead of targetNamespace= "http: //ofbiz.apache.org/sc" ? This would be clearer. Is there something blocking this possibility (recursivity or/and xmlns value)? We could keep the shorcut for the xmlns prefixes. This said, it does not change your question about step 5, and I'm more to have it optional (ie separate copies of the schemas at step 1). Then of course we would use (eg) targetNamespace= "http: //ofbiz.apache.org/site-conf.xsd" for the current files, and targetNamespace= "http: //ofbiz.apache.org/sc" for the modified copy I have though still to see how this would affect autocompletion, notably using catalogs, but that seems not to be a problem.
          Hide
          jamesyong James Yong added a comment -

          Step 5 can be optional. If step 5 is not implemented, we will create separate copies of the schemas at step 1. So existing schemas will not be modified.

          What do you think?

          Show
          jamesyong James Yong added a comment - Step 5 can be optional. If step 5 is not implemented, we will create separate copies of the schemas at step 1. So existing schemas will not be modified. What do you think?

            People

            • Assignee:
              jacques.le.roux Jacques Le Roux
              Reporter:
              jamesyong James Yong
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development