2 Replies Latest reply on Dec 19, 2013 3:57 AM by sebi2706

    Re: [forge-dev] [aerogear-dev] Aerogear.js for CRUD

    burrsutter

      It sounds like, at a minimum, we have a bug in the Forge scaffolding to support Aerogear.js

       

      My next concern would be that since this "feature" was introduced with jQuery 1.9, it could be that a LOT of the world's REST endpoints are no longer POST compatible with Aerogear.js, nothing to be done about that except to document it well for Aerogear.js when the time to promote it heavily comes up.

       

      Aerogear.js doc issues also include confusion of datamanager/store (getting started guide is not clear for when those are needed) and the seemingly missing docs for Pipe.  Plus, the first example seen by the end-user should include the use of iteration through the results, not an underscore template which hides some of the details.

       

       

       

      On Dec 18, 2013, at 10:47 AM, Karel Piwko <kpiwko@redhat.com> wrote:

       

      To my understanding, HTTP 201 should always return created entity and its

      content should be based on Content-Type header field.

       

      See http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

       

      On Mon, 16 Dec 2013 16:25:53 -0500 (EST)

      Vineet Reynolds Pereira <vpereira@redhat.com> wrote:

       

      >> It would be better to treat this as a flag to be enabled during REST resource

      >> scaffolding. It would allow users to choose how the resource behaves -

      >> * send a 201 response with Location header,

      >> * send a 201 response with Location header and also a response entity.

      >>

      _______________________________________________

      aerogear-dev mailing list

      aerogear-dev@lists.jboss.org

      https://lists.jboss.org/mailman/listinfo/aerogear-dev

       

       

      _______________________________________________

      forge-dev mailing list

      forge-dev@lists.jboss.org

      https://lists.jboss.org/mailman/listinfo/forge-dev

       

        • 1. Re: [forge-dev] [aerogear-dev] Aerogear.js for CRUD
          lincolnthree

          I'm a little confused. Is this a bug in the Forge scaffolding, or a new

          requirement because of the upgrade to jQuery 1.9 in the AeroGear client?

          The Forge scaffolding seems to work fine. Is this something that prevents

          the current forge scaffolding or REST endpoints from working correctly, or

          only when paired with something from Aerogear? Is this something that

          exists and can be tried? Just curious because I'd like to know if we broke

          something, or missed a requirement.

           

           

          On Wed, Dec 18, 2013 at 10:54 AM, Burr Sutter <bsutter@redhat.com> wrote:

           

          It sounds like, at a minimum, we have a bug in the Forge scaffolding to

          support Aerogear.js

           

          My next concern would be that since this "feature" was introduced with

          jQuery 1.9, it could be that a LOT of the world's REST endpoints are no

          longer POST compatible with Aerogear.js, nothing to be done about that

          except to document it well for Aerogear.js when the time to promote it

          heavily comes up.

           

          Aerogear.js doc issues also include confusion of datamanager/store

          (getting started guide is not clear for when those are needed) and the

          seemingly missing docs for Pipe.  Plus, the first example seen by the

          end-user should include the use of iteration through the results, not an

          underscore template which hides some of the details.

           

          >

           

          On Dec 18, 2013, at 10:47 AM, Karel Piwko <kpiwko@redhat.com> wrote:

           

          To my understanding, HTTP 201 should always return created entity and its

          content should be based on Content-Type header field.

           

          See http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

           

          On Mon, 16 Dec 2013 16:25:53 -0500 (EST)

          Vineet Reynolds Pereira <vpereira@redhat.com> wrote:

           

          >> It would be better to treat this as a flag to be enabled during REST

          resource

          >> scaffolding. It would allow users to choose how the resource behaves -

          >> * send a 201 response with Location header,

          >> * send a 201 response with Location header and also a response entity.

          >>

          _______________________________________________

          aerogear-dev mailing list

          aerogear-dev@lists.jboss.org

          https://lists.jboss.org/mailman/listinfo/aerogear-dev

          >

          _______________________________________________

          forge-dev mailing list

          forge-dev@lists.jboss.org

          https://lists.jboss.org/mailman/listinfo/forge-dev

           

           

           

           

          --

          Lincoln Baxter, III

          http://ocpsoft.org

          "Simpler is better."

           

          • 2. Re: [forge-dev] [aerogear-dev] Aerogear.js for CRUD
            sebi2706

            On Wed, Dec 18, 2013 at 4:54 PM, Burr Sutter <bsutter@redhat.com> wrote:

             

            It sounds like, at a minimum, we have a bug in the Forge scaffolding to

            support Aerogear.js

             

            My next concern would be that since this "feature" was introduced with

            jQuery 1.9, it could be that a LOT of the world's REST endpoints are no

            longer POST compatible with Aerogear.js, nothing to be done about that

            except to document it well for Aerogear.js when the time to promote it

            heavily comes up.

             

             

            Before you used Aerogear, you had also a version using only jquery, right ?

            Did you had the same behavior when doing a POST ? If yes, it's not

            only Aerogear based apps that have an issue but all the webapps around the

            world using jquery's ajax 1.9 stuff.

             

             

             

             

            Aerogear.js doc issues also include confusion of datamanager/store

            (getting started guide is not clear for when those are needed) and the

            seemingly missing docs for Pipe.  Plus, the first example seen by the

            end-user should include the use of iteration through the results, not an

            underscore template which hides some of the details.

             

             

            Could you open a new thread/jiras for the doc issues so that we don't mix

            all the things in one thread ?

             

             

            >

            On Dec 18, 2013, at 10:47 AM, Karel Piwko <kpiwko@redhat.com> wrote:

             

            To my understanding, HTTP 201 should always return created entity and its

            content should be based on Content-Type header field.

             

            See http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

             

            On Mon, 16 Dec 2013 16:25:53 -0500 (EST)

            Vineet Reynolds Pereira <vpereira@redhat.com> wrote:

             

            >> It would be better to treat this as a flag to be enabled during REST

            resource

            >> scaffolding. It would allow users to choose how the resource behaves -

            >> * send a 201 response with Location header,

            >> * send a 201 response with Location header and also a response entity.

            >>

            _______________________________________________

            aerogear-dev mailing list

            aerogear-dev@lists.jboss.org

            https://lists.jboss.org/mailman/listinfo/aerogear-dev

            >

            _______________________________________________

            aerogear-dev mailing list

            aerogear-dev@lists.jboss.org

            https://lists.jboss.org/mailman/listinfo/aerogear-dev