Hey hey hey now.... you you calling "smart"?
Yeah, I did find examples in O'Reilly's Definitive HTTP Guide of
POST's
returning plain text... I doubt there's any restriction there. But
really, you interpreted what I had said as invoking specs... I was
not.
I was assuming that the dictates of RESTful rails reflected the
original
intentions of HTTP (i.e. that we return the location of the newly
created resource after a POST).
absolutely - there is no argument from me that *when* you can give
the URI of a newly created resource, that's what you do - always.
And by the way, I never interpreted what you said as invoking specs -
my most recent reply was in response to a question (paraphrasing)
like: "if you're not supposed to return content, then why the Accept
headers?" - and my reply was "the spec says you can return an entity
(content) when the result is not URI accessible - that's why".
But really, I was/am far more concerned with the reality of web
browsers: if you return html content from a POST, you break the
history.
It's that simple. The designers of rails understand that; that's why
they had generated controllers redirect after a successful save.
Okay, no arguments there either. But I don't get *too* hung up on a
slightly goofy history in the event of having to re-render a form
with errors - after all, I also do AJAX which is generally not
terribly back-button friendly - it's just tradeoffs.
But going straight back to the form on errors still has the potential
for screwing up users. I'd rather design for user comfort than
follow my
notions of architectural purity.
Or perhaps you're not talking purity.... what do you mean by
"potential
timing issues - however insignificant"? That this data is not pulled
fresh from the db? Doesn't seem like redisplaying the form directly
solves that.
The timing issue (remember I said "however insignificant") is this:
flash is used in the next http request for the current session - no
guarantees about whether or not another one of the user's windows (or
tabs) issuing a completely unrelated request to the app will steal
your flash. Yeah, it's an incredibly small chance. But that chance,
along with the fact that what you are talking about is actually more
work and that it relies on shoving serialized objects into the
session, makes the "always redirect even on errors" strategy
unattractive.
Actually, I've never understood the aversion to AR objects in the
session at all. I mean, I'm all for light sessions for performance
sake
(though many many many apps really don't have to worry about that),
but
why does putting something more complex that a string or an integer in
the session give people the willies.
Experience has taught me that my life is simpler if I don't store
fully-hydrated objects in the session
Maybe I'm just spoiled by my time in javaland where we'd put all sorts
of stuff in the session. I actually wrote a Flash (though I did not
use
that ridiculous name) for Spring MVC and for WebWork just to carry my
domain objects through the error redirect.
Then I get fully into rails and find resistance to the idea... hmph.
heh - well, you only seem to be getting resistance from one loudmouth
(me) so don't take it too harsh
Trev