3 Replies Latest reply on Feb 18, 2011 8:54 AM by kcbabo

    configuration schemas

    kcbabo

      I was just walking through the example for M1 and I think it would provide a nice usability bump if we had the configuration schemas available when the user edits the switchyard.xml.  For M1, the only bit a user is going to add is:

       

      <service name="OrderService" promote="OrderService">

             <soap:binding.soap>

                 <soap:serverPort>18001</soap:serverPort>

                 <soap:wsdl>wsdl/OrderService.wsdl</soap:wsdl>

             </soap:binding.soap>

          </service>

       

      Or some approximation thereof.  Since the user is going to have to type this out until we get visual tooling on deck, the very least we could do is provide a sensible autocomplete.  IINM, Eclipse will help with this if we have the schemas declared in the configuration document with a pointer to their location (xsi:schemaLocation).  With the schemas available to the project, the user should be able to CTRL+Space through the various elements and select appropriate attributes from a drop-down.  At least, that's how I remember it working. :-)


      Thoughts?

        • 1. configuration schemas
          dward

          I'm one step ahead of ya'. As part of the work for SWITCHYARD-79, I created a switchyard-v1.xsd.  Yesterday.   I will most likely resolve that jira and push later today.

          • 2. Re: configuration schemas
            mageshbk

            David, yes the main switchyard schema is needed. I am another step ahead of you, the soap-binding-1.0.xsd is already pushed . Will the main schema include the soap schema?

             

            soap-binding-1.0_schema.png

            • 3. configuration schemas
              kcbabo

              The main configuration xsd should not explicitly reference any component xsds.  The is that implementations and bindings are pluggable, so as long as a binding.soap, implementation.bean, etc. extend their base counterparts (sca:binding and sca:implementation for now), then we are good to go.


              Speaking of which, binding.soap should extend sca:binding. ;-)