> That's why you don't write an "if txt_requested" it the page isn't
> supossed to return plain text.
> But I see your point: The approach is fragile and error-prone .
I think you're missing part of my point here. Take this case for
example:
You have a resource that can be represented both in html, xml and
json. The client's accept header is "application/html,application/
xml,*;q=0.9", which means something like "I want html, but if you
can't, then you can also give me xml. I can also take anything else,
but in that case I'll be 10% less happy". In your if..elif chain you
might end up serving txt (because the client said he can take it),
eventhough you could've served html and made it 10% more happy.
> But then you would need to write a separate render_html and
> render_json for each GET.
> Isn't that a bit messy?
You can reuse the same render_json, that's not supposed to change. And
about the different render_htmls, you need extra processing that is
specific for each page anyway. I think it's still better than a bunch
of if..elifs that repeat everywhere in your code.
> ...
> Or maybe not... if they are on the same class of the page:
>
> class hello:
> @mimerender.represent(
> html = self.get_html, (*)
> json = self.get_json) (*)
> def GET(self, name):
> if not name: name = 'world'
> message = 'Hello, %s!'%name
> return {'message': message}
>
> def get_html(self, data):
> ... more processing ...
> return render.hello(data)
Seems reasonable to me, but watch out in the marked (*) lines: 'self'
means nothing there.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web.py" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/webpy?hl=en
-~----------~----~----~----~------~----~------~--~---
