Ahh.... Okay...  Ummmmm..... :)

Well, how about this...  let me get all of the backend functions in place and working and then come back for some advice on how to properly implement the front end.  Obviously the backend can be written in a way that is completely blind to the "enforcement" layer...

If I have things straight, All it needs to know is whether it should

- create a new entry and, if necessary, a file to contain this entry,
- update an existing entry,
- or delete an existing entry which can exist within a 'feed'-based collection of 'entry's and/or in an entry-based file of its own

Of course there can be one entry in a 'feed'-based file and still be a valid atom file, so while a collection is normal for a 'feed'-based file, its not required.

At least, that sounds right, but based on the fact that I was still lost over the PUT vs. POST thing, I'll stop assuming anything at this stage and just listen to what others such as yourself tell me is the correct interpretation, and how to handle this properly.  My pride is already shot to hell, no need to worry about that at this stage, and instead I'll just make sure I am doing things the way they're supposed to be done and be happy with the result and the fact that the result is correct based off of those who know where they're talking about :)

So let me get the first part of this complete, and then ping back this thread to see where things sit in regards to necessary changes to ensure things are working as they should be.

Thanks for your help, Joe!  Very much appreciated :)

On 6/7/06, Joe Gregorio <[EMAIL PROTECTED]> wrote:
On 6/7/06, M. David Peterson <[EMAIL PROTECTED]> wrote:
> In what should be fairly obvious, I am using file extensions to
> represent the action that is desired to take place upon the atom feed.
> for .omx extensions only GET and HEAD are allowed, for .atom only GET,
> for .update, only POST, .create, only PUT, and .delete, only DELETE.
> This adds a layer of "obvious" to the action that is taking place (or
> at very least is being requested to take place.) This will allow for a
> fairly simple and straightforward way to access, edit, update, and
> delete a particular atom feed, or entry contained within that feed.
> For example, http://extf.net/blog/2006/06/01/This_Is_An_Entry.create
> would create the entry in the folder 2006/06/01/This_Is_An_Entry,
> http://extf.net/blog/2006/06/01/This_Is_An_Entry.update would update
> that same entry, http://extf.net/blog/2006/06/01/This_Is_An_Entry.atom
> would return a copy of the atom feed for that entry, and
> http://extf.net/blog/2006/06/01/This_Is_An_Entry.delete would delete
> that entry.

If I understand this correctly I think you have a problem.
In the APP there is only one URI for an entry specified, the edit URI
returned either via the Location: header or in the feed via
the link/@rel='edit' member, and that URI needs to be able to
handle GET, PUT, and DELETE.

  -joe

--
Joe Gregorio        http://bitworking.org



--
<M:D/>

M. David Peterson
http://www.xsltblog.com/

Reply via email to