Loading ...
Sorry, an error occurred while loading the content.

11433RE: [rest-discuss] RE: [whatwg] Proposing URI Templates for WebForms 2.0

Expand Messages
  • Mike Schinkel
    Nov 1, 2008
    • 0 Attachment
      Subbu>> I don't disagree, and I do see the value of templates for
      non-browser scenarios. But the most of the web today won't be taking
      advantage of this for a long time.

      HTML5 won't be taken advantage of for a very long time, so how is this a
      critcism?

      >> Again, I don't disagree about loose-coupling, but the technique serves
      just a tiny tiny fraction. Also consider the amount of JS code out there
      that knows how to construct URIs from form params and other inputs. That
      won't be migrating to use templates anytime soon.

      If URI Templates are added I can see them be immediately incorporated into
      CMS like Drupal, WordPress and Joomla (I use the former two so I'll add it
      if nobody else does) and frameworks like Ruby on Rails, Django, and CakePHP.
      Most (all?) of those frameworks use clean URLs but can't use forms w/o using
      Javascript and URI templates would be a cleaner and simplier approach that
      it would be crazy for people NOT to use it.

      I for one will blog about it and promote if via Twitter and expect others
      like dret and Jerome (and probably Mark) will do the same.

      >> Same as above. Those services/servers can very well allow form-encoded
      data. I would argue that, doing so is better since it would let them work
      with existing browsers and JS libraries.

      So your only argument against is someone would need to create a URI Template
      library and then they would need to use it? Just how hard is it to find and
      use another library?

      With that argument there should be no planning for HTML5 because "existing
      libraries" don't work with HTML5, right?

      @dret>> i think the main question is whether HTML should look beyond
      services designed specifically for backing forms, or not. it certainly could
      without harming backwards-compatibility, and one could also argue that this
      would actually promote the design and implementation of services with more
      well-designed RESTful APIs than form-encoded data. seen this way, such a
      feature would be a pretty smart way of slowly improving the state of how
      services are provided on the web.

      Well said.

      -Mike Schinkel
      http://mikeschinkel.com


      -----Original Message-----
      From: Subbu Allamaraju [mailto:subbu@...]
      Sent: Saturday, November 01, 2008 1:56 PM
      To: Erik Wilde
      Cc: Mike Schinkel; 'Mark Nottingham'; 'Ian Hickson'; 'Jerome Louvel';
      whatwg@...; uri@...; rest-discuss@yahoogroups.com
      Subject: Re: [rest-discuss] RE: [whatwg] Proposing URI Templates for
      WebForms 2.0


      On Nov 1, 2008, at 10:01 AM, Erik Wilde wrote:

      > Subbu Allamaraju wrote:
      >> I see the use cases, but what is the server gaining with this
      >> flexibility? In other words, how many servers out there are going to
      >> benefit from this technique?
      >
      > the question is more how many page authors will be able to reliably
      > develop forms against services/servers? i think mike's idea is pretty
      > good because it increases loose coupling between clients and servers.

      I don't disagree, and I do see the value of templates for non-browser
      scenarios. But the most of the web today won't be taking advantage of this
      for a long time.

      > on today's web, forms and services are more or less tightly coupled,
      > and they almost are developed as one thing. mike proposes an
      > architecture that introduces a more loose coupling, because a form is
      > able to interact with more services than before.

      Again, I don't disagree about loose-coupling, but the technique serves just
      a tiny tiny fraction. Also consider the amount of JS code out there that
      knows how to construct URIs from form params and other inputs. That won't be
      migrating to use templates anytime soon.

      > ( mike, please correct me if i am wrong. )
      >
      >> Not having templates in forms does not violate URI opacity since HTML
      >> forms do follow a well-defined and well-understood approach to
      >> construct a URI from form parameters.
      >
      > yes, but if you have some service out there that expect certain URIs,
      > then currently it is not possible to build a form for that, unless the
      > service does expect form-encoded data. mike's proposal would allow
      > forms to interact with a much wider set of services.

      Same as above. Those services/servers can very well allow form-encoded data.
      I would argue that, doing so is better since it would let them work with
      existing browsers and JS libraries.

      Sincerely,
      Subbu
      ----
      http://www.subbu.org
    • Show all 25 messages in this topic