On Apr 24, 9:12 am, Masklinn <[email protected]> wrote:
> On 24 Apr 2009, at 16:24 , Carmine wrote:
>
> > On Fri, Apr 24, 2009 at 2:41 PM, Masklinn <[email protected]>
> > wrote:
>
> >> On 24 Apr 2009, at 10:55 , earcar wrote:
> >>> 1. does Django support REST queries?
> >> I fear that question doesn't make any sense, REST is an architectural
> >> style, not a language or anything, there are no "REST queries".
>
> >> Other than that, yes you can make django understand remote procedure
> >> calls via URLs, there might even be third-party apps for that. I
> >> don't
> >> think Django has any "native" support for that though.
> > Yeah, your're right, I meant "does Django provide a way to do RESTful
> > applications easily (so: xml serialization and response validation and
> > deserialization)?"
>
> Django doesn't ship anything for XML serialization or deserialization,
> but Python does. On the other hand Django provides facilities for
> request validation (forms), and the request/response flow is flexible
> (e.g. you could hook a validation middleware to ensure all your
> response validate, or you could just have your views return XML data
> and wrap them in a decorator validating the response and making it
> into a django response... although I fail to see why you'd return
> invalid XML in the first place)
>
> >>> 4. is possible to render views using xslt?
> >> I think you mean templates here, in Django's lingo. Yes you can
> >> although it might not be the smartest idea ever, and you won't be
> >> able
> >> to use Django's template system
>
> > Why is it not a good idea?
>
> Because, to speak crudely and give my opinion, XSLT sucks.
>
> >>> or better render in xml,
> >> Use Genshi as a template engine instead of django's template system.
>
> >>> leaving the xslt work to the browser?
> >> That's a bad idea. If only because not all browsers can do that.
>
> > Are there other reasons why it's a bad idea?
>
> See above, as far as I'm concerned the concept that underlies XSLT is
> interesting, but the execution is an abortion, if you want to generate
> XML you're better off using an XML template language (Genshi, TAL,
> whatever...)
Hi,
I'm just coming in to second this, particularly in the case where you
have instances stored in a database through the ORM. If that's the
case, my experience was that it was much easier to write templates
that rendered XML, than to either serialize the object to XML, or
serialize it and then transform the result. To make things easier on
the user, I suggest using separate URLs: one set for the human
readable HTML; another for the web service API. However, since we
still don't know where your data is going to be stored, we can't say
if this will work for you. If you do have the unfortunate restraint
that you must store your XML as files, then XSLT may be the way to go.
Now, as for using Django on the client side, it can be done, but I
found that using the models required a bit of work (my client needs to
set up the database in memory each time). You can ask for more details
if you decide to go with Django.
Finally, ask yourself what features of Django you're going to be
using. If it's just the URL dispatching, to call your own code, with
your own storage mechanism, and your own rendering solution (e.g.,
XSLT), then you may want to consider something lighter, like the oft-
mentioned web.py (http://webpy.org/).
--Rick
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" 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/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
