Re: Django Design Patterns

[Antje Kazimiers]

Hi Fatjon,

I wonder how much you can try finding that out on your own by just
grepping for the names of the common Gang of Four [1] - design patterns
in the django source code. I just tried Observer, Factory and find
examples in the code, which sound like the developer really followed the
intention of that pattern, when they named the function / class, which
is good. Another example is Decorator:

> git grep decorator

gives many results, among those the file

django/utils/functional.py

There are the lines of code

def keep_lazy(*resultclasses):
    """
    A decorator that allows a function to be called with one or more lazy
    arguments. If none of the args are lazy, the function is evaluated
    immediately, otherwise a __proxy__ is returned that will evaluate the
    function when needed.
    """
    if not resultclasses:
    raise TypeError("You must pass at least one argument to
keep_lazy().")

    def decorator(func):
    ..
    return decorator

and that to me really looks exactly what the purpose of a decorator is.

Antje

[1] https://en.wikipedia.org/wiki/Gang_of_Four


On 11/17/19 3:40 AM, Fatjon Gërra wrote:
> Hi guys, can anyone suggest me some resources book/video/article where
> I can learn more about Design Patterns that the Django Team used in
> writing Django as a framework? For example, here
> <https://docs.djangoproject.com/en/2.2/misc/design-philosophies/> the
> Active Record pattern is mentioned. I am looking for the other ones. I
> want to dive into Django's source code and learn about Design Patterns
> at the same time. Thanks for the help!
> -- 
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-users+unsubscr...@googlegroups.com
> <mailto:django-users+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/039a922c-a882-4e82-be0b-0ea568850074%40googlegroups.com
> <https://groups.google.com/d/msgid/django-users/039a922c-a882-4e82-be0b-0ea568850074%40googlegroups.com?utm_medium=email_source=footer>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/91000c02-9596-0a9d-985d-f1a2c2df5562%40gmail.com.

Django Design Patterns

[Fatjon Gërra]

Hi guys, can anyone suggest me some resources book/video/article where I 
can learn more about Design Patterns that the Django Team used in writing 
Django as a framework? For example, here 
<https://docs.djangoproject.com/en/2.2/misc/design-philosophies/> the 
Active Record pattern is mentioned. I am looking for the other ones. I want 
to dive into Django's source code and learn about Design Patterns at the 
same time. Thanks for the help!

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/039a922c-a882-4e82-be0b-0ea568850074%40googlegroups.com.

Design patterns with users / groups

[Guy Bowden]

Bit of a design question:

I have a site where there are a few different views depending on each 
user's status - i will explain:

   1. A user can create an object, so should be able to view it and update 
   it.
   2. A user can 'follow' another users object, so should be able to view 
   it and it's children
   3. A user could be granted permission to administer another users 
   object, so should have the same permissions as the original owner.
   
So, the question is...

When an object is created, should I also create two additional user groups 
and assign the permissions to those groups? Then all I'd have to do is add 
a follower to the followers group.

"followers_[modelname]_[pk]", "administrators_[modelname]_[pk]"

Or, do I assign administer / follow / view / update permissions per user?

This has just really occurred to me as an option because I've only really 
seen Groups as a much larger way to organise users - i.e. "members", 
"administrators" etc. But this seems like a good way to go in this instance 
rather than assigning permissions to individual users.

Pros / Cons? Is this a normal way to handle permissions?

I can see that there would obviously be a lot more groups created, but 
permissions would only be assigned to groups, not users, so easier to 
manage..?

Cheers
Guy

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

Re: Django Design Patterns and Djen of Django books on Kindle Store

[Gethin Llyn ab Alwyn]

Are your Books complete?


On 17 February 2012 09:31, Shabda Raaj <sha...@agiliq.com> wrote:

> We have published our Ebooks on Kindle Store and would love to get
> some reviews. (Just $1 each)
>
>
> http://www.amazon.com/The-Djen-of-Django-ebook/dp/B006P1K0YY/ref=ntt_at_ep_dpt_2
>
> http://www.amazon.com/Django-Design-Patterns-ebook/dp/B006OYO9SK/ref=ntt_at_ep_dpt_1
>
> (They are also available for free should you prefer that.)
>
> http://agiliq.com/books/djenofdjango/
> http://agiliq.com/books/djangodesignpatterns/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>

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

Django Design Patterns and Djen of Django books on Kindle Store

[Shabda Raaj]

We have published our Ebooks on Kindle Store and would love to get
some reviews. (Just $1 each)

http://www.amazon.com/The-Djen-of-Django-ebook/dp/B006P1K0YY/ref=ntt_at_ep_dpt_2
http://www.amazon.com/Django-Design-Patterns-ebook/dp/B006OYO9SK/ref=ntt_at_ep_dpt_1

(They are also available for free should you prefer that.)

http://agiliq.com/books/djenofdjango/
http://agiliq.com/books/djangodesignpatterns/

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

Re: Design patterns for create/update view

[Eric Abrahamsen]

On Mar 23, 2009, at 6:48 PM, Liubomir.Petrov wrote:

>
> Yep, i'm already using generic views, but its a big pain (a lot of
> code) for a single view that embeds create & update in one place.
> I wanned to ask here, because maybe my approach (the single create/
> update view) is not right ?

I'm not quite sure what you mean here, are you saying it's a lot of  
code in your url config to have CRUD lines for each model in each app?  
You could take a look at the admin app to see how it does model  
autodiscovery, and get some ideas about how you might automatically  
create url config lines for each model. The code lives in contrib/ 
admin/sites.py

Is that what you meant?


>
> On Mar 23, 12:13 pm, Eric Abrahamsen  wrote:
>> On Mar 23, 2009, at 6:06 PM, Lyubomir Petrov wrote:
>>
>>
>>
>>> Just wondering are there any docs/examples of design pattern with
>>> django for creating a "create/update" view.
>>
>> These views are written for you! See the CRUD section of the Generic
>> Views page:
>>
>> http://docs.djangoproject.com/en/dev/ref/generic-views/#create- 
>> update...
>>
>> All you have to do is design the URLs, and you can take hints from  
>> the
>> admin contrib app for that.
>>
>> Yours,
>> Eric
>>
>>
> >


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

Re: Design patterns for create/update view

[Liubomir.Petrov]

Yep, i'm already using generic views, but its a big pain (a lot of
code) for a single view that embeds create & update in one place.
I wanned to ask here, because maybe my approach (the single create/
update view) is not right ?

On Mar 23, 12:13 pm, Eric Abrahamsen  wrote:
> On Mar 23, 2009, at 6:06 PM, Lyubomir Petrov wrote:
>
>
>
> > Just wondering are there any docs/examples of design pattern with
> > django for creating a "create/update" view.
>
> These views are written for you! See the CRUD section of the Generic  
> Views page:
>
> http://docs.djangoproject.com/en/dev/ref/generic-views/#create-update...
>
> All you have to do is design the URLs, and you can take hints from the  
> admin contrib app for that.
>
> Yours,
> Eric
>
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Design patterns for create/update view

[Eric Abrahamsen]

On Mar 23, 2009, at 6:06 PM, Lyubomir Petrov wrote:

>
> Just wondering are there any docs/examples of design pattern with
> django for creating a "create/update" view.

These views are written for you! See the CRUD section of the Generic  
Views page:

http://docs.djangoproject.com/en/dev/ref/generic-views/#create-update-delete-generic-views

All you have to do is design the URLs, and you can take hints from the  
admin contrib app for that.

Yours,
Eric


> >


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

Design patterns for create/update view

[Lyubomir Petrov]

Just wondering are there any docs/examples of design pattern with
django for creating a "create/update" view.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: View design patterns for inherited templates

[Malcolm Tredinnick]

On Mon, 2009-03-02 at 05:00 -0800, Daniel Roseman wrote:
> On Mar 2, 10:41 am, Mattias  wrote:
> > Hi,
> >
> > I'm just learning Django, and had a question with my first site.
> >
> > To have a common layout for multiple pages (even those in different
> > applications / python code folders) on the site, I'm using template
> > inheritance.
> > But the base template uses a few variables, for example the name of
> > the logged in user and some of his settings. These need to be provided
> > as parameters from *every* view's render_to_response call that uses a
> > template inheriting from base.
> >
> > How should I structure my code to access these in every view?
> > An idea I had was to:
> > * make a basehelper.py to go with the base.html template
> > * have a get_params(request) function there that returns a dict with
> > the base template parameters
> > * every view would use this and add its own values before passing it
> > to render_to_response.
> >
> > But is there something more generic for this problem in Django?
> >
> > Mattias
> 
> This is what context processors are for - they insert variables into
> the template context. See
> http://docs.djangoproject.com/en/dev/ref/templates/api/#id1

Well, context processors are sometimes useful here. One restriction,
though, is that context processors are only given the "request" as a
parameter, not everything else that is passed to the view function.

Sometimes, if extra information is needed, it's more useful to go with a
common "finishing up" function that you call. Since a view typically
ends with a call to render_to_response(), you aren't adding any extra
complexity if you replace that with a call to
finish_up_view(request, ...), passing in a whole bunch of information.

The finish_up_view() function, which you write, can then add in whatever
extra information you like to the context -- which can now depend on
more than just the "request" variable -- and finally return the result
of render_to_response().

I find myself using that pattern almost routinely nowadays. Even if
finish_up_view() is initially only just a proxy for
render_to_response(), over time, more things tend to be added as a
common "do common extra stuff" holder.

Again, context processors might well do the necessary stuff, but they
aren't always powerful enough or at the right place in the code path. So
this is another idea to keep in mind.

Regards,
Malcolm



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

Re: View design patterns for inherited templates

[Daniel Roseman]

On Mar 2, 10:41 am, Mattias  wrote:
> Hi,
>
> I'm just learning Django, and had a question with my first site.
>
> To have a common layout for multiple pages (even those in different
> applications / python code folders) on the site, I'm using template
> inheritance.
> But the base template uses a few variables, for example the name of
> the logged in user and some of his settings. These need to be provided
> as parameters from *every* view's render_to_response call that uses a
> template inheriting from base.
>
> How should I structure my code to access these in every view?
> An idea I had was to:
> * make a basehelper.py to go with the base.html template
> * have a get_params(request) function there that returns a dict with
> the base template parameters
> * every view would use this and add its own values before passing it
> to render_to_response.
>
> But is there something more generic for this problem in Django?
>
> Mattias

This is what context processors are for - they insert variables into
the template context. See
http://docs.djangoproject.com/en/dev/ref/templates/api/#id1

As well as enabling them as described above, if you're using
render_to_response you need to be sure to add the
context_instance=RequestContext(request) parameter to the call.
--
DR.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

View design patterns for inherited templates

[Mattias]

Hi,

I'm just learning Django, and had a question with my first site.

To have a common layout for multiple pages (even those in different
applications / python code folders) on the site, I'm using template
inheritance.
But the base template uses a few variables, for example the name of
the logged in user and some of his settings. These need to be provided
as parameters from *every* view's render_to_response call that uses a
template inheriting from base.

How should I structure my code to access these in every view?
An idea I had was to:
* make a basehelper.py to go with the base.html template
* have a get_params(request) function there that returns a dict with
the base template parameters
* every view would use this and add its own values before passing it
to render_to_response.

But is there something more generic for this problem in Django?

Mattias

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

Re: design patterns

[Diego Ucha]

There is also this thread:
http://groups.google.com/group/django-users/browse_thread/thread/a26d805427aa643f/249463a6f63958f7

[]s
Diego Ucha

On 23 maio, 21:56, "Juanjo Conti" <[EMAIL PROTECTED]> wrote:
> I do it with jquery (client side) getJSON funcion (tamplate exmaple):
>
> 
> 
> jQuery(document).ready(function($){
>
> var prefix = "{{ prefix }}"
> var opcionnula = {{ opcionnula }}   //incluir la opción
> nula en la lista de localidades y provincias
> var provincia = "#id_" + prefix + "provincia"
> var localidad = "#id_" + prefix + "localidad"
>
> $(provincia).change(carga_localidades)
>
> if (!opcionnula) {
> $(provincia).children("option:first-child").remove()
> $(localidad).children("option:first-child").remove()
> }
>
> function carga_localidades(){
> var id = $(provincia).val()
> $.getJSON('/localidades/provincia/' + id, {},
> function(localidades){
> $(localidad).html('')
> if (opcionnula) {$(localidad).append(' value="">-')}
> $.each(localidades, function(k, v){
> $(localidad).append('' + localidades[k]["fields"]["nombre"] +
> '')
> })
> $(localidad).change()
> })
> }})
>
> 
>
> This is the view calling when js points to /localidades/provincia/n/
>
> def localidades_por_provincia(request, id_prov=None):
> if id_prov:
> p = Provincia.objects.get(id=id_prov)
> data = serializers.serialize('json', p.localidad_set.all(),
> fields=('nombre'))
> return HttpResponse(data)
> else:
> return HttpResponse(str([]))
>
> --
> Juanjo Conti
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---

Re: design patterns

[Juanjo Conti]

I do it with jquery (client side) getJSON funcion (tamplate exmaple):



jQuery(document).ready(function($){

var prefix = "{{ prefix }}"
var opcionnula = {{ opcionnula }}   //incluir la opción
nula en la lista de localidades y provincias
var provincia = "#id_" + prefix + "provincia"
var localidad = "#id_" + prefix + "localidad"

$(provincia).change(carga_localidades)

if (!opcionnula) {
$(provincia).children("option:first-child").remove()
$(localidad).children("option:first-child").remove()
}

function carga_localidades(){
var id = $(provincia).val()
$.getJSON('/localidades/provincia/' + id, {},
function(localidades){
$(localidad).html('')
if (opcionnula) {$(localidad).append('-')}
$.each(localidades, function(k, v){
$(localidad).append('' + localidades[k]["fields"]["nombre"] +
'')
})
$(localidad).change()
})
}
})


This is the view calling when js points to /localidades/provincia/n/

def localidades_por_provincia(request, id_prov=None):
if id_prov:
p = Provincia.objects.get(id=id_prov)
data = serializers.serialize('json', p.localidad_set.all(),
fields=('nombre'))
return HttpResponse(data)
else:
return HttpResponse(str([]))

-- 
Juanjo Conti

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---

design patterns

[Gene Campbell]

Someone recommended http://mochikit.com/ recommended as a good ajax
toolkit.  I don't think you'll find design patterns there - like how
to design software.

I'm a noob, and only trying to help.


On Fri, May 23, 2008 at 5:14 AM, unixdude_from_mars
<[EMAIL PROTECTED]> wrote:
>
> Being new to web development I was wondering what the best resource
> would be for web design patterns implemented in django, js, ajax,
> dojo.
>
> Specifically -- I am interested in dynamic drop down list, where the
> list items come from my database, but are links that allow one to
> drill down.  Each link would invoke and new quiery to the database and
> generate a new list which generates new quieries..etc.
>
> current I have a working web site using linux, apache, django, and
> mysql. I have read the django book, and looked at some sites on the
> web that implement django.
>
> Can anyone suggest where I might find a good reference or example of
> dynamic dirill down lists implemented in django?
>
> Also -- the most current design patterns for things that are common
> such as rollovers, random banners, menus and such.  Does anyone have
> good tutorials on such subjects that they can recommend.
>
> Thanks
>
> James
> >
>



--
Picante Solutions Limited
e: [EMAIL PROTECTED]
w: 06 757 9488



-- 
Picante Solutions Limited
e: [EMAIL PROTECTED]
w: 06 757 9488

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---

design patterns

[unixdude_from_mars]

Being new to web development I was wondering what the best resource
would be for web design patterns implemented in django, js, ajax,
dojo.

Specifically -- I am interested in dynamic drop down list, where the
list items come from my database, but are links that allow one to
drill down.  Each link would invoke and new quiery to the database and
generate a new list which generates new quieries..etc.

current I have a working web site using linux, apache, django, and
mysql. I have read the django book, and looked at some sites on the
web that implement django.

Can anyone suggest where I might find a good reference or example of
dynamic dirill down lists implemented in django?

Also -- the most current design patterns for things that are common
such as rollovers, random banners, menus and such.  Does anyone have
good tutorials on such subjects that they can recommend.

Thanks

James
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---