default conventions for conneg/ajax -- what do we want?

[Jeremy D. Miller]

I'm back at the conneg/view changes this morning and want to start the conversation about our default conventions for attaching input and output options on BehaviorChain's.

For a *new* default conventions:

* Any endpoint that responds to any Http verb besides GET will accept and output Json if it has no other kind of output

Today, we've got:

* Actions that return strings write plain/text

* Actions that return strings but the method is suffixed by "Html" write text/html

* Actions that return HtmlTag or HtmlDocument write text/html

* Actions that return AjaxContinuation or any subclass of AjaxContinuation write json (it's a little bit special)

* Actions where either the input or output type implements the JsonMessage interface will write text/json or application/json and accept text/json, application/json, or application/x-www-form-urlencoded (Asymmetric Json)

* Explicitly, Actions marked with:

    [JsonOutput] -- writes text/json or application/json.  Has no effect on intputs

    [AsymmetricJson] -- http posts and json in, json out

    [SymmetricJson] -- json in, json out

    [Conneg] -- configurable for one offs
 

and finally, you can also explicitly do:

Media.ApplyConneg(filter) that today will just add xml, json, http in, xml json out.

I'm nuking the complete "Output.ToXXXXXXX" syntax in FubuRegistry with the idea that the Media hive will take up the slack.

Thoughts?

Jeremy D. Miller
The Shade Tree Developer
jeremy...@yahoo.com

[Kevin Miller]

Sounds good. Some concerns in descending order of how much I give a fsck:

Will you have the ability to ApplyConneg([ filter1, filter2])? Just thinking that right now you either get all the media formatters for content negotiation or it gets filtered down to the 1 you pick. There is a good chance I might want JSON, Atom, iCal but not XML. 

Are you going to look at supporting file extensions tacked on to routes to coerce the content-type? <route>.json or <route>.xml 

This practice seems to be common in other frameworks. Not saying it is right but it is surely more user friendly than requiring http Accept headers be set. 

Why the 3 different [*Json*] attributes? Why not just have one [Json] and if user's want to get into the nitty gritty use the DSL. Thinking keep it simple. Less is more. Don't make me think kinda thing. 

Not too excited about the JsonMessage convention being built in. It is just as easy to configure such a convention yourself if this is needed via conneg. And then there is the [*Json*] attributes which give you the same effect. Thinking less ways to do the same thing is better. 

KevM

--
You received this message because you are subscribed to the Google Groups "FubuMVC Development Group" group.
To post to this group, send email to fubumv...@googlegroups.com.
To unsubscribe from this group, send email to fubumvc-deve...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fubumvc-devel?hl=en.

[James Crowley]

Just digging through old posts on this, and just wanted to +1 the ability to apply multiple specific media formatters (I will be using iCal, JSON and Atom), and if there's a way we can get support for file extensions to override content-type?

Jeremy from what you're saying, is there no way to do this kind of thing at all right now?

Thanks very much,

J