Leveling up on MediaWriters

[Ryan Rauh]

Hey yall, 

I'm building a feature in our app to enhance our edit in place functionality. It's been a really messy part of our app and I've got some ideas on how to clean it up and make it much simplier. 

I'm thinking about using a special accept type to do some special sauce for certain pages while I slowly migrate each page to the "new" edit in place. 

Maybe something like Accept: application/json+edit-in-place

I'm studing a FubuMVC.Export to see how its using MediaWriters to get some inspiration. 

Quick question:

Why the need for two accept types? Accept: "application/xlsx,application/json; charset=utf-8"

[Joshua Arnold]

Joe can speak to the two accept types. The export bottle does a few tricks that got awkward.

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

[Jeremy D. Miller]

Are you asking why you'd ever need more than one accepted type,  or why export did it that way?

That's the equivalent to saying "I'd prefer you send me an Excel file, but if you can't do that I'd accept a json payload as well."  This theoretical client would then be responsible for sniffing the content-type of the response and acting accordingly.

Not sure that's what you were asking though.

[Dru Sellers]

Ryan, you might consider 'application/vnd.fubumvc.editinplace' (or some derivative)

the 'vnd' prefix is the preferred 'custom' accept type

Interesting read on 'vnd' 

http://stackoverflow.com/a/1112986/392558

http://blog.2partsmagic.com/restful-uri-design/

-d

[Ryan Rauh]

  However I ran into issues with IE

Exactly what I wanted to know. I noticed that application/xlsx always returned json and was curious why. That was very helpful Joe, thank you! Saves me a lot of cursing at IE :)

-Ryan

On Thu, May 16, 2013 at 2:59 PM, Joe McBride <uicra...@gmail.com> wrote:

Why the need for two accept types? Accept: "application/xlsx,application/json; charset=utf-8"

This is a little awkward, but here's how it's currently working and the reasons for the two accept entries.

Short answer:  Basically what Jeremy said - you're asking for application/xlsx, but in lieu of that you'll take application/json too.  The xlsx export media writer happens to always return json.  You can actually leave the application/json off and Chrome and FF work as expected.  However I ran into issues with IE not treating the response as json without the accept header which can lead to more awkward code on the client.

Long answer:  By design, the export Endpoint gets triggered when application/xlsx is requested.  However it always returns json with a url that can be used to download the generated xlsx file.  This is so we can generate a temp file on the server and use the built-in DownloadFileModel that fubu provides to download the file. By design it's a two-step process: 1) request the file generation 2) download the generated file.  One of the things we wanted to have it do is just tie into an existing Endpoint Action.  That's great - however things get awkward when that action also has a view associated with it, or multiple other media writers, such as the traditional conneg xml/json writers.  For everything to play nice in all browsers, the client needed to request the two accept types, and the Media Writer - ExcelMediaWriter<T> - needed to provide those two as Mimetypes as well.

Hope that helps!

Joe

[Jeremy D. Miller]

Do you need to do that though?  You could just keep it simple and accept pure json now and completely bypass any kind of custom media writer.

[Ryan Rauh]

I'm not relieving every detail but... maybe, I haven't gotten too deep into it yet. 

I'm more floating some ideas and I was legitimately curious about the two accept type thing.

[Jeremy D. Miller]

Now, what would be super, awesomely cool would be if you'd do a reusable bottle that used Html conventions heavily to generate the two pieces of edit in place with swappable strategies for actually applying the changes to the backing persistence.

I hated the edit in place code on the client side.  I thought it was a huge DRY violation of just about everything.  Duplicated html conventions, duplicated validation logic, etc.

I like the edit in place mechanics in slick grid a lot better than whatever awful JS library we used for Blue's edit in place.

[Ryan Rauh]

 use Html conventions heavily to generate the two pieces of edit in place with swappable strategies for actually applying the changes to the backing persistence.

Definitely agree here and this is actually what I'm shooting for. 

I like the edit in place mechanics in slick grid a lot better than whatever awful JS library we used for Blue's edit in place.

Thanks for the tip, jeditable is not the best thing in the world and hasn't been maintained for +3 years. I will take a look at slickgrid and see what I can steal or use.