Re: #25582: Add a way to build URLs with query strings

[Rob Hudson]

At Mozilla we've used a jinja2 template filter called 'urlparams' for quite
some time. You can see the code in jingo here:
https://github.com/jbalogh/jingo/blob/master/jingo/helpers.py#L116

In Python:
urlparams(reverse('translate', kwargs={'slug': document.slug}),
to_locale=locale)

In Jinja2 templates (but the idea would be similar in Django):
https://code.djangoproject.com/ticket/25582
>>
>>  {{{
>>
>> It is a common question on stackoverflow and other places:
>>
>> How to reverse() to url including GET parameters? Example:
>> .../myview?foo=bar
>>
>> ​
>> http://stackoverflow.com/questions/9585491/how-do-i-pass-get-parameters-using-django-urlresolvers-reverse
>>
>> ​http://stackoverflow.com/a/27641445/633961
>>
>> It would be very nice if django could implement a short-cut which provides
>> this.
>> It would be useful for python code and template, too.
>> }}}
>>
>> {{{
>> If we do add it, it likely needs a discussion on the
>> DevelopersMailingList
>>  to figure
>> out what the API should look like. See also #10941
>>  which asks for a template
>> tag for creating query strings in templates.
>> }}}
>>
>> What do you think?
>>
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/0f8dbd9f-b42d-4d17-806b-d965c0999b85%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
-Rob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAK2QP5bwU3s_1uzGMiwmu%2BP_u7SP5eF0zq3-E8k1sUj-TD2E7A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: User_logged_in signal

[Rob Hudson]

I opened bug: http://code.djangoproject.com/ticket/15043

I actually stumbled on this just a few days ago while trying to put a
session_key to user ID mapping into Redis upon login and was stumped
for awhile why it didn't match the session key of my logged in user.

-Rob

On Sun, Jan 9, 2011 at 10:29 AM, Sayane  wrote:
> Take a look at
> this: http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/__init__.py#L73
> Is there any reason, why this signal is sent before flushing session? It
> makes request.session useless for all receivers.
>
> --
> 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.
>



-- 
-Rob

-- 
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: FK Autocomplete Widget [GSoC '09 Admin UI Improvements]

[Rob Hudson]

If I recall correctly, there's another branch on the that project that
was refactoring the autocomplete widgets so that there were
essentially 2 widgets:  A widget intended to be used in your own
Django code, and an admin widget that was a subclass for use in the
admin.

To me that would be a nice feature addition.  It does, however, bring
into question the fact that a widget, intending to be used on the
public side, would depend on jQuery for its UI.  Is Django ready to go
there?  Or would an admin-only autocomplete widget be preferred?

Also, at the time, many of the jQuery autocomplete widgets were in a
state of flux or had some warts.  Our (Jannis and my) idea at the time
was to write our own from scratch, custom and optimized for Django.
That looks to be about a year ago so the state of things is probably
much different today.  (Or not?)

-Rob

On Wed, Jun 2, 2010 at 7:13 AM, Sergej dergatsjev eecho
 wrote:
> Current Admin Extensions
>
> ForeignKeyAutocompleteAdmin - ForeignKeyAutocompleteAdmin will enable
> the admin app to show ForeignKey fields with an search input field.
> The search field is rendered by the ForeignKeySearchInput form widget
> and uses jQuery to do configureable autocompletion.
>
> http://code.google.com/p/django-command-extensions/
>
>
> 2010/6/2 bydesign :
>> I second the vote to add the GSoC '09 Admin UI foreign key
>> autocomplete! It's actually somewhat embarrassing that this
>> functionality hasn't made it in yet. Foreign keys in the admin
>> interface become unusable if you have more than 50 or so rows in the
>> table. I hope that since this code has already been written and
>> tested, it can be included very soon!
>>
>>
>> On Jun 1, 9:30 am, Russell Keith-Magee 
>> wrote:
>>> On Thu, May 27, 2010 at 8:26 PM, Philipp Metzler  wrote:
>>> > hello,
>>>
>>> > i'm looking for exactely the same solution for an "Ajax foreign key
>>> > filter in the Django admin interface" and hoped it would be integrated
>>> > into the admin interface. I think it should be standard behaviour and
>>> > could be configurable in the admin.py Is the development of the admin
>>> > interface going in that direction or is it not planned at all?
>>>
>>> We're at the start of a development cycle, so the plans for the next
>>> release haven't been finalised yet (beyond the broad guideline that it
>>> will be a feature-light, bugfix heavy release). If this is an area
>>> where you would like to see improvements, feel free to make a specific
>>> proposal (preferably one accompanied by sample code :-)
>>>
>>> Yours,
>>> Russ Magee %-)
>>
>> --
>> 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.
>>
>>
>
> --
> 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.
>
>



-- 
-Rob

-- 
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: EmailMessage mangles body text

[Rob Hudson]

On Tue, Apr 27, 2010 at 6:38 PM, Leo  wrote:
> Digging deep into Python's innards reveals that this is a somewhat
> esoteric protection in case you're writing out Unix mailbox files. The
> specific issue is here: 
> http://docs.python.org/release/2.6.2/library/email.generator.html#email.generator.Generator
> and involves the mangle_from_ flag.
>
> The hugely more likely case is that if you're using Django's
> EmailMessage class you're sending emails rather than writing Unix
> mailbox files and are running into this bug that way.

Wouldn't these e-mails end up on other servers that might save the
message in a Unix mailbox format?  And if so, wouldn't removing the
">" from the "From" cause problems?

-Rob

-- 
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: admin javacripts

[Rob Hudson]

On Fri, Feb 19, 2010 at 8:58 AM, Luke Plant  wrote:
> IMO, using 'library agnostic' javascript in the admin will mean we
> just end up implementing our own library, which will end up being an
> ad hoc, informally-specified, bug-ridden, slow implementation of half
> of jQuery/dojo/etc, and even less likely to be able to interop with
> other libraries.

I agree.  And now that jQuery is in the admin, it seems like there's a
decision point...

1) Do we put jQuery in base.html and have Django's widgets and plugins
assume it will be there?

* Benefits: Javascript admin customizations are simpler and can use
the jQuery already on the page.
* Trade off: If someone wants to override base.html and put in
mootools, e.g., Django's widgets break.

2) Or do we put jQuery in each widget's media setting and encapsulate
both jQuery and the plugin code in a closure?  Which seems like where
Django has been heading by default and the one I would advocate.

* Benefit: Users can override base.html and add their own JS library
of choice, even if it's jQuery for easy development or things outside
of widgets.
* Trade off: A bit trickier to develop admin widgets.  But perhaps
this could be worked on -- something like jQuery UI's widget factory
methods?

-Rob

-- 
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: admin javacripts

[Rob Hudson]

I've battled many of these same issues when working on the debug
toolbar... it needs to work the same in any environment it gets loaded
into and, as such, has slightly different requirements put on it.  It
is seeming the admin is heading the same direction to some degree.
While certain parts of the admin are (or will be) using jQuery
(widgets, etc.) there's the potential that someone has skinned the
admin in such a way that they need an admin with Prototype, for
example, to function.  That's leading me to think admin widgets and
plugins need this same level of encapsulation.

On the ticket I posted a bit of skeleton javascript code that shows
how to completely encapsulate both jQuery and widget code into a
closure.  It's seeming like a good idea to take this approach for all
widgets and plugins that are developed for Django.  It goes the extra
step of checking a minimum version of a pre-existing jQuery and passes
in a boolean whether or not jQuery was loaded from Django or provided
via custom JS by the developer.  I don't know if those are needed
exactly, but it's there.  This is the basic structure I'm now using
for the debug toolbar and it's working well.

Happy to help in some way on this if I can.

-Rob

On Thu, Feb 18, 2010 at 2:20 AM, Ales Zoulek  wrote:
> Hello,
> there a ticket about jQuery in admin that breaks any site-included jQueries
> and there's no easy/clean way to prevent it.
> http://code.djangoproject.com/ticket/12882
>
> Let's see a bigger picture there.
> To my knowledge, admin has two ways how to include custom JS. One template
> based second py-api based:
> 1] base_site.html (or other top level template)
> 2] ModelAdmin.Media class
> First forces user to copy at least part of the html code to his own project
> templates. Second allows only per-model javascripts. (Please note that none
> of them solves the bug reported in a ticket.)
>
>
> I'd see to possible ways how to fix the ticket.
> - Quick and easy:
> For some reason, admin uses the ModelAdmin.media to contruct it's own list
> of javascripts. Isn't it safe to say that admin has a fixed set of JS libs
> it uses and include them on all pages in base.html?
> It seems to me safer and more straight-forward behaviour then including
> "some.js" if ModelAdmin has some actions, and "some-other-lib.js" if
> ModelAdmin.opts.get_ordered_objects(). It makes a bit difficuilt to prevent
> javasript name conflicts in site-wide javascripts. I'd propose
> that ModelAdmin.media would serve only for apps, not to admin itself and all
> admin's JSs would be included in base.html.
> The down part is ofcourse thirtd party apps, that can cause some JS
> collisions, but its at least easier to control which app I install and what
> templates/js it uses or overwrites, and they don't "magicaly" intrude their
> js in every change list page.
>
> - Not so quick and definitely more controversial
> What I'd really like is to have some means how to affect admin's behaviour
> per-project (not only by redefining admin templates).
> That would include overriding it's JS inclusion paths, but other things as
> well (global actions, extra context, items per page in change list, etc...)
>
>
> What are your thoughts about that?
>
>
> Regards,
> Ales
> --
> Ales Zoulek
> +420 604 332 515
> Jabber: ales.zou...@gmail.com
> --
>
> --
> 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.
>



-- 
-Rob

-- 
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: Why not datetime.utcnow() in auto_now/auto_now_add

[Rob Hudson]

On Tue, Nov 24, 2009 at 3:36 PM, Russell Keith-Magee
 wrote:
>
> Time zone handling is definitely something that Django could handle
> better, but simply switching to UTC for certain functions isn't the
> solution.
>

I like the solution proposed on ticket 10587:
http://code.djangoproject.com/ticket/10587

Basically, it proposes that timezones are handled analogous to how
Unicode is handled -- that is, everything within Django boundaries is
treated as UTC, with timezone conversions happening on input and
output, but never within Django and always stored as UTC in the
database.

Ticket 10587 was closed as a duplicate of 2626, but I think 10587 has
the better description and proposal in it.

-Rob

--

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: Public method for getting model field names in order of definition

[Rob Hudson]

On Wed, Oct 21, 2009 at 6:38 AM, David Chandek-Stark
 wrote:
>
> The values_list() query set method is useful for dumping data to CSV,
> etc.  However, I find that I often want to use it without specifying
> the field names (to get them all) and yet also include the field names
> as the first row in my data export.  There is no "public" method for
> getting all the names of a model's fields in the order of definition.
> Model._meta.get_all_field_names() returns a sorted list, and one has
> to read the source code to discover that one should (probably) use the
> "attname" attribute of a field for its name rather than the "name"
> attribute.  The ValuesQuerySet superclass of ValuesListQuerySet by
> default sets its field names with:
>
> [f.attname for f in self.model._meta.fields]
>
> So, my question is: Do folks think that it would be good to have a
> public method for getting the field names in order of definition?

I do, and have another use case in mind...

For example, let's say you have a Profile model and you have a profile
edit view which uses a ModelForm.  In the edit template you can simply
output the {{ form }} or iterate over the form:

{% for field in form %}
# output field
{% endfor %}

But if you wanted to redisplay that information back to the user in a
read-only form, there is no iterative way to do so (as far as I know).
 Instead you must specifically "hard code" each field:


Field 1
{{ profile.field1 }}



This doesn't solve your use case, but I'd like to see some sort of
ModelDisplay, which mimics ModelForm, and can be used in such a way to
either specify select fields or exclude fields:

class ProfileDisplay(ModelDisplay):
class Meta:
model = Profile
exclude = ('user',)

You could then pass this to your template and iterate over it:


{% for field in profile_display %}
{{ field.field_name }}
{{ field.value }}
{% endfor %}


In the past I've discovered the model_to_dict in
django/forms/models.py that could be used for this if only it used a
SortedDict instead of a plain dict.  With this minor change...

@@ -121,7 +121,7 @@ def model_to_dict(instance, fields=None, exclude=None):
 # avoid a circular import
 from django.db.models.fields.related import ManyToManyField, OneToOneField
 opts = instance._meta
-data = {}
+data = SortedDict()
 for f in opts.fields + opts.many_to_many:
 if not f.editable:
 continue

You could then, in your view, do:

profile_display = model_to_dict(profile_obj, exclude=('id', 'user'))

And in the template, do:


{% for field_name, value in profile_display.items %}
{{ field_name }}
{{ value }}
{% endfor %}


Which I think would be a nice shortcut for template creators and also
reduces code change as you adapt your models.

All that said, I'm not sure if I'd propose this change for this
purpose... or if we did the method might better live somewhere else.
The model_to_dict method is used specifically for Forms as the
docstring cites: Returns a dict containing the data in ``instance``
suitable for passing as a Form's ``initial`` keyword argument.

Is this a use case others could use?

-Rob

--

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=.

Re: The this-needs-to-be-in-django angst

[Rob Hudson]

On Wed, Oct 21, 2009 at 12:22 PM, mrts  wrote:
> A DVCS mm-tree
> --
>
> Quoting
> http://en.wikipedia.org/wiki/Andrew_Morton_(computer_programmer)
>
> "He currently maintains a patchset known as the mm-tree,
> which contains not yet sufficiently tested patches that
> might later be accepted into the official Linux tree."
>
> I.e. there would be a DVCS branch (avoiding the f-word now)
> maintained either by a core dev or a designated community
> member that would accept patches more liberally -- but still
> only patches that are up to Django standards, i.e. tests and
> docs remain mandatory.
>
> This will probably be most effective in context of the bug
> days, otherwise the management overhead may be too big.
>
> Also, that branch would have a few buildbots running tests
> on it.

Another benefit of a merge-queue branch is testing and verifying that
multiple patches play well together before actually hitting trunk.
For multiple big branches this is even more important.

-Rob

--~--~-~--~~~---~--~~
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: Proposal: Tutorial Refresh

[Rob Hudson]

On Sat, Oct 10, 2009 at 6:04 AM, Ned Batchelder  wrote:
> My strong feeling is that these two goals will quickly become impossible to
> reconcile.  I think the idea of a conference site is a good one (everyone
> will understand the problem domain, lots of interesting avenues to explore,
> it's not yet-another-blog), but aiming for it to be the actual site used for
> DjangoCon will not work in the long run.
>
> The tutorial is extremely important.  It will be the first part of the docs
> read by 98% of new users.  Don't complicate it by tying it to DjangoCon.
> This thread has already seen requests for features that will be great for
> real use, but would probably be too much to put into a tutorial.  While it
> would be very cool to have the two sites be just one site, I think it will
> either create an overgrown underexplained tutorial as DjangoCon adds
> features needed for a real-world conference site, or a simplistic toy
> DjangoCon site because the tutorial needs to ensure that everything is
> clean, understandable, and accompanied by clear prose.
>
> Why not serve just one master well, and have the tutorial be purely about
> exposition and pedagogy?

After more thought I agree with Ned.  Not only will the goals be hard
to reconcile, I think we're encroaching the turf of the DjangoCon
conference organizers.  I also think the data model will be
sufficiently complex and lead to a lot of hand waving in the tutorial.

Ideally, I think a good candidate for a website/tutorial will have the
following components:

* The goal and domain should be simple to grasp and explain in a few sentences.
* Have one main app that is the central focus on the website
* Have one main model, with several peripheral models that could be
introduced as the tutorial progresses.
* Be complex enough to require many areas of Django (e.g. Forms,
Aggregates, Caching, etc)

I'll have to ponder further on what fulfills these requirements.

One thought I had was to use the existing poll tutorial, but expand it
to be a site on its own.  Something along the lines of
http://strawpollnow.com/ but not necessarily with the Twitter
integration?

Thanks,
Rob

--~--~-~--~~~---~--~~
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: Proposal: Tutorial Refresh

[Rob Hudson]

I, too, like the idea of a conference site.  It fills a void and
sounds useful for upcoming conferences.  I wasn't too crazy about the
blog idea, and was convinced away from the snippets idea.  So shall we
call it a conference site and move on?  :)

For a nice reference implementation, I'd like to point to the software
running the Open Source Bridge website.  It's developed in Ruby on
Rails and is hosted on Github:
http://github.com/igal/openconferenceware

I attended the Open Source Bridge conference and thought the website
was one of the most well done of any conference I've been to -- from
initial call for talks to attending and checking the schedule.

The website is here:
http://opensourcebridge.org/

If the intention is that this will be used for the DjangoCons, we
would need input from those that run DjangoCon.  For example, I really
liked the open submission process and the fact that the conference
took everyone's comments (which were private) into consideration when
picking the subset of talks.  But I can imagine that's not for
everyone.

Thanks,
Rob

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Proposal: Tutorial Refresh

[Rob Hudson]

I'd like to propose the addition of a new tutorial that represents a
complete website, describing everything from start to finish.  This
would allow for many more topics to come into play -- things we all
deal with at some point in developing websites using Django.  This
would also allow for those topics to have a concrete central model and
not be hypothetical situations.  The end result should be source code
someone can checkout of a source control repository and run
themselves.  It would also be nice if the site being developed in the
tutorial were available and useful to the community as a whole.

To that end I'm also proposing that the site be http://www.djangosnippets.org/,
as long as James Bennett is ok with it.  The source code is already
available and under a BSD license.  The site is already well used and
important to the community.  The model is relatively simple (snippets)
with the possibility of a few 3rd party apps for things like ranking
of snippets, tagging, registration, Pygments, etc.  Django snippets
would also benefit from this process by getting an update to Django
1.0 (or newer).

I think an outline of the tutorial steps and what should be covered is
important to solidify at the outset.  That way if someone has a
particular interest in, say, caching, they could jump right in and
start fleshing out that step.  There are some dependencies on early
steps, of course.

Here's a very rough proposed outline that should be fleshed out more
and more detail added to each step on what topic areas to cover.  Much
of the current tutorial could be "ported" to the appropriate steps...

1. Creating a project - install, runserver, settings
2. Creating an app - app philosophy, INSTALLED_APPS
3. Creating models
4. Enabling the admin
5. Writing urls and views - generic views, custom views
6. Templates
7. Forms
8. Tests
9. 3rd party apps
10. Search
11. Feeds
12. Caching
13. APIs
14. i18n and l10n
15. Deployment

What I'd like to know is:
* How do people feel about a tutorial that covers a complete site?
* How do people feel about that site being Django snippets?
* Comments on the proposed outline?  Are there any important steps
missing?  Ordered logically? Feel free to add detail to any step.
* Do we cover things not in Django -- like model migrations, search,
RESTful APIs -- using 3rd party Django apps?
* Would it be possible to do this openly, with easy user comments,
like the Django book?  Is that software available?

Also, if we're going to pull this off we're going to need people to
help in a variety of ways.  So I'm also curious who might be
interested.  We'll need: authors to write some sections, reviewers to
give feedback, editors to clean up text and bring uniformity to the
whole thing, developers to make sure the software the tutorial is
describing is coded using best practices and works, a handful of
people to drive the process and foster community involvement, etc.

Feedback welcome,
Rob
--~--~-~--~~~---~--~~
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: Proposal: Better HTML4 support

[Rob Hudson]

On Mon, Sep 28, 2009 at 6:38 AM, Russell Keith-Magee
 wrote:
> By way of greasing the wheels towards trunk: if the outcome of this
> mailing list thread was a wiki page that digested all the ideas,
> concerns and issues into a single page, it will make the final
> approval process much easier. Luke Plant's wiki page on the proposed
> CSRF changes [1] is a good model to follow here - I wasn't involved in
> the early stages of that discussion, but thanks to that wiki page, I
> was able to come up to speed very quickly and see why certain ideas
> were rejected.
>
> [1] http://code.djangoproject.com/wiki/CsrfProtection

I don't mind trying to piece a Wiki page together documenting the
current conversation.  I agree it will make a good pointer for
reference and future discussions.

-Rob

--~--~-~--~~~---~--~~
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: Proposal: Better HTML4 support

[Rob Hudson]

On Sat, Sep 26, 2009 at 11:33 AM, Simon Willison
 wrote:
> I don't think it would involve form widgets being rendered with
> templates simply because of the performance overhead - even with the
> template caching improvements it's still a lot of work just to output
> an input tag. It might involve some kind of light-weight helper for
> outputting tags though - render_tag('input', {'type': 'text', 'name':
> 'blah'}, xhtml=True) maybe.

For lack of knowing about anything better, I keep falling back to
Werkzeug's HTMLBuilder class[1].  Pulled out and stripped of comments,
it weighs in at 77 lines of code...

Here's a brief Python shell of how it works...

>>> html = HTMLBuilder('html')
>>> html.input(type='text', name='blah', value='"Quote & Ampersand"')
u''
>>> html.select(name='template', id='id_template', *[html.option(v, value=k) 
>>> for k, v in dict({1: 'One', 2: 'Two', 3: 'Three'}).iteritems()])
u'OneTwoThree'

I really like how it handles children nicely, as in the select/option
example above.

>>> xhtml = HTMLBuilder('xhtml') # XHTML dialect
>>> xhtml.input(type='text', name='blah', value='"Quote & Ampersand"')
u''

This automatic CDATA escaping in XHTML is also nice:

>>> html.script('var id=document.getElementById("id")')
u'var id=document.getElementById("id")'
>>> xhtml.script('var id=document.getElementById("id")')
u'/**/'

I could see using something like this and making a template tag
wrapper around it like the namespace template tag you mention below.
I *think* that would simplify a lot of what you see in the Django
template widget render code that deals with attributes (e.g.
buildattrs, flattatt), which should make writing widgets and
sublcassing widgets a bit easier.

> The form.as_p stuff works as either HTML or XHTML. It would be nice to
> further emphasise the ease with which people can create their own
> reusable form templates (define them as an includable fragment that
> iterates over the form), and it would be nice if there were more
> finely grained methods for things like accessing the HTML ID of a form
> field. I don't see any reason to templatise those parts in particular
> though - unless someone has smart ideas about how baked in default
> templates could dramatically improve the overall form experience.

I agree with what I think I'm reading here -- a goal being to give
designers more fine grained control over the form and form elements at
the template level.

> That's tricky. There are really only a few tags that actually differ -
> anything that needs to be self closing, which means the following:
>
> 
> 
> 
> 
> 
> 
> 
> 
> 

Also:





> Of these, only meta, link, img, input and br are really common. I can
> think of a few ways of dealing with this, none of them particularly
> enticing:
>
> 1. a {% selfclose %} template tag:
>
>    
>
> {% selfclose %} outputs either blank or " /" depending on the doctype.
>
> 2. a {% tag %} tag:
>
>    {% tag br %}
>
> Like the {% field %} tag, this could take optional attributes:
>
>    {% tag br class="break" %}
>
> 3. {% field %} style tags for all of the self-closing XHTML tags:
>
> {% br %} {% br class="break" %}
> {% hr %}
> {% meta name="dc:author" value="Simon" %}
>
> This option really sucks - that's 9 new template tags polluting our
> default template namespace which do almost nothing. That said, if we
> added template tag namespacing we could at least do {% tag.br %}, {%
> tag.hr %} etc.
>
> They're all pretty horrible, but I think out of those I prefer option
> 1 (maybe with a better, shorter name).

I think you might want both 1 and 3.  (1) for those that want finer
control or just don't want to use the underlying HTML wrapper, and (3)
for those that do.

Would it be something to consider adding special case tag, like
comments, to represent the self closing slash depending on current
context's doctype?  For example, something like {% / %}?

[1] http://dev.pocoo.org/projects/werkzeug/browser/werkzeug/utils.py#L126

I feel like I'm starting to get a picture in mind for all the pieces
at play here.

Thanks,
Rob

--~--~-~--~~~---~--~~
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: Proposal: Better HTML4 support

[Rob Hudson]

On Sat, Sep 26, 2009 at 2:13 AM, Simon Willison  wrote:
> Yes - I looked briefly at how much work was involved in doing this and
> it's not insubstantial, which is why I opted for string replacement
> just to demonstrate the API. I'm confident the exact functionality of
> django-html could be replicated in a less messy way by patching core,
> but it would require quite a bit of refactoring of django.forms.

This is the bit I was hoping we could get to.  What would that
refactoring look like, you think?  Would it involve making forms use
Templates?  Or something else?

> I think the key problem is template filters, which often produce XHTML
> (linebreaksbr for example). This could be solved by allowing template
> filters selective access to the template context, which I'm in favour
> of in the absence of a compelling argument against. This could be done
> in a way that allows existing filters to continue to work - maybe
> something as simple as this:
>
> register.filter('cut', cut, takes_context=True)
>
> Which emulates the register.inclusion_tag API.

We've got django.forms and tags/filters on the plate.  How might we
fix something like comments which has templates which write out XHTML
(or other little places which hand code HTML)?

For example, if one includes contrib.comments in their HTML4 website,
it doesn't validate...
http://validator.w3.org/check?uri=http%3A%2F%2Fjacobian.org%2Fwriting%2Fsnakes-on-the-web%2F=%28detect+automatically%29=Inline=0

Ahem.  Sorry Jacob!

I'd really hate to see something like this everywhere:



> Really not keen on that - designers should be able to pick their
> doctype, and there are some cases where specific pages of a site (or
> of a reusable app) might need to use a specific doctype - MathML
> output still requires XHTML for example.

I agree.

Simon mentioned how HTML and XHTML could result in Javascript and DOM
differences -- should we be concerned about being too dynamic about
swapping out HTML for XHTML, and vice versa, for fear of breaking
Javascript and CSS that rely on them?

For example, I think the Django admin is fine as XHTML since it isn't
intended to be an included part of your website.  But say we were able
to easily set a different doctype that rendered as HTML4.  Does that
have the possibility of really breaking things?

> I've somewhat foolishly volunteered for a bunch of 1.2 related hacking
> already (CSRF, logging, signing) but I remain actively interested in
> this, so I'll try to keep an eye on things and see if there's anything
> I can contribute.

If we can come up with something that everyone is happy with, I'm in
for volunteering time to help code it.  I'm sure it will be a learning
experience for me as far as Django internals, but I'm willing to put
the effort into it.

Thanks,
Rob

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Proposal: Better HTML4 support

[Rob Hudson]

Or: Why is HTML4 such a PITA to get right?

Outline:
* What I know about HTML4 and Django
* Some info about past efforts and discussions
* Thoughts and curiosities about what we can do

What I know about HTML4 and Django


First, let's not let this turn into an argument about HTML vs XHTML.
People have their preference one way or the other, and I believe
Django should be agnostic.

Currently, however, Django *is* biased to producing XHTML output in
the various places that output HTML, such as comments, formtools,
csrf, forms.widgets, and various filters and HTML utilities that
output "" tags.  For someone that prefers an HTML4 doctype, this
is a hassle with no easy answer.

Some info about past efforts and discussions
=

Some tickets already open on this...

Ticket #6925: CSRF html output is not valid html (it is xhtml)
http://code.djangoproject.com/ticket/6925

Ticket #7281: Add doctype tag to webdesign template tags
http://code.djangoproject.com/ticket/7281

Ticket #7452: Settings for HTML4 or XHTML output
http://code.djangoproject.com/ticket/7452

Proposal from Mar 2008:
Form rendering with filters...
http://groups.google.com/group/django-developers/browse_thread/thread/5f3694b8a19fb9a1

Proposal from Sept 2008:
{% doctype %} and {% field %} tag for outputting form widgets as HTML
or XHTML...
http://groups.google.com/group/django-developers/browse_thread/thread/f04aed2bc60274f0

Since those tickets aren't closed as "wontfix" or "invalid", and much
of the conversation surrounding this agrees that *something* should be
done, I'm hoping to start a conversation as to what that something
might be.

Thoughts and curiosities about what we can do
==

After thinking for some time, I've only been able to come up with two ideas...

1. Incorporate something along the lines of Simon's django-html
project (http://github.com/simonw/django-html).

I think the genera idea is this: You set a doctype in your base
template via a template tag (e.g. {% doctype "html4" %}, and any
rendering that is done after that (in inherited or included templates)
is based on this doctype.

Advantages:
* It puts the doctype decision into the hands of the designer.
* It allows for different parts of an application to have different doctypes.

Shortcomings:
* Fixes the symptom, not the bug. [1]  I think the fix should not do
string replacement, but output the correct HTML in the first place.
(I realize this is the best one can hope for as a 3rd party app, but
if something were to come into core it would have the ability to fix
things properly.)
* Doesn't "fix" the rest of the areas where Django outputs XHTML.  Is
it possible?
* Ties various parts of Django to the-thing-that-produces-HTML.

2. Add a new setting, e.g. settings.DOCTYPE, that various parts of
Django and 3rd party apps use to render HTML.

Advantages:
* Simple and straightforward

Shortcomings:
* Yet another setting
* Doesn't allow for template level decisions of doctype by designers


Since I think idea #1 has the best chance of making headway, I've
tried to look at how it might be done.  Unfortunately, I don't know
the template system well enough to see how setting {% doctype "html4"
%} might be able to affect other areas of Django.  Here was my thought
process the other night...

If Django widgets and other parts of Django always used the Template
system to render HTML, it might be possible to set some global context
variable of the current doctype.  But perhaps the reason for not doing
this initially is because each `get_template` call results in a read
from the filesystem (or thread safety?)?  In which case, we should
consider fixing #6262, Cache templates.  Using Templates everywhere
does inhibit re-use of pieces of Django outside of Django as they
would all now rely on Django's templates.

There's also the option of something like Werkzeug's HTMLBuilder[2]
and their use in Solace widgets[3].

I don't claim to have the answer, but I'm willing to put time and
effort into helping solve this.  Thoughts?  Other ideas?

Thanks,
Rob

[1] http://www.pointy-stick.com/blog/2007/09/04/fix-bug-not-symptom/
[2] http://dev.pocoo.org/projects/werkzeug/browser/werkzeug/utils.py#L126
[3] http://bitbucket.org/plurk/solace/src/tip/solace/utils/forms.py#cl-294

--~--~-~--~~~---~--~~
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: 1.2 Proposal: Add a few more tutorial steps

[Rob Hudson]

On Thu, Aug 20, 2009 at 1:03 PM, Nicolas Steinmetz wrote:
> Maybe you can inspire from the Jobeet [1] tutorial which consists at the
> beginning as an advent calendar (a one hour tutorial published
> everyday). Jobeet is a Job board and allow to deal with all aspects of
> Symfony framework from framework installation to deployment.
>
> Building a job board as a *real* app is I think more interesting than a
> basic poll app that nobody will use or do not look like a real app.

I very much agree with this and would be on board to help.  Using a
full website as a tutorial allows for explanation of topics you might
not get in a simple example tutorial — things like deployment,
caching, tests, data/schema migration as models evolve (though not
currently part of Django), feeds, internationalization, etc.

I don't know that I'd necessarily copy what Jobeet has done, but
perhaps something that's already being used in the Django community,
is open source, and could be improved a bit.  Something like
DjangoSnippets perhaps?

-Rob

--~--~-~--~~~---~--~~
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: Suggestion: Better way to extend user table

[Rob Hudson]

Take a look at ticket 3011:
http://code.djangoproject.com/ticket/3011

--~--~-~--~~~---~--~~
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: 1.2 Proposal: django debug toolbar in contrib

[Rob Hudson]

I'm not sure if this is the place but here are some other issues or
questions I have if this were to happen...

* The jQuery question is a big one.  I've taken strides to make the
debug toolbar interoperate with other popular JS frameworks (mootools
and prototype, namely).  But if jQuery were decided against, would it
make sense to re-use some of the Javascript libraries that Django has
developed for its admin?  Would it use the same admin media handler
trick?

* Which set of plugins are included, and of those that have settings,
what are their defaults.  Some defaults currently optimize to general
case and provide more debugging information, but on larger sites
performance may suffer severely.  It may make sense to take a
philosophy of best default performance with opt-in added debugging.

* Should there be a place for plugins (panels) that don't make the
cut?  Panels consist of some Python and some HTML, so it's not a
single file.  They *could* be changed to work similar to form.widgets
with a render method and HTML backed in... but I'm not a huge fan of
that.  But it would make it a bit easier for posting on a site like
Django Snippets.

* Should the UI match that of the Django admin (overall theme, colors,
etc)?

* If the debug toolbar is incorporated, should we consider different
integration options?  e.g. Currently the debug toolbar injects URLs
into the project in a rather ugly way -- could this be done better if
it were part of Django?

Thanks,
Rob
--~--~-~--~~~---~--~~
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: 1.2 Proposal: django debug toolbar in contrib

[Rob Hudson]

On Tue, Aug 11, 2009 at 7:01 AM, Russell
Keith-Magee wrote:
> Firstly, there is the simple issue of ownership and copyright.
> Obviously, those that have written DDT components that are to be
> included need to be onboard with this idea.

On this point I've strived to be pro-active (thanks to Jacob)...
before any new commits from new committers were merged I made sure
they're code was ok to be licensed under BSD and they were listed in
the AUTHORS file.  Seeing as the "framework" part hasn't changed a
whole lot in the year or so it's been out, it seems like a worthwhile
consideration to me.  And I'd be for it.

> Secondly, plugins. As I understand it, DDT is half framework, and half
> a collection of debugging plugins, and one of the sources of forking
> is people writing their own plugins. I haven't dug into this in
> detail, but in order for DDT to get to trunk, we would need to be able
> to ship an interface that is conceptually similar to db.backends -
> that is, we will advertise a stable interface, and ship a small number
> of obvious plugins. The community would then be in a position to
> contribute extra plugins - some of which might one day get added to
> django.contrib. If there is any disagreement in the interface that a
> plugin is expected to implement, this would be a serious impediment to
> inclusion in django.contrib.

You understand it correctly.  I've always meant to advertise a little
more the fact that panels are just classes (subclasses of DebugPanel)
that can be imported from anywhere given the full Python path to the
debug toolbar config.  And you are correct that some forks are adding
panels that I wasn't comfortable merging due to the fact that they
might be too specific and made more sense as a custom panel.
Actually, to my knowledge, all the forks are panel specific and are
not changing the core "framework" part of the debug toolbar.

> Thirdly - look & feel. I haven't used DDT for a while, so I don't know
> what the state of the art is here. Last time I used DDT, it worked
> fine, but I felt that it needed a little UI polish, especially in
> providing a way to hide it or preventing the toolbar from obscuring
> meaningful parts of the underlying site. I don't know how time and
> forking has treated this particular aspect of DDT.

Agreed.  UI isn't my strong point and I've always hoped a designer
would be inspired to give it a full treatment.  There's also the
jQuery aspect of it.  I think this probably leads to a bigger
discussion.  I have a local branch that makes some big improvements in
this area already.

> Lastly - time. This needs to be done in a timely fashion. If we're
> going to include DDT in Django v1.2, then we're going to need to have
> a consensus position - if not a ready-to-commit patch, then at least
> agreement on what would be in a ready-to-commit patch - in a little
> over a month. It it takes much longer than that to reconcile the
> forks, then we may need to consider this a work-in-progress for v1.3.

Perhaps some discussion at DjangoCon?  :)

> So - if you (or anyone else) is interested in advocating the addition
> of DDT to django.contrib, you're going to need to make sense of the
> mess for the core team. The first step in this process is wrangling
> the forked community into a single repository that is a candidate for
> inclusion.

Hopefully I answered some of these questions and made some sense of the mess.

-Rob

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

1.2 Proposal: Add a few more tutorial steps

[Rob Hudson]

At the end of the 4th step of the tutorial, it lists some tutorials
that are upcoming:

Coming soon
===

The tutorial ends here for the time being. Future installments of the tutorial
will cover:

* Advanced form processing
* Using the RSS framework
* Using the cache framework
* Using the comments framework
* Advanced admin features: Permissions
* Advanced admin features: Custom JavaScript


I'd be happy to help flesh out one or more of these.  This isn't
necessarily a 1.2 feature but would be a nice addition to the
documentation.

If someone already had an idea on these wanted to add some more
details of what to cover under one of those topics, I (and others?)
can try to flesh one out during the 1.2 phase.

-Rob

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Ticket 8638: Provide setting to disable e-mail sending

[Rob Hudson]

Hi Django Devs,

I saw that ticket[1] made it into the 1.1 list and I was drawn to it.
I have a project that will be doing some mass sending of emails soon,
so I could definitely use something more than what is currently there.

Firstly, the title simply says it wants the ability to disable emails,
while some of the comments on the ticket are looking for a bit more
than simply disabling.  Where would we like to take this?

In case we headed down the road to trapping and looking at emails that
tried to send, I wanted to be a bit smarter about what needs to be
done so I poked around the code a bit and did some research.  I ended
up writing a blog post on what I found[2].  Essentially you can fire
up a built-in SMTP server that's already baked into Python, change the
port number for your email, and you're trapping emails and can view
all headers, etc.

If we wanted to add the ability to trap, debug, and view emails that
were sent, I have a few ideas I'd like to get feedback on.  The ideas
are in order of complexity in my mind...

1) Add a management command that launches a mail server.  Something
similar to runserver, and the user would have to adjust their email
settings accordingly...

   ./manage.py runmailserver localhost:1025

What I like about this is it can be extended or redirected to a file.
We can add a --format= option for plain text, mbox format, eml format,
or whatever other standard mailbox formats there are.

Or possibly even provide a dotted path to the class you want to use in
its place, similar to middleware, that gets loaded.  This might be
useful if you want to log emails to a database...

   ./manage.py runmailserver 1025 --
class=myproj.mailserver.EmailDatabaseLogger

I'm curious if running this should imply that the EMAIL_* settings get
hijacked and overridden for as long as the mail server is running.  If
not, see idea #2.

2) In combination with #1, add a new option to runserver to override
the EMAIL_* settings.  So you'd run #1 in one console, then something
like this in the 2nd:

   ./manage.py runserver --emailport=1025

This saves the user from having to adjust settings for local
development if they're not already set up to do so.  But it still
requires both commands to have a matching port number, thus...

3) A step up in the automation and involving more discussion... Add
another option to runserver to launch a mail server for debugging.
This would hijack the mail server settings, launch a local smtp
server, and then runserver.  All output would be in the same console.
I think this idea is a bit limiting considering all the fun stuff you
can do with #1.  This would be option overload for runserver I think.
But it does have the added benefit of running a single command in a
single console.

   ./manage.py runserver --maildebugger


Other ideas or thoughts?

Thanks,
Rob

References:
[1] http://code.djangoproject.com/ticket/8638
[2] http://rob.cogit8.org/blog/2008/Nov/20/testing-emails-django/


--~--~-~--~~~---~--~~
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: Absolute paths in settings.py

[Rob Hudson]

On 10/30/08, Thomas K. Adamcik <[EMAIL PROTECTED]> wrote:
> If django where to ship something like this __file__ would point to somewhere
>  within the installation folder of django, which is obviously not what we 
> want.

Not necessarily true.  If this code were in the settings.py from the
project_template it would get laid down in your project when you ran
django-admin.py startproject, which is, I think, the appropriate place
for this relative path stuff to land.

See: 
http://code.djangoproject.com/browser/django/trunk/django/conf/project_template/settings.py

+1 from me.  :)

-Rob

--~--~-~--~~~---~--~~
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: Decouple messages from contrib.auth

[Rob Hudson]

On 10/28/08, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
>  On Mon, Oct 20, 2008 at 12:33 PM, Rob Hudson <[EMAIL PROTECTED]> wrote:
>  > I think decoupling messages from contrib.auth is a worthy step to
>  > making auth a little bit more reusable.
>
> Agreed. However, doing this in a backwards-compatible manner is going
>  to be tricky.
>
>  > By doing so, however, Django would need to ship with a
>  > contrib.messages (or similar) app which brings with it other thoughts
>  > and considerations:
>
> Probably it'd make sense to make this part of
>  ``django.contrib.sessions``; there's no real way to pass messages
>  without at least an anonymous session.

>From the looks of it, the patch on
http://code.djangoproject.com/ticket/4604 is heading this direction
re: backwards compatible and part of contrib.sessions.

Maybe SmileyChris can speak to both of these points and if it could be
a potential solution?

Thanks,
Rob

--~--~-~--~~~---~--~~
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: Decouple messages from contrib.auth

[Rob Hudson]

On Mon, Oct 20, 2008 at 11:33 AM, Rob Hudson <[EMAIL PROTECTED]> wrote:
>  * Should a pre-existing reusable app (like django-notification[2])
> be used/considered instead?
> [2] http://code.google.com/p/django-notification/

I actually meant to link to the django-notices app, which has the
benefit of not requiring a SQL query per request, but had both open in
different tabs:
http://github.com/uggedal/django-notices/tree/master

-Rob

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Proposal: Decouple messages from contrib.auth

[Rob Hudson]

Hi Devs,

I just posted a question on Django users about how to best remove the
extra query to auth_messages on every request while still using
contrib.auth and contrib.admin in my own code[1].  This led me to the
thought that contrib.auth should follow the reusable apps mantra of do
only one thing and do it well.

I think decoupling messages from contrib.auth is a worthy step to
making auth a little bit more reusable.

By doing so, however, Django would need to ship with a
contrib.messages (or similar) app which brings with it other thoughts
and considerations:
  * How to make messages more reusable.
  * Should it have more features?
  * Should a pre-existing reusable app (like django-notification[2])
be used/considered instead?

I almost convinced myself that Groups and Permissions could also stand
on their own as separate contrib apps but then thought that as an
overall "auth" app, they make sense.

[1] 
http://groups.google.com/group/django-users/browse_thread/thread/cf8f7aefe2039873
[2] http://code.google.com/p/django-notification/

Thanks,
Rob
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Process for new contrib apps?

[Rob Hudson]

Hi Devs,

At DjangoCon it was mentioned that you were working on a process for
nominating or approving 3rd party Django apps to be pulled in as
official contrib apps.  I'm curious if that's been worked out yet.

Thanks,
Rob
--~--~-~--~~~---~--~~
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: {% doctype %} and {% field %} tag for outputting form widgets as HTML or XHTML

[Rob Hudson]

On 9/9/08, Simon Willison <[EMAIL PROTECTED]> wrote:
>  http://code.google.com/p/django-html/

As a 3rd party app this is awesome.  It's simple and clean and doesn't
require much from the user.

But as part of Django itself, it seems like fixing django.forms (the
source) would be a better solution.

To avoid adding yet another setting (unless it's warranted here) can
the setting of a doctype in a template tag set a value in
django.conf.settings that django.forms can then check (with a
reasonable default)?

I recall seeing a patch that adds a new setting and updates (at the
time) django.newforms with some if/else logic based on the setting to
the various widgets' render methods.  I can't seem to find it now.

I'm just trying to point out that for Django to output a string that
then later gets "fixed" smells funny to me (ask Malcolm likes to say).

-Rob

--~--~-~--~~~---~--~~
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: {% doctype %} and {% field %} tag for outputting form widgets as HTML or XHTML

[Rob Hudson]

On 9/9/08, Simon Willison <[EMAIL PROTECTED]> wrote:
>
>  Back in March there was a discussion about providing a way to output
>  django.forms widgets as HTML (at the moment they always use XHTML,
>  which leads to nastyness on sites using an HTML doctype):

After I read that I created the doctype part in a patch on this ticket
but didn't have the genius idea of the {% field %} tag to take it the
rest of the way...
http://code.djangoproject.com/ticket/7281

So awesome and simple.  I love it.

I'll get rid of my weird form hack on my latest project and test this out soon.

Thanks,
Rob

--~--~-~--~~~---~--~~
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: Locations needed for 1.0 sprints.

[Rob Hudson]

OSCON is July 21st to the 25th in Portland, OR.  It's not in a date
range listed but I'm curious if something could be arranged there?  If
not a sprint maybe a BOF or just a meet and greet?

On Jun 25, 3:58 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> Hi folks --
>
> I'm setting up sprints leading up to the 1.0 release, and I need some
> volunteers to host a couple of 'em.
>
> So far, here's what we've got by way of sprinting:
>
> July 10-12: EuroPython
> July 18: Sausalito, CA
> August 1: ?
> August 8: Lawrence, KS
> August 15: ?
> August 22: ?
>
--~--~-~--~~~---~--~~
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: Experimental Git repository available

[Rob Hudson]

On 6/19/08, Rob Hudson <[EMAIL PROTECTED]> wrote:
> Use the `-T`, `-t`, `-b` flags, or `-s` if the project has a "standard
>  layout".  This should bring over branches and tags as well.

I forgot to reference the man page (which was in my clipboard):
http://www.kernel.org/pub/software/scm/git/docs/git-svn.html

-Rob

--~--~-~--~~~---~--~~
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: Experimental Git repository available

[Rob Hudson]

On 6/19/08, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
>  On Thu, Jun 19, 2008 at 11:55 AM, [EMAIL PROTECTED]
>  <[EMAIL PROTECTED]> wrote:
>  > Is this only going to offer the trunk branch?
>
>
> Until I learn more about Git, yes :)
>
>  If you know the correct incantation to add other git-svn-created
>  branches, feel free to school me :)
>
>
>  Jacob

Use the `-T`, `-t`, `-b` flags, or `-s` if the project has a "standard
layout".  This should bring over branches and tags as well.

-Rob
-- 
"ROCK OUT!"  \m/.  .\m/

--~--~-~--~~~---~--~~
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: Understanding HTML, XML and XHTML

[Rob Hudson]

On 6/10/08, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>  However, if we _ever_ want to get v1.0 out the door, we're going to
>  have to draw the line somewhere. This wouldn't be a trivial change -
>  at the very least, it will require a bit of discussion to work out
>  exactly what we should be doing. If we spend our time having those
>  discussions and implementing the result, thats time that isn't being
>  spent finishing newforms-admin, nailing the stray bugs post-qsrf, or
>  doing any of the other tasks on the v1.0 todo list.
>
>  Can I suggest that you log this as a ticket, mark it someday/maybe,
>  summarize your thoughts if you feel so enthused, and put a pin in it
>  until post v1.0. Once we have that out the door, we'll be looking for
>  something to do, and a HTML4 transition of some sort could be it.

I agree any sort of transition should be tabled for now.  And a
transition to HTML4 will also likely lead to discussions of having
XHTML support as an alternative.

And supporting HTML4 "in the meantime" (weird, that song by Helmet is
playing in shuffle mode as I typed that) would be nice if it were
easier, but there are some hackish ways to get it to work as is, so
maybe it's not worth the effort of distracting devs when a 1.0 push is
on.

-Rob

--~--~-~--~~~---~--~~
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: Understanding HTML, XML and XHTML

[Rob Hudson]

Hi Dango devs,

I wanted to publicly apologize for the framing of my question... I
meant it to be humorously provocative but I fear it could be easily
misread to be rude and annoying, and not easily turned into something
productive.  That wasn't my intention.

I am curious if anyone thinks having support for outputting html4
compliant markup in Django is a good thing?  And if so, what can I do
to help make that become a reality?

In searching for previous discussions I found one that I brought up in
Jan 2007 that never got traction, though most people seemed to agree
that there was some merit to the argument...
http://groups.google.com/group/django-developers/browse_frm/thread/b2ace4f7f69a73f6/78b927bc18d093d5

There was also some discussion (and I believe an attempt) to making
templatetags for newforms, I believe, based on Simon Willison's
suggestion:
http://groups.google.com/group/django-developers/browse_frm/thread/5f3694b8a19fb9a1

Is this important for anyone else besides me?

My humble apologies,
Rob

--~--~-~--~~~---~--~~
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

[Rob Hudson]

Posting this here rather than someone's blog post comments:

Just a note up front, Django has completely changed the way I build
websites and I'm totally enamored with it, but I'm trying to think of
how official releases could have benefitted myself in my situation and
this is what I came up with...

Let's pretend the following history occurred...

* 0.97 was released with the major change being the update to unicode.
* 0.98 was released whose main features were auto escaping and QSRF.
* 0.99 will soon be released whose main feature is newforms admin.
* 1.0 will be released with minor updates and stabilization.

Some benefits I see if this had happened.  Specific pretend version
examples reference those above...

* Easier to know up front what's new, backwards incompatible, etc.
because there'd be release notes and we can plan to migrate when
ready.  Versus an arbitrary revision and checking the backwards
incompat wiki page, looking at docs to see what has "New in
Development Version", etc.

* Easier to set up a server to host Django apps depending on all of
0.96, 0.97, 0.98 vs possibly having revs -- at least you can simply
svn up a point release branch for security fixes.  On revs you'd have
to back port a patch to a certain rev if a security fix was released
to not also update the stuff you don't want.  Another example is
Webfaction -- they now offer 0.96 and "trunk", but who's trunk is it
and when is it updated?  I don't want my website to break b/c they
updated out from underneath me.  I'd much rather have a recent point
release that I can depend on and still get some of the new goodies in
recent Django.

* Online HTML documentation is frozen with each release.  If we were
tracking individual revs, this is not true -- docs would only be
frozen with the Django tree.  This also gathers people around a
vocabulary, e.g., you can ask which version a person is using more
definitively.  If a person says "trunk" you have to know which
revision or when they last updated.  If they say, "I updated to 0.98
and now I see HTML garbage in my website." you know it's probably
because of the auto escaping.

* 3rd party apps could more easily plan updates.  For example, after
qsrf merge, django-tagging was broken. If django-tagging instead said
it worked against 0.97, there could have been a planned update to
0.98.  Granted, the breakage would have still occurred for those
following trunk, but the benefits of the releases above is that the
3rd party people can claim with certainty that their code works
against a certain release, not "this works against trunk and may break
if they change their API."

* There have been a few cases where getting something in trunk to get
more eyes on the code to work on it has been beneficial.  After a
point release you can merge in unstable code and get the main
developer's eyeballs fixing things (sort of like the flurry of code
coming into the Linux kernel after an official release).  It sounds
like a faster iteration process to me than people not wanting to break
trunk b/c it's the norm to run production websites off of it.

I'm not arguing for the above releases or a pre 1.0 release, I'm only
trying to make some claims that frequent releases can be a good thing
for the Django ecosystem as a whole.

-Rob

--~--~-~--~~~---~--~~
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

[Rob Hudson]

On 6/7/08, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>  On Sat, Jun 7, 2008 at 7:23 PM, Rob Hudson <[EMAIL PROTECTED]> wrote:
> > Where I work we use 0.96 (though I use trunk on my personal projects).
>  >  We use 0.96 because we have up to 12 separate Django projects
>  > rotating through at a time
>
> In that environment, perhaps you should work on tools and techniques
>  to make automated porting work.  Otherwise, you're going to have a
>  painful legacy  problem.

I think it depends on the project, but I wouldn't mind hearing more of
your thoughts on this because it's something I have to deal with.
Perhaps we should take it offline unless others might benefit from the
conversation.

When our projects are done, they're done.  They work as intended and I
don't see any reason to upgrade them from 0.96 to 1.0.  If it ain't
broke, why fix it?  When 1.0 comes out, we'll upgrade our core
libraries to work against 1.0 and that will be our new default.  The
only reasons I can think of to want to upgrade a finished site is for
security or major performance enhancements -- one of which is usually
back-ported to 0.96 for as long as it's supported (which I'm not sure
Django has specified).  What I'm wishing for in trunk are more
developer friendly features -- things that make it easier on the
developers.

Please tell me more about the legacy problem you are predicting.

And for Django devs -- are there specific dates or number of releases
when Django no longer rolls out security patches for older releases?

Thanks,
Rob

--~--~-~--~~~---~--~~
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

[Rob Hudson]

On Sat, Jun 7, 2008 at 4:45 PM, Tim Chase
<[EMAIL PROTECTED]> wrote:
> I'm not sure blessing it with a number does much but pander to
> folks that are scared to make a tough call:
>
> Use 0.96:  blessed with a magic number, but old and not much like
> 1.0 will be
>
> or use Trunk:  suggested (but not  blessed with a number), much
> closer to like 1.0 will be, and still some changes to be expected
> when new-forms hits.

Where I work we use 0.96 (though I use trunk on my personal projects).
 We use 0.96 because we have up to 12 separate Django projects
rotating through at a time and all at various phases of development.
We don't have the resources to continuously update all of them to
trunk and fix the various backward incompatible changes that might
crop up, and each one can't be on its own trunk release or trying to
assemble any sort of library would be a nightmare.  Not even
mentioning having to support various Django releases on our production
servers.  So we're stuck on 0.96 until 1.0 comes along.

Not so much a tough call to pick 0.96 in our case, but I'm jealous at
the more than 1 year of great features in Django trunk.

-Rob

--~--~-~--~~~---~--~~
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: Little help with #6886 ("Assigning a Model Instance to a Foreign Key Attribute Doesn't Cache the Instance")

[Rob Hudson]

On Sat, Jun 7, 2008 at 1:03 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> One suggestion is to assign to "foo.bar_id" instead of "foo.bar"; that
> skips the validation hook. But if you've got more suggestions I'm
> listening...

I got around it just by putting the FK assignments in a try block and
catching and echoing the exceptions.  (This is an old database that
has no constraints and I'm migrating it to one that does -- so echoing
out the errors helps point out places that need manual updates
anyhow.)

Personally I'm ok with the change but it does change the way I think
about trapping errors with Django models somewhat -- being more aware
that assignment could raise and error rather than save().

-Rob

--~--~-~--~~~---~--~~
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: Little help with #6886 ("Assigning a Model Instance to a Foreign Key Attribute Doesn't Cache the Instance")

[Rob Hudson]

On Sun, Jun 1, 2008 at 8:11 AM, Ivan Sagalaev
<[EMAIL PROTECTED]> wrote:
> Why not defer it to save()? Currently you can assign invalid values to
> other fields and it won't break until save():
>
> obj.time = 125 # Ok
> obj.save() # ProgrammingError
>
> And many things even won't break at all like assigning a string to a
> boolean attribute.
>
> Anyway my point is that early validation will break code that relies on
> legitimate behavior: "assing values in bulk, then fix some, then save".

I was just bitten by this (having since svn up'd trunk).  I have some
data migration scripts that make a lot of assignments up front, extra
logic to clean up a few things, and then wraps the save() in a try
block.

-Rob

--~--~-~--~~~---~--~~
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

[Rob Hudson]

On Sat, Jun 7, 2008 at 12:06 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> * Start a "train release" schedule: schedule a couple of 1.0 betas, a
> rc or two, and then a final release. Features that are done by the
> dates get released, those that aren't, don't. Make these dates
> aggressive but not crazy. And -- here's the controversial part -- make
> newforms-admin an "optional" part. If it's done, awesome; if not,
> include it in the next release. The current admin has some bugs, yes,
> but it's usable enough. As long as we advertised that it's on the way
> out we shouldn't have too much trouble.

This is similar to the Ubuntu release schedule -- release every 6
months and whatever is done/stable at the time makes it, otherwise
things wait for the next release (which isn't too far out).

+1 from me, and it provides for a little motivation since there is a
target date on the horizon.

-Rob

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Understanding HTML, XML and XHTML

[Rob Hudson]

I'm pretty sure this has been beaten to death, and I was going to pass
on sending this in, but this paragraph made me ask, "What would it
hurt to ask?":

{% block quote %}
Unfortunately, sometimes you are not fully in control of the content
you produce. For example, this very blog, published with WordPress
tags. If you find yourself in this same boat, encourage your tools
vendors to provide support for generating valid HTML.
{% endblock %}

That came from this article which puts up some very strong points
regarding HTML and XHTML and browser rendering (preferring HTML4), and
points out that many leading web standards experts are also
recommending HTML4:
http://webkit.org/blog/68/understanding-html-xml-and-xhtml/

(Donning flame retardant suit b/c I'm sure I'll get flamed for being a
retard here...)

Is Django really the web framework for *perfectionists* if it, by
default, prefers the imperfect XHTML in newforms and the admin (and
other places)?  If not a complete switch, could we at least not make
those who are anal about outputting HTML4 not have to work[1]
harder[2] than[3] those who are ok XHTML?

-Rob

[1] http://www.djangosnippets.org/snippets/618/
[2] http://www.djangosnippets.org/snippets/716/
[3] http://code.djangoproject.com/ticket/6925


--~--~-~--~~~---~--~~
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: Form rendering with filters

[Rob Hudson]

I'd like to know too.  I especially liked both of Simon Willison's
ideas of 1) Template tags for form rendering, and 2) Outputting and
setting of a _doctype variable that the template tags use to decide
what kind of HTML to output.

If nobody has officially started anything, could we set up a Google
code project with the hopes of this being included in Django once it's
working and all the kinks are worked out?

-Rob

On May 21, 2:30 am, Aral Balkan <[EMAIL PROTECTED]> wrote:
> Just a quick bump: has there been any progress on this?
>
> Thanks,
> Aral

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Model Inheritance in qsrf and User?

[Rob Hudson]

I don't know if this should go to devs or users but I wanted to ask...

Now that queryset-refactor has implemented model inheritance (and will
soon be in trunk), will the recommended way to tie in new columns to
contrib.auth.models.User change?  For example, if we want to add in
profile information specific to our apps?

Thanks,
Rob
--~--~-~--~~~---~--~~
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: Maybe DEBUG=True should only record the last N SQL queries?

[Rob Hudson]

Simon Willison wrote:
> Of course, this behaviour is documented... but I think it's reasonable
> to expect that many people will miss that part of the docs.

Where?  I didn't know about this and feel like I've read most of the
Django documentation and the Django book.  I'm purposefully looking
for it and can't find it.

Thanks,
Rob
--~--~-~--~~~---~--~~
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

[Rob Hudson]

Just a note: I'm not going to champion this one since I do know
regular expressions.  I simply read elsewhere that it is a common
stumbling block for newbies and thought I'd bring it up.

Actually, the regex newbies I know usually just need a few examples to
get them off the ground.  E.g. use "[-\w]+" for slugs, use "\d+" for
digits or id numbers, etc.

Adrian makes a good point about not wanting multiple ways to specify
URLs.  That does seem a bit ugly.

Thanks for the discussion.  :)

-Rob

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Easier URL patterns

[Rob Hudson]

It was discussed previously that making URL matching easier by not
having to understand regular expressions would be a nice goal, and
perhaps a nice 1.0 goal...
http://groups.google.com/group/django-developers/browse_thread/thread/b4c237ad76f9eeca/b9b2acc81fe6e5cf

I just stumbled across yet another way routing could be handled in merb:
http://toolmantim.com/article/2008/1/22/merb_routing_in_0_5

Note: I'm not pointing out merb as any better example than others
mentioned in the above thread.  I only mention is as the article that
sparked my interest and reminded me of the prior discussion.

Something like this (ignore delimiting syntax for the moment):

url('/{{ slug }}/', myview),

would be much less daunting to those that haven't read the Friedl book
than this:

url(r'^(?P[-\w]+)/$', myview),

Please correct my assumptions if they're wrong...

* Converting "{{ slug }}" to "^(?P[-\w]+)/$" seems easy enough
and could be done in the django.core.urlresolvers.RegexURLResolver's
__init__ method as a quick check of what the string contains (a regex
to produce the regex?).

* Defaulting to "[-\w+]" makes sense to me as a default regular
expression to catch most URL patterns.  It can catch strings, slugs,
and numbers.  Things like this would still work: "/{{ year }}/{{ month
}}/{{ day }}/{{ slug }}/" but may not be as optimized as specifically
looking for digits or [a-z].

* I only chose the "{{" delimiter b/c it's already used in templates.
I'd think any delimiter could be used so long as it isn't hard to
distinguish it from typical regex syntax.  (e.g. "[slug]" might not be
the best).

If interested, I could toy around with a patch.  Though once decided,
it doesn't seem like it would end up being much of a code change.

-Rob

--~--~-~--~~~---~--~~
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: Adding InnoDB table engine to sql.py create table statements

[Rob Hudson]

On 3/24/08, Alex Koshelev <[EMAIL PROTECTED]> wrote:
>
>  Hi, ro60
>
>  There is no need in such setting. Just now you can set table engine to
>  entire database or in settings.py per-connection with
>
>  DATABASE_OPTIONS = {"init_command": "SET storage_engine=INNODB" }

Or to avoid this setting and to set MySQL to always use InnoDB, make
sure the "skip-innodb" setting is commented out in /etc/my.cnf and add
default-table-type=innodb (plus the other innodb_* settings you might
need).  I've heard setting that DATABASE_OPTION adds a bit of overhead
on database connection initialization.

-Rob

--~--~-~--~~~---~--~~
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 + SQLAlchemy as a potential GSoC project

[Rob Hudson]

On 3/24/08, James Bennett <[EMAIL PROTECTED]> wrote:
>
>  On Mon, Mar 24, 2008 at 3:23 PM, Ben Firshman <[EMAIL PROTECTED]> wrote:
>  >  Would proposing a complete replacement be a tad too controversial for a 
> GSoC
>  >  project?
>
>
> Yes. It also wouldn't succeed as a project, because it's the Google
>  *Summer* of Code, not the Google Several Years of Code.

And it sounds like 'empty' and 'brosner' are making good headway on it...
http://blog.michaeltrier.com/2008/3/21/django-sqlalchemy

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Should manage.py startapp create a urls.py file?

[Rob Hudson]

If it's common advice to make apps portable and bundle urls along with
an app, shouldn't manage.py startapp also drop in a default urls.py
file?

I realize it's simple to create a skeleton file yourself, but if
manage.py did it, it's one less thing to think about and do, and also
promotes good url bundling.

-- 
kthnxbye,
-Rob

--~--~-~--~~~---~--~~
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: Reconsider ADMIN_MEDIA_PREFIX default?

[Rob Hudson]

On 12/18/07, Vinay Sajip <[EMAIL PROTECTED]> wrote:
> A reasonable approach would be that the media root for any app is
> conventionally /media/app_label. This is easily organisable under
> Apache/mod_python by having a single media location /media/ for which
> you do a "SetHandler None", then create a "media" directory in the
> Apache document root, and in that directory create symbolic links to
> app_label1 -> /path/to/media/for/app/with/label/app_label1, etc.

I like the idea but doesn't this run into the same like-named
app_label problem that the other thread is trying to solve?  eg:
"ellington.search" and "marketplace.search" would both map to
/media/search/.

-Rob

--~--~-~--~~~---~--~~
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 weekly updates?

[Rob Hudson]

On 12/13/07, Empty <[EMAIL PROTECTED]> wrote:
> For those that enjoy an audio dump, for a commute or something, I've
> put together a podcast called This Week in Django.  It's a bit
> experimental at this point, but I'm playing around with different
> ideas.  You can find more here:
>
> http://blog.michaeltrier.com/2007/12/14/this-week-in-django-episode-001
>
> Michael
> blog.michaeltrier.com


Wow, that's great.  Sounds good too.  If we did set up a mailing list
we all could collaborate on the changeset picks, blog post picks, etc.

How do we go about setting up a new mailing list on google groups?
Anyone have a suggestion for a name?

Cheers!
-Rob

--~--~-~--~~~---~--~~
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 1.0 features -- the definitive list

[Rob Hudson]

Would it be too much to start thinking about marketing for the 1.0
release?  By marketing, I mean, screencasts, t-shirts, coffee mugs.
Possibly a not-for-profit entity to pipe whatever proceeds or
donations through to help support Django coding, or have paid
bounties, etc.

IIRC, some of these things have always been shelved for the 1.0 release.

-Rob

--~--~-~--~~~---~--~~
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 weekly updates?

[Rob Hudson]

On 12/11/07, Patryk Zawadzki <[EMAIL PROTECTED]> wrote:
> Why not use 
> http://code.djangoproject.com/timeline?ticket=on=50=90=rss
> ?

I am actually.  But I did just realize the description fields has the
full details of the comment.  The description field would require a
bit of processing since it contains escaped HTML, however.

--~--~-~--~~~---~--~~
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 weekly updates?

[Rob Hudson]

On 12/11/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> Looks like a good start. If you can sort out the details of how to
> manage this as a group effort and get a regular publication rhythm
> going, I'll poke Jacob and Adrian and see what we can do.

Great.  Thanks.  I did ask Jacob if it were possible to tell Trac to
not truncate the Changeset descriptions so short.  As it is, I have to
go into each changeset detail page to view the full details to
include.  This *could* be automated but it would be much simpler if
truncation wasn't so short.  I don't know Trac so I'm not sure if this
is a setting or not.

> One suggestion - another section that might be worth adding is
> 'notable blog entries' - There are a few community members that keep
> really good blogs (B-List being the most notable example, but there
> are others); when they post a good article, it would be worth
> mentioning in the weekly update.

Definitely.  I kept it short just to focus on the Trac stuff and dev
list.  As the week goes by I'm paying attention to my news reader and
will flag blog posts throughout the week.  I was also going to include
bits from Django snippets, like the Active Directory thing that came
through yesterday.

What is a bit of a struggle is what to filter.  All changesets is
obviously too much and you can get that from the timeline anyway.  I'm
sure I'll often miss what's important to others.  My goal is to focus
on changesets that have a larger impact on the code base, or dev list
threads that have a larger impact, etc.  I'm sure that will always be
a challenge.

Thanks,
Rob

--~--~-~--~~~---~--~~
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 weekly updates?

[Rob Hudson]

On 12/8/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> The same is true of a weekly Django update message. There is
> absolutely nothing stopping you from writing a weekly blog message and
> publishing it somewhere.

I posted a quick proof of concept:
http://rob.cogit8.org/blog/2007/Dec/10/django-week-review-dec3-dec92007/

I'll be monitoring a few resources throughout the week to hopefully do
a bit better job of picking up on external resources and news.

With guidance from the Symfony weekly update editor, I've written a
Python script to parse the RSS feed of Django's Trac timeline to count
tickets (open, updated, closed), changesets, and wiki updates.  And to
output Markdown formatted links to changesets so it's a copy/paste
operation to pick the highlights.  This can/will evolve each time I
use it I'm sure.

On 12/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I would be willing to take on this editor role for a week, once every
> month/two months, if we just have a detailed checklist of what to do
> during that week, and agree on a format for how to compile an django
> roundup.

What would be the best way to organize a group of newsletter editors?
A mailing list?  If so, let's kick it off.  Sounds like fun.

-Rob

--~--~-~--~~~---~--~~
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 weekly updates?

[Rob Hudson]

On 12/8/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> I'm not sure I'd be a fan of a completely automated mechanism - Django
> has a certain sense of style and finess that isn't conveyed by simply
> aggregating all updates into a single message.

The intent of my first message was to propose a partially automated
update, not a completely automated one -- where the author has the
choice to edit very little or get a bit more elaborate as time
permits.  Something with a straight forward and easy to put together
format.  And something that, with very little editing and human input,
would still be a worthwhile and useful update.

> As always, it's easy to propose a technical solution, but ultimately
> what we need is a warm body - and they're a lot harder to come by. If
> you're volunteering to be that warm body, you're welcome to help out.

I was volunteering.  But it's also nice to hear feedback on whether
the whole endeavor sounds worth it, or if the general format sounds
good, etc.  Or even if Clint is just taking a break and plans on
coming back.

Or if there are a few people interested in helping so we all can do
rotations and it's not such a burden on one person each week.

Thanks,
Rob

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Django weekly updates?

[Rob Hudson]

Hi Devs,

I've been missing the weekly updates that Clint Ecker was doing and so
I thought I'd write in to pitch an idea and offer some help if I
could.  I'd say a good goal to keep these going would be to not rely
in a single person as much.  If we can come up with a weekly format
that is not very time consuming, some tools to generate parts of it,
and maybe a mailing list for people to push ideas to, anyone could
gather up the pieces and push a weekly update out.

I really like Symfony's weekly updates and they seem a bit easier and
less time consuming to put together, while still providing enough
linkage and updates for people.  Here's an example:
http://www.symfony-project.org/blog/2007/11/11/a-week-of-symfony-45-5-11-november-2007

The basic format, adapted to Django, could be:
  - Dev mailing list summary.  Mostly just links to the thread.
  - Trac changeset summary with links.  (A trac report)
  - Dev digest.  This looks like some sort of Trac script to show how
many changes, new tickets, closed tickets, etc.  I'm not great at Trac
I'd need help figuring out how to generate this info easily.
  - Documentation updates or book changes.
  - Important wiki updates
  - New Django sites
  - New Django blog posts out on the internets
  - I'd also like to see updates or notices on software related to
Django.  Not exactly plugins as Symfony has a section for, but the
various google code projects, etc.

Thoughts?  Is the mailing list idea for notices/updates possible?  I'd
be willing to kick this off and post to said mailing list for weeks I
can't compile an update.  In the weekly summaries we can publish the
mailing list so people know where to send update notices.

Personally, I think it's important to do summary updates, especially
as we're pushing towards a major release.

Thanks,
Rob

--~--~-~--~~~---~--~~
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: Custom permissions and contenttypes

[Rob Hudson]

On Sep 27, 12:53 am, eXt <[EMAIL PROTECTED]> wrote:
>I found that there was a change in
> django.contrib.contenttypes.management.py which adds:

I wrote that patch so I can at least respond but I think this bubbles
up into a design decision for Django...

> This causes removal of my custom content type and custom permissions.
> So my question is - is there any other way to have custom permissions
> in Django? Maybe the above piece of code should just be removed?

I think the more common case is modifying or removing models vs.
adding custom content types and permissions.  But at the same time it
would be nice if it were flexible if this is a common enough case.

Is there anything in Django to "register" a custom content type or
permission that the ContentType object can call on to determine if a
content type is registered, and if not, remove it?  Or could one be
added?

-Rob


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Is model.objects.all().delete() optimized to use DELETE FROM?

[Rob Hudson]

Hi Devs,

Is model.objects.all().delete() optimized to use DELETE FROM?  I'm
only asking because I was trying to clear a table with about 20k
records and it took minutes rather than seconds.  I'm using MySQL as
the backend.  I'm not very familiar with the database query mechanism
and I know it's being rewritten.  I couldn't find much in the few
places I poked.

Thanks,
Rob


--~--~-~--~~~---~--~~
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: #2465 - Make select_related() related work for ForeignKeys with null=True

[Rob Hudson]

On 9/15/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> On Sun, 2007-09-16 at 00:36 +, Rob Hudson wrote:
> > http://code.djangoproject.com/ticket/2465
> >
> > I'm running into this and it makes sense to me that select_related
> > should do this right.  I'm curious of Adrian's comment about this
> > involving a bunch of LEFT JOINs and why that's a bad thing?
>
> It's a lot slower at the SQL level. Try it and see: put two joined
> tables into a database and allow the foreign key column to be NULL. Put
> in 100,000 rows or so. Now select a joined version of the tables using
> INNER joins and then LEFT OUTER joins. Time it. Notice the difference.
> Imagine you were doing that a few times a second.

Thanks for the reply and explanation.

-Rob

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

#2465 - Make select_related() related work for ForeignKeys with null=True

[Rob Hudson]

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

I'm running into this and it makes sense to me that select_related
should do this right.  I'm curious of Adrian's comment about this
involving a bunch of LEFT JOINs and why that's a bad thing?

Thanks,
Rob


--~--~-~--~~~---~--~~
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 import location of objects to docs?

[Rob Hudson]

> However, we're always interested in any way to make the documentation
> better, so if you can come up with a way to make this idea work, we
> can take a look at it.

That's the hard part and was hoping someone would have a bright
idea.  :)  The best idea I've had is to spell out the full path to the
object or method the first time it is used in the documentation,
similar to how you spell out an acronym the first time but just use
the acronym thereafter.

eg:

When a page is requested, Django creates an django.http.HttpRequest
object that contains metadata about the request. Then Django loads the
appropriate view, passing the HttpRequest as the first argument to the
view function. Each view is responsible for returning an HttpResponse
object.


That gives enough context for a programmer to write an import
statement or a path to view the source if they really want to dig
deeper.  And to me doesn't interrupt the flow of the reading at all.

-Rob


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Add import location of objects to docs?

[Rob Hudson]

Hi Devs,

One of the things I'm always stuck with when reading the docs is
knowing where to import the described methods or objects from.  For
example, just now I'm working on Q objects and just read the
documentation but don't know where they live without having to jump
into the source of where I think they live.

I'd be happy to help document where things are in the docs if we come
up with a standard way to document them.

A couple of ideas:

1) Add a footer to pages and when a new method or object is brought up
link to the footer which shows where it lives in the Django source.

2) Use a HTML abbrev attribute so the user can hover the method name
or object name and see the appropriate "from django.db.models.query
import Q".

I ran into this the other day when I was showing someone docs on
render_to_response and that they needed to add the RequestContext -- I
had to figure out where both of those were.

If this is a good addition, it might make for a good task during the
sprint for newbies like myself not very familiar with Django
internals.

Thanks,
Rob


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

should paginator validate and auto-convert args?

[Rob Hudson]

Hi Devs,

I just bumped into this and can see both sides so I'm posting here...

I'm working on a project that wants a list view to have configurable
num_per_page for pagination.  I set it up to pull from the GET (eg: /
search/category-slug/?per_page=10).  What I did was check for the
existence of per_page in request.GET and pass it to the paginator in
my generic list view.

What I got was:

TypeError at /search/category-slug/
unsupported operand type(s) for //: 'int' and 'unicode'

because GET['per_page'] is a unicode string and not an int.

I could easily convert to int in my view, checking for ValueError at
the same time but I'd have to do that in all my views if I had more
than one which doesn't seem right.

It makes some sense to push this conversion down into paginator.py,
but what if there is an error on conversion.  It would probably not be
good to have a default in paginator, would it?

try:
self.num_per_page = int(num_per_page)
except ValueError:
self.num_per_page = PER_PAGE_DEFAULT

Or simply let ValueError bubble up?  Or is it best to leave it be?

If we want paginator to auto-convert I can file a bug and submit a
patch (which is already sitting in one of my git branches) but the
other is a design decision I'm curious about.

Thanks,
Rob

PS: Sorry if this comes through twice -- I got an error, waited a few
minutes, then posted again.


--~--~-~--~~~---~--~~
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: Run script from management.py

[Rob Hudson]

I've approached this like the following, though I'd be interested to
hear if there is a better way.  I like putting the environ settings in
the script itself so everything is self contained (could be run from
cron, etc)...

At the top of my Python file I have this:

import os, sys
# Connect to Django to use models
sys.path.append(os.path.expanduser('~/sandbox/myproject'))
os.environ['DJANGO_SETTINGS_MODULE'] = 'myproject.settings'
# Pull in relevant models
from myproject.myapp.models import Model1, Model2, Model3
etc...

-Rob


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

proposal: update QuerySet.get() to return a default if object does not exist?

[Rob Hudson]

I did a search and found this thread:
http://groups.google.com/group/django-developers/browse_thread/thread/49a6b99dbcea4364/dbaa965c304feed3

It looks like there was general support for the idea but the thread
died and as far as I can tell there was never any decision or ticket.

Just tonight I found myself writing this a number of times:

category = None
try:
category = Category.objects.get(name=category_name)
except Category.DoesNotExist:
pass

It would be great if get too an argument to return a default value if
the item doesn't exist.  I understand this could be tricky if you have
a field named 'default'.  Gary Wilson points out a few options which
I'll repeat here:

1) Add a get_or_none() method that returns None if object does not
exist.

2) Add a get_or_default() method that accepts a "default" keyword
argument, the value of which gets returned if object does not exist.
If a default is not specified then None gets returned by default.

3) Modify the current get() method to accept a "default" keyword
argument as in option 2), except that instead of returning None if
"default" is not specified, a DoesNotExist exception is raised like
normal.  To return None, you would have to explicitly say
"default=None".


Is it possible to have a keyword argument with a leading underscore?
To me it's not unreasonable to have a reserved column name for this
and validate barks if you try to use it in your models in order for
this to work:

category = Category.objects.get(name=category_name, _default=None)

Cheers!
-Rob


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

DDN: On portability of apps and using Meta.app_label

[Rob Hudson]

Hi Devs,

I'm working on a patch for #5177
(http://code.djangoproject.com/ticket/5177) which will clean up
orphaned content types and Malcolm questioned, "What happens if a
model has Meta.app_label set?" and further went on to explain that it
was never clearly determined if app_label should only refer to the
containing app.

If it did only refer to the containing app, then my patch is safe --
it will remove content type entries for models that no longer have a
matching model in an app.  If it can refer to other apps, that means
one can inject a model into another application, and my patch could
potentially delete valid content types.

If I've gathered all my information correctly, app_label was orginally
added so one not need to have models in models.py and can break models
up into many files.  (Changeset 2277)  Setting Meta.app_label also
seems to be essential to dynamic models
(http://code.djangoproject.com/wiki/DynamicModels).

If I can summarize and email Malcolm sent to me, which is probably way
more coherent and correct than I could explain, he states the
following...

"""
There's a really annoying semi-bug in Django whereby if
you want split your models up into multiple files, say, a directory
structure along the lines of

   application/
  __init__.py
  models/
 __init__.py
 modelA.py
 more_models/  # Just to show it's not one-layer deep
__init__.py
modelB.py

then importing a model from application.models.modelA or whatever
doesn't work out of the box. So, you have to manually set the
Meta.app_label attribute on each model so that it knows how to work out
which app it belongs to.

[...]

That's all well and good. However, what isn't "clear" (as a way of
saying "we haven't made a declarative announcement about this") is
whether it's permissible to set app_label to something that isn't
"application" in the above example. Could I inject a model into another
app altogether by using this attribute?

If we decide that's really not supported and we won't guarantee it, then
that would be best. Because then we can one day fix the above situation
in a portable fashion -- the "portable" bit because people forget you
can have directories inside of directories -- and we can assume that all
of an application's models are initialised in a single call to a
post_syncdb-listening function.
"""

Thanks,
Rob

--~--~-~--~~~---~--~~
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: manage.py idea?

[Rob Hudson]

On Aug 15, 4:44 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> I look forward to seeing your patch! :-)

First attempt is in this ticket...
http://code.djangoproject.com/ticket/5177

I do need to test a bit further on a real project and with users who
have permissions to see how it all manages itself.  Tonight I just
tested that the content types were being added and removed
successfully (and permissions were magically being handled correctly
in auth_permissions).

I'll quote the ticket since I'm not sure where this really belongs...

The first patch works but I haven't tested fully. I had assumed I
would also have to figure out how to manage the various permissions
tables but it seems to be taking care of itself. I looked to see if
the delete() on the ContentType object had some trickery to update the
permissions but didn't find anything.

This doesn't remove the orphaned model tables themselves either, which
is probably good... the idea for this patch was to avoid having to
delete rows in the contenttype and various permissions tables,
dropping a table is easy enough.

Cheers!
-Rob


--~--~-~--~~~---~--~~
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: manage.py idea?

[Rob Hudson]

On 8/15/07, Deryck Hodge <[EMAIL PROTECTED]> wrote:
> Why not, rather than adding another option in django.core.management,
> have the contenttypes app do this?  The existing post_syncdb hook
> could be extended to clear unused content types as well as create new
> ones.
>
> You would have to remember to run syncdb after a reset though, but
> this would be better than reseting all content types or adding another
> option IMHO.

After reading the code in django.contrib.contenttypes.management it
does seem the natural place.  And it makes sense to me that content
types would tidy up after itself if it noticed orphaned content types.

Is this a common problem for people or just me?  I don't run into it
with every app, but I do refactor my models often times and run into
this, and think it would be nice if there were a more automated way to
clean up those tables.

-Rob

--~--~-~--~~~---~--~~
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: manage.py idea?

[Rob Hudson]

On 8/15/07, Collin Grady <[EMAIL PROTECTED]> wrote:
> Shouldn't really be an issue with his scenario though, since he said
> this was during initial dev on the data model, so he wouldn't even have
> much (if any) data yet :)

Right, but when it comes time for the next app I create in that
project, I'd want the same thing.

-Rob

--~--~-~--~~~---~--~~
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: manage.py idea?

[Rob Hudson]

On 8/15/07, Collin Grady <[EMAIL PROTECTED]> wrote:
> Wouldn't reset do that?
>
> ./manage.py reset auth contenttypes

I haven't tried that but that looks like it would clear those tables
completely vs. purging only the unused tables.

Would following that with a syncdb then restore the content types for
the installed apps?  I'll have to test that later.

-Rob

--~--~-~--~~~---~--~~
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: manage.py idea?

[Rob Hudson]

PS: I should add before Malcolm tells me, "We accept patches" that I'm
willing to code this up for submissions if the idea is generally well
received.  :)


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

manage.py idea?

[Rob Hudson]

One of the things I typically do when starting a new project/app is to
spend some time adjusting and tweaking the data model.  One thing I
run into sometimes when I change my model name is leftover content
types in the database and also in the permissions.  It's a bit of a
pain removing these manually.

Would it be worthwhile to add a way to purge unused content types via
manage.py?  It could look at INSTALLED_APPS and anything not installed
it removes?

-Rob


--~--~-~--~~~---~--~~
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: feedback on full atom feed support

[Rob Hudson]

I've been watching the development with interest.

I'm probably your user #1 with curiosity that might lead to user #2.
I know the basics of what Atom is and what AtomPub is (but not quite
clear on where REST and full AtomPub differ or relate -- they sound
like they have a lot of overlap where maybe REST is at the HTTP level
and AtomPub is more on implementation details?)

I had an RSS feed set up but wanted to do Atom feeds.  I wasn't too
crazy about how subclassing Feed required having a template file to do
full content feeds, so I rolled my own using the Atom1Feed base
class.  It wasn't difficult and the code is simpler, IMO.

Now I'm wondering if the feed is valid and will wonder off to figure
out how to determine that after I send this.  To that end, the
suggestion of a warning or an easy way to test feeds via Django would
be helpful.

Cheers!
-Rob


--~--~-~--~~~---~--~~
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: Simple improvement suggestion for django.contrib.syndication.feeds

[Rob Hudson]

FYI: I've also contributed a patch for this ticket:
http://code.djangoproject.com/ticket/3624

It adds some extra support so the feeds don't need to hit the
filesystem just to pull in a simple template.

-Rob

On Aug 7, 4:28 am, jorjun <[EMAIL PROTECTED]> wrote:
> Done. Thanks for guidance.
>
> > Even if you can't generate an SVN diff, it would be better to post
> > this in a ticket; posting it to the list means it is more likely to
> > get lost in the traffic.


--~--~-~--~~~---~--~~
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: Autoescaping: good time?

[Rob Hudson]

On Aug 2, 12:55 am, Michael Radziej <[EMAIL PROTECTED]> wrote:
> I'd still suggest a 'default off' policy at least when autoescape is
> introduced, just to give users a transition period. A 'default on' policy
> means that autoescape will break a lot of custom template tags and filters.
> The policy could then change to 'default on' shortly before a new release.

I kind of think it should just be done 100% in 0.97 and announced in
the release notes.  Everyone should know that pre 1.0 there will be
some backward incompatible changes and should watch out for them, no?
So far Django has had great docs on transitioning between releases.

-Rob


--~--~-~--~~~---~--~~
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 Success Stories

[Rob Hudson]

> Now, there's one small wrinkle that may prove unfortunate for you: in
> the Django community, it's pretty much established practice to equate
> good ideas with a volunteer offer. By this precedent, I do believe
> you've volunteered to gather this material .
>
> Seriously, though -- if it's something you've got time for, I at least
> would benefit greatly from it.

Yeah, that was the intention somewhat but honestly I thought it might
just fall into place.  Maybe I'm being hopeful.  :)

Things I think that need to happen...

1) Set up a page on the wiki with instructions and suggested outline
of a success story.
2) Post a "Call for Success Stories" somehow, maybe via the weekly updates.
3) Keep an eye on the page and linked pages.

I thought an outline could be as simple as:

* Describe prior infrastructure and what was wrong.
* Describe current Django infrastructure and if or how it fixed the
prior issues, the more detail the better.

Anything else?

Cheers!
-Rob

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Django Success Stories

[Rob Hudson]

Hi Devs,

One thing that came out of the Django Meet-up at OSCON was someone
asking for advice on how to convince their superiors that Django is a
good choice.  This obviously depends on the needs of the individual or
shop, but I was wondering if we could add a section to the Wiki for
success stories -- a place where people who have switched can write
about how the switch went and why Django is working out well for them?

If the idea is good, to get the ball rolling we could ask for stories
in the weekly update.  I know our company has one and I'm sure there
are many others.  We could, perhaps, discuss a general topic outline
for those submitting success stories for maximum benefit to readers to
hear more about particular needs and requirements and how Django fit
those needs.

Just an idea.

-Rob


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Django Tutorial

[Rob Hudson]

Hi Devs,

I've been recommending Django to web developer friends.  I typically
first point them to Jacob's excellent video on Google for the
background on Django (with the caveat that some code might be out of
date but the general history and Django philosophy is well
represented)...
http://video.google.com/videoplay?docid=-70449010942275062

I then point them to the Django documentation where one of the first
things they try to do is walk through the tutorial.  This is where I
often hear some complaints about the tutorial.  To be perfectly
honest, I've never thought to follow up and hear what they thought
wasn't so great... I've just referred them on to more material (like
open code available to look at, the Django Book online, etc.)

But I do recall when I walked through the tutorial that it was good
and well explained, but the example itself (Polls) left something to
be desired.

I'm curious if it's ever been considered to rewrite the tutorial with
a more apt app or project?  My main question is if it's open for
discussion or do most think it's a fine tutorial.  If most think it
could be better, then I'd like to open the discussion on what kind of
app or project might be more suitable and interesting to a wider
audience and the parts of the tutorial itself.

Thanks,
Rob


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Django Windows Installers

[Rob Hudson]

Hi Devs,

In http://code.djangoproject.com/wiki/VersionOneFeatures I see Windows
Installers listed with no leader and no start status.  I'm pretty
comfortable building installers using NSIS (nsis.sf.net) as we do that
where I work and could chip in here.

Has it been discussed what the installer should install?  I'd be happy
to help out but more specifics would be nice.  Here are some general
questions, and if answers come in I'll update that Wiki page to add
"Comments about Specific Features" down below.

* Install Python?  Full version or other?  v2.4?
* Install a database or just SQLite?  Options to install others
(mysql, postgresql)?
* Options for other common libs like Markdown or Textile, etc?
* Uninstaller?

If I were to do this by default, I'd probably approach it as follows:
* Bundle Python v2.4 but incorporate checks for pre-existing Python,
or maybe just execute the pre-existing Python installer.  (Testing
needed.)
* Use SQLite.
* No common libs, just bare minimum to get Django running.

Cheers!
-Rob


--~--~-~--~~~---~--~~
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: git and Django

[Rob Hudson]

On Jul 19, 2:10 am, Michael Radziej <[EMAIL PROTECTED]> wrote:
> Was git-svn easy to set up? I'm having issues with its ugly sibling
> "git-svnimport" ...

On a Mac with MacPorts, very easy:

$ sudo port install git-core +svn

Anywhere else I'm not sure but the above suggests that git-svn is a
build-time configuration option in git itself.

Thanks for the pointers on the other bits... I'll have to take a look.

-Rob


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

git and Django

[Rob Hudson]

After going to a git presentation by Randal Schwartz and watching the
video by Linus on git, I decided to play with it some for a patch I'm
testing in Django.  I got git and git-svn installed on my Mac, pulled
down the Django source and started a new branch for the patch I'm
working on.

What's *really* cool is branches all live in the same directory so you
don't have to change your Python site-packages to point to a new
branch to test, just 'git checkout branch-name' and Django reloads
automatically and you're there.

What I can't figure out is how to create a nice patch from git to
include into Trac.  I tried "git format-patch master" but that outputs
something you'd send in an email.

I also tried "git diff master" and while this is a lot closer it
prepends "a" and "b" to the to path trees.  So you'd then have to use
"patch -p1 < mydiff", which may be what Trac does by default, I'm not
sure.

Is anyone else doing this?  Is there a better way to emit patches from
git?

Thanks,
Rob


--~--~-~--~~~---~--~~
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: Multiple Profiles

[Rob Hudson]

I'd like to hear what others think of this approach b/c it makes a lot
of sense to me and does seem much easier in that:

1) The newly defined user object is in request
2) There's one place to get user info

Thanks for sharing,
Rob


--~--~-~--~~~---~--~~
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: ForeignKeys and friends interface

[Rob Hudson]

On Apr 6, 3:51 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:

> [An unproven gut feeling: keeping a small reminder, however subliminal,
> that things are relational-database backed is actually a good idea. It
> will stop widely read people from thinking there is a true object
> backing store. Your notation disguises that somewhat. I'm not sure we
> can avoid the leaky abstraction here because we are limited by using
> relational backing stores. Acknowledging that in our notation is not
> necessarily bad.]

Awhile ago there was a thread on aggregate methods (SUM, AVERAGE, etc)
and the stated goal was to come up with a way to make those work so
that the programmer didn't require knowledge of SQL.  Yet this seems
to say that knowledge of the underlying SQL is good.  And the keyword
ForeignKey is certainly a database term and not a general English
term, where maybe is_a or belongs_to might be.

I'm not saying ForeignKey should change, but I'm suggesting that maybe
restricting Django to come up with a way to query for aggregate
functions that is more English-like doesn't seem to fit with the rest
of the models and ORM that I can see.

-Rob


--~--~-~--~~~---~--~~
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: Design decision on #3532 -- spaceless templatetag

[Rob Hudson]

> Ok - initial opinion appears to be anti configurability and anti
> changing the default. Another option is to introduce a different tag
> for the 0-spaces case. Opinions? Suggestions for names? Spaceless is
> the obvious choice, but that name is taken :-)

My thought was:

"spaceless" is no spaces for those wanting to compress their HTML and
don't care about readability.

"normalize_spaces" could be a name for keeping spaces but normalizing
them all to a single space.  Or perhaps even "single_spaces" which is
slightly less to type and provides hints to 1 space.

-Rob


--~--~-~--~~~---~--~~
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: Design decision on #3532 -- spaceless templatetag

[Rob Hudson]

> Ok - initial opinion appears to be anti configurability and anti
> changing the default. Another option is to introduce a different tag
> for the 0-spaces case. Opinions? Suggestions for names? Spaceless is
> the obvious choice, but that name is taken :-)

My thought was:

"spaceless" is no spaces for those wanting to compress their HTML and
don't care about readability.

"normalize_spaces" could be a name for keeping spaces but normalizing
them all to a single space.  Or perhaps even "single_spaces" which is
slightly less to type and provides hints to 1 space.

-Rob


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Possible bug: How does Django decide when to quote SQL arguments?

[Rob Hudson]

I was reviewing all the SQL calls in my page views by taking advantage
of the context variable "sql_queries" when DEBUG=True.

I found this query that isn't quoted correctly (I trimmed out some
stuff to make this shorter):

SELECT
  -- various fields listed here
FROM
  `page_content`
INNER JOIN
  `page_attribute`
  AS `page_content__attribute`
  ON `page_content`.`attribute_id` = `page_content__attribute`.`id`
WHERE
  (
`page_content`.`page_id` = 78
AND `page_content__attribute`.`name` = Alt Page Title
  )
ORDER BY
  `page_content`.`sequence` ASC
LIMIT 1

In the WHERE clause, page_content__attribute.name argument should be
quoted but it's not.  If I run this manually I get an SQL error.

The Python line is this (which is wrapped in a try block in case we
get an IndexError:
title = next_page.content_set.filter(attribute__name='Alt Page
Title')[0].text_content

Actually, I'm seeing this in other queries as well, whenever I have an
INNER JOIN it seems the WHERE arguments are assumed to be numeric (ie:
not quoted).

Thanks,
Rob


--~--~-~--~~~---~--~~
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: IntegrityError patch

[Rob Hudson]

I like it... I had to do a all encompassing "except" just the other
day because IntegrityError was in MySQLdb.


--~--~-~--~~~---~--~~
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 ORM bug when your app has a model named "ContentType"?

[Rob Hudson]

> Could this be related to #2874 ?

2874 looks related in that it is another bug resulting from a similar
type of circular table relationship.


--~--~-~--~~~---~--~~
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 ORM bug when your app has a model named "ContentType"?

[Rob Hudson]

On Feb 9, 3:12 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> So after some back and forth about whether this should or shouldn't
> work, there didn't seem to be any resolution. Your gut feeling looks
> right to me Rob: it should probably work as you expect (no collision),
> although it won't surprise me if it doesn't (because ContentTypes are
> mixed into generic relations, which is part of core still).
>
> I'll have a look at this, since I've delved into models.loading a lot in
> the past (and intend to do so again in the near future).

After seeing the select_related(depth) patch go in, that made me want
to see if limiting the depth of this affected the error I was seeing
in the SQL.  Result: it doesn't affect it.  Using select_related()
still adds those strange tables that don't really exist.

But!  I did find the root of what's causing this bug and it may occur
regardless of the name of the model...

Our content system has these relationships:

Content -> ContentType
Content -> Attribute -> ContentType

There's more than one way to follow the relationships to land at
ContentType.  (Aside: We originally added ContentType to Attribute so
we could filter the pulldowns of our Attributes by ContentType since
our content attributes only make sense for certain types of content.)

If I remove the FK from Attribute -> ContentType, the extra junk in
the SQL goes away.

It should be easy to test this on table names other than ContentType.

Hopefully this is an extra clue to track this down, and maybe this bug
is already known?

Cheers!
Rob


--~--~-~--~~~---~--~~
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: Upcoming Django release, and the future

[Rob Hudson]

On Feb 26, 9:46 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> I've close #760 and #3335 with this comment:

Design decision: Django won't include default 404 and 500 templates.
OK.

But does that invalidate those bugs?  The default templates were a
possible solution to fix both of them.

Both of these bite the end user when they migrate from development to
production so these seem especially ugly to me... changing DEBUG
shouldn't break your site.  Perhaps under DEBUG=True Django should
detect the existence of 404.html or 500.html when one of these errors
occurs?  Or maybe ./manage.py validate should perform this check?

If anything, flatpages docs should mention to the user to make sure
they have a 404.html template or it will break when DEBUG=False.
That's certainly something I could provide a patch for.  Is there
another place to add docs that all projects must contain 404.html and
500.html templates?

Thanks,
Rob


--~--~-~--~~~---~--~~
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: Upcoming Django release, and the future

[Rob Hudson]

Could we get a design decision on whether to add default, non-django
looking 404 and 500 templates?

It seems pretty minor but important as there are 2 cases where
switching from DEBUG=True in development to DEBUG=False for production
could end up biting you...

1) With DEBUG=False and a 500 occurs and there's no 500.html, Django
exposes a traceback...
http://code.djangoproject.com/ticket/760

2) If using flatpages...
http://code.djangoproject.com/ticket/3335

Adding a fallback 404 and 500 template would fix these.

-Rob


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

app completion in django_bash_completion - testing please

[Rob Hudson]

I implemented app completion and would like comments and testing for
those on *nix.

What's the easiest way to provide a patch?  Open a new ticket and
attached?  Or attach it to the original bash_completion ticket here:
http://code.djangoproject.com/ticket/1240 ?  I'm pasting the diff
below so people can test for now.

A couple notes:

* My patch uses sed, grep, and tr instead of the previous patch which
uses Python.  The Python way does seem nice since Django already knows
about its own apps.  But Adrian made a comment on the ticket above
that it didn't work for him.

* Depends on settings.py being named "settings.py" and depends on the
user being in the project root directory (where settings.py is).  The
previous patch had this dependency too.

* This essentially does the following (each command):

  1. Filters settings.py and prints everything in INSTALLED_APPS
  2. Strips any lines with django in them
  3. Does pattern matching to get the app name.
  4. Finally, tr merges the separate lines into a single line with
apps separated by spaces.

It's working on my Mac.  If I type "./manage.py sql " and press tab
twice, I get a list of apps and starting to type one does tab
completion.

Comments appreciated.

-Rob

Index: extras/django_bash_completion
===
--- extras/django_bash_completion   (revision 4557)
+++ extras/django_bash_completion   (working copy)
@@ -79,10 +79,12 @@
 adminindex|install|reset| \
 sql|sqlall|sqlclear|sqlindexes| \
 sqlinitialdata|sqlreset|sqlsequencereset)
-# App completion isn't yet implemented, but here's where
that
-# would go.
-# COMPREPLY=( $(compgen -W "auth core" -- ${cur}) )
-COMPREPLY=()
+# App completion
+apps=`sed -n '/INSTALLED_APPS = (/,/)/p' settings.py | \
+  grep -v django |
+  sed -n "s/^[ ]*'.*\.\(.*\)'.*$/\1 /pg" | \
+  tr -d '\n'`
+COMPREPLY=( $(compgen -W "${apps}" -- ${cur}) )
 return 0
 ;;


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

newforms: Subclassing forms and sequencing?

[Rob Hudson]

I saw this changeset go in and am wondering if it is possible to
specify a sequence order for the fields to display.  Example:

class Person(Form):
first_name = CharField()
last_name = CharField()

class PersonWithMiddle(Person):
middle_name = CharField()

But where you want this to display like this:

>>> print p.as_ul()
First name: 
Middle name: 
Last name: 

Instead of middle name getting appended to the end.

I personally don't have a specific need for this currently.  Mostly
curious.

-Rob


--~--~-~--~~~---~--~~
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: if form name is like "name[key]", convert to dict in request.POST

[Rob Hudson]

On Fri Feb 09, 2007 at 02:54:44PM -0800, SmileyChris wrote:
> 
> Hi Rob, there's similar functionality in Django already (but it's
> undocumented afaik) using a custom data structure called
> DotExpandedDict:
> http://code.djangoproject.com/browser/django/trunk/django/utils/datastructures.py#L215
> 
> I just opened a ticket regarding it's undocumented nature.

Interesting.  I'm guessing it's not wired up to request.POST... I tried
naming my form like name="name.key" and got no DotExpandedDict love.  :)

Thanks,
Rob

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Proposal: if form name is like "name[key]", convert to dict in request.POST

[Rob Hudson]

This is obviously borrowed from PHP but I think there are useful
reasons to copy this behavior.

The idea...

If one constructs their HTML forms, naming their form elements as
"name[key]" like so:

  
  
  
  etc.

Django would then convert this to a dictionary of form:

  f = {
'name': 'value of f[name]',
'address': 'value of f[address]',
'city': 'value of f[city]'
  }

This is also useful for grouping multiple select boxes:

  
   One
   Two
   Three
   

(I'm not sure how Django handles multiple selects currently.)

Processing within Django, to me, becomes simpler, and one can do
things like the following rather than iterating over all items in
request.POST:

  if request.POST.has_key('f'):
for k,v in request.POST['f'].iteritems():
  # process key/value pairs in some way

Grouping your forms into dicts like this also lets you do iterative
logic while avoiding other POST items (eg: input type=submit values or
X,Y coordinates).

I'm not sure how this would tie in with newforms since we're not using
Django's forms and validation (at least for now).

Cheers!
Rob


--~--~-~--~~~---~--~~
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?

[Rob Hudson]

I'd like to see more inline documentation of the code.  Some .py files
have this but some don't.  Just an overview of what the file does, how
things are organized, maybe some concrete examples via doctests.
Something for the average python programmer to get a toehold into what
the code is doing.

Inline in the code seems like a good place for this to me.  It can be
updated as the code changes.  And those digging around in the code are
the ones who will benefit the most from it.

Cheers!
-Rob


--~--~-~--~~~---~--~~
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

[Rob Hudson]

> I agree this approach is a huge improvement over the current syntax,
> but I wonder whether it can be expanded even more. Instead of
> dictionaries, let's use objects:

Woah... inline that is specified by objects that can be subclasses?
I'll have to wrap my head around that one.

Would it be possible to nest inlines?  This is one limitation we
sometimes bump up against since our data model spans more than a few
relationships sometimes, and it would be nice to have greater inline
depth.

For example, if you have:

class Kingdom(models.Model):
#
class Admin:
inlines = (
StackedInline('Phylum')
)

class Phylum(models.Model):
kingdom = models.ForeignKey(Kingdom)
class Admin:
inlines = (
StackedInline('Class')
)

class Class(models.Model): # ignore the reserved word :)
phylum = models.ForeignKey(Phylum)
class Admin:
inlines = (
StackedInline('Order')
)
etc...

Could that work and span all those relationships, following the
relationships as it goes.

-Rob


--~--~-~--~~~---~--~~
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 ORM bug when your app has a model named "ContentType"?

[Rob Hudson]

> Django has a builtin type called "ContentType",
> http://code.djangoproject.com/browser/django/trunk/django/contrib/con...
>
> I'd just rename yours to something else and be done with it.

As a workaround, sure.  I've already worked around the issue.

But I don't think Django would want this type of restriction.  I've
tried to track how this might get in the SQL myself but it's beyond
me.  I'm just offering to help assist or share my model offline if
needed.

-Rob


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Django ORM bug when your app has a model named "ContentType"?

[Rob Hudson]

I'm getting a weird bug here and this is what I've deduced...

I've got a "Page" model and a "Content" model.  Content has a FK to 
Page.  I also have a "ContentType" model and Content has a FK to 
ContentType.  This is where I tell it if the content is text or other 
media content.

The problem comes when I use Content.objects to pull data...

This works:
  Content.objects.filter(page__number=11020)

But this doesn't:
  Content.objects.select_related().filter(page__number=11020)

When I view the SQL, the one with selected_related includes invalid 
tables in the SELECT clause, namely:

  '`page_contenttype6`.`id`',
  '`page_contenttype6`.`name`',

Even though it already has the real tables:

  '`page_contenttype`.`id`',
  '`page_contenttype`.`name`',

When I look in the django_content_type table, the row with id=6 is:
  |  6 | content type | contenttypes | contenttype |

This seems like too much of a coincidence.  The row for the 
"ContentType" content type is this:
  | 10 | content type | page | contenttype |

How can I help further debug this?


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---