#7198 - Better error message when app is missing models.py

[Justin Lilly]

Not sure why this particular ticket is marked as DDN, as it seems like
a no-brainer. The patch provides a more clear error message when a
user is attempting to load an app which doesn't have a models.py.

https://code.djangoproject.com/ticket/7198
https://github.com/django/django/pull/39

Happy to respond to any feedback, as I think this is a worthwhile
change.

-- 
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: #11930 - submitting patches against djangoproject.com files?

[Justin Lilly]

You can find it in the community_redux version of the code which will
be deployed any day now.

[0]: https://github.com/jacobian/djangoproject.com/tree/community_redux

On Sat, Dec 4, 2010 at 8:48 PM, Greg Turner  wrote:
> Hi,
> I have a patch for #11930 that in to be applied against djangoproject.com's
> base.css file. As far as I can see, base.css is not in the project
> repository. Who is the custodian of this file, and the other CSS files? Is
> there a reason it's not in the repo?
> Greg.
>
> --
>
> Dr Greg Turner
> Director, the Interaction Consortium
> http://interaction.net.au
> Phone: +61 2 8060 1067
> skype: gregturner
> Follow us on twitter:
>
> http://twitter.com/theixc
> http://twitter.com/gsta
>
> --
> 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.

Re: Allow slug to be prepopulated on edit

[Justin Lilly]

I don't believe there is.

Historically, this is there because slug fields usually make their way
to be used
for URLs. As such, changing the title of an object shouldn't adjust its URL as
that can be bad for SEO and folks who might have bookmarked it.

You can, however, add your own javascript via the methods listed in the
docs[0]. If you need more help on this, please direct your questions to
django-users as this has more to do with using django than the core product
itself.

Best of luck,
  -justin

[0]: 
http://docs.djangoproject.com/en/dev/ref/contrib/admin/#modeladmin-media-definitions

On Mon, Oct 25, 2010 at 4:32 AM, Alex  wrote:
> File "admin_modify.py" method "def prepopulated_fields_js(context)"
> Line 11:
> if context['add'] and 'adminform' in context:
> should be changed to
> if 'adminform' in context:
> to allow slug be auto updated every time and not only on the entity
> creation in admin.
> Is there any setting to do it without changing Django internal source
> code?
>
> --
> 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.

Re: #6375 -- Class Based Views: Opinions on commit plan

[Justin Lilly]

Because you asked, I think this sounds like a great idea.

When you have decided you like the API for create/update
views, please send another email to the list, so that we
know we've hit a stable API to write documentation
against.

 -justin

-- 
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: Inclusion of easy-thumbnails into Django Contrib

[Justin Lilly]

One of the criteria for django.contrib is that the item for inclusion
is a "de facto standard implementation of common patterns"[0]. From
your own admittance there are conflicting views about how this should
be handled. Perhaps if someone abstracts this out a bit and has
something like image processing backends, it may make a bit more sense
for inclusion, but as it stands, I'm -1.

 -justin

[0]: http://jacobian.org/writing/what-is-django-contrib/

On Thu, Sep 16, 2010 at 1:26 PM, ptone  wrote:
>
>
> On Sep 16, 9:43 am, Patrick Altman  wrote:
>> Another "community voice" contribution on this thread...
>>
>> I am of the opposite opinion.  I think it would be better for Django as a 
>> whole if django.contrib approached zero.  In fact, I would have no problem 
>> with seeing it go away completely and promote auth and sessions to core but 
>> done in a way that is pluggable.  The reasoning behind this opinion is that 
>> it leaves the surface area in the project smaller to maintain and it's 
>> really not that hard to add a sorl-thumbnail external app to a Django 
>> project.  Furthermore, it provides more freedom for these apps to mature and 
>> develop at their own pace.
>>
>> I realize I could very well be in a minority opinion here, but thought I'd 
>> throw it into the mix nonetheless.
>
> Another vote for evolving away from contrib.
>
> My hope is that one day http://djangopackages.com/ will become
> packages.djangoproject.com
>
> (and along with that a management command startapp-dist which starts a
> distributable skeleton)
>
> -Preston
>
>>
>> On Sep 16, 2010, at 11:33 AM, Brian O'Connor wrote:
>>
>>
>>
>> > I have absolutely no pull in decision making, but maybe my message will 
>> > count towards a "community voice".
>>
>> > I think that including an image thumbnail package that integrates into the 
>> > database as easily as sorl.thumbnail and easy_thumbnail are is a great 
>> > idea.  From what I can tell, sorl.thumbnail was the de facto standard for 
>> > getting thumbnails in to Django, and I think it has just as much of a 
>> > place in Django contrib as some of the other contrib apps do.  I don't 
>> > think it belongs in the core, but contrib seems like an excellent place 
>> > for it to go along with the other batteries in the pack.
>>
>> > On Thu, Sep 16, 2010 at 12:24 PM, Yo-Yo Ma  
>> > wrote:
>> > I have no data to support the following assertion, but it's not too
>> > unreasonable: More people probably need thumbnail images than they
>> > need comments. Comments are most used on blogs, whereas thumbnails can
>> > be used on blogs, e-commerce, photo hosting, social networking,
>> > project management, et al. It's not to say that we don't need
>> > "contrib.comments", just that I wouldn't want to lose easy_thumbnails.
>>
>> > On Sep 15, 11:32 pm, "David P. Novakovic" 
>> > wrote:
>> > > Actually, that really did sound negative. Sorry :)
>>
>> > > Is there a trac ticket open to address this issue? Generally it'd be
>> > > better to get discussion happening over a ticket and if there are
>> > > serious issues that need to be addressed then they can be discussed
>> > > here.
>>
>> > > I know it'd be nice to get things like easy-thumbnails accepted into
>> > > django.contrib , but the truth is that this probably falls outside of
>> > > things that that should be in contrib. Contrib isn't really an easier
>> > > way to get stuff into django, it still has to satisfy a bunch of
>> > > conditions like the rest of the code in the core.
>>
>> > > The real question is not "can it be included?" but why is it a problem
>> > > that this is a third party lib at the moment? Is there a strong case
>> > > that it be better if it was part of django core or does it do its job
>> > > just fine the way it is now?
>>
>> > > David
>>
>> > > On Thu, Sep 16, 2010 at 3:09 PM, David P. Novakovic
>>
>> > >  wrote:
>> > > > I don't want to sound negative, but answering your own question before
>> > > > anyone else can doesn't change the answer ;)
>>
>> > > > D
>>
>> > > > On Thu, Sep 16, 2010 at 3:00 PM, Yo-Yo Ma  
>> > > > wrote:
>> > > >> Is there any plans to 
>> > > >> incorporatehttp://github.com/SmileyChris/easy-thumbnails/
>> > > >> into django.contrib? I have seen so many apps/libraries come into and
>> > > >> go out of existence (http://code.djangoproject.com/wiki/ThumbNailsfor
>> > > >> instance mentions sorl-thumbnails which is no longer being developed).
>> > > >> I just turned the key with easy-thumbnails and voila. It's like magic,
>> > > >> but not. It's easy enough to see what's going on behind the scenes.
>>
>> > > >> This is something that, with the help of the core and other
>> > > >> contributors, could be really great. It works for me as it it is, but
>> > > >> it may not work for a more "enterprise" application that uses S3, etc.
>> > > >> It might not be 

Re: Error email flooding on high traffic production sites

[Justin Lilly]

This seems applicable to dcramer's django-db-log.

http://github.com/dcramer/django-db-log

This might also dovetail with logging support which may make it into
1.3, so it might be worth looping in the folks involved in that.

 -justin

-- 
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: Documenting new features: built-in obsolescence of the "versionadded" tag.

[Justin Lilly]

While I know it comes with extra work, I think the contents of the
versionadded bits need to be reworked into the body of text. While I
can't remember any specific examples, I remember reading docs a few
times and coming across versionadded statements that were at the
bottom of their section rather than where they would have naturally
flowed in the text.

On Fri, Jul 23, 2010 at 3:49 PM, Jacob Kaplan-Moss  wrote:
> On Fri, Jul 23, 2010 at 9:37 AM, Jeremy Dunck  wrote:
>> I think maybe the rendering can just be altered to ignore tags with
>> the old values?
>
> Actually, I think I'd rather just remove them -- plenty of people
> (including me) read the docs in plain text, and the "versionadded" is
> just cruft.
>
> I'd suggest we strip out any versionadded/changed directives that
> refer to versions we no longer support.
>
> Jacob
>
> --
> 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.

Re: contrib.Auth

[Justin Lilly]

To add another point, this doesn't mean that the day 1.2 hits release that
everyone is gung-ho on 1.3. If past releases are any indication, there is
usually a refactory period of a few weeks when everyone is basking in
post-release bliss.

 -justin

On Mon, Feb 8, 2010 at 6:46 PM, Karen Tracey  wrote:

> On Mon, Feb 8, 2010 at 6:39 PM, Vitaly Babiy  wrote:
>
>> Hey Guys,
>> So 1.2 is almost out the door so I wanted to raise an issue that I would
>> love to start working to fix for 1.3.
>>
>
> Not to discourage you, but be aware the focus of most attention until 1.2
> actually goes out is still 1.2. Feature freeze doesn't mean the release is
> done, it means attention shifts to bug fixing. You many not find many people
> ready to start thinking deeply about 1.3 just yet.
>
> Karen
>
> --
> 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.

Re: Django Design Czar

[Justin Lilly]

Just to hit on another point that might have been missed by Alex's -0/1 is
that we don't have someone to pick the positions.

When evaluating meritocracy, we've traditionally had someone who was able to
do the selection. Some number of Jacob / Simon / Adrian / other commiter has
effectively vetted all current core commiters. The entire *point* of this,
is that we don't have someone who can properly do the selection. The only
person who can fill this role is Wilson. Outside of that, I think it would
make sense for a vote among people who feel they have a stake in the design
side of things and can fairly suggest someone get to vote that person in,
with BDFL blessing. The names that come to mind are those that have popped
up here and there. Jeff, Idan, Nathan, Bryan, the Grapelli team, etc. I, for
one, am willing to trust their judgement on someone who can lead this
design-czar selection process, if Wilson doesn't come out and name his
successor, as it were.

 -justin

(the above with the usual caveats recognizing Wilson's contribution & role)

-- 
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: #11716 - Bug fix ready for checking

[Justin Lilly]

The accepted tag is typically for someone triaging to accept that yes, this
really is a bug (that we want to fix). You should not change this yourself.

 -justin


On Fri, Nov 13, 2009 at 7:24 PM, Leo  wrote:

> Could I please get a core committer or a triager to take a look at
> this ticket and triage it please? It fixes a fairly core bug in the
> db.model.field code:
>
> http://code.djangoproject.com/ticket/11716
>
> What's the right process here, should I move it to 'Accepted' myself?
>
> --
> --Leo
>
> --
>
> 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=.
>
>
>

--

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: shortcut proposal

[Justin Lilly]

Just to add something a little different, there is a 5th option, that
may fall into place w/ #4. The @render_to decorator. works like:

@render_to('myapp/mypage.html')
def home(request, foo):
return {'foo':foo}

http://www.djangosnippets.org/snippets/821/

This isn't a 1:1 replacement, but I've started using it in all of my
projects.

 -justin



signature.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: URL of current page in Django Form

[Justin Lilly]

Hi Neal.

 You're looking for the django-users list. This is for talking about
the core framework, not how to use it.

 Best of luck!
  -justin


On Thu, 06 Aug 2009, NealWalters wrote:

> 
> Is there a keyword that will automatically put the URL of the current
> page in the Django form?
> Or do I have to do that in code and pass it to the form as a normal
> user variable?
> 
> Here's what I'm trying to accomplish. I have a feedback form on a base
> template.  When the user clicks the feedback button, it will post to /
> submitFeedback.  One of my database fields is the URL, so I know which
> screen the users was commenting on.
> 
> Thanks,
> Neal Walters
> 
> > 

--~--~-~--~~~---~--~~
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: Multi-DB Status Update

[Justin Lilly]

On Tue, 28 Jul 2009, Ricardo Santos wrote:

> What is the current status of the multi version support? I mean will
> it be merged with trunk any time soon?
 
... snip ...


I think this is slated for the 1.2 timecycle. The GSoC istelf ends
sometime in late August, so that's likely the earliest timeframe for
this. That said, it could invariably be later as it may not be in a
usable state. Furthermore, it will likely not be "production ready"
for at least a few weeks after that.

Hope it helps,

  -justin

--~--~-~--~~~---~--~~
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: Multi-DB Week 0 Update

[Justin Lilly]

If you recall the conversation between Alex and Simon, it will support  
this.

-justin



On May 29, 2009, at 9:29 AM, Marco Louro  wrote:

>
> Hey Alex,
>
> Not sure if this is the right place, but I guess you're the right
> person to ask..
>
> Will Multi-BD be flexible enough that it will allow to choose a DB at
> runtime, depending on something like the user or the domain and not
> tied to models at all? From what I've read that's not possible right
> now (don't need to change backends, just database name, password and
> server), and it's also not easy.
>
>
> Thanks,
> Marco
>
>
> On May 23, 5:05 am, Alex Gaynor  wrote:
>> Hey all,
>>
>> GSOC is officially scheduled to start tomorrow (my time), however  
>> I've take
>> the liberty of getting quite a jump on my work (as I described last  
>> week).
>> During this week I got the save using parameter and using queryset  
>> method,
>> these are fairly untested however.  The reason for this was after  
>> updating
>> the management commands and testing harness for multiple database  
>> support
>> any fixtures being loaded would be loaded N time (where N is the  
>> number of
>> dbs in your settings.DATABASES setting), so I needed to make sure  
>> each
>> fixture got loaded into each DB, this meant adding the using  
>> parameter to
>> save, which also uses querysets... and it was turtles all the way  
>> down :)
>>
>> So while that's basically working, the test suite as a whole is  
>> still not
>> passing (http://paste.pocoo.org/show/118532/is the results for  
>> me).  The
>> reason for this (as best I can tell) is that Postgresql runs DDL  
>> operations
>> inside a transaction, and since transaction support isn't actually  
>> working
>> across DB at this point the CREATE TABLE statements never actually  
>> get
>> committed.  Which brings us to the problem: updating the  
>> transaction stuff
>> in itself isn't a huge task, and making django use transaction  
>> stuff where
>> necessary isn't tremendously onerous.  However, one of
>>
>> --
>> "I disapprove of what you say, but I will defend to the death your  
>> right to
>> say it." --Voltaire
>> "The people's good is the highest law."--Cicero
> >

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

[Justin Lilly]

n ajax callback to an app-developer
> specified method.
>  2) give the app-developer more control of the showAddAnotherPopup.
>
>
> Is this the right place for this discussion?  If not, what is?
>
> Margie
>
>
> On May 25, 3:11 am, Zain Memon <z...@inzain.net> wrote:
>> Since GSoC officially started a couple of days ago, I've implemented a rough
>> draft of an autocomplete widget for foreign keys in the admin.
>>
>> You can see a screenshot and a short write-up of the functionality on my
>> blog 
>> here:http://inzain.net/blog/2009/05/a-foreign-key-autocomplete-widget-for-...
>>
>> Also, I've set up a GitHub repo for my work until official svn branches are
>> handed out. You can follow my progress 
>> here:http://github.com/zain/django/tree/master
>>
>> Zain
>>
>> ---
>> My GSoC 
>> proposal:http://inzain.net/blog/2009/05/django-gsoc-09-admin-ui-improvements/
> >
>



-- 
Justin Lilly
Python/Django Developer
http://justinlilly.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-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: History tracking for models

[Justin Lilly]

Take this question to django-users please. Also, check out marty  
alchin's pro django foe this snippet.

-justin



On May 13, 2009, at 3:36 AM, kailash  wrote:

>
> Hi,
>Just want to know is there any way of tracking the history in the
> database of a model.
> Like..every time i update a row using model.save() , the data that
> previously existed gets recorded into any table???
> If there's any such functionality please let me know..because the
> module i've developed for this scenario is not fool-proof...
>
> Thanks
> Kailash.K
>
> >

--~--~-~--~~~---~--~~
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: Posting to the wrong list (was: Re: Need Django Developer urgent)

[Justin Lilly]

As an alternative, we could try FRAMEWORK for extra emphasis. Perhaps  
a bit janky, though.

  -justin



On May 8, 2009, at 9:24 AM, Marty Alchin  wrote:

>
> On Fri, May 8, 2009 at 7:05 AM, Jacob Kaplan-Moss
>  wrote:
>> """
>> Discussion group for Django developers. This group is used for
>> discussion of developing Django itself, not user questions; Please  
>> use
>> django-users for issues regarding using the framework, questions for
>> the Django user community, outreach, etc.
>> """
>>
>> If you've got any suggestions of ways to make that more clear --  
>> other
>> than renaming the list, which isn't going to happen -- I'd love to
>> hear 'em.
>
> I'm not sure if it'll actually avoid confusion, but could we just do
> away with the first sentence entirely? After all, even before reading
> the description, they know it's a Google group called
> django-developers. Does the first sentence actually add anything
> useful? That would allow the description to lead off with the actual
> purpose of the group, so hopefully it would do some good.
>
> As for Ned's suggestion of "core", I wonder if that would be better
> suited in the description of what we develop. Maybe something like
> "...discussion of developing the core Django framework..." perhaps?
>
> -Gul
>
> >

--~--~-~--~~~---~--~~
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: pagination django

[Justin Lilly]

This is a question more suited for django-users as this mailing list  
is for the development of the core framework.

  -justin



On Mar 25, 2009, at 6:15 AM, nicemira  wrote:

>
> please friends,
> how can I paginate my product with this method: I want to do a newline
> after every two products
> please,answer me as soon as possible
>
> >

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

Re: "Delete selected objects" in admin batch edit

[Justin Lilly]

It would seem to me that the method we're using for context_processors
might be a good one. A list of things available by default, then you
can override it in settings.py in order to provide different ones or
remove some of the defaults. I think it could very well. Thoughts?

 -justin

-- 
Justin Lilly
Web Developer/Designer
http://justinlilly.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-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: #9282 (comment moderation features) and Akismet removal

[Justin Lilly]

My thoughts are that while akismet is the current gold standard, it
should be replaceable with another, user-defined, backend if you so
choose. Another that comes to mind is http://stupidfilter.org/main/
which attempts to tell if something is stupid, rather than spam.

 -justin

On Sun, Mar 22, 2009 at 9:42 PM, James Bennett <ubernost...@gmail.com> wrote:
>
> Ticket #9282 [1] is aiming to integrate the simple comment-moderation
> features from my (now out-of-date) comment-utils application directly
> into contrib.comments, and I notice from looking at the ticket and
> attached patches that the built-in support for calling out to Akismet
> has been removed.
>
> Is there any reason behind that? I know there's always some wariness
> when it comes to relying on a third-party service for a Django
> feature, but Akismet seems to be the gold standard for this and
> providing at least a CommentModerator subclass which supports it would
> probably be a big win for ease of use (if it's not there, writing one
> will likely be the first thing most people do when setting up
> moderation).
>
>
> [1] http://code.djangoproject.com/ticket/9282
>
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of correct."
>
> >
>



-- 
Justin Lilly
Web Developer/Designer
http://justinlilly.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-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
-~--~~~~--~~--~--~---

Can I get another pair of eyes on a few tickets?

[Justin Lilly]

Just rounding up a list of tickets I've worked on which could use
another pair of eyes. Consider this a call for reviews for the
following tickets:

6273 support for passwd-like password changing

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

A new feature, albeit a small one, which adds a management
command for changing a user's password. Adrian called it a "good
idea".

7944 generic date-based views get confused with a single-digit numeric
month_format

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

This is specifically to review strptime_delimiters4.patch as the
one after it doesn't seem to add any additional functionality and
it lacks tests. This the #4 patch has been working in production
with no ill-effects.

10237 symmetry lost when inheriting a self-referential m2m field via
MTI

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

When a model inherits a self-referential m2m field via a
non-abstract base class, it loses symmetry because the of a
comparison that doesn't take into account an object's
ancestry. The code involved here is from around magic removal.

10538 html id conflicts in admindocs

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

Simple fix for conflicting HTML id's in the admindoc's model list
view. Fixed by prepending "app-" to the id attribute.

10583 id should be visible from the admin for the sites framework

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

This one is quite new (just submitted it today), but I think as
we have to use the SITE_ID in settings.py, it ought to be
viewable through the admin. Otherwise, we have to drop to the
database which seems a bit pointless. This is a simple change to
the admin.py's list_display attribute.
--~--~-~--~~~---~--~~
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: New Functionality: built-in Message Passing

[Justin Lilly]

It seems as though you're looking for django-qpid-messaging on google
code or github. Luckily for you, that name isn't taken!*

In all seriousness, however, this functionality seems to be better
served in a separate (reusable) app. You can take inspiration from the
greater reusable community (Django Hotclub), or perhaps something like
django-evserver (
http://popcnt.org/2008/01/django-evserver-asynchronous-server-for.html
).  While I'm sure your idea will work perfectly for your use case, it
seems to me that it would be more appropriate at the app level, rather
than core.

 -justin

* I actually didn't check to see if the name was taken or not.

On Thu, Mar 5, 2009 at 11:19 AM, Joshua K <jobe...@gmail.com> wrote:
>
> Hello Everyone,
>
> I have some ideas for some features I'd like to implement in Django,
> and wanted to bounce them off of everybody.
>
> I am building a site for which I'll eventually charge users for data
> and membership fees:
>
> http://www.bankhealthmonitor.com
>
> However... even though my site is bolted down like Fort Knox [1], I do
> not plan on storing any information on users, beyond phone number and
> data that the site requires to operate, on my webserver or its
> database.  Instead, I plan to store all of that information in my
> accounting server, where it's safer behind 10 levels of firewall and a
> big dog named Rocky.
>
> I am currently using the Apache Qpid project to pass messages.  [2]
> My site runs financial models, and the methods inside views.py pass
> requests off via QPid to the model servers, which run the models and
> pass a result back.  But I thought... hey, wouldn't that be a great
> way to allow me to manage customer data on a remote server?
>
> I am using Google Protocol Buffers [3] to serialize complex
> structures.  In my day I've used a number of Python XML libraries such
> as ElementTree and BeautifulSoup, and nothing comes close to the
> simplicity of using ProtocolBuffers  to serialize data.  (Yeah, I
> could just Pickle it, but Protocol Buffers also work with C++ and
> Java.)  The one drawback to Protocol Buffers is its lack of
> flexibility.  When using Protocol Buffers, you write a spec file
> describing your message, and then you run a compiler that generates
> Java, Python, or C++ helper classes.  If your message format changes,
> you need to re-compile... but your apps will still work with the old
> messages.
>
> My proposal is this.  I'd like to expand the code that handles
> models.py to include built-in support for serializing data and sending
> it over the wire via QPid.  This is the way it might work:
>
> 1. Create a standard models.py file.
> 2. Run an option on manage.py, that will generate the protobuf spec
> file and compile the spec file.  It would also take the resulting
> Python code and make it 'fit' with Django's ORM.
> 3. Create your views.py and templates.
> 4. Profit!
>
> If you were to include information in models.py about the transport,
> such as:
>
> send_with_exchange = "pubsub"
> send_with_topic = "finances"
>
> ...then you could send the data inside your model, to Qpid, with one
> method call... just like you might use a method call today to save the
> model to the database.  But what if you want your datum to go to
> multiple places?  No problem.  Using QPid's publish-subscribe model,
> any application subscribed to topic "finances" would get the datum you
> sent above.
>
> There is a philosophical problem, however.  Models.py ought to
> describe what a datum looks like, and that's it.  It should not
> describe how you send that datum down a wire.  Where else could we put
> Qpid information?  setup.py is a good place for "here's how to connect
> to the server" info, but not queue info.
>
> So you might wonder, why is a guy named Josh proposing that he include
> code, custom to his app, that drives two other somewhat obscure
> packages, in Django itself?  Django is already a pleasure to work
> with.  Think about what you could do if you could very, very easily
> include message passing between Django and backend systems?  This is
> what developers in corporate settings spend time doing every day.
> Django already has two advantages when it comes to productivity: a) it
> is Python, and b) it is Django.  Add message passing to the mix (and
> therefore the ability to construct highly secure systems - banking,
> etc) and it becomes a lot more compelling for more corporate types to
> use it.
>
> The only problem is I have 100 dozen other projects I'm working on -
> but this seems like a good way to go.
>
> Thoughts?
>
> Cheers,
> -Joshua Kramer
>
> [1] http://www.globalherald.net/jb01/weblog/21.html
> [2] http://qpid.apache

Re: Perl port of the django template system.

[Justin Lilly]

I find it interesting that no one has brought up jinja. They did  
something that follows django's template syntax, and have still built  
up a community. There is also the ruby version which is called liquid  
iirc that borrows heavily from django's syntax. Basically, it doesn't  
need django in it's proper name to become popular.

I'm personally against django being in the name for the same reasons I  
don't think people should put 3rd party modules under their django  
install because from django.template import perl_stuffjust makes  
things confusing, both for newbies looking for documentation as well  
as switchers.

+1 for reindhart though :)

-justin


On Dec 16, 2008, at 10:33 PM, Jeremy Sandell   
wrote:

>
> On Dec 16, 9:32 pm, Justin Bronn  wrote:
>>> I'm not sure if I work is derived from yours, since I only used the
>>> documentation (http://docs.djangoproject.com/en/dev/ref/templates/builtins/ 
>>> )
>>> for my work, but I thougt I would better just ask:
>>
>>> Would you please allow me to use the name Django for my project?
>>
>> I'm not the one with the final say here, but I highly suggest that  
>> you
>> come up with a new name for your module.  The jazz meme (e.g., [Duke]
>> 'Ellington', 'Ella' [Fitzgerald]) is what others have done if you're
>> looking for a suggestion.
>>
>> The BSD license is not the issue, it's that Django is a registered
>> trademark assigned to the Django Software Foundation (DSF).  Having a
>> Perl module of the same name may cause confusion of our customers
>> (users), a circumstance that trademark law gives the DSF the legal
>> right to prevent.  If we allow every language a 'Django' template
>> module, the DSF risks losing the trademark rights, and thus we won't
>> be able to wield the legal sword against the real bad actors out
>> there.
>>
>> Regards,
>> -Justin
>
> As a user of Django, I personally like the idea of the jazz meme;
> however, since he's porting it in a different language (and thus, for
> a different community) that might be confusing to those unfamiliar
> with Django. For example, say someone's fed up with Template::Toolkit
> and is looking for a different syntax that fits their wants and/or
> needs better.
>
> I'm *not* a legal beagle, but would something like
> "Djangoize::Template" or what-have-you work for this? I know I've seen
> plenty of derivatives out there thus far in the Django community
> itself, e.g., django-hotclub, but not for use outside of the
> framework.
>
> Just looking for some clarification. The idea of a similar syntax
> being available to other languages sounds nice, but I have a pretty
> strong bias. (:
>
> Thanks,
> - Jeremy
> >

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

Re: Dropping Python 2.3 compatibility for Django 1.1

[Justin Lilly]

On Nov 27, 2008, at 8:20 AM, Tim Chase wrote:
>
> However, I haven't seen any/much expression of *want* that 2.4 be
> dropped any time in the near future (and there are a much larger
> number of 2.4 deployments).  I wouldn't schedule that "2.4 will
> be dropped in Django 1.3" timetable, but rather a similar lead-up
> process as 2.3 has experienced -- a JKM post of "dropping 2.4
> support.  Discuss" when 2.4 starts causing enough problems to be
> more trouble than it's worth.


I think a big point to remember here is that, while there isn't a  
desire to drop 2.4 right now, it won't stay that way. With 3.0 coming,  
I'm sure we're going to want to make the switch before long (6 months?  
1 year?) During that time, you don't want to say  Python versions 2.4  
and 2.5 will no longer be supported by django.

With a goal of 3.0 compatibility like James mentioned, you'll want to  
provide a roadmap of upgrades. If I have to upgrade my RHEL 4 to RHEL  
5 b/c django drops 2.3 support, and I get 2.4, then in 6 months you  
want me to upgrade to get 2.5, then in another 6 months, upgrade to  
2.6 / 3.0... you're going to make some sysadmins very unhappy.  
Conversely, the ability to upgrade from 2.3 to 2.5 will make the  
transition much easier because you know you're set for at least 2  
releases (1+ year).

I'm +0 to dropping 2.3 support and +1 to having a deprecation roadmap  
that spells out which versions will lose support and when.

  -justin

--~--~-~--~~~---~--~~
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: installmedia command - A story for distributing media with apps

[Justin Lilly]

Not sure if you guys are aware, but this seems a very likely candidate
for django-exensions which extends manage.py like functionality.

http://code.google.com/p/django-command-extensions/

-justin

On Tue, Sep 16, 2008 at 7:22 PM, Julien Phalip <[EMAIL PROTECTED]> wrote:
>
> On Sep 17, 8:49 am, Brian Beck <[EMAIL PROTECTED]> wrote:
>> On Sep 16, 6:45 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
>>
>> > Serving is totally orthogonal -- everyone is already serving up
>> > MEDIA_ROOT in their projects somehow anyway, and this just copies
>> > files to MEDIA_ROOT.
>>
>> Sorry, I guess that's not totally true -- everyone who uses more than
>> just the admin app has set up static file serving for MEDIA_ROOT.
>
> I really like the idea. However, I think there should also be a way to
> configure it to not copy to MEDIA_ROOT but to somewhere else.
>
> It would also be good to get that deployment system play nicely with
> custom file storage (if you're hosting your media on S3 for example).
>
> Also, instead of just copying the media files, it should also do some
> cleanup. Say, if you're tracking trunk for a given app, when you SVN
> update that app you want stale media files to be removed.
>
> Just some thoughts.
> >
>



-- 
Justin Lilly
Web Developer/Designer
http://justinlilly.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-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: Flatpages with multiple blocks/sections

[Justin Lilly]

You may want to check out django-chunks. I'm pretty sure it does what  
you are looking for.

  -justin



On Aug 20, 2008, at 4:41 PM, lingrlongr <[EMAIL PROTECTED]> wrote:

>
> I have found that the Flatpages application is very useful, especially
> in projects where you create a site for someone else and you allow
> them to change the content as they need.  The only drawback with the
> application, however, is that there's only one block/section of
> modifiable content.
>
> My solution was to pretty much copy the django.contrib.flatpages
> application into my project and adjust it to conform to my
> specifications.  As one would guess, that's not very clean, as I'd
> want my copy to change as Django's changed, but I saw no other way as
> I could not easily extend what was already there.
>
> For my use, I'll just touch on the basic changes I made.  I left out
> any "logical" imports below.  Also note that changed
> "django.contrib.flatpages" to "flatpages" where necessary so my
> changes did not refer to the original.
>
> # myproject.flatpages.models.py
> class Section(models.Model):
>slug = models.SlugField(_('slug'), max_length=50)
>content = models.TextField(_('content'), blank=True)
>flatpage = models.ForeignKey(FlatPage)
>
>
> # myproject.flatpages.admin.py
>
> class SectionInline(admin.StackedInline):
>model = Section
>
> class SectionAdmin(admin.ModelAdmin):
>fieldsets = (
>(None, {'fields': ('slug', 'content', 'flatpage')}),
>)
>list_display = ('slug', 'flatpage',)
>list_filter = ('flatpage',)
>search_fields = ('slug', 'content')
>
> admin.site.register(Section, SectionAdmin)
>
> (also add inlines = [SectionInline,] to FlatPageAdmin class)
>
>
> # views.py - before creating Request Context
>
># Create a dictionary, indexed by section slug, of section content
>d = {}
>for s in f.section_set.all():
>d[s.slug] = mark_safe(s.content)
>
>...etc...
>
>c = RequestContext(request, {
>'flatpage': f,
>'section': d,
>})
>
> So of course, in my templates I could just render a block/section of
> content as {{ section.section_1 }}.
>
>
> Do we think something like this could be useful for the general
> population, either as part of flatpages or as a separate app?
>
> Keith
>
> >

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

[Justin Lilly]

The longer you leave it, more incompatible changes are going to be
introduced between 0.96 and 1.0.  If a release is made between then it
gives people a chance to update their sites to fix any problems with
compatability, as well as a chance to play with some of the new
features.


I think this is the part people want to avoid. What the devs keep echoing is
that it's uncool to have people take their.96 code and go through all of
their backwards incompatible changes to get it up to a .97 release only to
have to do the same thing when NFA lands. I think if you're itching for a
release, dive into the nfa code and get to work. That's going to be the
quickest path to a release, not belly-aching over it on this list.

 -justin

On Sun, Jun 8, 2008 at 11:11 AM, Phil M <[EMAIL PROTECTED]> wrote:

>
> On Jun 8, 9:27 am, Wim Feijen <[EMAIL PROTECTED]> wrote:
> > My vote is +1, because I think Django needs another stable release
> > right now. Fortunately, the trunk is stable (thank you!). Rob says
> > that it is good for a software project to have regular releases on a
> > half-year basis and I totally agree. This gives everyone the
> > opportunity to use a recent version of Django. Right now,
> > unfortunately, people with strong demands on stability, have to revert
> > to an outdated Django 0.96 or take a risk using Django trunk, which
> > feels like a choice between two wrongs.
> >
> > Personally, I would be very happy to use a Django 1.0, with or without
> > newforms, just as it happens. And considering the posts, just having
> > this discussion already seems to motivate people into action! :)
>
> Quite a few Django projects are using the trunk version instead of the
> stable version for their addons, which is annoying for me running the
> stable version.  The problem is that Django has been so long without a
> release that the stable version is now a stale version - it reminds me
> of Debian taking so long with their releases.
>
> Every once in a while a release is needed for all the developers to
> group together on a common target, instead of being forced to pick
> between 0.96 and trunk.  I'm not looking for a 1.0 release, just
> something to keep developers going with a release until 1.0 is ready.
> At the moment people are forced to pick between stale and trunk, which
> ends up with more people picking trunk.
>
> The longer you leave it, more incompatible changes are going to be
> introduced between 0.96 and 1.0.  If a release is made between then it
> gives people a chance to update their sites to fix any problems with
> compatability, as well as a chance to play with some of the new
> features.
>
>
>
>
>
>
>
>
>
>
>
> >
>


-- 
Justin Lilly
Web Developer/Designer
http://justinlilly.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-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

[Justin Lilly]

I'm pretty sure its been stated several times on the board but there will be
no versions released between .96 and 1.0.

On Sat, Jun 7, 2008 at 12:48 PM, Rob Hudson <[EMAIL PROTECTED]> wrote:

>
> Regarding this blog post:
> http://www.technobabble.dk/2008/jun/07/django-importance-releases/
>
> I think the most often reason why I've heard is that it takes time to
> create a release, post it, push security patches to it, etc.  Which
> makes sense, but at the same time there are a lot of valid points in
> the blog post.
>
> I'm curious if it would help to have a release team, or just certain
> people to "own" a release.
>
> For example, I for one could help (given the right privileges) package
> up a 0.97 release, tag it, update the various bits on the website, and
> sit by ready to make a patch release for any security updates.
> Someone else could "own" the 0.98 release.  Once 0.97 is no longer
> supported, that frees me up to "own" another release.
>
> Just a thought.
>
> -Rob
> >
>


-- 
Justin Lilly
Web Developer/Designer
http://justinlilly.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-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: Databrowse - text overlapping

[Justin Lilly]

As its a visual issue, I'd also probably include a screenshot.

On Fri, Jun 6, 2008 at 8:48 AM, Russell Keith-Magee <[EMAIL PROTECTED]>
wrote:

>
> On Fri, Jun 6, 2008 at 7:55 PM, Kless <[EMAIL PROTECTED]> wrote:
> >
> > There is a little issue. The name of the tables -on the left- is
> > overlapping to the name of the objects -on the right-, when there are
> > large names.
>
> Please log suspected errors and bugs in the ticket tracker. Bug
> reports in the mailing list tend to get lost over time.
>
> Yours,
> Russ Magee %-)
>
> >
>


-- 
Justin Lilly
Web Developer/Designer
http://justinlilly.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-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: Which editor for Django code ??

[Justin Lilly]

Seems you've done a bit of duplicate work. If you're in Textmate, try going
to Text>Convert>Spaces to Tabs (or) Tabs to Spaces
Should do what your script does, I think.

 -justin

On Wed, May 28, 2008 at 12:46 PM, Daniel Bushman <[EMAIL PROTECTED]>
wrote:

>
> I use Textmate (with the Django bundle) and soft-tabs.  Sometimes If I
> paste code from the web there are indentation problems.   Here's what
> I use for quick clean-up:
>
> * search for [tab] and replace with [4 spaces] (using soft-tabs)
>
> I recorded a macro which does "select all" and then performs this
> search and replace.  Then I tied it to a hot-key.  So if pasted code
> has a problem, I just hit cmd-f3 and the problem is solved.
>
> Or In some cases I use:
>
> * "Cleanup whitespace" from the Python bundle
> or
> * "Show Invisibles" from the "View" menu to help spot the
> inconsistency visually.
>
> Hope this helps,
> Daniel
>
> On May 14, 9:31 am, "narendra.tumkur" <[EMAIL PROTECTED]>
> wrote:
> > Hi guys,
> > Trying to edit django code and keep running into indentation problems.
> > Have tried XCode, Textmate and JEdit on Mac OS X.
> >
> > What do you guys use?
> >
> > Cheers
> > Narendra
> >
>


-- 
Justin Lilly
Web Developer/Designer
http://justinlilly.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-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: SVN Milestones

[Justin Lilly]

We have one. Its called 1.0 and the more you contribute, the closer you get
;)
 -justin

On Wed, Apr 16, 2008 at 7:47 PM, David Cramer <[EMAIL PROTECTED]> wrote:

>
> Can we start setting some milestones so SVN stops being SVN :)
>
> E.g. a .97 release, or .96.2 or something. It would make things a lot
> more sane to know where you're at, as everyones using SVN now, but SVN
> changes so much from X revision to Y revision that there really needs
> to be tagged releases.
> >
>


-- 
Justin Lilly
Web Developer/Designer
http://justinlilly.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-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 Software Foundation

[Justin Lilly]

Awesome. Thanks!

On Tue, Apr 1, 2008 at 10:27 PM, Jacob Kaplan-Moss <
[EMAIL PROTECTED]> wrote:

>
> Hi Justin --
>
> Yes, there is a Django Software Foundation. We're still working on
> getting everything set up and all the paperwork filed, but it does
> exist :)
>
> Jacob
>
> >
>


-- 
Justin Lilly
Web Developer/Designer
http://justinlilly.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-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 Software Foundation

[Justin Lilly]

Hey guys,  I remember hearing about the DSF at PyCon. Is it a reality yet?
Is the official name the DSF? I could use a bit of guidance for an article
I'm writing up.

 -justin

-- 
Justin Lilly
Web Developer/Designer
http://justinlilly.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-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: Unfair ticket management

[Justin Lilly]

Ivan,

I'm sure the developers do check for duplicate tickets, but they're busy
people. Not to mention with nearly a thousand tickets open, it can be
difficult to remember all of them and easy to miss one. I might suggest
coming here with an air of curiosity instead of an accusatory tone for best
results.
Good luck,
   -justin

On Mon, Mar 31, 2008 at 7:52 AM, Ivan Illarionov <[EMAIL PROTECTED]>
wrote:

>
> Hey, I've just found that ticket #6789 was merged into trunk while my
> ticket #6654 that was filed a month earlier and does the same thing
> was ignored.
>
> My patch is still better because it removes INVALID_PROJECT_NAMES that
> became unnecessary -- all those names will be detected by __import__.
>
> Why the developers don't check for duplicate tickets?
>
> --
> Ivan
> >
>


-- 
Justin Lilly
Web Developer/Designer
http://justinlilly.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-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 a relative option to FilePathField

[Justin Lilly]

Fair enough. Forget I mentioned it :-/

On Fri, Feb 22, 2008 at 1:20 PM, [EMAIL PROTECTED] <
[EMAIL PROTECTED]> wrote:

>
> I agree with Graham because you don't know where python will be
> executed from what would the path be relative to?
>
> On Feb 22, 9:33 am, "Justin Lilly" <[EMAIL PROTECTED]> wrote:
> > I would personally vote on making it an optional parameter if
> RELATIVE_FIELD
> > (or something like that) is present. If it isn't present, require it
> just
> > like always.
> > -justin
> >
> > On Fri, Feb 22, 2008 at 9:46 AM, Graham Carlyle <
> >
> >
> >
> > [EMAIL PROTECTED]> wrote:
> >
> > > In your example I think RELATIVE_FIELD would be relative to the django
> > > python process's current working directory which seems a bit
> arbitrary.
> > > Having an absolute path parameter seems a good thing, but storing this
> > > prefix for each record seems redundant and inflexible.
> >
> > > Graham
> >
> > > On Fri, 2008-02-22 at 09:05 -0500, Justin Lilly wrote:
> > > > What would stop you from doing something akin to:
> >
> > > > upload = model.FilePathField(path=RELATIVE_FIELD, match="foo.*",
> > > > recursive=True)
> >
> > > > where RELATIVE_FIELD is defined in your settings.py file? Perhaps
> I've
> > > > missed the mark on this.. I'm relatively new to django-dev
> > > > discussions.
> >
> > > > -justin
> >
> > > > On Fri, Feb 22, 2008 at 6:16 AM, Graham Carlyle
> > > > <[EMAIL PROTECTED]> wrote:
> >
> > > > I'd like to request that FilePathField should have an extra
> > > > option that
> > > > causes it to only save a relative path (to the path
> > > > parameter), say
> > > > called "relative".
> >
> > > > Having an absolute path stored makes it harder to move data
> > > > between
> > > > machines that are set up differently (say development and
> > > > production).
> > > > In this circumstance I would typically set the path
> parameter
> > > > from the
> > > > settings file.
> >
> > > > The "relative" argument could default to False to keep the
> > > > current
> > > > behaviour by default. Actually i can't think when you would
> > > > want
> > > > absolute paths but maybe someone does.
> >
> > > > Shall I create a ticket (and possibly a patch) for this? or
> am
> > > > I missing
> > > > something?
> >
> > > > cheers,
> > > > Graham
> >
> > > > --
> > > > Justin Lilly
> > > > Web Developer
> >
> > --
> > Justin Lilly
> > Web Developer
> >
>


-- 
Justin Lilly
Web Developer

--~--~-~--~~~---~--~~
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 a relative option to FilePathField

[Justin Lilly]

I would personally vote on making it an optional parameter if RELATIVE_FIELD
(or something like that) is present. If it isn't present, require it just
like always.
-justin

On Fri, Feb 22, 2008 at 9:46 AM, Graham Carlyle <
[EMAIL PROTECTED]> wrote:

>
> In your example I think RELATIVE_FIELD would be relative to the django
> python process's current working directory which seems a bit arbitrary.
> Having an absolute path parameter seems a good thing, but storing this
> prefix for each record seems redundant and inflexible.
>
> Graham
>
> On Fri, 2008-02-22 at 09:05 -0500, Justin Lilly wrote:
> > What would stop you from doing something akin to:
> >
> >
> > upload = model.FilePathField(path=RELATIVE_FIELD, match="foo.*",
> > recursive=True)
> >
> >
> > where RELATIVE_FIELD is defined in your settings.py file? Perhaps I've
> > missed the mark on this.. I'm relatively new to django-dev
> > discussions.
> >
> >
> > -justin
> >
> >
> >
> >
> > On Fri, Feb 22, 2008 at 6:16 AM, Graham Carlyle
> > <[EMAIL PROTECTED]> wrote:
> >
> > I'd like to request that FilePathField should have an extra
> > option that
> > causes it to only save a relative path (to the path
> > parameter), say
> > called "relative".
> >
> > Having an absolute path stored makes it harder to move data
> > between
> > machines that are set up differently (say development and
> > production).
> > In this circumstance I would typically set the path parameter
> > from the
> > settings file.
> >
> > The "relative" argument could default to False to keep the
> > current
> > behaviour by default. Actually i can't think when you would
> > want
> > absolute paths but maybe someone does.
> >
> > Shall I create a ticket (and possibly a patch) for this? or am
> > I missing
> > something?
> >
> > cheers,
> > Graham
> >
> >
> >
> >
> >
> >
> > --
> > Justin Lilly
> > Web Developer
> >
> > >
>
>
> >
>


-- 
Justin Lilly
Web Developer

--~--~-~--~~~---~--~~
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 a relative option to FilePathField

[Justin Lilly]

What would stop you from doing something akin to:
upload = model.FilePathField(path=RELATIVE_FIELD, match="foo.*",
recursive=True)

where RELATIVE_FIELD is defined in your settings.py file? Perhaps I've
missed the mark on this.. I'm relatively new to django-dev discussions.

-justin



On Fri, Feb 22, 2008 at 6:16 AM, Graham Carlyle <
[EMAIL PROTECTED]> wrote:

>
> I'd like to request that FilePathField should have an extra option that
> causes it to only save a relative path (to the path parameter), say
> called "relative".
>
> Having an absolute path stored makes it harder to move data between
> machines that are set up differently (say development and production).
> In this circumstance I would typically set the path parameter from the
> settings file.
>
> The "relative" argument could default to False to keep the current
> behaviour by default. Actually i can't think when you would want
> absolute paths but maybe someone does.
>
> Shall I create a ticket (and possibly a patch) for this? or am I missing
> something?
>
> cheers,
> Graham
>
>
> >
>


-- 
Justin Lilly
Web Developer

--~--~-~--~~~---~--~~
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: Visual recognition of Django website

[Justin Lilly]

I personally would also like a favicon for the django sites. I took the
liberty of creating one using django's colors and fonts (stole the d from
the logo).

 http://www.flickr.com/photos/[EMAIL PROTECTED]/1397125183/

Hope that is useful,
  -justin

On 9/17/07, Mikkel Høgh <[EMAIL PROTECTED]> wrote:
>
>
> On Sep 17, 3:33 pm, Dave <[EMAIL PROTECTED]> wrote:
> > On Sep 15, 10:22 pm, Mikkel Høgh <[EMAIL PROTECTED]> wrote:
> >
> > > To illustrate my point, take a look at this image, a screenshot of a
> > > very normal Firefox tab bar of mine:
> http://mikkel.hoegh.org/galleries/odd_stuff/i_3_favicons?size=_original
> > > It's much easier for me to find what I need by help of favicons - and
> > > yes, most of the time, I have so many tabs open that I cannot see the
> > > title of the web pages.
> >
> > Easy, Django is the one without a favicon... oh wait, there's lots of
> > them in there.. I presume you're complaining to all of the other sites
> > that don't have them too?
>
> Ideally, I should be, shouldn't I? Regardless, I don't see how helping
> all kinds of strangers get better branding on their websites. I do see
> the benefit strengthening the Django brand, however, since in open
> source, more interest equals more momentum.
>
> I'm not denying that my motivation here is somewhat selfish, but this
> would be a small and quick thing to do. Granted, my Firefox habits are
> perhaps not quite normal, but favicons remain a useful visual reminder.
>
>
> >
>


-- 
Justin Lilly
University of South Carolina

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