Re: #6735 -- Class based generic views: call for comment

[David Larlet]

Jacob Kaplan-Moss a écrit :

On Tue, Oct 5, 2010 at 8:03 AM, Russell Keith-Magee
  wrote:

  * Are there any outstanding tickets on generic views that will be
closed by merging this branch, and do they ask for any features that
aren't fixed by this branch?


Almost certainly yes :)

We could *really* use a volunteer who can wade through the open
tickets, look at all the GV-related tickets, and answer this question
concretely.

Anyone? Bueller?


#1282: archive_today generic view should accept a month_format parameter 
instead of hardcoding '%b'

Done, through MonthView.month_format

#2367: pagination for date based generic views
Depends on http://github.com/bfirsh/django-class-based-views/pull/2

#8378: Generic views cache-like behavior
Last edited one year ago, not sure if it's still relevant

#13753: Generic views don't redirect to an URL name, like 
django.shortcuts.redirect does

Done, no more post_save_redirect argument but View.redirect_to()

#13842: XViewMiddleware fails with class-based views
Must be fixed before class-based views merge.

I hope I didn't forget one, it's really hard to search with Trac...

Best,
David

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: #6735 -- Class based generic views: call for comment

[David Larlet]

Russell Keith-Magee a écrit :

I've just added a summary of the last thread on class-based views [1].
This summary isn't 100% complete -- any contributions from interested
parties are welcome. Try to keep opinions to a minimum; this page is
about documenting the strengths and weaknesses of various approaches,
not about expressing opinions. In the same way that CSRF [2] and
session-messages [3] have good wiki pages describing the design
considerations, we need to be able to explain to future generations
why class-based views are the way they are.

Thanks for taking that time.


I'd like to try and get this in for 1.3. It's a big feature, which
means it needs to be in by October 18. However, based on the state of
the patch that Ben has prepared, I think this is an achievable goal.

I think too but it needs a lot of feedback from the community.


Three things are required to make this happen:

  * Documentation. It looks like David Larlet has made a start on this
already, but there's lots more required.

Yes, only a start but I'm working on it, any help is really appreciated.

  * Conversion of the github project into a patch on trunk.
Do you see that as a total replacement of actual views.generic or should 
we go for a old/new dance?

  * Feedback on the API, especially the generic view replacements.
A first feedback from a fork [1], I think it can be interesting to move 
the paginate view too.


I already have one specific piece of API feedback: the current
implementation requires that all view logic is contained in GET(),
POST() etc style views. This is fine, except for the fact that there
are occasions where GET and POST share a lot of common logic. It would
make sense to me to allow for a request() method that is the direct
analog of how we do views right now, wrapping lines 53-59 of base.py
into a request() method. This would allow users to define their own
dispatch mechanisms, or share logic between GET and POST (and any
other http method) as necessary.
What do you think of [2], is that what you have in mind? I chose 
dispatch, as Luke suggested, because request can be confusing.


Best,
David

[1] 
http://github.com/josesoa/django-class-based-views/commit/5f24e25e83f63b44b7049a746713bec0cb16e34a
[2] 
http://github.com/bfirsh/django-class-based-views/commit/20b63340bbf2b6152f88b5ee47865689d9fae3a6


--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Revised form rendering

[David Larlet]

Hi,

Le 11 juil. 2010 à 17:36, Russell Keith-Magee a écrit :
> I'd like to propose a few extensions to Django's form library for 1.3.
First of all, thanks or your proposal, the current form rendering is the worst 
part of Django to me and I'd like to help to improve that in 1.3.

> Layout
> --
> style, we can get that by simply loading a different renderer that
> implements that style:
> 
> {% load custom_renderer %}
> {% form myform %}
> 
> Django would ship with {% form %} implementations of the 'as_p' and
> 'as_ul' strategies, so getting 'as_p' rendering would mean:
> 
> {% load xhtml_p_forms %}
> {% form myform %}

Just a personal feedback, to me the rendering strategy is related to a whole 
project and should be defined in settings, it's too easy to forget a loading in 
a template. I know that you can use the django.template.add_to_builtins 
function but it in this case it should be documented.

> 
> Widgets
> ---
> 
> Chrome can also be parameterized; for example:
> 
> {% form myform field name using autocomplete:"name_autocomplete" %}
> 
> might define a chrome that implements an Ajax autocomplete widget
> using the named URL "name_autocomplete" as a data source. This has to
> potential to start giving an answer to the "Why doesn't Django do
> AJAX" monkey; Django won't provide an AJAX solution out of the box,
> but packaging a chrome that implements AJAX should be a lot easier.

If it requires an extra {% form %} arg it will not be that easier if you need 
to override all third-party apps' templates. Note that I haven't got any 
solution, that's more to bring the discussion on that topic :-).

> 
> Doctypes
> 
> 
> Once these two changes are in place, we use the form template tag
> specify the doctype that is passed to the widget render call. A
> 'html5_p_forms' library will pass 'html5' as the doctype when
> rendering fields, and get HTML5-compliant form fields; the
> 'xhml1_p_forms' library will pass 'xhtml1', and get XHMTL1-compliant
> form fields.
Again, why not directly in settings in order to be project's specific? Is there 
anybody mixing doctypes on the same website? (backward compatibility maybe?)

Regards,
David

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Class based generic views in 1.3?

[David Larlet]

Le 28 mai 2010 à 00:01, Luke Plant a écrit :

> On Thursday 27 May 2010 17:29:28 David Larlet wrote:
>> Hello,
>> 
>> We're working on this with Ben during djangocon.eu sprint [1]. Any
>> comment appreciated, still a work in progress though.
> 
> Looks cool.  I think Jari's idea of a class method to instantiate the 
> classes would be a great pattern to establish - something like an 
> 'as_view' classmethod on the base class which returns a view function 
> that uses the class:
> 
>@classmethod
>def as_view(cls, *initargs, **initkwargs):
>def view(*args, **kwargs):
>obj = cls(*initargs, **initkwargs)
>return obj(*args, **kwargs)
>return view
> 
> The developer can choose whether to write 'MyClassView.as_view()' 
> directly into the URLconf, or put a line into views.py like 'my_view = 
> MyClassView.as_view()'
> 
> This will solve the thread safety issue, and doesn't require another 
> import for a decorator, as Jari pointed out.
> 
> We could decide whether to apply decorators inside as_view() or  
> __call__().  The argument for putting it in 'as_view' is that __call__ 
> does some processing that you might want to skip entirely (e.g. the 
> get_object() call - if we applied a 'cache_page' decorator, we 
> wouldn't want the get_object() call to be made at all if there was a 
> cache hit).
We discussed that point with Jacob and it looks like it's easier to modify 
urlresolvers to create a new instance of the class when we detect it's a class, 
this should solve the thread safety issue. Do you see any drawback to this 
approach?
That way we can declare decorators via a decorators' list [1] or directly in 
the class [2]. I'm not fond of the second way, decorating a decorator, but we 
can create decorators dedicated to class based views easily that way.
> 
> On that point, I think 'GenericView' should be split into 'ClassView' 
> and 'GenericView'.  The get_object() call is probably not a good thing 
> to have on a base class.
Agreed, I'll make that change.

Thanks,
David

[1] 
http://github.com/bfirsh/django-class-based-views/blob/master/class_based_views/tests/views.py#L24
[2] 
http://github.com/bfirsh/django-class-based-views/blob/master/class_based_views/tests/views.py#L43

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Class based generic views in 1.3?

[David Larlet]

Hello,

We're working on this with Ben during djangocon.eu sprint [1]. Any comment 
appreciated, still a work in progress though.

Regards,
David

[1] http://github.com/bfirsh/django-class-based-views


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: [Proposal] Adding optional SITE_DOMAIN and SITE_NAME variables in settings.py

[David Larlet]

Le 14 mars 2010 à 12:27, James Bennett a écrit :

> On Fri, Mar 12, 2010 at 4:39 PM, aditya  wrote:
> 
>> Currently, Django uses "example.com" for both the domain and the
>> name.  The only way to change that is to wade into the actual
>> database.
> 2. If it turns out there's a real problem, provide a solution which
> doesn't involve one-time settings and which, preferably, leverages
> existing and proven features of Django rather than trying to add new
> ones just for this case.

Just my 2 cents, the "Django way" to deal with one-time settings is to ask 
directly the user (see admin user's creation) during the syncdb call. But, most 
of the time, I end up adding fixtures for the admin and launch syncdb with the 
--noinput option. Faster.

That's a bit off-topic but this can lead to security issues given that your 
default fixtures will load whatever the environment. How do you handle this: 
fixtures by environment? Maybe we should reconsider the 
/sql/..sql pattern to add an environment info?

Regards,
David

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: shortcut proposal

[David Larlet]

Le 16 oct. 2009 à 23:15, Sean Brant a écrit :
> Using a decorator allows you to do cool things like
>
> @provides_html('myapp/mypage.html')
> @provides_json(optional_serialize_callback_can_go_here)
> def my_view(request):
>return {'foo': 'bar')
>
> Then your provides_* could check the accept-header and know how to
> response. Html renders a template and json would serialize the dict.

It reminds me a proof of concept: http://code.welldev.org/djangorators
You can chain a lot of decorators but it will lead to hardly readable  
code, mostly because the order matters.
Anyway, it's interesting to see that a lot of people are thinking  
about the same approach...

David


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Offering sponsorship to work on improving Django

[David Larlet]

Le 20 juil. 09 à 22:46, Alex Dedul a écrit :
> I want to offer sponsorship if anyone would like to work on improving
> Django. We can organize it in the way GSOC do this - i.e. you specify
> subproject on Django you want to do, some community decision made
> about usefulness about this subproject and if this decision is yes -
> when you start real work and i'm paying you for this. Other way i see
> - you can just push for example for 1.1 release, then 1.2 etc. We can
> discuss this in more detail, i'm in no way want to do this like too
> formal or the like, you can propose your ways to do real work on
> Django and get paid for this.
>
> So, what do you think about this ?

Alex,

Before organizations' discussion, maybe you should expose your  
sponsorship's motivations?

Regards,
David


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: "Delete selected objects" in admin batch edit

[David Larlet]

Le 24 mars 09 à 09:36, Elliott a écrit :
> Given these reasons it only makes sense to me to leave delete off by
> default and provide an easy way to enable it, both globally or for
> each model.

I agree with Elliott, admin actions are great and we were all  
impatients to see it in action - no pun intended - but enabling  
deletion by default is a bit "critical" (feedback from clients). Maybe  
we can work together on #10595?

Regards,
David



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: MarkupField

[David Larlet]

Le 23 févr. 09 à 23:27, James Turk a écrit :

> To me there are a few big problems with the markup_func proposal as  
> I see it:
>
> * it removes the ability to provide multiple markup_types on a given  
> field
> * what is unpythonic about taking in two extra parameters to  
> customize the field?

Isn't it possible to define your choices+functions in settings? Like:

MARKUP_CHOICES = {
   'markdown': markdown.markdown,
   'textile': textile.textile,
   and so on
}

This way you can generate your choice field iterating through keys and  
render appropriate markup given values.

My 2c,
David


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: When Django will run on python3k?

[David Larlet]

Le 19 févr. 09 à 09:58, martin.xu a écrit :

>
> I like python 3k.,but I cannot run Django on python 3k?
>
> Is there any pacth that port  Django to  Python 3.0?

First result in google:
http://wiki.python.org/moin/PortingDjangoTo3k

Regards,
David



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: App Engine port

[David Larlet]

Le 10 févr. 09 à 17:53, Alex Gaynor a écrit :
> David, I think I mentioned this to you, but I believe that by using  
> the new F() objects we can actually remove the raw SQL entirely, I'd  
> need to put some more thought into this(and perhaps Malcolm already  
> has) but it should be possible.

Alex, I agree with you (not yet tried though), it's only a timing  
issue. There are two possibilities: moving then reF()actoring or doing  
both in the meantime/same patch. I adopted the first one because I got  
no answer to my previous email and that's the blocking point to me, I  
thought there were more chance that it get commited quickly keeping  
the patch as simple as possible.
Now, if you think it's important to do both and provide some feedback  
on the way I did the move I'll be glad to work on it.

Regards,
David


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: App Engine port

[David Larlet]

Le 10 févr. 09 à 05:25, Malcolm Tredinnick a écrit :
> There's also
> simple enough stuff like removing the last vestiges of raw SQL from a
> couple of places (most notable related fields, but that should  
> probably
> go after, or in tandem with, a rewrite of related fields to clean them
> up in general).

That's the goal of #10109. Good to know there is eventually an  
interest in this.

Regards,
David

http://code.djangoproject.com/ticket/10109


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Custom date formats and admin

[David Larlet]

Hello,

Today I tried to handle custom dates formats in admin and there are a  
couple of issues related to that.

First on rendering, AdminDateWidget doesn't inherit from DateTimeInput  
which seems more logic to me. I eventually update the patch #7656 and  
it works. Is there any reason against that approach before I add tests  
and documentation?

Then on validation, my first idea was to allow  
form.fields.DEFAULT_DATE/TIME_INPUT_FORMATS to be overridden by  
settings and I think it makes sense because from my experience, when  
you decide to create a website (let's say, in French) you do not want  
to pass your custom input_formats argument to all your fields. I know,  
I can add a FRDate/TimeField in localflavor but it doesn't solve the  
admin issue either. Are there drawbacks to this approach?

I know that the timing isn't that good because you are working on big  
1.1 features but I need it now and I'll work on it so feedback is  
appreciated before I submit complete patches.

Regards,
David

ps: looking for tickets on this topic, I found #8962 which is  
interesting in terms of consistency, note that the author discuss the  
interest of settings in comments too.

http://code.djangoproject.com/ticket/7656
http://code.djangoproject.com/ticket/8962


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Feedback from django-roa module

[David Larlet]

Le 19 janv. 09 à 18:43, David Larlet a écrit :
> I got an issue with M2M relations because SQL is hardcoded and I  
> can't catch it in Query(Set) object: 
> http://code.djangoproject.com/browser/django/trunk/django/db/models/fields/related.py#L428
> It is/will be an issue for all non-sql backend (CouchDB for  
> instance) and I think it should be fixed. Otherwise, I'll need to  
> hack a large part of Django just to support those relations.

Given the amount of answers :) let's discuss a concrete  
implementation, I just submitted a ticket #10109 about that and I'd  
love to know your thoughts about the design of the patch (no  
documentation nor tests for now, for the moment it just works for my  
project).

Regards,
David

http://code.djangoproject.com/ticket/10109
http://code.djangoproject.com/attachment/ticket/10109/patch_django_10109.20090123.diff
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Feedback from django-roa module

[David Larlet]

Hello,

I'll try to sum up my main issues with Django, trying to add a Django  
ROA/WOA/SOA/BuzzwordOA module which uses a custom backend in order to  
access remote resources in a RESTful way. Basically, it calls URLs  
instead of hitting database (a picture is worth a thousand words, look  
at the schema here: http://welldev.org/django-roa-diagram.png for  
details).

My first attempt was to create my own backend (as Oracle one) but it  
eventually looks way too complicated (I don't need all SQL machinery)  
and I end up with my own Model/Manager classes. I planed  to use Meta  
class in order to add resource URL but I can't because of Meta's  
restriction:
http://code.djangoproject.com/browser/django/trunk/django/db/models/options.py#L89
Eventually, I use a static method because it's easier but I don't know  
if this restriction is worth the pain.

I got an issue with M2M relations because SQL is hardcoded and I can't  
catch it in Query(Set) object: 
http://code.djangoproject.com/browser/django/trunk/django/db/models/fields/related.py#L428
It is/will be an issue for all non-sql backend (CouchDB for instance)  
and I think it should be fixed. Otherwise, I'll need to hack a large  
part of Django just to support those relations.

Integrating auth is not as hard as I thought thanks to inheritance, I  
just wrote my own remoteauth app and it works. Great. On the other  
side, integrating admin is more complicated. The main issues come from  
integrated ContentTypes (I'm still thinking about an elegant way to  
handle that) and hardcoded way to retrieve objects:
http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/options.py#L584
A get_object method on ModelAdmin can solve this issue. In the same  
attempt, it's useful to be able to easily change the ChangeList class  
in order to customize url_for_result (for instance), it'll be solved  
once #9749 is commited. I'm sure people involved in composite PKs #373  
will agree with me :)

I hope it will not be considered as a rant, my English is pretty basic  
but I just want to discuss those issues in order to help the community.

Regards,
David Larlet

#9749 http://code.djangoproject.com/ticket/9749
#373 http://code.djangoproject.com/ticket/373


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Dropping Python 2.3 compatibility for Django 1.1

[David Larlet]

Le 27 nov. 08 à 02:39, Eduardo O. Padoan a écrit :

>
> On Tue, Nov 25, 2008 at 3:08 PM, Jacob Kaplan-Moss
> <[EMAIL PROTECTED]> wrote:
>>
>> Hi folks --
>>
>> I'd like to officially drop Python 2.3 support in Django 1.1.  
>> Discuss.
>>
>> Jacob
>
> +1 -- because reusable apps developers could all close those
> py2.3-related bugs as wontfix.

But who has submitted those bugs? That's the interesting point.

David, +1


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: A (last-minute) compromise on {% url %}

[David Larlet]

Le 29 août 08 à 17:18, Jacob Kaplan-Moss a écrit :

>
> Hi folks --
>
> While working on some URL-related issues, I ran across a pretty big
> problem with having ``{% url %}`` propagate ``NoReverseMatch`` up into
> the templates: if it does that, there's no way to have "optional"
> links.  The perfect example is #7810 and the admin docs: if the URLs
> for the admin doc views are installed, the admin should show a
> (correct) link to the docs; if they're not installed, the link
> shouldn't be there. Unfortunately, with the current ``url`` tag, there
> isn't any way to make this work.
>
> I started poking at it, and it turned out to be *very* easy to add a
> ``{% url ... as varname %}`` syntax to capture the URL into a variable
> for later use. As a side effect, I made this syntax *not* raise errors
> but instead return an empty string. This makes for a very natural
> use::
>
>{% url django-admindocs-docroot as docroot %}
>{% if docroot %}
>Documentation
>{% endif %}
>
> Patch here: 
> http://code.djangoproject.com/git/?p=django;a=commitdiff;h=6c7d85a3cf6a3c7b161d960f86ea1cb111ded605
>
> So: I know this is technically a "feature addition," but it makes the
> fixes to some silly bugs far easier. Are there any objections to me
> sneaking this into 1.0?

+1 for this, before I test if someone already knows the answer, is it  
possible to use this var in blocktrans?

{% url args as myurl %}
{% blocktrans %}
 foo baz
{% endblocktrans %}

That's potentially the best solution for the endless discussion about  
urls in blocktrans.

Best,
David



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: One more issue with file storage

[David Larlet]

Le 10 juil. 08 à 21:11, Marty Alchin a écrit :
>
> On Thu, Jul 10, 2008 at 2:52 PM, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
>
>> This was also influenced by the Amazon S3 API which was going to be
>> implemented as an alternate strategy for this project.
>
> There's also work being done on an S3 storage system that'll be dead
> simple to drop in once my file work lands. I don't have a link for it
> offhand; David, if you're listening, can you point the way to your
> repo? It's gonna be some good stuff.

Sure, the latest version is available at 
http://code.larlet.fr/django-storages/file/d8a8ae7b1381/S3Storage.py
It'll not work with the new in-progress-chunked patch but I'll update  
it as soon as the filestorage stuff is working.

Hope it helps, do not hesitate to comment.

David




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: URL Resolvers: a little refactoring goes a long way

[David Larlet]

Ken,

It looks interesting but are there any examples of your urlresolver  
usage?

David

Le 24 juin 08 à 21:35, Ken Arnold a écrit :

>
> newforms-admin has a special-cased URL dispatcher in site.py. (see
> #6470)
>
> Various REST-ish frameworks have a '.*' url mapping and a similar
> hacky dispatcher.
>
> Django has a nice URL dispatcher in core/urlresolvers.py, which could
> drop in and replace those ad-hoc dispatchers. Only it takes the name
> of a module where you'll find urlpatterns, instead of urlpatterns
> itself. Removing that one assumption to a subclass makes
> RegexURLResolver immediately more useful.
>
> I've pulled the common functionality into a BaseRegexURLResolver,
> which takes (regex, url_patterns, default_kwargs) in __init__. If
> url_patterns is callable, it calls it before first use and takes the
> result.
>
> RegexURLResolver then inherits from BaseRegexURLResolver, but
> overrides url_patterns to lazily import the module.
>
> I've tried using the newly factored base class in my version of a
> RESTful Resource class, and so far I like the results. The naming of a
> few things could use some more thought, though. A tangible upshot is
> that nested resources become much easier to configure; some recent
> email on this list discussed that.
>
> Patch? I got a little carried away improving the documentation and
> trying to fix #4824, so the diff looks much scarier than the change.
> The result lives temporarily at
> http://code.google.com/p/django-webapp/source/browse/trunk/dwa/urlresolvers.py
>  
> .
> I haven't run the test suite on it, but I've tried two of my apps on
> it and they work. (The attempt at fixing #4824 actually caught a minor
> bug in my app code...)
>
> I wanted to get any feedback on this change before submitting a
> ticket, but if people think it's a good idea, I can clean up the patch
> and make a ticket.
>
> -Ken
>
> >


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Introducing ModelView, a RESTful class-based view of your resources

[David Larlet]

Salut Clément,

Le 19 juin 08 à 16:15, tifosi a écrit :
>
> Hi David,
>
> Thank for your code and the repository, I use the django-rest- 
> interface and
> it's good news, that someone continue the job.
>
> I would like to get nested resources (e.g.: /articles/1/comments/ or
> /user/username/jobs/) and the problem is that you have to pass  
> statically
> the queryset. I think I can use a decorator but I don't know how I  
> can do
> this. Do you have a suggestion?

I'll think about that this weekend, I have some ideas about the way to  
handle that in an easy way.
>
>
> (Sorry for my English, I'm French)

Nobody is perfect ;)

Cheers,
David

ps : you can join us on #django-fr



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: One more issue with file storage

[David Larlet]

Le 9 juin 08 à 19:11, Marty Alchin a écrit :
> I've been fairly quiet on the file storage front for a while, since
> it's basically done now, and is just waiting on the streaming upload
> ticket to hit trunk first. Since I got to that point, however, I've
> had two different people, working on two different storage backends,
> both approach me with the same question. It doesn't seem like a
> showstopper to me, but I'd definitely like to get it addressed. I've
> been mulling it over for a while now and can't come up with a
> universally "good" solution, so I'd like to bring it to the group for
> discussion.

Unfortunately, I hadn't found any elegant solution since our last  
discussion.

> * Storage systems take the name that the model knows about and maps it
> to an actual storage mechanism. This way, each site is free to decide
> how and where its files are stored and retrieved, independent of any
> specific model.

About Storages, I eventually setup a repository which is more flexible  
than ticket #6390
http://code.larlet.fr/django-storages/
There is already the S3 one and I'll work on the FTPStorage soon. Hope  
it helps, let me know if there are other storages in progress.

Cheers,
David


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Introducing ModelView, a RESTful class-based view of your resources

[David Larlet]

Le 9 juin 08 à 13:52, David Larlet a écrit :

>
> Le 8 juin 08 à 16:11, Ivan Sagalaev a écrit :
>>
>> David Larlet wrote:
>>> This is not a secret that I'm interested in both Django and Semantic
>>> Web. I'm following discussion about Django+REST for more than two
>>> years and when I realize that newforms-admin branch will use class-
>>> based generic views [1], I decided that it's probably the right  
>>> moment
>>> to do something with that.
>>>
>>> [1] http://code.djangoproject.com/ticket/6735
>>
>> David, this is a good news for us REST-fans :-). However don't you  
>> think
>> it could better start living as a separate app? It could get some  
>> early
>> adoption without needing to pursue inclusion in trunk.
>
> Of course, I just want to know if it could be possible as a middle- 
> term goal because it doesn't involve the same energy if it's for me,  
> a couple of REST-fans or the trunk (for example, tests and  
> documentation are not exactly the same).
>
> Anyway, I'll setup a repository and add some generic tests, that's  
> the minimum.

Here it is: http://code.larlet.fr/django-modelviews/ (at least for the  
first part).
I'll setup the base architecture but feel free to participate, push  
access is granted for all.

Cheers,
David
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django releases

[David Larlet]

Le 10 juin 08 à 03:16, Karen Tracey a écrit :
> I'd trade your controversial part for an alternative: merge mewforms- 
> admin back to trunk now.

+1 if involved people in this branch agree (I hadn't found the time to  
test it yet...).

> I think it's a shame newforms-admin wasn't done in a fashion similar  
> to newforms

Very good idea, the transition/merge will be easier if there is an  
alternative like that.

David


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Introducing ModelView, a RESTful class-based view of your resources

[David Larlet]

Le 8 juin 08 à 16:11, Ivan Sagalaev a écrit :
>
> David Larlet wrote:
>> This is not a secret that I'm interested in both Django and Semantic
>> Web. I'm following discussion about Django+REST for more than two
>> years and when I realize that newforms-admin branch will use class-
>> based generic views [1], I decided that it's probably the right  
>> moment
>> to do something with that.
>>
>> [1] http://code.djangoproject.com/ticket/6735
>
> David, this is a good news for us REST-fans :-). However don't you  
> think
> it could better start living as a separate app? It could get some  
> early
> adoption without needing to pursue inclusion in trunk.

Of course, I just want to know if it could be possible as a middle- 
term goal because it doesn't involve the same energy if it's for me, a  
couple of REST-fans or the trunk (for example, tests and documentation  
are not exactly the same).

Anyway, I'll setup a repository and add some generic tests, that's the  
minimum.

>
>> * Handle receivers in order to use it as an API (for the
>> moment,
>>   it assumes that you receive formencoded data), need more
>> reflexion.
>
> How about registering handlers for specific mimetypes that would  
> convert
> from raw data into a python dict. ModelView will have a built-in  
> method
> for formencoded mimetype and a derived class could add its own like  
> this:
>
> @register_mimetype('application/atom+xml')
> def atom_to_dict(self, data_stream):
> # parse data_stream
> return {
> 'attr': 'value',
> }

Yes, that's one of the approaches I'm thinking about, as for  
permission, using decorators looks to be interesting. I need to write  
some doc about that too.

Thanks for your answer,
David



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Introducing ModelView, a RESTful class-based view of your resources

[David Larlet]

Hello,

This is not a secret that I'm interested in both Django and Semantic  
Web. I'm following discussion about Django+REST for more than two  
years and when I realize that newforms-admin branch will use class- 
based generic views [1], I decided that it's probably the right moment  
to do something with that.

[1] http://code.djangoproject.com/ticket/6735

The attached code is built on top of this patch, I need to discuss  
with jkocherhans in order to avoid duplicate code but consider it more  
as a proof-of-concept for now, here is the (incomplete) doc:


 ModelView: a RESTful class-based view of your resources
 ===

 Philosophy
 --

 The goal of this class is to provide a lightweight REST  
interface, I know
 that django-rest-interface exists but it's abandoned and it  
suffers from
 some defaults. Given my experience with it, I always need to  
rewrite large
 parts of the library in order to customize it to fits with my own  
needs.

 In order to avoid this with ModelView, the philosophy is to allow
 dead-easy subclassing with granularity at each point.

 Note: I totally respect what had been done before and this class is
 inspired from a lot of existing projects so many thanks to all  
authors.


 Goals
 -

 Basically, it dispatches requests to the appropriated function  
given the
 HTTP verb and it allows you to specify a responder in order to  
avoid
 duplication of code at the resource logic level.

 You can specify your own responders, and restrict to allowed HTTP  
methods.

 Secret goal: to be honest, I dream of resource oriented stuff in
 Django's trunk for years now. A RESTful Django's (newforms-)admin  
could be
 awesome too in order to provide a built-in API!


 Example
 ---

 A quick example in order to demonstrate what is possible.

 models.py::

 class Post(models.Model):
 title = models.Charfield(max_length=200)
 slug = models.SlugField(max_length=200,  
prepopulate_from=('title',), unique=True)
 content = models.TextField()

 urls.py::

 blog = ModelView(Post.objects.filter(is_online=True),  
responders=(HtmlResponder, JsonResponder), methods=('GET',))
 blog_admin = ModelView(Post.objects.all(), methods=('GET',  
'POST', 'PUT', 'DELETE'))
 urlpatterns = pattern('',
 url(^blog/(?P[-\w]+)/(?P(html|json))?/?$),  
blog, name='blog'),
 url(^blog/admin/(?P\d)/), blog_admin,  
name='blog_admin'),
 )

 Note: here we consider that you want a custom admin for your blog,
 otherwise Django's built-in admin is much more interesting, of  
course.


 TODO
 

 * Add tests and documentation
 * Create a collection of generic Responders
 * Handle receivers in order to use it as an API (for the  
moment,
   it assumes that you receive formencoded data), need more  
reflexion.
 * Handle privacy, need more reflexion
 * See what can be done with APP, it could be fun!
 * Ideas?


I know that it needs tests and documentation but I'd like to bring the  
discussion here because I think it's important to have feedback before  
going too deep. So let me know if my secret goals above are crazy or  
if I need to spend more time on this.

Cheers,
David (aka david`bgk on #django-dev)



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

from django.core.exceptions import ObjectDoesNotExist, ImproperlyConfigured
from django.http import Http404, HttpResponse, HttpResponseNotAllowed
from django.views.generic.base import BaseDetailView


class HtmlResponder(object):
"""
HtmlResponder renders an object or a list of objects with the Django
templating system.
"""
def __init__(self, queryset):
self.queryset = queryset

def render_response(self, request, template, context_vars, mimetype=None):
"""
Returns an HttpResponse for the given request, template object,
dictionary of context variables, and optional mimetype.
"""
context = RequestContext(request, context_vars)
template = template.render(context)
return HttpResponse(template, mimetype=mimetype)

def get_template(self, opts, target='list'):
"""
Returns a loaded template, the template_name depends of the model name.

Examples::

blog/post_list.html
auth/user_detail.html

Re: Django-RDF

[David Larlet]

Stefan,

It looks really promising but it's really hard to evaluate it without  
any code (or detailled examples). I can't wait for the ready-for- 
release time :)
Is there any reason that you don't use any existing lib (rdflib,  
librdf, rdfalchemy, etc)?
Anyway, let me know if I can help, I'd just subscribed to the google  
group.

Cheers,
David

Le 10 mai 08 à 13:19, stefan a écrit :

>
> Hi there fellow Django enthusiasts,
>
> My name is Stefan, I'm a tech type like probably all of you, and I'm
> based in Iceland for the time being. This is my first post here,
> although, I've been lurking on django-devel for awhile. I started
> working with Django in fall 2006 and I've been playing with Python and
> RDF on and off since ca. 2003.
>
> I wanted to share a little project I've working on with you guys, in
> the hope that perhaps a couple of other folks might be interested in
> joining me?
>
> The project is a reusable app called Django-RDF, and it's aimed at
> providing unintrusive RDF support for Django.
>
> By unintrusive I mean, the Django-RDF app should work seamlessly with
> any existing Django projects without requiring changes to existing
> models, database setup, etc. Just, drop it into place.
>
> And, RDF support means two things first - having the ability to query
> models using SPARQL, and return data using RDF/XML (and later N3
> etc.).
>
> Then, third (and not quite as important to me as having seamless
> support for existing models) - also having the ability to store data
> in a triple store in case one might like a user-extensible data model,
> etc. Fun stuff, but regular models have better performance.
>
> I've got many of the basic pieces working, including a compiler that
> turns not-quite-SPARQL into SQL, models for storing ontology elements
> and implementing the triple store, and some view support that turns
> out RDF/XML - I think everything necessary for getting started, but
> not really anything more.
>
> Of course, all this stuff is brand new and hasn't been used in a
> production environment yet, so please be prepared for speedbumps if
> you decide to give it a try :)
>
> There is a couple of tarballs at http://code.google.com/p/django-rdf,
> one with the code and another with a set of RDF ontology files that
> were collected from various places and are used during initial setup.
> The Google Code page also has a bit more text describing the project.
> I'll be importing the SVN repo shortly, the code was wrapped up inside
> another project, needed to be cut out, and I still need to do a bit of
> trimming. And, I know I need to write instructions, etc. etc. All in
> good time. I'll try to respond fast as I can to your emails with
> questions, pointing at all the stuff that's not right yet, etc.
>
> I hope this will strike a chord with some of you guys - that would be
> highly motivating for me. Cheers,
> Stefan
>
>
> >


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: QSRF Related

[David Larlet]

Le 29 avr. 08 à 22:38, David Cramer a écrit :

>
> Yes im aware of the backwards incompatibility page but that mostly  
> covers the public api. A lot of time for our uses we have to go  
> beyond just using the public api. This is another situation where  
> having more releases could help :)

When you decided to use the trunk, each revision is a new version.  
It's your responsibility to follow at least those feeds:
http://code.djangoproject.com/log/django/trunk/docs?limit=10=stop_on_copy=rss
http://pipes.yahoo.com/pipes/pipe.run?_id=eBkuqM7C3BG9t0vuJhOy0Q&_render=rss

What if you need the doc for the revision just before the qs-fr merge?  
With the recent sphinx generator addition it's really easy to generate  
your own local copy of the documentation with your revision.

David
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: API question for model saving

[David Larlet]

Le 28 avr. 08 à 09:33, David Danier a écrit :

>
>> Sometimes when calling save(), we know (for business reasons) that it
>> must create a new object or raise an error. Similarly, in other  
>> cases,
>> it either must update an existing object or raise an error.
>
> I think discussion about this issue has been on this list before, last
> time someone suggested adding create() and update()...and keeping  
> save()
> as an method calling these two, like:
> -8<
> class Model(...):
>   def save(self, ...):
>   if self.has_pk() and self.pk_exists():
>   self.update()
>   else:
>   self.create()
>   def update(): ...
>   def create(): ...
> >8-
>
> So what is the big advantage of having an new parameter in save() like
> you suggested? With having create()/update() you can do similar  
> things.
>
> Additionally it would be possible to override only parts of the
> save()-logic in classes extending Model (for example when needing to
> calculate field-values on create, but not on insert...which is  
> currently
> difficult).
>
> And, of course, you would have no problems with naming the new  
> parameter
> and difficulties in creating self-explaining possible values ("not
> must_create", rather than "must_not_create").

I'm +1 on this solution, which turns the well known pattern:

def save(self):
if not self.id:
self.some_date = datetime.now()
super(Model, self).save()

to:

def create(self):
self.some_date = datetime.now()
super(Model, self).create()

BTW, create()/update() sounds more explicit to me than save().

David


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Easier URL patterns

[David Larlet]

Le 8 avr. 08 à 08:25, Adrian Holovaty a écrit :
>
> On Mon, Apr 7, 2008 at 3:49 PM, Rob Hudson <[EMAIL PROTECTED]>  
> wrote:
>> would be much less daunting to those that haven't read the Friedl  
>> book
>> than this:
>>
>>url(r'^(?P[-\w]+)/$', myview),
>
> Note that this example is more complicated than it needs to be. I'd
> write it like this:
>
>(r'^([-\w]+)/$', myview)
>
> I'm -1 on having multiple ways of specifying URL patterns. One of the
> points of a unified framework is to have One Clear Way to do things,
> and introducing a new scheme makes things more conceptually
> complicated. If we did indeed add this, then developers who wanted to
> reuse Django apps would have to know both pattern syntaxes -- unless
> we encouraged public-shared apps to use one particular URL pattern
> scheme over the other, in which case it defeats the purpose of having
> two.
>
> Note that it's entirely possible now, without modifying any of Django
> itself, to do this. Just write a wrapper around the patterns()
> function that parses the syntax and creates "real" regular
> expressions. Rob, if you're big on this idea, you should implement it
> and upload it to djangosnippets.org.

In this case, what about a default dictionary of popular regexps? I  
use it all the time:

re_urls = {
 'username': '(?P\w+)/',
 'pk_value': '(?P\d+)/',
 'foo_args': '(?P\d+)?/?',
 etc
}

urlpatterns = pattern('',
 url(r'%(username)s%(pk_value)s%(foo_args)s' % re_urls, myfunction)
)

Isn't it more readable? And it do not break anything.

David
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: GSoC proposal: Resource-based Models

[David Larlet]

Le 2 avr. 08 à 02:09, [EMAIL PROTECTED] a écrit :
>
>
> Models in Django are conceputally based on tables in a database. I'd
> like to enhance that with the introduction of resource-based models.
> The basic idea comes from Ruby on Rails' ActiveResource, which allows
> for interaction between two sites through a RESTful API. I would like
> to take this a step further and provide an implementation of this type
> of interface not bound specifically to REST. The interface will be
> generic enough to allow for different types of sources.

I couldn't be more interested in a GSoC because that's exactly what I  
miss in Django. Thanks for proposing that project, I really hope it  
will be accepted and count me on for extending the base with at least  
RDFModel once you setup the base. I'm already dreaming of some kind of:

   class User(models.RDFModel):
   user = whatever(DjangoUser.name)
   # mmh, I need more time to think about the way to declare triples

   class Meta:
   source = sources.FOAFSource()

Good luck!

Cheers,
David
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: django-restapi Improvements Proposal

[David Larlet]

Le 7 mars 08 à 20:26, Jared Flatow a écrit :

>
> On Mar 7, 2008, at 3:19 AM, versae wrote:
>> After working with great intensity with django-restapi we discovered
>> some fails and some unimplemented features,
>
> Anything in particular?

Same here, we (my team) need to fix a lot of things in the original  
restapi but your implementation looks really interesting!
Our main concerns were to handle:
* privacy at verb level and we use decorators too
* issues with caching when you use the same collection with different  
renderers or when you want to filter a queryset but you seemed to fix  
that point with the new implementation (I hadn't verified)
* ModelForm instead of model_for_* which are now deprecated (not  
finished, still in my todo), your implementation do not cover html yet

There are other custom additions but it's a bit specific to our  
application. We'll see that later.
>
>
>> but our code is so large,
>> and I don't know whether your code proposal is backward compatible or
>> whether it will be added to trunk of django-rest-interface.
>
> Its not backwards compatible, more of an alternative. It think it
> would be best if all REST interface development was focused on the
> same project (it seems spread thin enough as it is), which is why I
> haven't yet created another separate source tree.

I totally agree with that point. A branch of the actual project is  
sufficient.

>
>
>> Anyways, we will study your code and if you agree, we can contribute
>> in a branch leaded by you.
>
> I look forward to hearing your thoughts!

I'm with you too, happy to see that this project is still alive.

Cheers,
David


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: extends headaches

[David Larlet]

Thanks, I try to do my best and five mistakes in the same sentence is  
not that bad ;)

Cheers,
David

Le 7 févr. 08 à 15:31, J. Cliff Dyer a écrit :

>
> I made a couple of minor grammatical changes for clarity, but your
> english was pretty good, David.
>
> Cheers,
> Cliff
>
> On Thu, 2008-02-07 at 15:06 +0100, David Larlet wrote:
>>
>> Le 6 f�vr. 08 � 21:01, SmileyChris a �crit :
>>
>>>
>>> On Feb 6, 9:43 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
>>> wrote:
>>>> It already results in a broken site, we're now just being a lot
>>>> clearer
>>>> about that.
>>>
>>> Actually, it only resulted previously in a broken site if the  
>>> extended
>>> template was being used in more than one depth of inheritance.
>>>
>>>>
>>>> Still, it's a wiki, feel free to update it if you like.
>>>
>>> Yea, go ahead and update it David, I think it's fair enough.
>>>
>>
>> I'd tried to use my best english but corrections are welcome :)
>> http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges#Raiseerrorsifextendsisnotthefirsttagofatemplate
>>
>> Best,
>> David
>>
>>
>>>
>
>
> >


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: extends headaches

[David Larlet]

Le 6 févr. 08 à 21:01, SmileyChris a écrit :

>
> On Feb 6, 9:43 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
>> It already results in a broken site, we're now just being a lot  
>> clearer
>> about that.
>
> Actually, it only resulted previously in a broken site if the extended
> template was being used in more than one depth of inheritance.
>
>>
>> Still, it's a wiki, feel free to update it if you like.
>
> Yea, go ahead and update it David, I think it's fair enough.
>

I'd tried to use my best english but corrections are welcome :)
http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges#Raiseerrorsifextendsisnotthefirsttagofatemplate

Best,
David


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: [7084] extends headaches

[David Larlet]

Le 5 févr. 08 à 22:05, Malcolm Tredinnick a écrit :

>
>
> On Tue, 2008-02-05 at 16:14 +0100, David Larlet wrote:
>> Hello,
>>
>> I'd just updated my local version of django and it raises errors due
>> to 7084 changeset (extends should be the first tag). I put all my
>> extends tags above all my load tags in every templates and I realize
>> that it raises errors for comment tags too... I used to keep svn  
>> infos
>> at the top of every file and now I need to put extends tag at the top
>> of every templates, a bit annoying. I understand that it avoids some
>> errors but I think that we could make an exception for comment tags
>> and maybe load tags too. Any thoughts?
>
> Aah .. comment tags. Forgot about those. I'll fix it.

Ok thanks.
>
>
>> By the way, it could be interesting to list that as a new backward
>> incompatible change?
>
> No, it's not meant to be backwards incompatible for correct code.;  
> it's
> just raising more visible errors. Not having the extends tag first  
> (for
> some definition of "first") was an error in any case and usually  
> didn't
> work, but the failure was often disguised.

I agree with you that it's not a backward incompatible change, but  
imagine you've missed that point and you decide to update your copy of  
django, it will result in a broken site. I think that it could be  
interesting to communicate on that point.

Best,
David
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

[7084] extends headaches

[David Larlet]

Hello,

I'd just updated my local version of django and it raises errors due  
to 7084 changeset (extends should be the first tag). I put all my  
extends tags above all my load tags in every templates and I realize  
that it raises errors for comment tags too... I used to keep svn infos  
at the top of every file and now I need to put extends tag at the top  
of every templates, a bit annoying. I understand that it avoids some  
errors but I think that we could make an exception for comment tags  
and maybe load tags too. Any thoughts?

By the way, it could be interesting to list that as a new backward  
incompatible change?

Best,
David


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Add Add "georss" tag to feeds

[David Larlet]

Le 20 déc. 07 à 10:27, Daniel de la Cuesta a écrit :

> Hi all,
>
> I want to add the geo tag (with latitude and longitude) to each item  
> of my feeds:
>
> 45.256 -71.92
> I am using the feeds framework:
> class LatestEvents(Feed):title = "Latest Events"link  
> = "/events/"def items(self):return  
> Event.objects.order_by('-start_date')[:5]
> Is there any way to add the new node to each item returned by  
> "items()"
> Thank you.


Daniel,

Attached is my current solution which is not really elegant but works.  
That's why I cross post to the developers mailing-list, maybe we can  
find a better way to handle that? There is a lot of duplicate code in  
my solution (and maybe there is a better one?, let me know) but I  
could easily generate a patch against the trunk for that.

Btw, I had noticed a bug in the SyndicationFeed class of django  
feedgenerator, language is the only parameter where force_unicode is  
applied and it returns u"None". This "conversion" cause problem in the  
"if self.feed['language'] is not None:" test. If you replace  
force_unicode by to_unicode it works. I'd submitted a bug and a patch  
on Trac, see #6303.

While we are at feeds, I got a "cosmetic" question. It seems that each  
generated feed in Django is not highlighted by Firefox when you read  
the source. Is there a reason to that? I can't find a way to find the  
cause.

Thanks,
David


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

from django.utils.xmlutils import SimplerXMLGenerator
from django.utils.feedgenerator import SyndicationFeed, Atom1Feed, rfc3339_date, get_tag_uri

class GeoSyndicationFeed(SyndicationFeed):
def add_item(self, title, link, description, author_email=None,
author_name=None, author_link=None, pubdate=None, comments=None,
unique_id=None, enclosure=None, categories=(), item_copyright=None, 
ttl=None, georss=()):
"""
Adds an item to the feed. All args are expected to be Python Unicode
objects except pubdate, which is a datetime.datetime object, and
enclosure, which is an instance of the Enclosure class.
"""
super(GeoSyndicationFeed, self).add_item(title=title, link=link, 
description=description, 
author_email=author_email, author_name=author_name, 
author_link=author_link, pubdate=pubdate, comments=comments,
unique_id=unique_id, enclosure=enclosure, categories=categories, 
item_copyright=item_copyright, ttl=ttl)
self.items[-1]['georss'] = georss and u"%s %s" % georss or None


class GeoAtom1Feed(Atom1Feed, GeoSyndicationFeed):

def write(self, outfile, encoding):
handler = SimplerXMLGenerator(outfile, encoding)
handler.startDocument()
if self.feed['language'] != u'None':
handler.startElement(u"feed", {
u"xmlns": self.ns, 
u"xml:lang": self.feed['language'],
u"xmlns:georss": u"http://www.georss.org/georss;,
u"xmlns:gml": u"http://www.opengis.net/gml"})
else:
handler.startElement(u"feed", {
u"xmlns": self.ns,
u"xmlns:georss": u"http://www.georss.org/georss;,
u"xmlns:gml": u"http://www.opengis.net/gml"})
handler.addQuickElement(u"title", self.feed['title'])
handler.addQuickElement(u"link", "", {u"rel": u"alternate", u"href": self.feed['link']})
if self.feed['feed_url'] is not None:
handler.addQuickElement(u"link", "", {u"rel": u"self", u"href": self.feed['feed_url']})
handler.addQuickElement(u"id", self.feed['id'])
handler.addQuickElement(u"updated", rfc3339_date(self.latest_post_date()).decode('ascii'))
if self.feed['author_name'] is not None:
handler.startElement(u"author", {})
handler.addQuickElement(u"name", self.feed['author_name'])
if self.feed['author_email'] is not None:
handler.addQuickElement(u"email", self.feed['author_email'])
if self.feed['author_link'] is not None:
handler.addQuickElement(u"uri", self.feed['author_link'])
handler.endElement(u"author")
if self.feed['subtitle'] is not None:
handler.addQuickElement(u"subtitle", self.feed['subtitle'])
for cat in self.feed['categories']:
handler.addQuickElement(u"category", "", {u"term": cat})
if self.feed['feed_copyright'] is not None:
handler.addQuickElement(u"rights", 

Re: Django 1.0 features -- the definitive list

[David Larlet]

Le 30 nov. 07 à 07:33, Adrian Holovaty a écrit :
>
> Let's get a definitive list of features we want in Django 1.0, and
> let's release it.

Just great.
>
> Without further ado, here's my list:
>
> * newforms-admin
> * queryset-refactor
> * django.newforms becomes django.forms
> * Model-level validation
> * Change django.templatetags not to use __path__ hacking
> * #3591 -- Make INSTALLED_APPS an instance, and each app an instance
> * #5361 -- File storage refactoring
> * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
>
> What am I forgetting?

Maybe use request.DATA instead of POST as discussed in #5682? It's  
backward compatible and not a Big Stuff but can require a lot of  
changes if it becomes the right way to do®.

David


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: form_for_instance and form argument, empty form?

[David Larlet]

Marty Alchin a écrit :
> On 11/7/07, David Larlet <[EMAIL PROTECTED]> wrote:
>   
>> Unfortunately, what happens with my Form is exactly what I'd like to do:
>> create a generic form from a Form class which define fields (with
>> widgets, etc) and methods and which is initialized with the content of
>> the instance. That seemed more natural to me instead of dealing with
>> fields, form and eventually form_for_fields... I know that those
>> functions are just shortcuts but it works very well in terms of
>> genericity and my main concern here is to integrate a generic way to
>> handle forms for resources in restapi.
>> 
>
> Well, from what you posted before, your forms aren't really all that
> "generic", so I'm not sure exactly what you're trying to accomplish.
>   
Ok, my previous example is really basic to extract the issue but I need 
to explain the background now.

restapi [1] let you define resources which match a queryset. Those 
resources are python class (just read at the 5 steps on the homepage of 
the project to understand it well). When a request is done to the url, 
the class call the __call__ function and dispatch this one to the right 
function given the HTTP verb (to sum up).

Now let's focus on the form part. The python class (Collection) can be 
instantiated with a form_class argument which is used in all functions 
that require form_for_* and this is a key element here. You can have a 
look at the bottom of the responder file [2] to see what I mean. I 
didn't know that a BaseForm was required here when I'd proposed to add 
this argument [3] and I thought that it was a good way to have a generic 
form which can be customized.

Since your previous email, I'm a bit confused about that because I 
realize that it's a bit useless if I can't get my forms from instances 
rendered with instances' data. I hope this is more clear now (even if my 
english is not that good...).

[1] http://code.google.com/p/django-rest-interface/
[2] 
http://django-rest-interface.googlecode.com/svn/trunk/django_restapi/responder.py
[3] 
http://groups.google.com/group/django-developers/browse_thread/thread/f86bd8ea6579baaa/709fdf8e092084ea?lnk=gst

SmileyChris a écrit :
> On Nov 8, 4:30 am, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
>   
>> When you pass in a subclass of Form, it's already got its fields in
>> the right place, but more importantly, it triggers that syntax
>> checking again, where it looks for new fields. It basically copies
>> fields from a parent class, then adds in the fields that it found in
>> the new class. However, since form_for_model and form_for_instance
>> don't supply any fields that way, all it gives the new form is what it
>> found in the parent class, completely overwriting the fields it got
>> from form_for_*.
>> 
>
> Actually, I see no good reason why you shouldn't be able to use a Form
> as the SuperClass of your form_for_* form.
>
> I've just attached a patch to #3815 which makes it work.
>
>   
Did this patch populate form fields with instance data? I can't figure 
out this given the tests.

Regards,
David

PS: RajeshD let me know if you're on this list, otherwise I'll forward 
this email to you, I don't want to cross post anymore.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: form_for_instance and form argument, empty form?

[David Larlet]

Marty Alchin a écrit :
>>> On 11/7/07, David Larlet <[EMAIL PROTECTED]> wrote:
>>>   
>>>> Hi all,
>>>>
>>>> I'd spent a long time finding that bug but I want to be sure before
>>>> submitting it on Trac. If you pass a form argument to form_for_instance
>>>> like that:
>>>>
>>>> forms.form_for_instance(foo, form=FooForm)
>>>>
>>>> with an instance of foo which only contains a basic field (let's say a
>>>> CharField) and FooForm with a unique field too, the input rendered will
>>>> not be completed with the content of the foo instance. If you remove the
>>>> form argument:
>>>>
>>>> forms.form_for_instance(foo)
>>>>
>>>> the generated form contains the content of the foo instance.
>>>>
>>>> I'd tried to find the bug but this line (122 of newforms.models):
>>>>
>>>> return type(opts.object_name + 'InstanceForm', (form,),
>>>> {'base_fields': base_fields, '_model': model,
>>>>  'save': make_instance_save(instance, fields, 'changed')})
>>>>
>>>> give me headaches ;-). The only thing I can say is that base_fields
>>>> contains the initial data before this line but my returned form not.
>>>>
>>>> Did somebody use this argument and can confirm?
>>>> 
>
> I can confirm that it does in fact work as you describe, but I don't
> believe it's a bug. The only documentation I was able to find on this
> argument is in the docstrings for form_for_model and
> form_for_instance, both of which clearly state that it's intended to
> receive a subclass of BaseForm, not Form.
>   
You're absolutely right on that point. I just found it in the 
documentation too: 
http://www.djangoproject.com/documentation/models/model_forms/
> Here's the difference.
>
> BaseForm is what provides all the real functionality for the form:
> iterating over fields, triggering HTML output, managing validation,
> etc. It's not normally used outside of Django's internals, because the
> Form class subclasses it already. However, it doesn't know anything
> about how to get the fields for the form. Instead, the Form class uses
> a special way to pull fields out of the class definition and assign
> them where they belong. form_for_model and form_for_instance don't
> need this syntax, so they bypass that step by directly assigning the
> fields where they belong when they create the class.
>
> When you pass in a subclass of Form, it's already got its fields in
> the right place, but more importantly, it triggers that syntax
> checking again, where it looks for new fields. It basically copies
> fields from a parent class, then adds in the fields that it found in
> the new class. However, since form_for_model and form_for_instance
> don't supply any fields that way, all it gives the new form is what it
> found in the parent class, completely overwriting the fields it got
> from form_for_*.
>
> That was a bit of a long explanation, but I think it's necessary to
> know what's going on, and it leaves me with two more points.
>
> As for what that form argument was meant for, it's designed for a
> BaseForm subclass. This allows you to add *methods* to your generated
> form, not new fields.
>
> As for what you're trying to do, check out the 'fields' argument to
> form_for_instance. It creates a form with just a subset of the fields
> from the original model.
>   
Wow, thanks for this interesting explanation! I always wondered what's 
the difference between Form and BaseForm without digging too deep into 
the code. Now that's really clear.

Unfortunately, what happens with my Form is exactly what I'd like to do: 
create a generic form from a Form class which define fields (with 
widgets, etc) and methods and which is initialized with the content of 
the instance. That seemed more natural to me instead of dealing with 
fields, form and eventually form_for_fields... I know that those 
functions are just shortcuts but it works very well in terms of 
genericity and my main concern here is to integrate a generic way to 
handle forms for resources in restapi.

If you have any suggestion about that I'll be very happy to learn a bit 
more :)

David


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

form_for_instance and form argument, empty form?

[David Larlet]

Hi all,

I'd spent a long time finding that bug but I want to be sure before 
submitting it on Trac. If you pass a form argument to form_for_instance 
like that:

forms.form_for_instance(foo, form=FooForm)

with an instance of foo which only contains a basic field (let's say a 
CharField) and FooForm with a unique field too, the input rendered will 
not be completed with the content of the foo instance. If you remove the 
form argument:

forms.form_for_instance(foo)

the generated form contains the content of the foo instance.

I'd tried to find the bug but this line (122 of newforms.models):

return type(opts.object_name + 'InstanceForm', (form,),
{'base_fields': base_fields, '_model': model,
 'save': make_instance_save(instance, fields, 'changed')})

give me headaches ;-). The only thing I can say is that base_fields 
contains the initial data before this line but my returned form not.

Did somebody use this argument and can confirm?

Regards,
David


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Changes to request_response have broken django-rest-interface

[David Larlet]

2007/10/18, Malcolm Tredinnick <[EMAIL PROTECTED]>:
>
> On Tue, 2007-10-16 at 21:52 +0200, David Larlet wrote:
> > 2007/10/10, David Larlet <[EMAIL PROTECTED]>:
> > >
> > > BTW, no more thought about the way of handling PUT? I've just added a
> > > patch against test.client which add .put() and .delete(), I'm waiting
> > > for (a) reaction(s) to add tests and documentation.
> > >
> >
> > Sorry for insisting on that point but this is important to me, once
> > the decision is taken I can produce patches but I need your feedback
> > here to continue :)
>
> Well, since I'm working on Django on a totally volunteer basis and
> already have a fairly large prioritised list of things to do -- many of
> which, quite honestly, have a larger impact on the broader Django
> userbase than this one -- as well as day jobs that need attention in
> order to pay the bills, it would be impolite of me not to entirely
> reshuffle things to meet your needs then. :-(


I perfectly understand because I'm in the same situation. But
sometimes, when someone motivated ask me politely and when this item
just take me a couple of minutes, I decide to put this one in top of
my todolist because I know that my decision will have consequences and
maybe this guy is insisting because he's got time right now.


> My personal preference is to use request.DATA and keep request.POST
> around as a backwards compatibility feature for a release or two. That
> way PUT, POST -- and if somebody wants to use it later, OPTIONS, etc --
> can all use the same attribute, since you can only be doing one at a
> time. That saves having to add a new attribute for every potential HTTP
> verb (note that the set isn't restricted to just PUT, POST, GET and
> DELETE) and helps write common code for processing the data --
> request.method tells you the verb, request.DATA gives you the entity
> body.
>
> My second favourite preference is to add request.PUT, as
> django-rest-interface does at the moment.
>
> However, neither decision is binding until at least one other core
> maintainer steps in with some agreement or sufficient time passes that
> I'm convinced they really don't care which way we go.

Thanks for your answer, I agree with you that request.DATA could be
interesting. I will update my patches with this proposition given the
fact that Jacob agree with you.

David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Changes to request_response have broken django-rest-interface

[David Larlet]

2007/10/10, David Larlet <[EMAIL PROTECTED]>:
>
> BTW, no more thought about the way of handling PUT? I've just added a
> patch against test.client which add .put() and .delete(), I'm waiting
> for (a) reaction(s) to add tests and documentation.
>

Sorry for insisting on that point but this is important to me, once
the decision is taken I can produce patches but I need your feedback
here to continue :).

Cheers,
David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Changes to request_response have broken django-rest-interface

[David Larlet]

2007/10/8, Peter Nixon <[EMAIL PROTECTED]>:
>
> Hi David
>
> Thanks for doing this. I have written a patch for mod_python and added it to
> the ticket. I have tested it and deployed it with a patched rest api in
> production ;-)
>
Ok, can you add your patch against django.http.__init__.py too, you
seemed to have modified parse_file_upload and QuerySet given returned
arguments.

BTW, no more thought about the way of handling PUT? I've just added a
patch against test.client which add .put() and .delete(), I'm waiting
for (a) reaction(s) to add tests and documentation.

Cheers,
David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: django-rest-api use [was Re: Changes to request_response have broken django-rest-interface]

[David Larlet]

2007/10/7, Malcolm Tredinnick <[EMAIL PROTECTED]>:
>
> The Resource class is quite as independent from everything as we would
> have liked. I say "we" here because towards the end of the SoC period,
> Andreas and I spent quite a long time trying to loosen a few of the
> couplings between output classes and the representation classes --
> Collection and Responder, in particular -- and we both felt it wasn't as
> neat as it could be, but we couldn't see how to improve it. That's
> probably still work in progress.

Yes, I have two issues here:
* The first one is about having an optional generic form because it's
a common use (at least for me) to have the create/update form in the
same page of the resource. I had to create my own BaseCollection and
BaseTemplateResponder to handle that case.
* The second is for adding a new function to the responder, I need to
curry this function in the __init__ of the Collection. Not really
elegant.

Unfortunately, I haven't a neat solution here...

>
> My own mental measuring stick during the whole project was to imagine a
> case where I was implementing Atom Publishing and using many models to
> represent what became a single article resource in the public interface
> (I have images, text, metadata, possibly a model with links in it for
> validation in the future, etc). You can fit this into Resource
> subclasses, but the amount of work you end up doing never really
> convinced me that the framework was helping me here. It felt like the
> same amount of work as if I did it from scratch, so where was the clear
> win in using the framework for this case and did it even feel wrong not
> to use it? Again, this isn't a mark against Andreas work, but was more a
> case of me trying to test the boundaries.
>

I agree, the other major headache is for resources which don't fit a
model. Maybe we can think about some basic examples for this part
because it's hard to speak about that without some concrete things.

> I should talk to Andreas about posting some of the discussions we had
> and where we left of on the wiki and creating a project mailing list so
> that other people can get in on the fun here.

Great idea, I'll be glad to help you (if I can).

Regards,
David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Changes to request_response have broken django-rest-interface

[David Larlet]

2007/10/7, Malcolm Tredinnick <[EMAIL PROTECTED]>:
>
> On Sun, 2007-10-07 at 02:39 +0200, David Larlet wrote:
> >  The
> > option (3) seems more natural to me to make the difference between
> > what you post and the POST verb, it's more explicit. What about
> > self.PUT in this scenario?
>
> That's called option (2). :-)
>

+ self.DATA?

> There are a lot of cases that Andreas' work doesn't cover, since REST is
> a very broadly applicable theory. That was one of the challenges of the
> project: working out what areas needed help and where we would just be
> adding constraints or creating equivalent amounts of work. As soon as
> you start to move to situations where your publically exposed resources
> don't map more or less one-to-one onto models, things become a lot
> trickier and we haven't quite solved that -- partly because I suspect
> it's not really solvable.
>
> My point here is not in any way to diminish the work Andreas has done or
> the use you are getting from it. In certain scenarios, it is obviously a
> great help and he's done some excellent design and implementation. I was
> very happy with the work Andreas did. However, some perspective is
> necesary. My point *is* to say that there are uses for PUT and POST
> beyond django-rest-api and there are plenty of situations where I would
> directly implement the handling, rather than using the django-rest-api
> classes. So we are looking for a consistent Django solution here, rather
> than just something that works smoothly with django-rest-api.
>
> It's that former case where I'm thinking there might be a reasonable
> overlap in the code between PUT and POST handling. I'm still not sure
> about this -- it's going to take a little more mulling over.

Ok, I do agree and I understand. I will answer on the second thread
about resources which not fit a one-to-one model.

> > I think too, given the success of the last one, what about some kind
> > of GSoC or REST sprint? At this point, it could be interesting to end
> > with something which can be merged to the trunk.
>
> I'm not against sprints, but we're talking about a very small change
> here.
>
> The reason we asked GSoC students to develop their apps as third-party
> applications this year was to precisely avoid any rush to inclusion.
> Django-rest-api is a perfect example: with the exception of needing PUT
> support in HttpRequest, there's no changes required to core, so there's
> no real need to include it in core. Maybe, one day, it might be a
> candidate for django/contrib/, but it's not at that point yet and for
> the time being, hosting at Google is great because it gives Andreas --
> and anybody else who wants to contribute -- an issue tracker, subversion
> hosting and the whole enchilada without any fuss. So let's stay focused
> on adding PUT support to HttpRequest in this thread.

Ok, that's just that in the initial proposition, the last point is
"Prepare the code to be merged to trunk" so I thought that it was one
of the goals but I agree that it could be kept as a third party app
for the moment.

Regards,
David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Changes to request_response have broken django-rest-interface

[David Larlet]

2007/10/6, Malcolm Tredinnick <[EMAIL PROTECTED]>:
>
> I had a quick read of it. Looks like you're on the right track.

Thanks for your reactivity.

>
> The main problem I see with it is that you're over-populating the data
> structures a bit. If the request is a PUT, you're still populating
> self.POST as a side-effect. We should neaten this up a bit.
>
> When I started to think about this and how we would use it, it's not a
> complete no-brainer and I'm beginning to think my original suggestion
> (and what Andreas implemented in django-rest-interface) might not be the
> easiest for end users (third-party programmers like yourselves). A
> couple of possibilities spring to mind:
>
> (1) We always populate self.POST and only self.POST. Since the
> recommended way to check the method is to check request.method first, it
> means the same code can potentially be used to handle PUT and POST data.
>
> (2) We populate self.POST if request.method == 'POST' and self.PUT if
> request.method == 'PUT' and leave the other one blank.
>
> (3) We leave self.POST available for backwards compatibilty, but use a
> more generic name like self.DATA for the data we extract. This is a
> version of (1) with renaming involved.
>
> Right at the moment, I'm probably slightly in favour of option (1)
> because it's the smallest change and we can think of self.POST as "the
> posted data" regardless of how the HTTP verb is spelt. Code will act
> based on request.method, but there are more possibilities for factoring
> out common pieces when working with the data.

I'm not sure that "smallest change" should drive the decision, even if
I admit that a backward incompatible change could be a pain. The
option (3) seems more natural to me to make the difference between
what you post and the POST verb, it's more explicit. What about
self.PUT in this scenario?

>
> So then the only change that is needed is to also populate that field
> when the method is "PUT" (with accompanying changes in HttpRequest).
>
> I'd be interested in hearing your thoughts, Peter and David, on this,
> since you've already got experience using that piece of the framework.
> Is there a lot of commonality between the way you're handling the PUT
> and POST paths? I know it's a slight change to Andreas' code, but it's
> not too intrusive from the looks of it. [Andreas: have I forgotten some
> subtlety here?]

The current standard solution of restapi, which get data given the
receiver looks enough flexible to me. I never had to factorize PUT and
POST because restapi already handle this for me.

> > * did I need to write tests for this new verb?
>
> Ideally, yes. It will probably require some changes to
> django.test.client to allow the news type of request. Then some
> additions to tests/modeltests/test_client would be appreciated.

Yes, I need client.put() and client.delete() for my personal use so I
can provide a patch for this part. It'll require some documentation
too, not that trivial patch eventually :).

>
> > * did I have to do something in django.http.HttpRequest?
>
> Yes. Search for wherever POST is referenced there and you'll need
> something similar for PUT. __getitem__ and _set_encoding are the two
> obvious places, although the latter one might be made moot if we put all
> the data into request.POST regardless of the verb. In that case, though,
> we'll need to make some of the errors and the __repr__ formats clearer,
> since referring unambiguously to "POST" may be confusing.

I had attached a patch for http.HttpRequest, it probably evolves given
the final decision we'll take but let me know if it's what you
thought.

>
> I understand that you guys are eager to get something done here so you
> can continue to track Django's trunk, so I'll try to respond quickly in
> this thread. But right at the moment, the design is as good as I think
> it can be, so let's take a moment to work on that. We're pretty close,
> though.

I think too, given the success of the last one, what about some kind
of GSoC or REST sprint? At this point, it could be interesting to end
with something which can be merged to the trunk.

Regards,
David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Changes to request_response have broken django-rest-interface

[David Larlet]

2007/10/5, Malcolm Tredinnick <[EMAIL PROTECTED]>:
>
> On Fri, 2007-10-05 at 16:17 +0300, Peter Nixon wrote:
> > On Thu 04 Oct 2007, Malcolm Tredinnick wrote:
> > > On Thu, 2007-10-04 at 18:10 +0300, Peter Nixon wrote:
> > > > I tried to open the following ticket but it thinks my IP is a spammer,
> > > > so I am sending to the list:
> > > >
> > > > http://django-rest-interface.googlecode.com/svn/trunk/django_restapi/res
> > > >ource.py tries to set "request.method = 'POST'" in order to run PUTs
> > > > through request._load_post_and_files() as POSTs as
> > > > _load_post_and_files() does not currently seem to support PUT. This used
> > > > to work, however current django SVN seems to have broken it. This
> > > > breakage seems to be by design as the HttpRequest doc says "All
> > > > attributes except session should be considered read-only." I am not the
> > > > author of django-rest-interface but I am using it in production.
> > > >
> > > > Can request._load_post_and_files() be updated to support PUT also in
> > > > order to fix this issue??
> > >
> > > The current django-rest-interface approach was a bit of a hack that
> > > turned out to pretty well so that we didn't need to change core at the
> > > time. We should get around to adding PUT support to HttpRequest, though,
> > > you're right.
> > >
> > > I've created ticket #5682 for this. It's a really trivial change (you've
> > > seen how simple it is in django-rest-interface), so shouldn't take too
> > > long to fix.
> >
> > Hi Malcolm
> >
> > Aside from the BIGINT patch (which still hasn't been applied) I haven't done
> > much hacking on Django internals so it is not so trivial for me. :-)
> >
> > I have been reading through ModPythonRequest, HttpRequest and
> > http://www.b-list.org/weblog/2006/jun/13/how-django-processes-request/ and
> > think I have almost got a handle on it. Do you think you will have a chance
> > to look at this soon or should I try to patch it myself?
>
> I would encourage you to try it yourself.
>
> It shouldn't be too hard.. let me point you at the right place. Have a
> look in django/core/handlers/*.py for where we set up the GET and POST
> properties (wsgi.py and modpython.py). It should be as simple as
> creating an analogous thing for PUT and then altering the call to
> _load_post_and_files so that it only populates POST or PUT when the
> method is appropriate.
>

Hi malcolm,

I use django-rest-interface too and I have this bug which need to be
quickly fixed so I submitted a patch which need review on  #5682, let
me know if I need to do something else. I will add a patch for
modpython too when this one will be accepted.

Peter, you can test it too, it solves the bug with django-rest-interface.

Two questions:
* did I need to write tests for this new verb?
* did I have to do something in django.http.HttpRequest?

Regards,
David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: GenericForeignKey and GenericRelation, possible bug?

[David Larlet]

2007/9/6, David Larlet <[EMAIL PROTECTED]>:
> Hi all,
>
> Before submitting a bug I'd like to be sure that it hadn't been done
> intentionally, here is the issue:
>
> I had a model with two GenericForeignKeys which where defined like that:
>
> class Foo(models.Model):
> item = generic.GenericForeignKey(ct_field="item_content_type",
> fk_field="item_object_id")
> item_content_type = models.ForeignKey(ContentType, related_name="item")
> item_object_id = models.IntegerField()
>
> step = generic.GenericForeignKey(ct_field="step_content_type",
> fk_field="step_object_id")
> step_content_type = models.ForeignKey(ContentType, related_name="step")
> step_object_id = models.IntegerField()
>
> It works but now I want to retrieve my Foo object from the Bar model
> for example:
>
> class Bar(models.Model):
> foo = generic.GenericRelation(Foo)
>
> Here I can't access the foo attribute from a Bar instance because the
> GenericRelation do not seemed to handle specific ct_field and fk_field
> in GenericForeignKey. I suspect this part of the GenericRelation's
> code with hard-coded "object_id" name:
>
> self.object_id_field_name = kwargs.pop("object_id_field", "object_id")
> self.content_type_field_name = kwargs.pop("content_type_field", 
> "content_type")
>
> Any thought before I hack my django in order to find a patch?

Ok, thanks to a previous message I found the solution:
http://groups.google.com/group/django-developers/browse_thread/thread/5c440115389b56a6/3139d2e61b81b908

I need to specify fields in my GenericRelation definition:
foo = generic.GenericRelation(Foo,
object_id_field='item_object_id',
content_type_field='item_content_type')

But I agree with webograph that it violate the DRY principle...

David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

GenericForeignKey and GenericRelation, possible bug?

[David Larlet]

Hi all,

Before submitting a bug I'd like to be sure that it hadn't been done
intentionally, here is the issue:

I had a model with two GenericForeignKeys which where defined like that:

class Foo(models.Model):
item = generic.GenericForeignKey(ct_field="item_content_type",
fk_field="item_object_id")
item_content_type = models.ForeignKey(ContentType, related_name="item")
item_object_id = models.IntegerField()

step = generic.GenericForeignKey(ct_field="step_content_type",
fk_field="step_object_id")
step_content_type = models.ForeignKey(ContentType, related_name="step")
step_object_id = models.IntegerField()

It works but now I want to retrieve my Foo object from the Bar model
for example:

class Bar(models.Model):
foo = generic.GenericRelation(Foo)

Here I can't access the foo attribute from a Bar instance because the
GenericRelation do not seemed to handle specific ct_field and fk_field
in GenericForeignKey. I suspect this part of the GenericRelation's
code with hard-coded "object_id" name:

self.object_id_field_name = kwargs.pop("object_id_field", "object_id")
self.content_type_field_name = kwargs.pop("content_type_field", "content_type")

Any thought before I hack my django in order to find a patch?

Regards,
David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Time for a new release?

[David Larlet]

2007/8/26, James Bennett <[EMAIL PROTECTED]>:
>
> On 8/26/07, David Larlet <[EMAIL PROTECTED]> wrote:
> > I agree that users do not try to read the local docs for the moment,
> > but maybe it's because the ReST style discourage them to do so. Let's
> > try to add html doc with the djangoproject's css and maybe more users
> > will use local docs. A lot of people don't even know the rst2html
> > command...
>
> I don't mean "users don't read the docs they got with the download", I
> mean "they don't know the docs are in the download". Hang out on IRC
> for a while and watch how often people ask "where can I get a copy of
> the Django documentation to read offline?"

I know, I'm here for months (david`bgk). Of course, this new addition
need to be documented.

>
> > About the release question, before voting can we have an estimation of
> > how far the newforms-admin branch is ready for the trunk? (did we
> > speak about days or weeks or months?)
>
> I don't think it's really something that'll be voted on, at least not
> in a broad general sense. If releases happened based on people in the
> mailing list saying they want it to happen, we'd be on Django 3000 by
> now ;)
>
> Given that one of our much-loved BDFLs (Adrian) seems to be against it
> and our release manager (me) seems to be against it, I don't think
> there'll be a release just yet...
>

Make sense (but you didn't answer my questions ;-)).

David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Time for a new release?

[David Larlet]

2007/8/26, Simon Greenhill <[EMAIL PROTECTED]>:
>
> On Aug 26, 9:56 pm, "David Larlet" <[EMAIL PROTECTED]> wrote:
> > I agree that users do not try to read the local docs for the moment,
> > but maybe it's because the ReST style discourage them to do so. Let's
> > try to add html doc with the djangoproject's css and maybe more users
> > will use local docs. A lot of people don't even know the rst2html
> > command...
>
> There are two tickets outstanding for a similar issue -
>
> #528 (add a local PDF/HTML docs generator)
> #4940 (have downloadable PDF versions of the docs).
>
> Please feel free to get stuck into implementing these :-) If we could
> provide a
> downloadable "bundle" of docs per version, this could help sort this
> problem out
>

Assuming you've got rst2pdf linked in #4940 and pdftk, you can
generate a huge (364 pages!) pdf with those commands:

$ for i in $(ls docs); do python rst2pdf.py docs/$i; done
$ pdftk docs/*.pdf cat output django_doc.pdf

At this point, it could be interesting to decide if we need a specific
order, fancy output, etc.

David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Time for a new release?

[David Larlet]

2007/8/26, James Bennett <[EMAIL PROTECTED]>:
>
> On 8/26/07, Nicola Larosa <[EMAIL PROTECTED]> wrote:
> > They shouldn't have to go the web site: the release docs should be on their
> > disk, within the installed release itself (see my other message).
>
> See above. I'm sure you mean well, but the experience of seeing people
> actually work with Django and its documentation is against you on that
> point.
>

I agree that users do not try to read the local docs for the moment,
but maybe it's because the ReST style discourage them to do so. Let's
try to add html doc with the djangoproject's css and maybe more users
will use local docs. A lot of people don't even know the rst2html
command...

About the release question, before voting can we have an estimation of
how far the newforms-admin branch is ready for the trunk? (did we
speak about days or weeks or months?)

David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: GSoC 2007 Status Update VII: Django REST interface

[David Larlet]

2007/8/19, Andreas Stuhlmüller <[EMAIL PROTECTED]>:
>
> On 8/17/07, David Larlet <[EMAIL PROTECTED]> wrote:
> > Just one (latest?) thought, it's a bit hard to debug because
> > 400 errors are not really verbose, is it possible to find a
> > way to make debug easier? For the moment, I have: if
> > settings.DEBUG: print i.errors but I'm sure it can be better.
>
> I made the 400 error template a bit more verbose. The responder
> classes that use serializers include the model errors in their
> responses anyway. Is this what you were looking for?

Exactly, thanks for your pointer.

>
> > In fact, the problem is that you use ResourceForm in
> > model_resource and it could be interesting to use the given
> > form_class instead.
>
> You're right, it might be nice to be able to change the validation and
> data cleanup behavior of resources. Check out the latest revision and
> tell me if this is along the lines you were thinking.
>

That's what I had in mind, thanks for your reactivity.

Two little "issues" (maybe issues should be submitted to the google project?):

* in TemplateResponder.update_form(), the 'update' var allow to deal
with different forms in the same template (add the hidden fake PUT
field for instance) but given the fact that there is no 'update' var
in the create_form() function, you can't simply use {% if update %},
simple patch: add 'update': False.

* in update_form(), you test if request.PUT: but AFAIK with the
middleware you can't do that, you should test with if request.method
== 'PUT':

David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: GSoC 2007 Status Update VII: Django REST interface

[David Larlet]

2007/8/13, Andreas Stuhlmüller <[EMAIL PROTECTED]>:
> I added code for forms to TemplateResponder (create_form,
> update_form), an example that shows how to use this code and another
> example that shows how to specify the data format at the end of your
> URLs.

I didn't know the curry function, very interesting!

> A few days ago, I started writing a short tutorial [2] that describes
> how to provide an API for an existing Django application using the
> REST interface. If you have any questions, ideas, can't get the
> interface to work or want to contribute bugfixes and other
> enhancements, please go ahead.
>

Just one (latest?) thought, it's a bit hard to debug because 400
errors are not really verbose, is it possible to find a way to make
debug easier? For the moment, I have: if settings.DEBUG: print
i.errors but I'm sure it can be better.

Regards,
David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: GSoC 2007 Status Update VI: Django REST interface

[David Larlet]

2007/8/12, Andreas Stuhlmüller <[EMAIL PROTECTED]>:
>
> On 8/11/07, David Larlet <[EMAIL PROTECTED]> wrote:
> > Here is my suggestion: the current forms from model or instance are
> > great but you often need a custom form, what about an extra-argument
> > to the collection (better because I already need a form in the
> > collection in order to return a creation form on the list view, about
> > that if you have better idea...) or the responder with the form class?
>
> Forms seem to be relevant only if you use TemplateResponder, therefore
> I am against adding form-specific code to ModelResource. You can
> already specify extra_context for TemplateResponder. Might that be
> sufficient?

In fact, the problem is that you use ResourceForm in model_resource
and it could be interesting to use the given form_class instead.
That's why I'm more interested in a resource argument.

About extra_content, when I'd like to give a form_class, I get an
instance in my dict which is not what I expected (I just want the
class). Maybe I haven't done the right thing? Can you put an example
of the use of extra_content to give a form class to the responder?

> > About urls, how can I get a "reversed url". For example, is it planned
> > to deal with {% url %} tag and permalink? I've tried to do this
> > without any success.
>
> This should definitely be possible, but I have not found an elegant
> way to do this yet.

Ok, thanks for your answer. My main concern is about the possibility.

Regards,
David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: GSoC 2007 Status Update VI: Django REST interface

[David Larlet]

2007/8/5, Andreas Stuhlmüller <[EMAIL PROTECTED]>:
>
> I am currently reading "RESTful Web Services" by Leonard Richardson
> and Sam Ruby. See [3] for a summary of the main points from the
> chapter on best practices for REST-oriented architectures with short
> notes on where the REST interface still needs improvement.

Really interesting summary, thanks for this work.

>
> If you feel that there are important issues I am missing, please write
> me or just open a ticket [4].

Here are some random thoughts:

* What about additional pages like: create form, update form, delete
confirmation and so on? I've just noticed the get_create_form at the
end of the TemplateResponder but how can I redirect to this function?
(I haven't seen how to do this in url generation.)
* How can I deal with custom forms for a resource?
* Is it possible to specify the format at the end of an url or will it
break the parsing?

And last but not least, what is the current stability? I need to use
this kind of library now and even if I develop my own last week which
fits my needs, I hope this one will replace it soon because I don't
want to break all my code once this project is merged to the trunk.

Regards,
David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: GSoC 2007 Status Update IV: Django REST interface

[David Larlet]

2007/8/3, Andreas Stuhlmüller <[EMAIL PROTECTED]>:
>
> On 7/13/07, David Larlet <[EMAIL PROTECTED]> wrote:
> > * About users, how can I handle django users' permissions? John
> > Sutherland had already done some work on django-crudapi [1] and it
> > could be interesting to allow this access control.
>
> Good question. I would subclass one of the authentication classes,
> e.g. HttpBasicAuthentication, and add a has_perm() check dependent on
> the request method to is_authenticated().
>
> Currently, REST authentication is independent from Django's
> authentication middleware. It might make sense to move most of the
> code in HttpBasicAuthentication and HttpDigestAuthentication to
> django.contrib.auth.backends and to let the middleware do most of the
> work.
>

Sounds good to me.

> > I'm not fond of CRUD names and I prefer to keep an information on
> > the HTTP verb in the function name but it's maybe personal.
>
> I chose the CRUD names as they better describe what the methods
> actually do, but if the consensus is that it is more important to
> highlight the HTTP method, I will change this.

Eventually, I'm not against CRUD names but maybe we could be
consistent with rails ones?

> Thanks for your comments!
>
Thanks for your answer :)

Regards,
David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Proposal: QuerySet.exists() method

[David Larlet]

2007/7/14, Gary Wilson <[EMAIL PROTECTED]>:
>
> James Bennett wrote:
> > On 7/13/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> >> I'm biased, because I have an immediate need for this in a project,
> >> but this seems general and useful enough for inclusion in QuerySet.
> >
> > Implementing the check in __nonzero__ and having people test by doing
> > 'if some_queryset' or 'if not some_queryset' feels more Pythonic,
> > while implementing it as a specialized 'exists' method feels closer to
> > SQL. Since the Django ORM already leans more toward the Python side
> > than the SQL, I'd say do __nonzero__ and advise boolean checks on
> > QuerySets instead of implementing a method to do the same.
>
> I agree, James.  I'm +1 for __nonzero__ and -1 for .exists()
>

I agree too, if documentation is a problem it can be resolved with a
simple example. So I'm +1 for __nonzero__ and -1 for .exists()

David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: GSoC 2007 Status Update IV: Django REST interface

[David Larlet]

2007/6/23, Andreas Stuhlmüller <[EMAIL PROTECTED]>:
>
> As always, criticism, ideas and suggestions are welcome!
>

Ok let's go :-)

First of all, thanks for your awesome work, I eventually take time to
review it and it sounds exactly what I expected. Here are some random
thoughts about the current implementation:

* About users, how can I handle django users' permissions? John
Sutherland had already done some work on django-crudapi [1] and it
could be interesting to allow this access control.

* About dispatch, why don't you use the __call__ trick? Joe Gregorio
uses it in djangocollection [2] and I find it really elegant. That the
way Jacob Kaplan Moss describes RESTful web services in django too in
the RESTful Web Services book [3] (which I recommend BTW).

* About functions' names, I'm not fond of CRUD names and I prefer to
keep an information on the HTTP verb in the function name but it's
maybe personal.

* About verbs, I know this is not really GSoC related but what is the
recommended way to handle fake PUT and DELETE from a browser? The
HttpMethodMiddleware[4]? Maybe a simple form/deletion in the polls
application will be an interesting example for a real django case.

Best regards,
David

[1] http://django-crudapi.googlecode.com/svn/trunk/views.py
[2] http://djangocollection.googlecode.com/svn/trunk/djcollection/views.py
[3] http://www.crummy.com/writing/RESTful-Web-Services/
[4] http://www.djangosnippets.org/snippets/174/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Status of contrib.comments rewrite?

[David Larlet]

2007/6/26, Jacob Kaplan-Moss <[EMAIL PROTECTED]>:
>
> On 6/26/07, David Larlet <[EMAIL PROTECTED]> wrote:
> > I'm just curious, I've read somewhere (maybe here) that the
> > contrib.comments package need to be rewritten in order to allow more
> > flexibility (like user.get_profile) and to use newforms. I thought
> > that's the main reason why this part is not documented.
> >
> > What's the status of this update? Did someone is already on this?
>
> I'm working on it; pretty close to a call-for-comments (sorry :) stage.
>
> Stay tuned,
>

There is some kind of magic stuff in django development that make
things happens just when I need it. Thank you all devs, definitely.

David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Status of contrib.comments rewrite?

[David Larlet]

Hi,

I'm just curious, I've read somewhere (maybe here) that the
contrib.comments package need to be rewritten in order to allow more
flexibility (like user.get_profile) and to use newforms. I thought
that's the main reason why this part is not documented.

What's the status of this update? Did someone is already on this?

David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: 'retrieve': the missing permission?

[David Larlet]

2007/6/20, David Larlet <[EMAIL PROTECTED]>:
> 2007/6/20, Gábor Farkas <[EMAIL PROTECTED]>:
> >
> > David Larlet wrote:
> > > 2007/6/18, David Larlet <[EMAIL PROTECTED]>:
> > >> Hi,
> > >>
> > >> I've just tried to use the permission_required decorator for my views
> > >> and I realise that there is a missing 'retrieve' permission. It's a
> > >> bit odd because others ones follow the CRUD permissions.
> > >>
> > >> Am I missing something here?
> > >>
> > >> The patch is trivial:
> > >> Add 'retrieve' to the auth.management._get_all_permissions function,
> > >> but I don't want to hack my django code so I wonder why this choice
> > >> had been done? (I suspect the admin goal which is driven by the
> > >> User.is_staff field but auth can be used elsewhere).
> > >>
> > >> David
> > >>
> > >
> > > Am I the only one who deal with this kind of permission issue? Or
> > > maybe there is an evident solution that I haven't found yet?
> >
> >
> > you can create your own permissions:
> >
> > http://www.djangoproject.com/documentation/model-api/#permissions
> >
>
> I know this solution which require to modify all my models or, easier,
> to hack the auth.management._get_all_permissions function as I said
> before.
>
> I just wonder why this permission is not part of the default
> permissions (like add, change and delete)?
>
> David
>
No more thoughts about that? I'm really surprised that it only happens
to me, maybe I will be luckier on the users' mailing-list?

David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

'retrieve': the missing permission?

[David Larlet]

Hi,

I've just tried to use the permission_required decorator for my views
and I realise that there is a missing 'retrieve' permission. It's a
bit odd because others ones follow the CRUD permissions.

Am I missing something here?

The patch is trivial:
Add 'retrieve' to the auth.management._get_all_permissions function,
but I don't want to hack my django code so I wonder why this choice
had been done? (I suspect the admin goal which is driven by the
User.is_staff field but auth can be used elsewhere).

David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: signals

[David Larlet]

2007/6/10, Brian Harring <[EMAIL PROTECTED]>:
> Curious, how many folks are actually using dispatch at all?

I use signals this way:
http://groups.google.com.mt/group/django-users/browse_thread/thread/dcc8ed4b26fd261c/12a19040ad7af699?lnk=gst=2#12a19040ad7af699
and it can be useful too when you need to send mass mail at each
modification of an object.

David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Ping: Extend "for" tag to allow unpacking of lists

[David Larlet]

2007/6/5, SmileyChris <[EMAIL PROTECTED]>:
>
> Ticket http://code.djangoproject.com/ticket/3523 has been sitting
> quietly for a couple of months as a design decision and it's a
> reasonably common question in the IRC channel so I thought I'd ask a
> core developer for a decision.
>

I'm not a core dev but as a daily user, this patch is really
interesting/pythonic so I'm definitely +1.

David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

archive_year generic view and object_list order

[David Larlet]

Hi,

I just wonder why the archive_year function returns an object_list
(with make_object_list parameter to True) which is ordered by
date_field. I know that I can use the reverse argument in for loop tag
but I wonder if I'm the only one to have this issue? What order did
you expect by default? I think the Meta one is better...

David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: RESTful web services for Django

[David Larlet]

First of all, thanks for your GSoC proposition, it looks very
interesting and I hope it will be integrated to the trunk at the end
of the summer because I really need it ;-).

2007/5/8, Andreas Stuhlmüller <[EMAIL PROTECTED]>:
>
> I will try to come up with a concrete example that allows me to
> illustrate the different ideas I have, both regarding part 1 and part
> 2 of my proposal, and that makes it easier to discuss these ideas.

I agree with you, it's hard to discuss high-level abstraction without
a concrete example. I have collected all REST relative links during
the last months on the feature grouping page:
http://code.djangoproject.com/wiki/FeatureGrouping#WebservicesREST

Hope it helps, I'm waiting for the example to comment your choices.

David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: GSoC status?

[David Larlet]

2007/4/29, Jay Parlar <[EMAIL PROTECTED]>:
>
> On 4/28/07, David Larlet <[EMAIL PROTECTED]> wrote:
> > I just hope those ones will be successful! Maybe we can learn from the
> > past and improve students/dev communication in order to help them a
> > bit more if they need it?
>
> I think for the most part, in terms of the scope of GSoC, the previous
> ones were successful. It seemed like most of the hard work was done,
> for each of the branches. (At least, auth and rlp seemed to do quite
> well).
>
> Problem was there wasn't enough demand/interest in the community to
> get them fully integrated, no one was stepping up to take over. There
> were always people (myself included) that wanted to use the various
> branches, but no one was willing to put the time in to make them trunk
> ready.
>
> The one problem with GSoC is that while students may have lots of time
> in the summer, that time tends to go towards zero once September hits
> :)
>
> I guess it all just depends on your measure of "success".

Of course :-)
To be clear, let's call success == integration in trunk. I just
pointed out that maybe a better communication will result as a better
involvement for both parties (students and devs) and more people will
test the branch in order to integrate this work in the trunk. As far
as I remember, students have time, they only need motivation. If they
work alone for six months, I think it will reduce their motivation.

David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: GSoC status?

[David Larlet]

2007/4/28, James Bennett <[EMAIL PROTECTED]>:
>
> On 4/28/07, David Larlet <[EMAIL PROTECTED]> wrote:
> > I'm just curious about SoC, especially the REST one, listed on this
> > page: http://code.google.com/soc/django/about.html
> >
> > Maybe it's time to make an "official" announcement?
>
> Well, what would you like to know? ;)
>

I just hope those ones will be successful! Maybe we can learn from the
past and improve students/dev communication in order to help them a
bit more if they need it?

David

PS : I don't want to blame anyone here for previous GSoC, excuse me if
my bad English is too direct.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: RESTful API

[David Larlet]

2007/4/25, John Sutherland <[EMAIL PROTECTED]>:
>
> Evening,
>
> I've put the RESTful API code that I mentioned in ticket 2553[1]. A
> few people have requested the code and so it's now in a Google code
> project:
> 
>
> Ideas? Suggestions? Requests?

About "RESTful", I don't know if you can call it like this given the
fact that you do not use http verbs (DELETE instead of /delete/ etc).
You can read the excellent Joe Gregorio's entry about that:
http://bitworking.org/news/125/REST-and-WS

A useful middleware which allow you to use PUT and DELETE easily has
been posted on djangosnippets:
http://www.djangosnippets.org/snippets/174/

About your code, I suggest you to use get_model_or_404 in your index view.

Anyway, thanks for sharing your code. I hope Django will have a native
RESTful implementation one day :-). I have added your contribution to
the feature grouping page:
http://code.djangoproject.com/wiki/FeatureGrouping#WebservicesREST

Regards,
David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Are we dropping auto_now and auto_now_add for 1.0?

[David Larlet]

2007/4/6, Brian Beck <[EMAIL PROTECTED]>:
>
> On Apr 2, 12:52 pm, "trbs" <[EMAIL PROTECTED]> wrote:
> > It could be just me, but although i don't mind losing auto_*, it don't
> > look very DRY in save.
> >
> > I know it's only a few lines (like 4 ? for both options, not using
> > default= for sake of keeping the logic together) but when lots of
> > models
> > have a cre_date and mod_date, those lines are repeated over and over
> > again in save().
>
> I agree. Using default= in place of auto_now_add is fine, but writing
> a save() for every model that needs auto_now is just annoying. A
> shortcut would be nice.

I agree with Brian.

Regards,
David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Stability of LogEntry in django newforms?

[David Larlet]

2007/4/3, Adrian Holovaty <[EMAIL PROTECTED]>:
>
> On 4/3/07, David Larlet <[EMAIL PROTECTED]> wrote:
> > I'd like to add a log for some objects of my project and after playing
> > a bit with signals, I remember that there is a similar "feature" in
> > admin which use LogEntry model. Eventually, I will use signals in my
> > models which call admin log_action function.
> >
> > Before I use this model for professional use, may I know if this part
> > of the admin is stable and is not intended to be removed in the new
> > branch?
>
> Hi David,
>
> The LogEntry model may or may not be tweaked a little bit before
> version 1.0, so it's probably safest not to interface with it directly
> in your own code.
>
> Adrian
>

Hi Adrian,

Thanks for your quick answer, I'll follow your advice.

Anyway, no idea about my second issue? (It's not really dev-related
maybe I had to post it on the user list?)

Cheers,
David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Stability of LogEntry in django newforms?

[David Larlet]

Hi,

I'd like to add a log for some objects of my project and after playing
a bit with signals, I remember that there is a similar "feature" in
admin which use LogEntry model. Eventually, I will use signals in my
models which call admin log_action function.

Before I use this model for professional use, may I know if this part
of the admin is stable and is not intended to be removed in the new
branch?

Next question is how did you make the difference with signals
(post_save) between creation and modification of an item?

Thanks,
David Larlet

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: About *Fields, newforms and lazyness

[David Larlet]

2007/3/6, David Larlet <[EMAIL PROTECTED]>:
> Hi,
>
> I got some troubles today with newforms. I use to create models fields
> with a first implicit verbose_name argument:
> email = models.EmailField("E-mail")
>
> Unfortunately newforms fields have quite similar argument (label) but
> it's not the first argument. Moreover, it's a bit annoying because I
> got an UnicodeError which drive me crazy before I verify the argument
> order.
>
> I know it's easy to type label= for all newforms fields but maybe we
> can reorder arguments in newforms before 0.96? What's your opinion
> about that? Am I the only one?
>
> Cheers,
> David
>

No more thoughts about this proposal? My co-worker has just done the
same mistake yesterday :-).

Cheers,
David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: About *Fields, newforms and lazyness

[David Larlet]

2007/3/6, Rubic <[EMAIL PROTECTED]>:

> You'd be breaking the code of early newforms adopters for an arguable
> benefit.  It wouldn't affect my development base since I explicitly
> use label=, but I can imagine other users might get irritated.

Given the fact that label is not always at the same argument place, I
doubt that it breaks previous code because you "need" to specify
label=

David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

About *Fields, newforms and lazyness

[David Larlet]

Hi,

I got some troubles today with newforms. I use to create models fields
with a first implicit verbose_name argument:
email = models.EmailField("E-mail")

Unfortunately newforms fields have quite similar argument (label) but
it's not the first argument. Moreover, it's a bit annoying because I
got an UnicodeError which drive me crazy before I verify the argument
order.

I know it's easy to type label= for all newforms fields but maybe we
can reorder arguments in newforms before 0.96? What's your opinion
about that? Am I the only one?

Cheers,
David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: ChoiceField and newforms

[David Larlet]

2007/2/28, Domenico Chierico <[EMAIL PROTECTED]>:
>
> HI,
>
> I'm new to django so excuse me if this is the wrong way to manage my
> problem.
>
> I've found a problem into form_for_model function related to
> forms.ChoiceField, that seem to be not considered, for IntegerField
> and FilePathField (and perhaps for others).
>
> Searching on web i've found a known solution for that, but i haven't
> found anything yet into official develop structure, so can someone
> explain me if it's a missing feature or you just don't care about that ?

Have a look at this bug: http://code.djangoproject.com/ticket/3268 It
still need tests.

Hope that helps,
David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Developer documentation?

[David Larlet]

2007/2/8, James Bennett <[EMAIL PROTECTED]>:
>
> Anybody got strong feelings on this?
>

It takes a lot of time and it depends on the target.

If it's to recruit django devs, ok. Otherwise, your django tips are
maybe more appropriated. I know it's not the "official" doc but,
except if you decide to transfer all your posts, it's an essential
resource, so... I hope you have redundancy on your server ;-).

David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Some kind of django.contrib.stats?

[David Larlet]

Hi,

I wonder if something like bbclone [1] (especially the "live" view
[2]) exists in python? I've just found Peastat [3] which looks new but
interesting (fortunately, the author is maybe on this list). What else
did you use to know where are your current visitors? Same question for
long term stats.

What about an optional stats view in the admin interface?

Cheers,
David

[1] : http://bbclone.de
[2] : http://bbclone.de/demo/show_detailed.php
[3] : http://www.throwingbeans.org/peastat.html

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Status update on newforms-admin branch

[David Larlet]

2007/2/4, Russell Keith-Magee <[EMAIL PROTECTED]>:
>
> The *Inline classes need not just be data containers - they could
> contain all the rendering information for handling their own display,
> and the display of the subforms for each related object - and if this
> is the case, they can be used by end users on their own forms.
>

I totally agree with this interesting proposition. Forms are not that
hard to htmlize but always take time, with those classes it could be
incredibly fast.

Cheers,
David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Critical ticket: can cause data loss

[David Larlet]

2007/1/30, Russell Keith-Magee <[EMAIL PROTECTED]>:
>
> On 1/30/07, David Larlet <[EMAIL PROTECTED]> wrote:
> > I'm +1 on this option. Before making decision what about at least add
> > a warning message on the documentation page?
>
> This is kind of the point. Which documentation page? Generic relations
> exist, but they aren't documented - specifically because they're not
> really ready for prime time yet (at the very least, they don't have
> any representation in the admin view).

Here is the documentation page:
http://www.djangoproject.com/documentation/models/generic_relations/

Cheers,
David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Critical ticket: can cause data loss

[David Larlet]

2007/1/29, James Bennett <[EMAIL PROTECTED]>:
>
> On 1/29/07, Ned Batchelder <[EMAIL PROTECTED]> wrote:
> >  I don't know that you need to make a release for this fix, but I think you
> > should alert people to it.  There is a mailing list for announcing releases
> > and security issues, right?  You should send a message to that list
> > announcing the patch.
>
> I will once I've backported it. The question in my mind is just
> whether we need 0.95.2 from this.

I'm +1 on this option. Before making decision what about at least add
a warning message on the documentation page?

Cheers,
David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Web services in Django

[David Larlet]

2006/12/22, juampa <[EMAIL PROTECTED]>:
>
> Hello all:
>
> I am trying to gather all the information I can about implementing web
> services with Django (XML-RPC, SOAP, REST). Can you suggest good
> sources of information/examples of implementations? What is the offical
> status of WS support in Django? Thanks.

Here is a really interesting ticket: http://code.djangoproject.com/ticket/115

Maybe it's time to collect all ressources in order to progress, feel
free to add yours:

On the web:
* XMLRPC in Django http://www.allyourpixel.com/post/xmlrpc-djgo/
* Django Ajax Redux http://lazutkin.com/blog/2005/dec/10/django-ajax-redux/

On mailing-lists:
* Extend URL resolver support for HTTP Methods / REST support:
http://groups.google.com/group/django-developers/browse_thread/thread/15056b2979180228/e9c4c94408a54f44
* metaapi: Django Meta-API - Invitation to Criticize!
http://groups.google.com/group/django-developers/browse_thread/thread/639016969c4cd323/745e4111d3835634
* Django, RDF & XUL
http://groups.google.com/group/django-users/browse_thread/thread/da7638815273dbcd/c0a371f9f6ebd286
* REST-like web services in Django
http://groups.google.com/group/django-users/browse_thread/thread/9f438744f6be28b4/bf7d2d3314d4df0f
* A RESTful Django?
http://groups.google.com/group/django-users/browse_thread/thread/540bce06cda01fc7/056d6c595547abc9

Ok, a lot of people waiting for this "feature" but it's not really
easy to deal with all possibilities so let's get back to the
discussion.

Cheers,
David

--~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Spamblocked ticket: #2282 (Urlify in admin compatible with accents)

[David Larlet]

2006/10/27, orestis <[EMAIL PROTECTED]>:
>
> Here's a thought:
>
> Can't every language have its own urlify.js file ? Like urlify.fr.js,
> urlify.el.js, urlify.de.js etc. Django selects the correct one by
> looking at the Locale settings, or falls back at the default (English)
> one if there isn't any.
>

Yes, I think it could be a good solution, I can do the urlify.fr.js file.

Cheers,
David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Trac and Akismet rejected spam

[David Larlet]

I'd like to update the french translations urls in
http://code.djangoproject.com/wiki/TranslateDocumentation with this
new content :
http://vrac.biologeek.com/askimet_error.txt and I get an Askimet
rejected spam error.

So, how can I do to update this page?

Regards,
David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Slides of Europython 2006?

[David Larlet]

Hi!

I'd like to know if it's possible to have access to django slides of
Simon's conf at Europython 2006. Maybe I haven't found those but there
are not listed on the official page:

http://indico.cern.ch/sessionDisplay.py?sessionId=9=44

Cheers,
David Larlet

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

urlify.js blocks out non-English chars - 2nd try?

[David Larlet]

Hi all,

I've recently added an enhancement (ticket #2282) about urlify without
checking for duplicate and there is already a proposal (my mistake)
and a discussion on this mailing-list which were unfortunatly closed
now: 
http://groups.google.com/group/django-developers/browse_thread/thread/cecdf42cb3430601/1a53ee84c1742b1e

I'd like to know if it's possible to do something about it? What are
previous conclusions and facts since the last discussion? I'm new in
Django and I may help in Python but not in js so I need your help ;).

My current problem is for french accents so it's not really difficult
(I've pasted a js from a french blog app on my ticket) but I'm
conscious there are more problems with other languages. Concerning
utf-8 URLs, I don't know if it's really a good idea because this is
actually associated to phishing...

Cheers,
David Larlet

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---