Plug-ins for Django
Hi, for our Django project, we developed an application which enables the usage of plug-ins for enhancement of the application. I know plug-ins for years using them a lot in "classical" application development, so when starting deveolping with Django, I really missed them and put a big effort into getting this feature. The plug-in app is small, consisting of about 4 or 5 classes and some functions for different template tags. We use it for about half a year now. It helps a lot to use sub projects and develop them seperately, especially, when there are different developers for different parts but no fixed dates for every project to finish together. It allows to define different types of plug-in interface, and provides a template tag for enabling plug-ins inside Templates or use them for enhancement of other functions like search. Now I would like to ask, if their is any interest in this app to make it available for other developers. I would like to make it an easy to use package, so that everyone, who could need this functions, can install it. But I could not find any informations, how to do this the best way, only the reference to this mailing list. So I hope to get some advices, what will be the next steps. Maria -- 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.db.models.Options contribute_to_class uses default connection instead of using DATABASE_ROUTERS
On Wed, May 12, 2010 at 1:14 AM, Peter Long wrote: >> Sounds like a bug in the patch to me. As I said earlier, the options >> class doesn't have any knowledge about the database that is being used >> for a specific operation, so it can't enforce per-database >> restrictions. In the case of db_table truncation, I suspect the right >> approach here is to store db_table as an untruncated string, and then >> truncate it at time of use inside specific backends or in queries. I >> suspect analogous changes will be required for #6148. >> >> This should also be logged as a bug; the truncation behavior that is >> currently implemented is definitely wrong. > > Thanks for the information. I will log a bug regarding the db_table > truncation and reference this thread in it. Hopefully I will be able > to describe the problem adequately. FYI - I got itchy fingers, so I opened a bug report: http://code.djangoproject.com/ticket/13528 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.
Re: Plug-ins for Django
On Wed, May 12, 2010 at 2:01 PM, Siebert, Maria wrote: > Hi, > > for our Django project, we developed an application which enables the usage > of plug-ins for enhancement of the application. I know plug-ins for years > using them a lot in "classical" application development, so when starting > deveolping with Django, I really missed them and put a big effort into > getting this feature. > > The plug-in app is small, consisting of about 4 or 5 classes and some > functions for different template tags. We use it for about half a year now. > It helps a lot to use sub projects and develop them seperately, especially, > when there are different developers for different parts but no fixed dates > for every project to finish together. > > It allows to define different types of plug-in interface, and provides a > template tag for enabling plug-ins inside Templates or use them for > enhancement of other functions like search. > > Now I would like to ask, if their is any interest in this app to make it > available for other developers. I would like to make it an easy to use > package, so that everyone, who could need this functions, can install it. But > I could not find any informations, how to do this the best way, only the > reference to this mailing list. So I hope to get some advices, what will be > the next steps. The next step depends on exactly what you're proposing. The fact that you're posting to django-developers (which is the mailing list for discussing the development of Django itself) suggests that you might be proposing this as something that should be added to Django itself. If this is indeed the case, then you need to open a ticket, describe your proposal in detail, and prepare a patch that can be applied to trunk. Then, when the v1.3 feature discussion period starts (which should be in a bit over a week), you can advocate for your proposal. However, if what you're proposing is a standalone project, then get an account on sourceforge/Google Code/github/bitbucket, upload your code, make sure you package it with a setup.py, submit it to PyPI, and announce it to the world on django-users (the mailing list for general users of Django). Even if you're ultimately aiming at the first option, the second option may be a better approach - proposals for trunk get a lot more traction if they've proven themselves as standalone projects. 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.
Re: Template Tag Not Reinitialized in Loop
I recently ran into this problem too for the first time. Essentially
this boils down to my not being able to use a templatetag in a loop in
some cases. What is the simple workaround that I'm missing?
-Steve
On May 5, 2:12 pm, Apreche wrote:
> I had a really strange bug in one of my custom template tags today. It
> took me the entire morning to figure it out, but I finally did. I'm
> not sure if it's a bug or a feature, but I wanted to make a post to
> help the next person who has this same problem.
>
> Let's pretend you make a custom template tag foo. The render method
> for foo is in a class FooNode, and you pass it a person from the
> context.
>
> {% foo persona %}
> {% foo personb %}
>
> Then, as is common, you have a list of people that you render with a
> loop in the template.
>
> {% for person in people %}
> {% foo person %}
> {% endfor %}
>
> It turns out that when a template tag stands alone, the __init__ of
> FooNode will be called each time the template tag appears. However,
> when the template tag is inside of a loop, the __init__ of the FooNode
> is only called once. That single instance of FooNode sticks around,
> and it's render method is called over and over as the loop goes
> around.
>
> This doesn't seem like that big of a deal. However, my template tag
> was written in such a way that data members of FooNode were being set
> in the __init__ and reused in the render(). Because the initialization
> only happened the first time through the loop, the template tag always
> rendered as if it was for the first person in the list. Those data
> members carried over to subsequent renders because the Node was not
> reinitialized. I managed to fix it, but be aware. If your template
> tags are behaving strangely when they are in loops, this is probably
> the issue.
>
> --
> 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
> athttp://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.db.models.Options contribute_to_class uses default connection instead of using DATABASE_ROUTERS
On May 12, 8:54 am, Russell Keith-Magee wrote: > > FYI - I got itchy fingers, so I opened a bug report: > > http://code.djangoproject.com/ticket/13528 > > Yours > Russ Magee %-) No problem. Thanks Peter Long -- 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.db.models.Options contribute_to_class uses default connection instead of using DATABASE_ROUTERS
As a related problem the manage.py validate seems to do the same thing -- that is import the default connection and do any validation using it. -- 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: Template Tag Not Reinitialized in Loop
Hi, On Wed, May 12, 2010 at 5:28 PM, subs...@gmail.com wrote: > What is the simple workaround that I'm missing? > > -Steve > in a nutshell, you save the name of the variable on initialization of the node and resolve it while rendering. See all the examples in django/template/defaulttags.py, e.h. [1] Kind Regards, Benjamin [1] http://code.djangoproject.com/browser/django/trunk/django/template/defaulttags.py#L55 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Class based generic views in 1.3?
On 11 May 2010, at 01:37, Russell Keith-Magee wrote: > > > Are class-based views planned for 1.3? Well, we haven't done any > formal planning for 1.3 yet, but I'm going to guess that the 1.3 high > priority feature list will essentially be "the features that got > dropped from 1.2", so in all likelihood, yes. However, that doesn't > mean that they will definitely be in 1.3 - someone still needs to do > the implementation. If you really want class based generic views, be > like Ben and make it happen -- show us the code!. Oooh, class-based views. This is something I've been thinking about a lot, and I'll probably dive into it at the Djangocon.eu sprints. Feel free to make a start Jari. ;) Ben -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Class based generic views in 1.3?
I have been using class views at work that are based off of Jacob's
base GenericView class since last summer.
http://github.com/fitzgen/class_views/blob/master/views.py
Things that people haven't really mentioned, but need addressing, that
we had to find solutions for:
* How to do redirects in class based views? See lines 71-86 and 166.
* How to decorate the __call__ method without doing a pointless
override of __call__ that just calls super so that you have something
to @decorate on top of. Check out the meta class on line 175. This
allows you to specify 'decorators = [login_required,
permission_required("polls.can_vote")]' on your subclass. I showed
this to Jacob at DjangoSki, and he seemed positive.
* How to decorate methods, when the decorator expects the first
argument to be request, and not self. See line 8. Ideally though,
Django's decorators would handle this, rather than forcing the use of
decorate_method_with on to the end users.
* How to deal with state and self. I have written an instantiator that
wraps the view class and instantiates a new instance of the class for
every request so that everything is thread safe. This works, but
agian, it would be nice if Django checked to see if the callable being
linked to a url route is a class, in which case it would handle the
instantiation of a new instance for every request. See line 188.
Excited to get this stuff in to 1.3!
_Nick_
On May 12, 1:16 pm, Ben Firshman wrote:
> On 11 May 2010, at 01:37, Russell Keith-Magee wrote:
>
>
>
> > Are class-based views planned for 1.3? Well, we haven't done any
> > formal planning for 1.3 yet, but I'm going to guess that the 1.3 high
> > priority feature list will essentially be "the features that got
> > dropped from 1.2", so in all likelihood, yes. However, that doesn't
> > mean that they will definitely be in 1.3 - someone still needs to do
> > the implementation. If you really want class based generic views, be
> > like Ben and make it happen -- show us the code!.
>
> Oooh, class-based views.
>
> This is something I've been thinking about a lot, and I'll probably dive into
> it at the Djangocon.eu sprints. Feel free to make a start Jari. ;)
>
> Ben
>
> --
> 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
> athttp://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.
