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

3459HTML form representations vs. resources (was: Re: [rest-discuss] Rebel)

Expand Messages
  • Vincent D Murphy
    Mar 3, 2003
    • 0 Attachment
      [started a new thread because this has nothing to do with Rebel..]

      On Monday, March 3, 2003, at 03:01 PM, Jeff Bone wrote:
      > a given piece
      > of content might also have an "editor" representation which
      > encapsulates the content in a Web-based interface for editing and
      > saving said content. Hence, I've got URIs like:
      >
      > /~jbone/Journal/2003/03/01/33?repr=editor-xhtml

      i just thought i would chime in and mention that i am using a similar
      technique for web editing interfaces. i have found that it doesn't
      make sense to have only a form-oriented HTML representation because
      e.g. drop-downs are problematic (read: impossible) to use hyperlinks
      with, and a pure HTML representation (with no form HTML) doesn't let
      you do any editing unless you're running some fringe client agent like
      amaya.

      so i have a HTML representation, and put the form-HTML representation
      in a seperate resource. i look at the form as a subordinate resource
      rather than just another representation.

      i would be interested in hearing what others think of this, pros/cons
      etc. my original thought process was that HTML forms don't have their
      own mime-type, (e.g. text/html+forms) so conneg was not an option.
      <shrug>

      so i would have something like:
      /~jbone/Journal/2003/03/01/33/form

      a GET on this gets you a HTML page with a form rather than 'normal'
      HTML; this form's target attribute is set to

      /~jbone/Journal/2003/03/01/33

      the form does a POST but i pre-process this on the server to actually
      mean PUT.

      > /~jbone/Journal/2003/03/01/33?repr=rdf-factset
      >
      > This allows all of these things to be directly accessed by simply
      > GETting them, rather than having to dip into conneg. AND it works well
      > for alternate representations that have some associated functionality,
      > beyond just this or that static format.

      i was going to suggest that perhaps "Content-type" or something would
      be a better name than "repr" but deja-vu tells me this has come up on
      this list before.

      off-topic tangent: try
      http://www.google.com/search?q=rest-discuss+Content-type+Vincent
      google doesn't seem to have crawled any archives of rest-discuss;
      bummer. sometimes i hate yahoo groups. i wonder whether the archives
      are hidden from crawlers behind their ads.

      i do think its important that people use standard attribute name/values
      for this though. otherwise interoperability will suffer big time, IMHO.
    • Show all 10 messages in this topic