Re: cached template loader is new in trunk/1.2, docs does not mention that
Further, cached template loader does not reload template when template is modified. I am not complaining, just feel that it should me mentioned in the doc, as normal expectation when developing/deploying django is that one need not restart apache when template changes, not with cached template loader. On Wed, Jan 6, 2010 at 9:54 PM, Amit Upadhyay <upadh...@gmail.com> wrote: > http://docs.djangoproject.com/en/dev/ref/templates/api/#loader-types, I > looked and could not find "cached.py" > in Django-1.1.1/django/template/loaders. > > -- > Amit Upadhyay > www.amitu.com > +91-9820-295-512 > -- Amit Upadhyay www.amitu.com +91-9820-295-512 -- 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.
cached template loader is new in trunk/1.2, docs does not mention that
http://docs.djangoproject.com/en/dev/ref/templates/api/#loader-types, I looked and could not find "cached.py" in Django-1.1.1/django/template/loaders. -- Amit Upadhyay www.amitu.com +91-9820-295-512 -- 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 doc improvement suggestion
Further, its difficult to locate information about generic relations on any of the following pages: - http://docs.djangoproject.com/en/dev/ - http://docs.djangoproject.com/en/dev/topics/db/models/#topics-db-models - http://docs.djangoproject.com/en/dev/ref/models/fields/#ref-models-fields Doing search on google leads to http://www.djangoproject.com/documentation/models/generic_relations/, which is not really the right place to learn about them, only some example usage. The actual information is available on "Content Types" page [ http://docs.djangoproject.com/en/dev/ref/contrib/contenttypes/], which is very non intuitive. Recommendations: - Make model fields reference page [ http://docs.djangoproject.com/en/dev/ref/models/fields/#ref-models-fields] either include these fields, or link to the content type page where they are, currently searching on that page for GenericForeignKey gives no results. - Make generic relations a top level item on documents page [ http://docs.djangoproject.com/en/dev/] I generally get the feeling that there are bit too many pages, we can make the entire thing better by clubbing related things together. Documentation should be organized from consumption point of view, and we can identify the following main class of consumptions: - somebody learning django -- devote a page for them - somebody writing models, containing db, queries, models, fields, custom fields etc - somebody writing views, contain request/response details, cookies, meta, urls, shortcut functions etc - somebody working with templates, standard tags and filters, writing own, shortcuts - deployment - installations: one page for windows, another for mac etc. I am suggesting we include some "power pages" for the above use cases, which just links to everything you need to know when doing this task, which is already available in our documentation section [may be even including offisite info]. On Sun, Jul 5, 2009 at 1:05 PM, Amit Upadhyay <upadh...@gmail.com> wrote: > Hi, > > I find http://docs.djangoproject.com/en/dev/topics/db/ page quite > inadequate. If I was doing that page I would include links to the following > pages, along with the ones that are there: > >- (Model Field Rerence, where all standard fields are listed) >http://docs.djangoproject.com/en/dev/ref/models/fields/ >- (Writing Custom Model Fields) >http://docs.djangoproject.com/en/dev/howto/custom-model-fields/ > > The content of these pages used to be clubbed with > http://docs.djangoproject.com/en/dev/topics/db/models/, which was very > handy, I have to open just one page, and all relevant information for > writing models is there, now I have to keep on searching. So I would at the > least add the links to the above to pages prominently on the top or on the > sidebar, as of now they are quite difficult to find. > > Please merge the three pages together, or at least put the cross links > prominently. > > Will create a patches if given a go ahead. > > -- > Amit Upadhyay > www.amitu.com > +91-9820-295-512 > -- Amit Upadhyay www.amitu.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
django doc improvement suggestion
Hi, I find http://docs.djangoproject.com/en/dev/topics/db/ page quite inadequate. If I was doing that page I would include links to the following pages, along with the ones that are there: - (Model Field Rerence, where all standard fields are listed) http://docs.djangoproject.com/en/dev/ref/models/fields/ - (Writing Custom Model Fields) http://docs.djangoproject.com/en/dev/howto/custom-model-fields/ The content of these pages used to be clubbed with http://docs.djangoproject.com/en/dev/topics/db/models/, which was very handy, I have to open just one page, and all relevant information for writing models is there, now I have to keep on searching. So I would at the least add the links to the above to pages prominently on the top or on the sidebar, as of now they are quite difficult to find. Please merge the three pages together, or at least put the cross links prominently. Will create a patches if given a go ahead. -- Amit Upadhyay www.amitu.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
hi
Hey, Checkout www.RemindMeSam.com . -- Amit Upadhyay Via - www.remindmesam.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: GET requests should not alter data?
On Fri, Oct 17, 2008 at 7:10 PM, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > > Amit Upadhyay wrote: >> The crux of that solution is the middleware: >> >> def process_request(self, request): >> state = request.method in ['GET', 'HEAD'] and 'slave' or 'master' >> connection.use_state(state) >> >> Which is same as what I am talking about. > > I feel obliged to correct this. It's not the crux in any way but a > convenient method of eliminating *most* but not all of hand work from > managing connections. Yeah, but how will you manage the connections in the cases this fails, when the connection is being used from django core, but by patching django in the fashion I mentioned above? You will have to go read entire django, find all views/middlewares shipped with it, and up the lines like these on the offending part. connection.use_master() try: ... # something that updates db finally: connection.revert() You can not manage connection used by django[core + contrib apps that comes with it]! > As many have pointed out such pure systems where > GET doesn't touch any state just don't exist. > > Unfortunately practice is more complex than theory and attempts to > ignore it lead to systems that nobody uses. This is not true. Do this: 1. make sure none of your apps do db writes on GET. [It was the case with my entire project already, other than one case, which was trivial to work around]. 2. Use non db session backend. 3. Not use auth messages. [This presented some problems for me, but I had luckily using wrapper for message creation and not User.message_set.create() as recommended in docs; after porting http://code.djangoproject.com/ticket/4604 to my django-0.96, all I had to do was to change few lines here and there]. And you have a safe "pure systems where GET doesn't touch any state", which is not complex and I use it at my website! It was kind of trivial in my case, I checked: none of the queries were modifying anything by granting only SELECT perms to user handling GET app/slave and testing all functionality of my website. If the prevailing mood is to be trusted, one would get an impression that the GET write db situation is so messed up in django, that this request.method based splitting for load balancing should not be considered at all. So many people may be getting misdirected by this. But then I can not say this for certainity for all django powered projects. There might be other bits lurking in parts of django I did not use/test, and some more may come in future in the bits I used and tested against, if django developers do not consider it something to think about, and leaves us to go through source code after every release. -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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: GET requests should not alter data?
On Fri, Oct 17, 2008 at 6:07 PM, James Bennett <[EMAIL PROTECTED]> wrote: > > I do not understand, when everywhere django tries so very hard in a > > pragmatic sense to decouple things where it logically makes sense, then why > > suddenly an ideological outburst of "because we are not violating any specs, > > we refuse to even think". > > And this is where the histrionics take over and I sign out. If your > first response to the discussion here is to say "Django developers > refuse to even think about this", then honestly I don't have the first > clue how to go about helping you. Don't get me wrong here, I mean "we refuse to even think" in a positive fashion, as a rational conclusion after much thinking, and may well be valid one for django in the current case. Its quite similar to position on thread safety, thread safety is complex issue, and trying to prove thread safety for entire django and all subsequent patches accepted would/could slow down the development quite a bit, and thus django developers/committers kind of "refuse to think about it" when committing/releasing. I just happen to think its much simpler in this case, django core+contrib apps in django svn[1] have hardly a dozen views+middlewares, it would not be difficult to go through them and put the info on a wiki page. [This is when "we refuse to think about" becomes django's position, which happens to be current position, my objection is merely that it should not be rooted in ideology, but on technical merits/considerations[2]]. [1]: I hate overloaded words, whats the term for django == django that is in the trunk? Django core? But it excludes contrib apps, but saying django core+contrib might imply/include apps that are not really in django.contrib, but also on google code etc. I guess django-svn should do. [2]: There are too many ways to use django, and one cant think about all of them is a valid technical reason, but what I am talking about here may be important enough given its impact in scaling, which should be kind of somewhere on django's priorities. -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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: GET requests should not alter data?
On Fri, Oct 17, 2008 at 4:03 PM, James Bennett <[EMAIL PROTECTED]>wrote: > > On Fri, Oct 17, 2008 at 5:07 AM, Amit Upadhyay <[EMAIL PROTECTED]> wrote: > > Either this becomes a django standard, every code that might update > database > > on GET doing something like: > > > > connection.use_master() > > try: > > ... # something that updates db > > finally: > > connection.revert() > > > > or we pray/discard this approach of scaling altogether. > > I love the smell of false dilemmas in the morning. I was trying "reductio ad absurdum", the "existing solution" to the "problem" I was presented with, leads to such absurdities, and therefore, my "problem" still stands. To reiterate, I am proposing: "avoid, and if not possible, document" for DB updates in GET, are you really saying you are against this? Is your logical position "encourage" or "don't care/document"? A developer goes to the django-dev list and says, "Django devs, my > application breaks when I assume that GET requests never do DB > writes." So the Django devs say, "Well, then, stop assuming that!" You have to make assumptions or/and read the source to evaluate any solution. DB selection based on request method is the only obvious solution I can come up with for scaling after exhausting caching options. Are you ruling it out for django apps? If so what are the other solutions? If not, should django not be a little accomodating about it? I do not understand, when everywhere django tries so very hard in a pragmatic sense to decouple things where it logically makes sense, then why suddenly an ideological outburst of "because we are not violating any specs, we refuse to even think". I guess its difficult to make progress on this thread sans wiki/patches. Lets revisit if/after I/someone come(s) up with something concrete. -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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: GET requests should not alter data?
On Wed, Oct 15, 2008 at 9:25 PM, bo <[EMAIL PROTECTED]> wrote: > > It seems that what you may want is something like > > http://softwaremaniacs.org/soft/mysql_replicated/ The crux of that solution is the middleware: def process_request(self, request): state = request.method in ['GET', 'HEAD'] and 'slave' or 'master' connection.use_state(state) Which is same as what I am talking about. This will break the moment a GET request tries to do any DB update. They have tried to solve the session issue by providing their own session backend. From the cursory look I did not find what is the fix for User.get_and_delete_messages issue, other than "hoping that it would be fixed by check_state_override" (GET request just after POST will go to master, which only works if all messages are gauranteed to be originated in web POST requests). Either this becomes a django standard, every code that might update database on GET doing something like: connection.use_master() try: ... # something that updates db finally: connection.revert() or we pray/discard this approach of scaling altogether. I modified it to force a master call for everything that was not a > "SELECT" in the final query, and once you force it to the master (or > it auto forces to the master) it will stay there for the duration of > the request to deal with the asynchronous nature of a master-slave > pair. > As I understand, this is too whacky in my opinion, what if after 100 SELECT queries in a view, one does a INSERT/UPDATE based on data obtained so far, SELECTs would have gone to slave, which may be lagging by an uncertain amount of time, and the write to master, this will lead to very hard to reproduce and debug race conditions. -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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: GET requests should not alter data?
On Wed, Oct 15, 2008 at 5:17 PM, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > > Amit Upadhyay wrote: >> This is not about specs or what is allowed, rather what is there in >> actual django. And about implementation goals for django. It is >> possible to have a django(core+contrib apps shipped with django) with >> only SELECT queries in response for GET request. So far I have >> identified two places and their work arounds. Are there more? They >> should be avoided, and if not possible documented. > > For example you can't implement OpenID consumer without altering > application state on GET (actually logging a user in happens upon HTTP > redirect). Its necessary given openid spec I guess. Can it be worked around by not splitting GET/POST for urls starting with /openid/? Can a GET on any request, thanks to some middleware maybe, write or writes are limited to one of few URLs? Such questions are not easy to answer offhand for someone who is using the app, and should be can go somewhere in readme.scaling.txt/less frequently asked question for the app may be. Along with other resources, files/directories etc that may be used by openid consumer, from the point of view of scaling. -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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: GET requests should not alter data?
On Wed, Oct 15, 2008 at 4:28 PM, Luke Plant <[EMAIL PROTECTED]> wrote: > It is not desirable to have Django try to enforce this, since GET > requests are allowed to have side effects, just not side effects that > "have the significance of taking an action other than retrieval" [1]. This is not about specs or what is allowed, rather what is there in actual django. And about implementation goals for django. It is possible to have a django(core+contrib apps shipped with django) with only SELECT queries in response for GET request. So far I have identified two places and their work arounds. Are there more? They should be avoided, and if not possible documented. Also I am talking about django core and contrib apps only [and hoping a SELECT only or workaround possible policy gets a official nod and voluntarily implemented by thirdparty developer apps]. > There are all kind of use cases where it is good to be able to track > the fact that the user has made a retrieval. (Amazon and 7digital > track pages you've visited, for instance, to help you keep track of > items you are interested in). This is not django core requirement, rather a django project's application logic, the reason I am distinguishing these two is because I have mostly written the application logic and when it presents me with a problem I would rewrite it to add some work around. That is not equally easy with django core, third party apps. Also I am not saying alter must not be allowed, just that it be considered as a necessary evil if at all, and scaling simplicity consideration should be weighed in when ever a new (sql) data alter on GET is considered. > Second, even if you could enforce it at the database level, there are > many other ways you could have side effects e.g. mail, filesystem. I am only thinking of database replication scenario and problems/gotchas that may be there in django if I blindly split traffic based on request method, in case of the database being the bottleneck. mail causes no concern, and file system would be problem but only if there are more than one webserver, and thus for the sake one issue per thread we can ignore it for now, focusing only on whats required to scale database server, which is big enough a problem. -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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: GET requests should not alter data?
On Wed, Oct 15, 2008 at 1:55 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > By the way, for something like sessions, the scaling solution is not to > use server-side storage at all for the session data. Typically sessions > don't actually hold that much data and even in cases like, say, a > checkout trolley, you could push the data into a session-correlated > table, rather than the session object itself. > > So client-side sessions (signed cookies, etc) are the way to go in that > case. Session-correlated table? Though you talked about session, I guess you were addressing my concern about user messages. User messages should probably ideally go to cookies, even if message can be long, they expire after only one request, so there is little cookie overhead. Session based messages[1] will also solve the same problem. So if we use non db SessionStorageEngine and Session based messages, we can live with SELECT only for GET requests. My wish for django would be, either 1. a position that other than the Session, there is no data changes by entire django if request method is GET. or 2. a wiki/doc page explaining what all database changes that can happen as part of GET request processing by django, and a suitable workaround [hoping a workaround exists for all use cases, currently the workaround for user messages is only available as a patch attached to a ticket]. Some kind of clarity on this would be good to have for 1.x. [1]: http://code.djangoproject.com/ticket/4604 -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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: GET requests should not alter data?
On Wed, Oct 15, 2008 at 1:20 PM, Amit Upadhyay <[EMAIL PROTECTED]> wrote: > Question: 1. is the expectation that GET request should only do SELECT > reasonable? 2. if 1, then should django enforce it? Clarification, enforce is ambiguous: Question2.1. django, core and contrib apps shipped with it, should internally not alter data on GETs, plus recommend third party django apps to not do the same. Question2.2. there be a middleware to enforce this on database level, raise assertion error if request.method == GET and sql.query_type != SELECT, so that I can say with certain confidence it has been done. [creating a sql user with only SELECT permission takes care of this so it is not strictly necessary, but such a middleware will make development easier]. I am not sure how it would work, but i think something like transaction middleware, doing something like django.core.db.only_allow_selects() in process_request if request.method == GET, and reverting in process_response, plus updating the django's db code to honor this. -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
GET requests should not alter data?
Usecase: for scaling a website(bottlenecked on database), one of the first thing to do after caching and other optimizations is to split requests to go to master/slave replicated database servers. One way of doing it is based on request.METHOD[1], GET requests going to slave, and POSTs going to master. Problem: django has a few instances where a GET leads to database changes. 1. session creation(INSERT) 2. User.get_and_delete_messages(DELETE). And probably others. Question: 1. is the expectation that GET request should only do SELECT reasonable? 2. if 1, then should django enforce it? [So far using non db based session backend, and allowing delete for auth_messages from "GET machines" and living with "a message appears more than once" is what I am doing]. [1]: For example through http://www.djangosnippets.org/snippets/1141/ -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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: django.forms.SafeForm - forms with built in CSRF protection
On Tue, Sep 23, 2008 at 8:43 PM, Brian Beck <[EMAIL PROTECTED]> wrote:
> The problem is that any token, no matter where we generate it, isn't
> going to be submitted back with the POST request unless it's a field
> in the form that was submitted. So the only options I see are
> mangling the HTML to add these fields (CsrfMiddleware), or add them to
> the form objects (SafeForm).
There is another option, a template tag. I would implement it as a
middleware and a template tag. Template tag csrf_protect, will require
CSRFMiddleware and django.core.context_processors.request, will add a
input file containing something derived from {{ request }} and
middleware will check and raise HttpForbidden. Its so ugly that it
does not deserve a form validation error in my opinion. This will
require least amount of changes in existing sites.
--
Amit Upadhyay
Vakow! www.vakow.com
+91-9820-295-512
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
old docs not opening
http://www.djangoproject.com/documentation/0.96/pagination/ Giving 404. Known issue or I should file a bug? -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
about templatetag namespaces
Hi,
I have identified a few issues over the time that makes working with custom
django template tags/filters a little less than ideal for me.
My chief problem is: if I see an unknown/unfamiliar tag/filter and want to
locate the exact code responsible, I have to do the following: find all
loads defined in the template, for each of those "loaded template
libraries", I have to find the py file by searching it in all
INSTALLED_APPS/templatetags folder and then scanning them for a
register_tag/register_filter call with the unknown name. This to me is a
little bit too much magical[PS1]. Further, what if there are more than one
apps with some_template.py in their templatetags folder? And why is it
called templatetags when it can have both filters and tags? (*tongue in
cheek remark :-).
Bottom line is clean namespacing is difficult to achieve as of now, but
would be possible with the following "syntax":
{% load mytemplatelib.few_tags as cool_tags %}
and used subsequently as {% cool_tags.show_something %}. Or the alternate
syntax:
{% load mytemplatelib.few_tags.* %} and I can do {% show_something %} [this
sytax would come with its warning similar to the ones issued against using
the "from django import *" like imports in python].
Note: mytemplatelib.few_tags would be search in sys.path and not in
installed_apps' templatetags folders.
As a template writer I will have to provide a module mytemplatelib.few_tags
with a show_something named function which acts as a tag. There would be
some decorators/protocol to tell if they are valid tag/filter.
Assuming the idea is accepted, It can be implemented in a mostly backward
compatible fashion, post 1.0, either by having a {% import %} named new
loader for 1.x, or even {% load %} name can be preserved as one can first
look into the old way of loading and if it fails can look for new way.
This has been discussed before[1], but I have some objections with the
latest implementation[2]:
* appname/templatetags still persist, and is the place where libraries will
be looked into, there is no reason for django to enforce and create its own
import paths, PYTHONPATH, sys.path etc are good enough for that. Let
application developers and templatetags library writer pick what makes
sense. Looking into INSTALLED_APPS constraint does not buy much and can be
cleaned up entirely.
* We still have to do the search if we get a new/unfamiliar template
tag/filter. This is just not pythonic to me.
Both these are backward incompatible changes, but like I said current way
can be kept, with some DepricationWarning, and 1.x may include the new way
which looks for module name in sys.path instead of app_name/templatetags/.
Subproposal:
Add settings: DEFAULT_TEMPLATE_EXTENSIONS [avoiding the words tags/filter as
it can be either], being a list of strings that will be automatically be {%
load whatever %} in all templeates.
Subsubproposal:
Split defaulttags into defaulttags_essentials which will include tags like
"load", "extends", "block" etc, which are really required for templates to
work vs others like "for"/"if" and the rest into some other module that gets
added by default in "settings.DEFAULT_TEMPLATE_EXTENSION". So that if I can
use the fancier versions of my template tags/filters by turning off the
django ones and using just mine, without having to use any namespace prefix,
and without having to worry abt conflicts with django's default template
tags/filters.
PS1: Though there is nothing stopping me from writing a script that takes
the tag/fitler name and returns me the qualified name of the function
handling the tag/filter.
[1]:
http://groups.google.com/group/django-developers/browse_frm/thread/2b5a4a31f0349d27/b92c96a8dccc214b#b92c96a8dccc214b
[2]:
http://code.djangoproject.com/attachment/ticket/2539/patch_2539_code_tests.diff
--
Amit Upadhyay
Vakow! www.vakow.com
+91-9820-295-512
--~--~-~--~~~---~--~~
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: Middleware class vs decorators (proposal?)
On Mon, Apr 14, 2008 at 2:00 PM, James Bennett <[EMAIL PROTECTED]> wrote: > > On Sun, Apr 13, 2008 at 6:05 AM, Amit Upadhyay <[EMAIL PROTECTED]> wrote: > > I was wondering about the reason that middleware classes were used > instead > > of decorators to implement middleware functionality. > > There are two cases, each with drawbacks: > > 1. Whatever system is available to provide additional processing is by > default applied only to a single specific view (e.g., a decorator). > The drawback is that you will inevitably want an easy way to say > "apply this everywhere" instead of manually applying the decorator to > every view. ... SNIP ... You got me wrong. I am talking about pre-applying the "middleware-decorators" to all views found thru urls.py processing. -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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: Middleware class vs decorators (proposal?)
On Sun, Apr 13, 2008 at 6:24 PM, Alex Koshelev <[EMAIL PROTECTED]> wrote: > > Hi, Amit! > > Check this utils function: > > http://code.djangoproject.com/browser/django/trunk/django/utils/decorators.py#L9 This wont really help much as I will still have to apply the decorators manually to all views instead of enabling them programmatically, and I can still not call the view more than once etc. I understand that it is probably too late for such a change, with a one book published and two in the pipeline, but was wondering if there was some advantage of the current design over this that I am missing. PS: This is another advantage of having middleware as decorators, we won't need that helper :-) -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Middleware class vs decorators (proposal?)
Hi, I was wondering about the reason that middleware classes were used instead of decorators to implement middleware functionality. One of the use cases that lead me into thinking about it is that I was looking for a way to have middleware apply only to views of one particular app [facebook app for example]. The MiddlewareNotUsed exception that is used by DebugMiddleware is very limited, vs if it was a decorator, the decorator would have the view passed and it could have taken a decision based on the module path of the view. The other use case I thought of was: on my site, there are some background processes running intermittently, and the load my mysql server, and abt 20-30 times a day on my site we get an error abt mysql server not responding. I imagined writing a middleware that will catch this exception, and sleep for a few secs and then call the view again, but I realized the current design of middleware does not allow that, and the only way to do this would be to send a http302 or something, which would be useless for POST requests and would be dangerous if website is loaded due to some reason [it will lead to recursive 302, adding up lot of load on the website]. With middleware I would have passed the actual view, and I would have caught the exception and in excpetion handler trying to call the view one more time before giving up. This is roughly how a middleware decorator would look like: def my_middleware(view): if not shud_apply_on_this_view(view): return view # this is part of __init__ currently, without access to view. def decorated(request, *args, **kw): x, y, z = get_xyz_from_request(request) # this is process_request phase, without access to args, kw etc. try: resp = view(*args, **kw) except TheExceptionIAmInterestedIn: do_something_with_it() # this is process_exception, but much more natural python, than to do if isinstance(ex, MyExcp) # plus i can call view again if i feel like. do_something_with_xyz(x, y, z) # this is process_response, having access to x, y, z is more natural than to attach them to self before and after the call of view return resp return decorated -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: add support for unicode-normalizing get/post-data?
On Thu, Apr 10, 2008 at 12:18 PM, Gábor Farkas <[EMAIL PROTECTED]> wrote: > p.s: if there is a way to achieve this without touching > django-internals, please tell me :) I would have written a view decorator that takes request, and normalizes the request.GET/POST before calling the real view. -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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: Fixing app_label
On Dec 6, 2007 1:46 AM, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > Why not also use actual module objects here instead of strings like with
> > view functions in urlconfs?
>
> I don't see the benefit. It makes sense for views so you can apply
> decorators to them in your urls.py file. I'm not sure what you'd want
> to do with a module. The less you actually import into your settings
> file, the better IMO.
Apps can have their own middlewares. Though it can still be handled without
imports.
INSTALLED_APPS = AppCollection(
App('foo.blog', middlewares=['example.mymiddleware']),
)
--
Amit Upadhyay
Vakow! www.vakow.com
+91-9820-295-512
--~--~-~--~~~---~--~~
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: An addendum to the escaping proposals
Hi, I just switched on the middleware and all my ajax post actions are broken now. I am going to dive in the source and try to figure out how to generate enough token that I can embed in the page on page load, so that all my requests go fine. I would appreciate some tips if someone can tell me if I can reuse the token or I will have to create more than one. Also if the token expire after sometime, that I have to worry about. -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
proposal: deprecate "date" and "time" template filters and create "formattimestamp"
[Rant] This is the second time I am hitting this issue. I have some models with DateTime field, and I wanted to show it in a given format, I googled "django template" and hit the first link. There I see "date" template filter, and am thinking cool, this is what I need. But suddenly I realize there is another filter called "time", and start to think, what is ""date"" and ""time"" anyways, integer, some particular class instance, am familiar with datetime module so guessed that the so ""date"" mentioned in "date" filter should be an instance of datetime.date class and "time" should take datetime.time. As soon as I realize this, I realize that my object is an instance of datetime.datetime, and is neither datetime.time nor datetime.time, and documentation gives me no clues or hints that either of the functions should be accepting datetime.datetime [they mention explicitly ""date"" and ""time"" in respective cases]. My common sense told me they should just accept it, but then I thought commonsense also tells if they did, there is no need of an explicit "time" filter, as "date" can handle that too, given that the filter argument only had time related format. At this time I realize I may have to implement my own filter for formatting datetime object, and it sucked, especially given that there are not one but two filter dedicated to handling datetimes already. I was like, what the hell, how bad could it be, and looked at the defaultfilters.py and dateformat.py, and realized other than cause all this confusion, the only reason to use "time" is to get some random sounding [KeyError?] error messages if you use wrong formatting characters. [/Rant] Template filters "date" and "time" are formatting tags, and there are three other formatting tags, they are named "filesizeformat", "stringformat" and "floatformat", in my opinion, these two should be named "dateformat", and "timeformat" for consistency, and better yet, should be replaced with a single "timestampformat" template filter. -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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: helper functions for validation
On 9/11/07, Marty Alchin <[EMAIL PROTECTED]> wrote: > That said, I'd also recommend that if you're going to draw any > parallels with unittest assertions, you should probably do it > reliably. Your validate_exception() example was completely unreadable > to me, because it works quite differently than the one in unittest. I agree with you on readability, and my proposal about function signature is not final, and probably can do well with further inputs. About validate_exception, this is the signature of the corresponding method in unittest: *assertRaises*( exception, callable, *args, **kw) they have removed message, but since args and kw will be passed to callable, these are the only two possible options for adding message: validate_raises(exception, msg, callable, *args, **kw) or validate_raises(msg, exception, callable, *args, **kw). I picked the former, and do not understand how it has become completely unreadable. It's not terribly Pythonic, but people use it because it works well. This is my point, a set of convenience function, well thought out, will be used by python programmer no matter even if it is as bad as looking like coming from java. The challenge is probably to figure out function names and signatures that are intuitive as best as we can. Support of server side form validation is a strong point for django, and a rich libraries of such functions would only make things better. Batteries included thing. I have created a wiki page[1] with proposed function names and signatures, please go through it, and see if they make sense, and might be useful for django. [1]: http://code.djangoproject.com/wiki/ValidationHelperFunctionsProposal -- Amit Upadhyay http://www.amitu.com/blog/ +91-9820-295-512 --~--~-~--~~~---~--~~ 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: helper functions for validation
On 9/11/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > Well... no. assertEquals exists in Python unittests because > assertEquals exists in JUnit, and unittest emulates the JUnit API. > This API is, in turn, based on xUnit, which was derived from SUnit, > the original Smalltalk implementation written by Kent Beck. > > The motivation in Python was to implement an xUnit API, not design a > specifically Pythonic test API. But they still get used. assert_(variable, msg) is more concise than if not variable: raise AssertionError(msg) Saves us 20 chars. [sure python has language support for assertion and you could as well write: "assert variable, msg", but this can not be done for validation, and above conciseness holds]. Before: if variable1 == variable2: raise ValidationError(msg) after validate_equal(variable1, variable2, msg) 12 few chars to type. Before: try: User.objects.get(username=variable) except User.DoesNotExist: pass else: raise ValidationError(msg) after: validate_exception(User.DoesNotExist, msg, User.objects.get, username=variable) 27 chars saved. Things like validate_[not_]almost_equal, validate_date_within_range, validate_date_before, validate_date_after will have to be implemented by the users, but if we had such a library with dozens of special purpose functions to assist validation, writing form validation would become all the more sweeter. -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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: helper functions for validation
On 9/10/07, Nis Jørgensen <[EMAIL PROTECTED]> wrote:
>
> Russell Keith-Magee skrev:
> > On 9/9/07, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> >
> >> Python unittest TestCase objects have a lot of helper functions like
> >> assert_(), failUnless(), assertEqual(), assertNotEqual() and so on[1].
> If we
> >> had a similar set of helper functions, possibly with more pythonic
> names,
> >> newform validation functions could be written a little more succinctly.
> >>
> >> def clean_password2(self):
> >> if self.clean_data['password1'] != self.clean_data
> ['password2']:
> >> raise ValidationError(u'Please make sure your passwords
> match.')
> >> return self.clean_data['password2']
> >>
> >> can become
> >>
> >> def clean_password2(self):
> >> assert_equal(self.clean_data['password1'],
> >> self.clean_data['password2', "Please make sure your passwords match."
> >> return self.clean_data['password2']
> >>
> >
> > I think a series of helpers for newforms validation is a reasonable
> > idea. I have a few comments about the exact form of your suggestions:
> >
> > - I'm not wild about the deviation from the established camelCase
> > naming convention. The tests are called assertEqual, assertRaises etc
> > in TestCase; although Django generally uses underscores rather than
> > camelCase, I think there would be more value in maintaining
> > similarity.
> >
> > - I'm also inclined to continue the similarities, and make the
> > assertion functions members on BaseForm. This would allow a
> > significant simplification of your proposal, as the data locations
> > (i.e., self.cleaned_data) can be implied.
> >
> > So - as a result of those suggestions, the helpers would look more like:
> >
> > def clean_password2(self):
> > self.assertEqual('password1','password2','Please make sure...')
> > return self.clean_data['password2']
> >
> > Thoughts?
> >
> I don't like the transformation of strings into field values. How would
> you compare a field value to a string?
Exactly my reason for not making it a method of BaseForm. If things were
simple and all validations were such that transfomation of strings into
field value was enough, we would have gotten rid of one or more "
self.clean_data" per statement for one extra "self.". Let me talk in code:
If for some legacy reason, password is supposed to be case in sensitive, we
would want to do:
def clean_password2(self):
self.validate_equal(self.clean_data["password1"].lower(),
self.clean_data["password2"].lower(), "Please make sure..")
return self.clean_data["password2"]
and automatic translation for string to field would not allow it.
I would much rather do:
def clean_password2(self):
d = self.clean_data.get
self.validate_equal(d("password1").lower(), d("password2").lower(),
"Please make sure..")
return d("password2")
and if we are doing such tests all the time, the "self." is just not buying
as anything. And we can make it:
import * from newforms.validation_helpers
def clean_password2(self):
d = self.clean_data.get
validate_equal(d("password1").lower(), d("password2").lower(), "Please
make sure..")
return d("password2")
There is no other reason to refer to self but to automatically translate
strings to field value.
--
Amit Upadhyay
Vakow! www.vakow.com
+91-9820-295-512
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
proposal: helper functions for validation
Python unittest TestCase objects have a lot of helper functions like
assert_(), failUnless(), assertEqual(), assertNotEqual() and so on[1]. If we
had a similar set of helper functions, possibly with more pythonic names,
newform validation functions could be written a little more succinctly.
def clean_password2(self):
if self.clean_data['password1'] != self.clean_data['password2']:
raise ValidationError(u'Please make sure your passwords match.')
return self.clean_data['password2']
can become
def clean_password2(self):
assert_equal(self.clean_data['password1'], self.clean_data['password2',
"Please make sure your passwords match."
return self.clean_data['password2']
or
def clean_code(self):
try:
ConfirmationCode(code=self.clean_data['code'])
except ConfirmationCode.DoesNotExist:
raise ValidationError("Code does not exist")
return self.clean_data["code"]
becomes:
def clean_code(self):
assert_not_raises(ConfrimationCode.DoesNotExist, "Code does not
exist", ConfirmationCode.objects.get, code=self.clean_data['code'])
return self.clean_data["code"]
or
def clean_username(self):
try: User.objects.get(username=self.clean_data["username"])
except User.DoesNotExist: pass
else: raise ValidationError("Username already taken")
return self.clean_data["username"]
becomes
def clean_username(self):
assert_raises(User.DoesNotExist, "Username already taken",
User.objects.get, username=self.clean_data["username"])
return self.clean_data["username"]
Message would be compulsory in these helper functions, and they will raise
ValidationError instead of AssertionError.
[1]: http://docs.python.org/lib/testcase-objects.html
--
Amit Upadhyay
Vakow! www.vakow.com
+91-9820-295-512
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Time for a new release?
The problem we are discussing here is not really a django specific one. The concerns Adrian pointed out can be easily taken care of by using branches. In theory the generic documentation enhancement should be applicable to all releases, but we know its only really applicable to the previous release, or may be the one before that, so its not like we will have to maintain lost of branches either. I say for each release, we create a branch, and each documentation enhancement be backported to it when applicable. I also say the default documentation on website be generated from the the latest release branch. This should solve all issues. On 8/26/07, James Bennett <[EMAIL PROTECTED]> wrote: > > > On 8/26/07, Nicola Larosa <[EMAIL PROTECTED]> wrote: > > Only if you make it so, and you shouldn't. :-) > > So do you have a means of pushing out updated docs to everyone who's > downloaded a tarball, every time we make a change that's not related > to documenting a change in Django itself? > > > It does not work. You cannot really get people to use the trunk docs, > but > > in many places say: "Oh, by the way, this little thing changed, please > > refer to the *right* release docs, but do come back when you're done, > thank > > you." again and again. > > Which isn't really what anyone's trying, so that's a bit of a red > herring. The problem we've been having is people who download the 0.96 > release and then try to follow the SVN version of the tutorial. This > simply will not work; there is no possibility of "do this part from > 0.96 and then come back", because the SVN tutorial is going to use > techniques (max_length instead of maxlength, __unicode__ instead of > __str__, named URL patterns, etc.) which simply cannot be made to work > on 0.96 in any fashion. > > Thus, the problem to solve here is simple: how do we ensure that > someone who downloads the 0.96 release uses the 0.96 version of the > documentation? > > Bundling HTML versions of the docs isn't a solution, because (speaking > from experience of reading django-users and hanging out on IRC) many > users never realize that the documentation is bundled with the > download in *any* format (just as many users probably never realize > that they get a free copy of "Dive Into Python" on most Debian-based > Linux distributions, and so ask where they can find a good Python > tutorial online). These are the same users who never find their way to > the release-specific docs on the website. > > Which is why it's been proposed that the default landing page for the > documentation should be the version for the latest release of Django, > not the SVN docs; this would solve the problem of people downloading > the release tarball (or installing a package on a Linux distro -- the > distros track releases, not SVN) and ending up at the SVN docs. > > > They shouldn't have to go the web site: the release docs should be on > their > > disk, within the installed release itself (see my other message). > > See above. I'm sure you mean well, but the experience of seeing people > actually work with Django and its documentation is against you on that > point. > > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of > correct." > > > > -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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: Peeking into database queries from the unit-test framework
On 7/28/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > The whole django.db.connection.queries thing has always been a bit of > a hack/wart. (Hackwart?) Maybe it's time to expose the underlying > queries in a more developer-friendly way. Off the top of my head, we > could allow the registration of callbacks with django.db.connection, > like so: > > django.db.connection.register_query_callback(lambda query: > sys.stderr.write(query)) Can't the same be done as a signal? Multiple parties can then listen for query execution. -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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: docstrings
On 7/26/07, Tom Tobin <[EMAIL PROTECTED]> wrote: > > I'm starting to seriously wonder if the 80-character line width has > outlived its usefulness. There are various naturally occurring bits > of code that just don't fit onto a single 80-character line, and the > options for chopping it up are all sub-optimal; increasing the minimum > width would decrease the number of occasions on which one might need > to deal with this frustration. Docstrings and comments also find > themselves cramped for space after a few indentation levels. I like to differ on this. Take your email for example, why is it wrapped at 80 chars? Because its easier to read. In source code this fosters better coding practice, if indentation level is too deep, you are doing something wrong. -- Amit Upadhyay http://www.amitu.com/blog/ +91-9820-295-512 --~--~-~--~~~---~--~~ 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: reverse pagination be made default?
On 7/23/07, Tom Tobin <[EMAIL PROTECTED]> wrote: > > This assumes pagination is always done on date-sorted items; there are > plenty of other uses for pagination (e.g., splitting up a very long > list of books, sorted alphabetically by title). I *really* wouldn't > want to wonder why my books are suddenly going Z-A when my default > sorting is A-Z. Also, this only makes sense when things are ordered by time, for other criteria, it would not make any difference either ways. -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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: reverse pagination be made default?
On 7/23/07, Tom Tobin <[EMAIL PROTECTED]> wrote: > > > On 7/22/07, Amit Upadhyay <[EMAIL PROTECTED]> wrote: > > I have just uploaded a patch for what I call "reverse pagination". > Please > > read about it here: > > http://code.djangoproject.com/ticket/4956. You can see it > > in action on my blog: http://www.amitu.com/blog/. > [...] > > To avoid confusion I was wondering if reverse pagination should be made > default. > > This assumes pagination is always done on date-sorted items; there are > plenty of other uses for pagination (e.g., splitting up a very long > list of books, sorted alphabetically by title). I *really* wouldn't > want to wonder why my books are suddenly going Z-A when my default > sorting is A-Z. Ordering of objects do not change. User would not see any difference other than the fact that page 1 contains items from 1-10 instead of latest item to latest - 10 items [assuming paginate_by = 10]. -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
reverse pagination be made default?
Hi, I have just uploaded a patch for what I call "reverse pagination". Please read about it here: http://code.djangoproject.com/ticket/4956. You can see it in action on my blog: http://www.amitu.com/blog/. The following will make sense after you have read the patch etc. I was trying to write the documentation to go with the patch, and I managed this: * ``reverse_pagination``: Default False. If this is set to true, objects are paginated in reverse. In reverse pagination, page number 1 is assigned to oldest page, where as in normal pagination it is given to latest page. There are some caching advantages when using this. I find this quite confusing, and would need some help from someone. To avoid confusion I was wondering if reverse pagination should be made default. The thing is I find reverse pagination to be advantageous than the normal, and I feel it should be the default behavior in stock django installation. There have been a couple of other backward-in-compatible changes, can this be considered? -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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: Message Passing for Anonymous Users
On 6/19/07, James Bennett <[EMAIL PROTECTED]> wrote: > > I'd be +1 on just switching the whole thing (messages for all users, > authenticated or not) to using sessions, in which case > django.contrib.auth.models.Message should be deprecated and replaced > by django.contrib.sessions.models.Message. Why is request.session["_messages"] not enough? It can be a list of string messages. -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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: configurable session age
On 6/14/07, Amit Upadhyay <[EMAIL PROTECTED]> wrote: > > Updated API: added set_life to SessionWrapper. It takes an integer, number > of seconds for which the session should be valid. It can also take > django.contrib.session.models.TILL_BROWSER_CLOSE, that will quell the > session at the close of browser. Calling set_life will overwrite the > global/default session expiry policy. > After further thinking I realize that TILL_BROWSER_CLOSE is not really required, all desired behavior can be achieved without it, so removed it. -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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: configurable session age
On 6/14/07, Amit Upadhyay <[EMAIL PROTECTED]> wrote: > > After further staring at the code, I realize that there still is some > problem, if session is modified after the cookie is set, django will revert > the cookie to expire when browser closes. The only solution seems to be to > put the expires_time itself in the session so it can get preserved. I have implemented this, and what looks like final-ish patch is attached on ticket. Both "remember me" and slashdot like "public terminal" features is possible now (in my limited testing). Updated API: added set_life to SessionWrapper. It takes an integer, number of seconds for which the session should be valid. It can also take django.contrib.session.models.TILL_BROWSER_CLOSE, that will quell the session at the close of browser. Calling set_life will overwrite the global/default session expiry policy. Somebody please review and test, and set "patch needs improvements" and "needs documentation" to false. Documentation included. Am totally clueless about how to write test for it, please help me. -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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: configurable session age
After further staring at the code, I realize that there still is some problem, if session is modified after the cookie is set, django will revert the cookie to expire when browser closes. The only solution seems to be to put the expires_time itself in the session so it can get preserved. How does it sound? On 6/14/07, Amit Upadhyay <[EMAIL PROTECTED]> wrote: > > Hi, > > This is a gentle reminder/ping for > http://code.djangoproject.com/ticket/2548 by Tsume. Its status is design > decision needed, but that is only because of a query by Adrian, about if the > requested use case may also want configurable cookie name. mtredinnick > replied to this saying it is not possible to do. This feature is a required > for "remember me" primarily, and that only requires configurable timeout. > > I have modified it to work with the scenario when > SESSION_EXPIRE_AT_BROWSER_CLOSE is set to True. I assume if someone has set > expires to some date in future, and SESSION_EXPIRE_AT_BROWSER_CLOSE is True, > the intention really is to expire the session after that much time and not > as soon as browser is closed. > > Please if you can consider checking it in. If interest is there, I will > attach a patch with documentation, not really sure how to write unittest for > it tho. > > -- > Amit Upadhyay > Vakow! www.vakow.com > +91-9820-295-512 -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
configurable session age
Hi, This is a gentle reminder/ping for http://code.djangoproject.com/ticket/2548by Tsume. Its status is design decision needed, but that is only because of a query by Adrian, about if the requested use case may also want configurable cookie name. mtredinnick replied to this saying it is not possible to do. This feature is a required for "remember me" primarily, and that only requires configurable timeout. I have modified it to work with the scenario when SESSION_EXPIRE_AT_BROWSER_CLOSE is set to True. I assume if someone has set expires to some date in future, and SESSION_EXPIRE_AT_BROWSER_CLOSE is True, the intention really is to expire the session after that much time and not as soon as browser is closed. Please if you can consider checking it in. If interest is there, I will attach a patch with documentation, not really sure how to write unittest for it tho. -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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: image bundle for django
Refer
http://groups.google.com/group/django-users/browse_thread/thread/3e7658074bedb6d8/4d8d3fdc63455ca7?#4d8d3fdc63455ca7for
context.
On 6/13/07, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
>
> On 6/12/07, Rob Hudson <[EMAIL PROTECTED]> wrote:
> >
> > One thought I had to counter that would be to group small images
> > together, then medium sized images, then large images. Depending on
> > how many images your website actually uses, this would need to be
> > tuned, but maybe it would help alleviate the wait. Also, grouping
>
>
> One of the ideas in my mind to extend this proof of concept was "named
> bundles". I was looking at them because of CSS issues, but same can be
> applied to both.
>
> I like the simplicity here, that you do not have to define bundles and use
> them in two separate steps, but what google does, making creation of bundle
> a conscious extra step, a little bit of hassle but more flexible for such
> requirements. Lets say we write a command line script "create_bundle" [lets
> say, part of manager.py if it gets to django proper], that will take a
> bundle name, and a set of images as input and create the bundle. Then in
> template files we can refer to the bundle names in {% img %} tag.
> create_bundle script will have to store the metadata about the names of
> images that have gone in the bundle and their relative order in some other
> place. These are additional complexities to tackle, nothing really
> difficult, a little inconvenient.
>
> We can probably go with both kind of bundles, if {% img %} supplies a
> bundle name, use named bundle, otherwise do what is being done current.
>
> Anyway, it's an interesting idea and nice to see an implementation.
>
>
> On 6/12/07, Justin Lilly <[EMAIL PROTECTED] > wrote:
>
> Also, I'm not sure if this is bug or design, but if you use this method,
> > you can't save the picture without a rather large hassel.
> >
>
> I am not sure I understood your concern here. There are many things wrong,
> its just a prototype, I am assuming the images are /static/something.ext and
> are all saved in the MEDIA_DIRECTORY. Suggestions welcome. [I was thinking
> what if the images are served from a different host, S3?, all those cases
> will cause problems and will have to be thought before it can go beyond
> prototype stage to candidate for contrib].
>
> On 6/13/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>
> > I really like this idea, but my needs are different.
> >
> > I don't need resizing of images in the bundle, and I don't like the
> > idea of loading all the original images in the bundle to determine
> > offsets in the final.
>
>
> Server side resizing was compulsory as otherwise the background technique
> would not work. AFAIK. Browser will just show the part of image, and does
> not shrink the background to fit.
>
> I see you're using mx.Misc.OrderedMapping. Does that do anything that
> > django.utils.datastructures.SortedDict doesn't do?
> >
>
> Nothing, I dint knew about it.
>
> --
> Amit Upadhyay
> Vakow! www.vakow.com
> +91-9820-295-512
>
--
Amit Upadhyay
Vakow! www.vakow.com
+91-9820-295-512
--~--~-~--~~~---~--~~
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: image bundle for django
On 6/12/07, Rob Hudson <[EMAIL PROTECTED]> wrote:
>
> One thought I had to counter that would be to group small images
> together, then medium sized images, then large images. Depending on
> how many images your website actually uses, this would need to be
> tuned, but maybe it would help alleviate the wait. Also, grouping
One of the ideas in my mind to extend this proof of concept was "named
bundles". I was looking at them because of CSS issues, but same can be
applied to both.
I like the simplicity here, that you do not have to define bundles and use
them in two separate steps, but what google does, making creation of bundle
a conscious extra step, a little bit of hassle but more flexible for such
requirements. Lets say we write a command line script "create_bundle" [lets
say, part of manager.py if it gets to django proper], that will take a
bundle name, and a set of images as input and create the bundle. Then in
template files we can refer to the bundle names in {% img %} tag.
create_bundle script will have to store the metadata about the names of
images that have gone in the bundle and their relative order in some other
place. These are additional complexities to tackle, nothing really
difficult, a little inconvenient.
We can probably go with both kind of bundles, if {% img %} supplies a bundle
name, use named bundle, otherwise do what is being done current.
Anyway, it's an interesting idea and nice to see an implementation.
On 6/12/07, Justin Lilly <[EMAIL PROTECTED]> wrote:
Also, I'm not sure if this is bug or design, but if you use this method, you
> can't save the picture without a rather large hassel.
>
I am not sure I understood your concern here. There are many things wrong,
its just a prototype, I am assuming the images are /static/something.ext and
are all saved in the MEDIA_DIRECTORY. Suggestions welcome. [I was thinking
what if the images are served from a different host, S3?, all those cases
will cause problems and will have to be thought before it can go beyond
prototype stage to candidate for contrib].
On 6/13/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> I really like this idea, but my needs are different.
>
> I don't need resizing of images in the bundle, and I don't like the
> idea of loading all the original images in the bundle to determine
> offsets in the final.
Server side resizing was compulsory as otherwise the background technique
would not work. AFAIK. Browser will just show the part of image, and does
not shrink the background to fit.
I see you're using mx.Misc.OrderedMapping. Does that do anything that
> django.utils.datastructures.SortedDict doesn't do?
>
Nothing, I dint knew about it.
--
Amit Upadhyay
Vakow! www.vakow.com
+91-9820-295-512
--~--~-~--~~~---~--~~
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: make model.save() take kw params
On 6/13/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > > On Wed, 2007-06-13 at 00:11 +0530, Amit Upadhyay wrote: > > Hi, > > > > Wouldn't it be cool if we can say > > user.save(email="[EMAIL PROTECTED]"), which will do the equivalent > > of user.email = "[EMAIL PROTECTED]"; user.save()? Should be single > > line change, putting a self.__dict__.update(kw) in model.save(). > > Aside from all the other points raised in the reply, there's a > "separation of powers" design principle at work: save() should never > raise validation errors. Validation happens, passes and *then* you can > safely call save(). The save() method might raise database integrity > errors, because we cannot guarantee that some other process entirely > hasn't done something at the db level we don't know about, but that's > all. Points taken. Utility functions like create_or_update() are just that: intentional > combinations of the two and you need to be able to handle both types of > errors, but you know what you are getting in for. In that case how about a update_and_save() method? -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
mailing list forking?
Do other people know about this: http://www.nabble.com/image-bundle-for-django-t3900874.html [I see 4-5 replies to my post on this page] vs http://groups.google.com/group/django-users/msg/4d8d3fdc63455ca7 [here, there is no reply]. -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
make model.save() take kw params
Hi, Wouldn't it be cool if we can say user.save(email="[EMAIL PROTECTED]"), which will do the equivalent of user.email = "[EMAIL PROTECTED]"; user.save()? Should be single line change, putting a self.__dict__.update(kw) in model.save(). -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: GSoC 2007 Status Update: Django REST interface
On 6/1/07, Andreas Stuhlmüller <[EMAIL PROTECTED]> wrote: > > This week, I have started checking in code. I am always happy about > feedback. Add a few lines to your (non-production!) urls.py [1], make > your models available in XML or JSON format and tell me what works for > you and what doesn't. I contributed patch for http://code.djangoproject.com/ticket/547, and tho did not object much when it was closed in favor of http://code.djangoproject.com/ticket/115, but I feel both your approach and #115 are wrong. Django is a web development framework, and not model development. REST (XMLRPC/SOAP) API are created to expose webservices, which by definition could be anything, not just models. CRUD is myopic world view. Have you seen the API's that Flickr/Delicious/FaceBook exposes? *None* of them are (strictly) CRUD related. What should you make easy is making any python function available through REST, and that function can in turn implement CRUD if you want. I am not against CRUD api, but thats a very small, and in my opinion unused subset of what REST etc would be used for. Developers, please relook at 547, and compare it with 115. 547 is closed by jacob saying " This is a subset of #115<http://code.djangoproject.com/ticket/115>." which I feel is not the case, as #115 is "Models CRUD via web services". Related bug: http://code.djangoproject.com/ticket/552 -- Amit Upadhyay Vakow! http://www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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: post_create signal
n 5/31/07, Ben Schwarze <[EMAIL PROTECTED]> wrote: > > > I've reconsidered the post_create signal issue, and can imagine that > the pre_save and post_save signals may be extended. What about a > simple additional attribute that wil be send. This could be fetched in > listener functions (e.g. is_update=True/False)? > > I'm not that sure whether it would be an backwards-incompatible > change, but it wouldn't blow up Django's core signals. And there would > be still a pre and post signal. > > Any ideas about that? How about doing a: self.is_new = not bool(self.id) in pre_save and if self.is_new: # do something in post_save? -- Amit Upadhyay Vakao! +91-9820-295-512 --~--~-~--~~~---~--~~ 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-values -> django-policy?
On 5/29/07, Derek Hoy <[EMAIL PROTECTED]> wrote: > > > Registry? +1 django-registry. -- Amit Upadhyay Vakao! +91-9820-295-512 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Multiple Profiles
I would recommend you take a look at lost-theories.com source code. One anti pattern that django docs seems to recommend is use django.contrib.auth.models.User as your main user model, and put rest of user info in yourapp.accounts.models.UserProfile or something. I propose, django officially recommends it as a bad approach. What we should tell new comers to django is: - create a FooUser in the yourapp.accounts.models, something like this: class FooUser(models.Model): duser = models.ForeignKey(User) # django.contrib.auth.models.User address = models.TextField() _get_username(self): return self.duser.username _get_email(self): return self.duser.email _set_email(self, email): self.duser.email = email self.duser.save() username = property(_get_username) email = property(_get_email, _set_email) - throughout your code base, use a foreign key to yourapp.accounts.models.FooUser instead of django.contrib.auth.models.User - infact for clarity, use variable name fuser whenever referring to FooUser, and duser when referring to django's User instance. - go as far as set wrong value for AUTH_PROFILE_MODULE to catch some code calling get_profile() - set up a middle ware: class FooUserMiddleware(object): def process_request(self, request): if request.user.is_authenticated(): request.fuser = FooUser.objects.get(duser=request.user) else: request.fuser = None => use request.fuser in all your views. - use the context_processor: def context_processor(request): d['fuser'] = request.fuser return d and use fuser in all your templates. You can access both fuser.username/email and fuser.address. This will go a long way making life of a lot of developers easier. You can have as many types of Users as you wont, not having to worry how to hack .get_profile() etc. And it is actually correct. Imagine if I have to have a friendship relationship between users, I can not obviously monkeypath django contrib auth app, so I would put that many to many in UserProfile as per current django recommendation, and user.get_profile().friends.all() sounds wrong. With this you can say fuser.friends.get(). Natural. On 5/8/07, Mi Reflejo <[EMAIL PROTECTED]> wrote: > > Hi, > > I have a project with multiple user types. That means: Multiple profiles. > > Since i don't have one AUTH_PROFILE_MODULE i can't use get_profile(). I > think i could do a intermediate M2M table but i don't want this overload and > i loose user_profile cache (Because in this scenery M2M table is cached but > not profile) > > To solve this issue i wrote a simple patch for contrib/auth/models.py. > [Patch is attached] that add one var to get_profile so you can choose your > profile table dinamically. > > Is there another solution for this? > > Regards, > -- > Martín Conte Mac Donell > http://www.catartico.com > > > > -- Amit Upadhyay Vakao! +91-9820-295-512 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Add a salt to the newforms fields names
On 3/22/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > > On Fri, 2007-03-23 at 06:48 +, Baptiste wrote: > > That feature would be unable by default, and the user could use it > > just for forms which didn't need to be autocompleted, eg. a comment > > form (which can use cookies to remember the user, it is really more > > powerful). > > Autocomplete isn't just designed to work on a single site. One of the I am -1 on this too. But the original poster gave me this idea: would it be useful to have a field which specifically disallows auto-complete. May be an optional argument for CharField? [HTML allows to do a autocomplete=off in input fields]. -- Amit Upadhyay Blog: http://www.rootshell.be/~upadhyay +91-9820-295-512 --~--~-~--~~~---~--~~ 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: feature request: user session
On 3/21/07, Michael Radziej <[EMAIL PROTECTED]> wrote: > > On Wed, Mar 21, Amit Upadhyay wrote: > > > Hi, > > > > Django has anonymous sessions, tracked by cookies. The session can not > be > > accessed from a different machine for the same user > > What do you mean with 'accessed from a different machine'? Another server > (in a load balancer or similar), or another client? Both isn't true. I mean from a different client/browser. > which drastically > > reduces the usefulness of sessions. Another approach to save something > > persistently for a user it to update the UserProfile model and create a > new > > row for the same, but this will require altering the corresponding table > > every time we realize we have one more thing to save. > > I probably simply don't get what you try to do. Can you give an example, > please? I have for example, lots of notifications to users, like show popup for this and show popup for that. The thing is user may not be interested in a lot of these popups [consider firefox's message: you are about to submit a data on unencrypted connection, are you want to proceed?"] and we want to put a checkbox in those dialog's saying "do not show this message again". I want to store this information somewhere, and currently I am doing it in UserProfile model of mine, but as things keep on getting added it becomes more unwieldy. Putting everything in a separate model removes the context of each settings, and makes documentation difficult, while if things are in sessions, only a set of views responsible for the given page on which we are showing the popup, and ajax handlers for it, will have to know about settings related to that page. No need to alter tables. Session is the right place for a lot of these things, (for if not, what is session suitable for?) but the current django session is not persistent, which leads to my this request. -- Amit Upadhyay Blog: http://www.rootshell.be/~upadhyay +91-9820-295-512 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
feature request: user session
Hi, Django has anonymous sessions, tracked by cookies. The session can not be accessed from a different machine for the same user, which drastically reduces the usefulness of sessions. Another approach to save something persistently for a user it to update the UserProfile model and create a new row for the same, but this will require altering the corresponding table every time we realize we have one more thing to save. I have proposed a solution for this, which I am going to code in couple of days, but in the meanwhile I would like to hear your feedback. http://code.djangoproject.com/ticket/3776 [little more info, about how I intend to implement is in the ticket]. -- Amit Upadhyay Blog: http://www.rootshell.be/~upadhyay +91-9820-295-512 --~--~-~--~~~---~--~~ 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: using "dictionary with attribute-style access" for newform
Actually no :-( It will conflict with keys, clear etc members of standard dictionary. May be I will write a MyForm that will do it locally for me, from which I will inherit the rest of my forms. On 3/7/07, Amit Upadhyay <[EMAIL PROTECTED]> wrote: > > Hi, > > I have an enhancement request for new forms, instead of doing > > def save(self): > > Blog.objects.create(title=self.clean_data["title"], description= > > self.clean_data["description"] ) > > > > and > > def __init__(self, blog, *args, **kw): > > super(MyForm, self).__init__(*args, **kw) > > self.fields["title"].initial = blog.title > > > > It would be better to use: > > def save(self): > > Blog.objects.create(title=self.clean_data.title, description= > > self.clean_data.description) > > > > and > > def __init__(self, blog, *args, **kw): > > super(MyForm, self).__init__(*args, **kw) > > self.fields.title.initial = blog.title > > > > Its easier on eyes as well as fingers. > > Please! I love you, I beg you! :-) > > -- > Amit Upadhyay > +91-9820-295-512 -- Amit Upadhyay Blog: http://www.rootshell.be/~upadhyay +91-9820-295-512 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
using "dictionary with attribute-style access" for newform
Hi, I have an enhancement request for new forms, instead of doing def save(self): > Blog.objects.create(title=self.clean_data["title"], description= > self.clean_data["description"]) > and def __init__(self, blog, *args, **kw): > super(MyForm, self).__init__(*args, **kw) > self.fields["title"].initial = blog.title > It would be better to use: def save(self): > Blog.objects.create(title=self.clean_data.title, description= > self.clean_data.description) > and def __init__(self, blog, *args, **kw): > super(MyForm, self).__init__(*args, **kw) > self.fields.title.initial = blog.title > Its easier on eyes as well as fingers. Please! I love you, I beg you! :-) -- Amit Upadhyay +91-9820-295-512 --~--~-~--~~~---~--~~ 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: Question about UserProfile
On 3/5/07, limodou <[EMAIL PROTECTED]> wrote: > > So I indeed see the cache process in django/contrib/auth/models.py, > and I have a question that, how to update the cache after I changed > UserProfile information? I can see any clue about it, if the cache > cann't be updated, this will make the information is out of sync. Or > if I can disable this cache process in User Model? This is not the right list for this question, django-users is better place. In cases where you have to update profile and use it later on in the same view, consider doing something like this: >>> profile = user.get_profile() >>> profile.email_confirmed = True # or whatever you wanted to do >>> profile.save() And use the profile object now onwards in the view. get_profile is only a convenient shortcut. -- Amit Upadhyay Blog: http://www.rootshell.be/~upadhyay +91-9820-295-512 --~--~-~--~~~---~--~~ 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: newforms: "forms with prefixes", nitpick
On 1/31/07, Honza Král <[EMAIL PROTECTED]> wrote: > > what if I have one Form class and want to use it twice in one > view/template/ tag ? > in that case, prefixes are my only hope... ;) Prefixes are good idea, but implementation is a bit more generic than need to. As of now either prefix will be *added* before the id or you have to override a method for allowing other formatting, python's string formatting is not used in prefix. Should be. -- Amit Upadhyay Blog: http://www.rootshell.be/~upadhyay +91-9820-295-512 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
newforms: "forms with prefixes", nitpick
Am a latecomer to newforms, loving it. I have minor issue with the way prefixes are handled: http://code.djangoproject.com/browser/django/trunk/tests/regressiontests/forms/tests.py#L2648 The prefix is prepended to the form names, which leads to some shortcomings, so add_prefix was created: http://code.djangoproject.com/browser/django/trunk/tests/regressiontests/forms/tests.py#L2733 -1 Can we simple not take prefix to contain a formatting string? That is what came to my mind when I read prefix when I first encountered it. Is there something I am missing? -- Amit Upadhyay Blog: http://www.rootshell.be/~upadhyay +91-9820-295-512 --~--~-~--~~~---~--~~ 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: Ideas for /examples/ directory
On 4/17/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: One quick constraint: None of the examples should require a database.Asking people to install database tables just to view examples isn'tacceptable, IMO.How about shipping a prepopulated sqlite db? To avoid dependency I recommend splitting the distribution in django, and django-dev? django, bare minimum for deployment, django-dev with examples and whatnot? -- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay+91-9867-359-701 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Validation-aware models: First stab
On 3/14/06, James Bennett <[EMAIL PROTECTED]> wrote: * It's conceptually simpler; instead of worrying about whichvalidation layer you got down to before an error occurred, you onlyhave to worry about two states: success and failure.* It's more logical; I still don't see any good reason why information about how to validate an instance of a model shouldn't be part of themodel.This is based on a simplistic assumption that everytime we are talking about validation in django context we are talking about model based validation. views are handling forms, and we should always add form in front of validation whenever we are talking about validation. Model can have a simplistic type checking like validation, which will raise ValidationError while saving, but trying to fit all/any form validation into model validation is just twisted. Django is a web framework. In web apps, the most common thing to validate is form. We can not ignore these two things. Bottom line, can you gaurantee all validations can go on model? Will you make model dependent on request, and any other potentially django external check a web developer might have to use in their application? We can not do validation in models, we can try, we can do a little bit, but there is no limit to what application specific requirement can ask. What is the point of making people learn about the model based validation framework when we are going to tell them that not all validation can be done, and you will have to invent your own validation framework? -- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay+91-9867-359-701 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
proposal: endif, endfor etc assume whatever follows in tag is comment
Hi,It regularly becomes difficult to track which {% endif %} belong to which {% if %}, it would be good if we can say {% endif start_process %} where start_process is purely comment. -- Amit Upadhyay
Blog: http://www.rootshell.be/~upadhyay+91-9867-359-701
--~--~-~--~~~---~--~~
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 -~--~~~~--~~--~--~---
Re: Validation-aware models: First stab
HI Adrian,Does it mean AddManipulator/UpdateManipulator are going away?This way of doing things is inconsitant with handling custom forms. If it is, a good step for django ORM, a bad step for django web framework.
Let me elaborate, this is my typical view:def confirm_email(request): if not request.user.is_anonymous(): return HttpResponseRedirect('../home/')
manipulator = EmailConfirmationManipulator(request) if request.POST: # If data was POSTed new_data = request.POST.copy() # Check for errors. errors = manipulator.get_validation_errors
(new_data) if not errors: # No errors. This means we can save the data! manipulator.do_html2python(new_data) manipulator.save(new_data) return HttpResponseRedirect("../home/")
else: errors = new_data = {} form = formfields.FormWrapper(manipulator, new_data, errors) return render_to_response('blogger/confirm_email', {'form': form},
context_instance=DjangoContext(request))Line in red used to be the only line which would depend on if I am using a django AddManipulator or my custom form. This perticular view initially was using AddManipulator with an extra validator, then I realised I needed a few more fields in the form, and I had to write my custom form, I derived it from the AddManipulator, added a few fields, overwrote .save() and nothing else changed. Virtues of object oriented programming.
Please let me know if I am missing something.-- A Sad DjangonautOn 3/13/06, Adrian Holovaty <
[EMAIL PROTECTED]> wrote:Just got back from a week-long Hawaii vacation, so I'm getting back
into the Django groove. Earlier today I committed the first stab atvalidation-aware models on the magic-removal branch:http://code.djangoproject.com/changeset/2518
Here's how it works:* Model instances have a validate() method. It returns a dictionary offield name -> list of error messages. If there are no errors, itreturns an empty dictionary.
* Behind the scenes, validate() actually does a two-pass validationover all the model instance's fields:* First, it runs the field's to_python() method, which isfield-type-specific and converts the data to the appropriate Python
type. For example, if a date field is set to '2005-01-03', to_python()converts it to a datetime object.* Second, for all fields that didn't have validation errors into_python(), it executes the field's validate_full() method. That
method can safely assume the data is in the correct data type.The separation of "type-specific" validation and "logical" validationmakes things a lot cleaner, both in concept and implementation. It's
sort of like the CriticalValidationError framework indjango/core/formfields.py in trunk.* Model instances' save() method will call validate() behind thescenes, and the object won't save if there are any validation errors.
I haven't coded this part yet, but it's a simple change.* I've only implemented to_python() and validate_full() for a handfulof field types in django/db/models/fields/__init__.py. The rest stillneed to be implemented.
* Every one of the to_python() and validate_full() functions that*are* implemented (to my knowledge) have unit tests intests/modeltests/validation/models.py. As we implement to_python() andvalidate_full() for other field types, they should get unit tests
immediately.EXAMPLE CODE:class Person(models.Model):name = models.CharField(maxlength=50)birthday = models.DateField()favorite_number = models.IntegerField()>>> p = Person(name='Joe', birthday='never', favorite_number='foo')
>>> p.validate(){'birthday': 'Enter a valid date in -MM-DD format.','favorite_number': 'This value must be an integer.'}>>> p = Person(name='Joe', birthday='2005-1-3', favorite_number='34')
>>> p.validate(){}>>> p.birthdaydatetime.date(2005, 1, 3)>>> p.favorite_number # note this is an integer now, no longer a string34Thoughts, criticisms? The only part I'm sketchy on is the side effect
of converting the values to their Python data types. Thecleanliness/consistency is quite nice, but it's slightly not somethinga developer might expect. However, we can solve the latter throughclear documentation.
-- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay+91-9867-359-701
--~--~-~--~~~---~--~~
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 -~--~~~~--~~--~--~---
Re: [Changeset] r2386 - django/branches/magic-removal/django/core
On 2/25/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: # generated settings file contains INSTALLED_APPS with the basics,# such as sessions, auth, etc.. Advanced users can remove any or all of that# if they don't want to use it.python foo/manage.py synchdb # creates tables for all INSTALLED_APPS # When you write some new models, just run "manage.py synchdb" again# to make sure things are in sync. This can later be expanded to include# ALTER TABLE statements.Thoughts? How about making manage.py work at myapp.mymodel level? -- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay+91-9867-359-701 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: Validation-aware models
On 2/22/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: prep_data would take the request, and return a dict suitable to passto the objects constructor. FWIW I think prep_data is a bad namethough. Other suggestions?Maybe something like this:new_data = MyModel.prep_data (request)my_obj = MyModel(new_data)ornew_data = prep_data(MyModel, request)my_obj = MyModel(new_data)Would you also post the snippet you think should be used when validating data for custom forms. -- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay+91-9867-359-701 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: Validation-aware models
On 2/22/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: Let's return to this subject, which was discussed a couple of weeksago. Here's my latest thinking on the subject.* Automatic manipulators go away. Instead of messing with those, tocreate a new model object you try instantiating it. Validation errors are raised at that point. Example:try:c = Crime(crime_date='2006-1-2', crime_type='theft')except ValidationError:print "You have errors."I dont like this because then form handling view code start to depend on if we are trying to create/modify a model or we have created custom forms. Very artificial. With the current code, I can add a few extra fields in the manipulator returned by AddManipulator()/UpdateManipulator(), or add extra validation function in the view code, which are specific to that view, I do not know how would it be done. -1* This plan is nice conceptually because it doesn't leave any chanceof bad data in any model instance. Currently, Django is "dumb" aboutdata in model instances -- it allows any arbitrary data there, and catching bad data is completely the responsibility of the developer.This can lead to some IntegrityErrors at the database level (searchthe django-users mailing list archives for examples) when thedeveloper forgets to validate. IntegrityError is still not ruled out by validation, unless you do things like checking database for uniqueness, and doing it at every setattr is not optimal. It would be best if we just tell users in big bold letters that doing object.save() can lead to integrity error, and you must catch them and do something about them, instead of giving them a false perception that they can do object.save() safely. Developer must pass form data through AddManipulator/UpdateManipulator.get_validation_error(object.__dict__.copy().update(CHANGES)), this is not too much to ask, you have to do it anyways for other forms. -- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay+91-9867-359-701 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: still some magic left in magic removal
On 2/4/06, Robert Wittams <[EMAIL PROTECTED]> wrote:
...Horrible api example deleted...Lets see. > Cramming everything in a class will always force us to do some meta
> programming.This has no meaning as far as I can tell. Are you seriously suggestingthat we shouldn't even use metaclasses? Well I am not saying we shoud never use metaclasses, but putting the models in seperate modules has many benefits.
the module name is in not capitalized, class name is, and i am free to pick up the module name which might be different than class name. people.all() returns a list of People. people.filter(name='asd') looks better than
Person.filter(name='asd')it leaves us the option of having a single file containing all admin information for example, and not wading through a monolithic huge single model file containg all 20 of my models, or going through 20 files if i have split them.
it leaves us the option of having a GuiAdmin without another round of modifications in the django core for adding yet another GuiAdmin inner class. admin then becomes a really normal app.things like module constants are back:
people.DEFAULT_HEIGHT, ofcourse you can modify Meta to allow such, but this is much cleaner in modules.with modules, django can recommend unittesting in "if __name__ == '__main__'"
>Devoting a module and spreading things give better flexibility.The sole purpose of the module in your example seems to be your
particular naming pecadillos. No, the sole purpose is to allow a model to be extensible from other places [eg Admin related settings defined in single file.] [making GUIAdmin possible as a just another app]
All the module does in your case isprovide a namespace -
this is a nice side effect. we already have one of those, the class.
Duplicating namespaces is not really a worthwhile pursuit.we do not have one namespace, we have three: model class, Admin and Meta.
Your method seems to force a lot of boiler plate crap everywhere, and afile for every class.
it is a lot of boilerplate if you want a lot of functionality as i demonstrated. for simpler cases it is not so: #from django.db
import modelsfrom django.contrib.admin import Adminclass Person(models.Model):first_name = models.CharField(maxlength=30)
last_name = models.CharField(maxlength=30)all = models.Manager(Person)Admin(all).register("People")#
vs#from django.db
import modelsfrom django.contrib.admin import Admin
class Person(models.Model):first_name = models.CharField(maxlength=30)
last_name = models.CharField(maxlength=30) class Admin: pass#So yes, if your application was three model large, you will find the current approach simpler, just one file, while I forcing three files. But this is a case when things start to become difficult as the project matures. After 5-10 you will start thinking of splitting the models across files, group them in saner fashion, assuming models are non trivial.
a) sane defaults with minimal boiler plate. In reality, "most" users are
never going to touch this multiple managers stuff, and they are notgoing to have fields called objects.Agreed, but by saying so we are ruling out module constants, or another Admin interface for now, which most users might benefit from.
(I also don't really buy the idea of different managers for storingthings in RDF and LDAP - if that is ever going to happen, it should be a
seperate concern : your class definition should not be bound to onestorage model. Think redistributable apps. )I see managers as purely backend providers. Whatever else you want you can do with your own functions.
def tall_people(): global all return all.filter(height > TALL_PERSON_HEIGHT)
b) possibility of customisation in the cases it is needed.But only by modifying the class. What if I want to write a configure admin UI? I can not write such an application right now, where as if admin was just a set of normal Admin objects, I could write GUI to discover models in the app, store a everything in a single file, [they are just a set of objects anyways in my proposal].
So I give this a big fat -1.I hope you would reconsider. :-)
-- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay+91-9867-359-701
still some magic left in magic removal
Hi,I was going through magic removal wiki page, and encountered this, I think there is still some magic left in the Custom managers, and multiple managers section. I have a following objections:
finding the default manager based on the order in which they are definedmanager instance magically contains self.model
I have the following suggestion: Put each model in a seperate module [in the myproject.myapp.models directory]. people.py###from django.db
import modelsclass PersonDoesNotExist(Exception): passclass RDFPersonDoesNotExist(PersonDoesNotExist): passclass Person(models.Model):first_name = models.CharField(maxlength=30)
last_name = models.CharField(maxlength=30)class PersonManager(models.Manager): def get_fun_person(self):try:return self.get(fun=True)except self.model.DoesNotExist
:print "Doesn't exist."class RDFPersonManager(models.Manager): pass # for futureclass LDAPPersonManager(models.Manager): passfrom django.settings import DATABASE_PROFILE2, LDAP_PROFILE
all = models.Manager(Person) # uses default django.settings.DATABASE_PROFILE # raises ObjectDoesNotExist fun_people = PersonManager(Person, settings = DATABASE2, exception = PersonDoesNotExist)
ladp_people = LDAPPersonManager(Person, settings = LDAP_PROFILE)rdf_people = RDFPersonManager(Person, exception=RDFPersonDoesNotExist)from django.contrib.admin import Adminadmin_db_people = Admin(all)
admin_db_people.list_display = ('first_name', 'last_name')
admin_db_people.register('People in Database') # no need for Admin classadmin_fun_people = Admin(fun_people)admin_fun_people.register('Tall People in Database)
admin_ldap_people = Admin(ldap_people)admin_ldap_people.register('LDAP Users')api usage:from myproject.myapp.models import people
p = people.Person(first_name='amit', last_name='upadhyay')p.save() # no default, raises ValueError: no manager specifiedp.save(manager=people.tall_people) # or people.all.save(p)try: p_rdf = people.ldap_people.get
(first_name='amit')except people.RDFPersonDoesNotExist: passelse: p_rdf.first_name = 'Amit' p_rdf.save() # person remembers where they came fromeveryone = people.all() # all is a manager, which is callable
upadhyays = people.all.filter(last_name__iexact = 'upadhyay')Cramming everything in a class will always force us to do some meta programming. Devoting a module and spreading things give better flexibility.
-- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay+91-9867-359-701
GvR prefers Django Template over Cheetah And Modularised Django
Hi all,One of the first thought that came to my mind when I read django documentation is, Django is really a set of related projects, Django ORM, Django Templates and Django Webframework, and can be used independently of each other. Came across this post by Guido: http://www.artima.com/weblogs/viewpost.jsp?thread=146606 where he likes Django Templates, but is bothered, a bit, by DJANGO_SETTINGS_MODULE thing. Won't it be cool if django splits the tree into different reusable packages, developed and maintained by you folks only. One can say there are almost independent, but it requires lots of familiarity in django to understand this, an outsider may not get this idea initially. [and this also required a little API to initialize Django Templates or Django ORM]. Imagine Django Template and Django ORM becoming Python 2.5 standard modules! Once people start using one component they may realize how good django really is, as GvR has, and maybe we will get close to a standard python web framework.Regards, -- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay+91-9867-359-701
Re: Implementation of descriptor fields
On 1/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Presumably this needs the same behaviour as a Manager i.e. doesn'tcache. So the the filter method needs to return a non-caching
QuerySet. To get a caching version, you would have to do .all(), soyou would have to do this everytime you actually wanted to get data:Article.objects.all().filter(blah..)Have not been following the discussion very closely, but why not have a parameter use_cache (defaulting to True) in the get_list and making it completely explicit. Sometimes I like the conveniece of not storing something in a variable, like from within a template, and calling the get_list [or get_set or whatever it is called in this branch] multiple times ( {% if
object.get_related_list %} {% for related_item in object.get_related_list %} # do something ... ) while at other times I need the accurate current list. -- Amit UpadhyayBlog:
http://www.rootshell.be/~upadhyay+91-9867-359-701
model level install and sqlreset
Hi,Off late I have found that my models are stable, but I have to keep on adding new ones. It would be good if django-admin.py had support for model level install option. "django-admin.py install myapp.mymodel "? Also it would be nice if we can have atleast model level sqlreset in case model changes, if the number of objects on the model is zero, django-admin.py can go on and recreate the tables for me. -- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay+91-9867-359-701
not getting date time javascript pickers
Hi,I am using trunk: 2116, and in the admin view, I am not getting the _javascript_ date and time pickers. Everything else seems to be working fine, is this normal?TIA,-- Amit Upadhyay Blog: http://www.rootshell.be/~upadhyay+91-9867-359-701
Re: how to set title/description for items in rss
On 1/27/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: I answered your question in another thread:http://groups.google.com/group/django-users/browse_thread/thread/0a7b94b58722470b/d378ce32a02d53ba Thanks a lot Adrian.-- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay+91-9867-359-701
how to set title/description for items in rss
Hi,I am trying to generate RSS feeds using Django, and followed the documentation, but am not able to figure out how to specify title and description for individual items. Right now Django is using the string representation of item objects. My feeds are "complex feed" as per documentation, I tried supplying a item_title, item_description methods similer to item_link, but it seems they are not getting called. Am I missing something obvious? Please help! -- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay+91-9867-359-701
Re: SQL Referential Integrity (WAS: Bulk delete? on django-users)
On 1/21/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: Yes, this means that people with MySQL 3/4 databases will need toupgrade or choose another database. But why should we spend so muchtime and effort writing, testing, and debugging a reimplementation ofreferential integrity in Django simply to support those who come to Django asking "Hey, I've got this nail; how do I use this bratwurst asa hammer?". Django is a complex enough without complicating theproblem by reimplementing half the features of a database to support those in the community that can't/won't upgrade.Hi, I appreciate your work but if it works by break it? I am thinking a good percentage of users will be using shared hosting etc to deploy their application, and they have very little control over the version of SQL server. [ object.delete() for object in get_list()] works, if its too slow, use custom sql [work on making it easy if it is not]. Delete is an edge case anyways.-- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay+91-9867-359-701
Re: SQL Referential Integrity (WAS: Bulk delete? on django-users)
On 1/19/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: On 1/19/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:>> On 1/19/06, Russell Keith-Magee <[EMAIL PROTECTED] > wrote:> > It seems like most of the internal reference walking logic in the> > object.delete() call would be eliminated if the foreign key fields> > were declared ON DELETE CASCADE or ON DELETE SET NULL (as > > appropriate).>> This is exactly what Django used to do, actually, back when it was> Postgres-only. Such are the compromises of having to support other> DBs. :-/Hrrm... /me breaks into verse of "get a real database"... :-) It just seems a waste to give up all the useful, efficientcharacteristics of a database like PostgreSQL for the sake ofsupporting less featured databases. Any in-code implementation ofsomething like referential integrity will always be slower and more bug-prone. Writing an application that avoids using referentialintegrity in order to maintain compatibility with less featureddatabases seems like asking for trouble, either when a bug in thereferential integrity code bites us, or when the server load becomes an issue.What would happen to _pre_delete and _post_delete? If I have "real database", and I after profiling I found a few bulk_delete too ineffecient for my application, what is stopping me from taking the database cursor, and executing the sql myself? -- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay+91-9867-359-701
Re: apps with the same name
On 1/14/06, Max Battcher <[EMAIL PROTECTED]> wrote: Joseph Kocherhans wrote:> Any ideas that don't involve 50+ character table names and 10 level> deep template directories? ;-)What about application relabeling? Just like you might do a python ``import something as somebettername`` when there are conflicts acrossnamespaces or you just want something nicer in your actual code, youcould just add an "as" option to INSTALLED_APPS to specify an app name. Very cool idea. This can solve the problem of table names and keeps admin urls simpler. But templates is still something you have to worry about, and one solution is to keep a module name based structure in template directory, but a better solution could be to make template system aware of the current app, let it query django to find the "as" name name, and use that as a prefix to all template paths. And ofcourse django-admin.py may contain a "rename app" command, just in case you later changed your mind about their name which renames all the tables in the database, as well as all the matching subfolders in all template directories. -- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay+91-9867-359-701
Re: Failing silently, and documentation thereof
On 1/12/06, Simon Willison <[EMAIL PROTECTED]> wrote: On 12 Jan 2006, at 06:59, James Bennett wrote:> The Django docs say that template filters should always fail silently> and never raise exceptions; they should instead return either the> original input or an empty string, as appropriate. And when writing > template tags, the tag's render() method should fail silently as well.We really need an official Django logging framework so stuff likethis can be logged (rather than the current email-to-adminsworkaround which doesn't scale to large deployments). +1I have been thinking about it myself too, tho logging can be done using logging module, or a special django application, used by other applications for explicit logging, but django.logging could provide an admin view showing apache like access log as well as other django specific logs. -- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay+91-9867-359-701
Re: Proposal: Shorter comment tag
On 1/12/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
Crap. Lets try this again without tabbing onto the send button.
On 1/12/06, Adrian Holovaty <
[EMAIL PROTECTED]> wrote:
On 1/11/06, scum <[EMAIL PROTECTED]> wrote:> Could the comment tag be simplified to something like {! !} or {# #}.
We've already got two different types of tags -- {% %} and {{ }} --
and introducing a third would be too complex for my tastes.Not wanting to disagree with the glorious leader :-), but I have to say I like the idea. First off; comments should always be encouraged, and the easiest way to make
something+1 to that.I just did a project in django and the templates were managed by a designer and he would make many mistakes, like not copying {% if %} {% endif %} around {{ variable }} when moving the variable around. Also its not very clear when modifying templates what all variables are available, and I had to regularly go back to view code to reconfirm the variable names etc. Comments are extreamly helpful, and any work to make them easy or encourage them is well worth it, and making a special {! !} would make it all the more obvious in the documentation, after all the first thing we read about templates is the template tags.
Another request: if debug is on, and if the url contains ?dumpTemplateContext, and client IP in settings.trusted_hosts [and blah blah blah depending on how paranoid you are], render_to_response, and family, ignores the actual template, and instead dumpts the context variable passed, and detailed instuctions about their type, and some comment on how to loop if the variable is list like and so on. This is meant to be used by the designers who would be creating template, so it can contain a link to tutorial, or dump the tutorial and faq and everything, anything to make the job of designer easier.
-- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay+91-9867-359-701
Re: Proposal: Django namespace simplification
On 1/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: On 1/7/06, kmh <[EMAIL PROTECTED]> wrote:> django.core.exceptions -> django.error+1We have a lot of django.http , django.shortcuts, django.form, django.contrib: single depth names, so we should allow this too, though I prefer django.exceptions over django.error[should be django.errors]. -- Amit Upadhyay Blog: http://www.rootshell.be/~upadhyay+91-9867-359-701
IntegrityError, how to catch it?
Hi,What is the rigth way of catching IntegrityError, the traceback I get suggests using _mysql_exceptions.IntegrityError, which is wrong because it assumes mysql, as well as it goes against the general python guideline of not using "hidden" members of modules. Here is my traceback:>>> u = users.User(id=None, username=' [EMAIL PROTECTED]', email='[EMAIL PROTECTED]')>>> u.save()>>> u2 = users.User(id=None, username='[EMAIL PROTECTED] ', email='[EMAIL PROTECTED]')>>> u2.save()Traceback (most recent call last): File "", line 1, in ? File "/home/l2g/amitu/DownloadServer/django_src/django/utils/functional.py", line 3, in _curried return args[0](*(args[1:]+moreargs), **dict(kwargs.items() + morekwargs.items())) File "/home/l2g/amitu/DownloadServer/django_src/django/core/meta/__init__.py", line 1026, in method_save ','.join(placeholders)), db_values) File "/home/l2g/amitu/DownloadServer/django_src/django/core/db/base.py", line 10, in execute result = self.cursor.execute(sql, params) File "/home/l2g/amitu/DownloadServer/django_src/django/core/db/backends/mysql.py", line 32, in execute return self.cursor.execute(sql, params) File "/usr/lib64/python2.4/site-packages/MySQLdb/cursors.py", line 137, in execute self.errorhandler(self, exc, value) File "/usr/lib64/python2.4/site-packages/MySQLdb/connections.py", line 33, in defaulterrorhandler raise errorclass, errorvalue_mysql_exceptions.IntegrityError: (1062, "Duplicate entry '[EMAIL PROTECTED]' for key 2")>>> We should have IntegrityError and other Database error in django.common.errors or django.core.db or something, and different backends should catch database specific ones and throw these, if we are not doing it already. Thanks,-- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay+91-9867-359-701
Re: admin reports wrong absolute url
On 1/6/06, Ian Holsman <[EMAIL PROTECTED]> wrote: Hi Amit.if you modify the 'domain' column in the 'site' table and put hostname:port#it should work ok.Hi Ian,Thanks, I played with the admin, and figured out this thing myself soon after I posted that mail. Is this documented somewhere? Thanks for all the help guys, django is living upto its claim for being the framework for people with deadline in my experience. :-)-- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay+91-9867-359-701
Re: admin reports wrong absolute url
On 1/5/06, Jason Davies <[EMAIL PROTECTED]> wrote:
Amit Upadhyay wrote:[snip]> But when I open the objects "change" page in admin, and try to follow "View> on Site" link, it takes me to some
http://localhost:6680/r/10/1/, which> 404s.You need to add the following to your urlconf:(r'^r/', include('django.conf.urls.shortcut')),Hi Jason,Thanks, this works, could not find this in the documentation for the models.
But this leads me a to a different problem: it is redirecting me to the absolute url including the hostname and and all, I am developing things using runserver, and using port forwarding to access the runserver port on remote server, and can not deploy it in the intended location unless I have done development as the Apache instance I am going to use is serving some other application already and I can not mess with it much. What is the logic behind this redirect? Why can't admin use the URL that get_absolute_url returns directly? Is there any easy way to disable this?
-- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay+91-9867-359-701
Re: subdomain specific settings file
On 1/3/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > What do you think?I'm not sure I get it -- you want to automatically load a settingsfile based on the subdomain? That seems a little too magic for me,especially when you can already do this just by changing DJANGO_SETTINGS_MODULE for each domain...Nopes, I don't want it to magically discover it, I am just recommending splitting the settings.py generated by django-admin.py into common_settings.py and wwwexamplecom_settings.py or something, latter keeping only subdoman/domain specific ROOT_URLCONF setting. People new to django are already quite confused, and running different instances of django with slightly modified settings.py does not apprear to be comepletely safe, this will tell them exactly what to do if they want to split their application in different subdomains/domains. There is already a SITE_ID which is quite confusing. -- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay+91-9867-359-701
subdomain specific settings file
Hi,Wish you all a very happy and fruitful new year!Djando URL resolution causes some problem with applications hosted in different subdomains. Consider www.example.com and blog.example.com. Both of them are running off the same database and share common admin, and so on, but are hosted in different subdomain, which causes problem with URL resolution. To solve this we can copy the settings file and change ROOT_URLCONF to point to different locations. I propose splitting settings.py into common_settings.py and www_settings.py. www_settings.py contains something equivalent to:from common_settings import *ROOT_URLCONF = 'examplecom.www_urls'This makes clear on what to do incase there are different subdomains, we can just add other subdomains specific setting files blog_settings.py and so on, which point to different ROOT_URLCONF and so on [we can overwrite other things too if required]. What do you think?-- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay+91-9867-359-701
Re: Descriptors for fields?
On 12/14/05, Robert Wittams <[EMAIL PROTECTED]> wrote: >>> How about _list. They are python lists anyway so that would help> too.>Did you even read my post? They aren't lists. They are possibly orderedsets. To be a list, it would need to always have a meaningful order, and it would also need to be able to have duplicates. This is not possiblein a relational system. Also list syntax is pretty rubbish for this,.append() seems a lot wierder than .add(), and it will act totallydifferently depending on the natural or supplied ordering of the set. This is not list semantics at all, so we shouldn't pretend it is.Actually I din't read the whole post, ignore my second sentence. We already have set_ for setting, and _set would be confusing if we use it for just getting the "set" as someone pointed out, so _list even if not totally accurate for the reasons you said. PS: As of .append() sounding much wierder than .add(), I am not so sure, if we can with a little sacrifice in taste make it more like something a user may be already familier with it would help mure than hurt. So the only thing that makes it non list is lack of duplicates? dict.keys() return a list even tho they are non duplicates. PPS: I have not properly followed the thread, nor am actually working like you, so please don't mind my mail if you don't like something I said. -- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay+91-9867-359-701
Re: Descriptors for fields?
On 12/14/05, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote:
On 12/14/05, Robert Wittams <[EMAIL PROTECTED]> wrote:[ p1.article_set.order_by('headline') ]> Is your confusion between set the verb and set the noun ? I don't really
> know how to fix that without refactoring the English language. I don't> know what else could be done here - pluralisation is a no no, etc etc.> If you can come up with a better automatic name than _set, let
> me know.How about _list. They are python lists anyway so that would help too.-- Amit UpadhyayBlog:
http://www.rootshell.be/~upadhyay+91-9867-359-701
HttpResponseRedirect and relative URLs
Hi,I am developing an application and am soon going to deploy on another server but the URLs won't be exactly the same. There are many places I have to construct URLs, for linking to other pages in my application as well as for redirecting, and it is not clear to me how to do it in a portable fashion. One solution is to put a setting in settings.py, but is there another more standard way to specify what relative location my application will be deployed? I use 'include' and put my urls in my apps urls.py, and documentation says: At any point, your urlpatterns can "include" other URLconf modules. This essentially "roots" a set of URLs below other ones.If I could get this "root", it would be much more DRY than to define the 'root' and use another setting. Run the 'root' through s/\^/\// before using it. More concrete proposal:Request contains a member: request.root, this contains urlregex encountered when an include was called; after a match has been found. This poses a problem of what to do if more than one includes are called as I believe its technically possible, and one solution might be either to make request.roots a list of strings, or django itself passes them through s/\^/\// and concatenates them together, which can directly be used by views to generate absolute URLs. -- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay+91-9867-359-701
Re: Removing the magic
On 12/7/05, Simon Willison <[EMAIL PROTECTED]> wrote:
On 6 Dec 2005, at 21:00, Adrian Holovaty wrote:> Thoughts?>> http://code.djangoproject.com/wiki/RemovingTheMagicI really like almost all of it. My one hang-up is this:
Person.objects.get_list(Person.q.first_name == 'Adrian')I like the Person.objects bit, but I'm not so keen onPerson.q.first_name - it's pretty verbose.+1 on the proposal but for the bit you mentioned. My head is turning inside out trying to make sense of
Person.objects.get_list(Person.q.first_name == 'Adrian'): Person.q.first_name == 'Adrian' is an _expression_ and should return True or False, so I am thinking == is a typo and you meant =, in which case you are trying to use keyword argumet, but how? What is type(
Perso.q.first_name)? >>> def f(a):... print a...>>> k = 'a'>>> f(k=10)Traceback (most recent call last): File "", line 1, in ?
TypeError: f() got an unexpected keyword argument 'k' Am I missing something obvious? Please elaborate someone. People
.get_list(first_name__exact='Adrian'
) sounds better to me.How about supporting an SQL where clause, as seen in Rails?
Person.objects.get_where('first_name = %s and last_name = %s','Adrian', 'Holovaty')Not exactly the same but
http://www.djangoproject.com/documentation/db_api/#where-tables talks about something that is very similer.-- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay
+91-9867-359-701
Re: Cache and GET parameters
On 12/6/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote: The remaining question is: What's the behavior if vary_on_get() isn'tspecified for a particular view? Do we cache everything (includingseparate cache entries for any combination of different GETparameters) or cache nothing (current behavior)? Quoting your original post:I have a couple of ideas for solutions. The first is to introduce aNO_GET_PARAMS setting, which would default to False. If it's set toTrue, Django would assume that *all* GET parameters (query strings), sitewide, contain meaningless information, and therefore would notaccount for them in creating cache. For example, a request to example.com/foo/?bar=baz would use the same cache as example.com/foo/.We might even be able to reuse this setting for other things; I'm not sure what, yet.Sounds fine to me.-- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay+91-9867-359-701
Re: save/delete/etc hooks for custom fields
On 12/1/05, Robert Wittams <[EMAIL PROTECTED]> wrote: Nebojša Đorđević - nesh wrote:>> IMHO some type of event system should definitely go in 1.0. Can we add> this to VersionOneFeatures?I wouldn't mind personally, but I think that at some point we have to draw a moratorium on 1.0 features - and that point has passed. 1.0 willnot be the end of development, far from it ;-)I am confused as to what really do you mean by event system? -- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay+91-9867-359-701
Re: Random Tag
On 11/29/05, Tom Tobin <[EMAIL PROTECTED]> wrote:
I'd be interested in feedback on ticket #919, which implements a"random" tag which parallels the functionality of the random filter.I'd also be curious as to where the best place would be to implement a
possible helper class for the weighted random option, as I wasconsidering making the weighted functionality available to the randomfilter as well.What is the use case of this tag? This looks like logic, template in philosophy dictates the layout of the data generated in the views. Putting weights for example, is it not more of a logic than presentation?
One common reason not to include such features which may not be used too much, is code bloat: more things to fix and maintain, every change in template system will have to be migrated to the 100 or so lines of code that you are adding.
+To specify optional weights for the items, include comma-separated integers+in the `random` tag, one for each item in order, like so::++{% random 4,1 %}+You will see me four times more often than the other option.
+{% or %}+You will see me only one-fifth of the time.+{% endrandom %}Putting weights in blocks may be better than clubbing them together? +To specify optional weights for the items, include w = weight
+in all random "blocks", like so::++{% random w = 4 %}+You will see me four times more often than the other option.+{% or w = 3 %}+You will see me only one-fifth of the time.
+{% endrandom %}++if w = weight parameter is not given, default weight equal to one will be +assumed.You don't have to worry about the syncing order and number of weights listed in top random block with the blocks specified.
Looking at the patches listed on tracker I cant stop being amazed about how clean most of them look. Kudos the elegant design of django.-- Amit UpadhyayBlog:
http://www.rootshell.be/~upadhyay+91-9867-359-701
Re: <% include %> should support select_template like sytax too
On 11/28/05, Tom Tobin <[EMAIL PROTECTED]> wrote: On 11/28/05, Amit Upadhyay <[EMAIL PROTECTED]> wrote:> Just that I felt dropping a mail on the list gives a little more visibility> and opportunity to get feedbacks, than just filing a ticket, which only a > handful of core-thus-busy developers monitor.Hmm, I actually have the opposite impression (albeit which may beentirely wrong); I think the Trac actually has very high visibility --being that it's prominently linked/featured on the project website -- and is closely monitored by many of the developers and users (based onmy observations from IRC, etc).If anyone wants to correct me here, please do. :-)Umm.. Consider http://code.djangoproject.com/ticket/398 for example. It looks like a good idea to me, patch is there, so is some discussion and suggestions, but activities ended 3 months back and from ticket there seems to be no idea if its being considered or what. Not as many people subscribe to mailing list as they do for ticket system for the very simple reason that there is no way to get notified of new tickets or comments in the tickets for which you did not explicitly add your self to CC of. One can argue that it may be a very high traffic and many may not be interested in subscribing to it. One solution would be to have more than one lists, one for ticket status update, another with all kinds of comments in all tickets, another may be for all comments in all tickets filed under various milestones etc. -- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay+91-9867-359-701
Re: <% include %> should support select_template like sytax too
On 11/28/05, Tom Tobin <[EMAIL PROTECTED]> wrote: > Done: http://code.djangoproject.com/ticket/949Thanks! The Trac makes it much easier to keep, well, *track* ofwhat's going on. :-) :-) Just that I felt dropping a mail on the list gives a little more visibility and opportunity to get feedbacks, than just filing a ticket, which only a handful of core-thus-busy developers monitor. -- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay+91-9867-359-701
<% include %> should support select_template like sytax too
Hi,<% include template_name %> includes the named template which is like get_template of the Python API for loading templates, for consistancy we should have a comma seperated template list similer to select_template. (Untested) Patch attached.-- Amit UpadhyayBlog: http://www.rootshell.be/~upadhyay+91-9867-359-701 django.patch Description: Binary data
Re: Django and AJAX: Setting aside the conflict
Here are my half cooked thought on the issue.On 11/18/05, Wilson Miner <[EMAIL PROTECTED]
> wrote:
I think we should be as toolkit-agnostic as we are
templatesystem-agnostic and ORM-agnostic. We deliver one with Django,and all Django code builds on the delivered ones. But we don't enforcethose on users, if they want to use something else.
We are asking the wrong question. Let me make a statement: Any AJAX support in django will modified/enhanced Django Template System. The modifications will be in the form of new tags being added to core or contrib, and we can have a set of tags for each _javascript_ toolkit based on their merits and user demand, and designing everything with that in mind/docs would be the way to go.
I have been reading http://code.djangoproject.com/wiki/AJAX and I don't much like the "Proposed Implementation".
1)Please read my comments on
http://code.djangoproject.com/ticket/552,
http://code.djangoproject.com/ticket/547 and
http://code.djangoproject.com/ticket/356 to see how I think RPC should be done, and not as suggested in the "The second layer will be a set of views" in the Wiki. Thinking having access to modems from _javascript_ is a magic solution, is tempting but wrong. There will be situations where you would want methods to be accessible from webservice, and putting all such possible methods in the models is not the right thing to do.
So my implementation of django will have SimpleJSONView in the lines of
http://code.djangoproject.com/ticket/552
, where you would register functions/objects to it, and they will then be available as json webservice.2) Then I have problem with:The idea is that in _javascript_ I should be able to do::
entries = rpc.get_list('blogs.entries', {'limit' : 15})
(or something) and have it Just Work™.
First of all that would be a blocking call, and blocking _javascript_ call have undefined behavoiur on different browsers, they may stop all other onmousovers, not a good thing. So we will have to use
deferreds. But I guess this is just some technicality implied in "(or something)". What I am trying to say is we may not be able to have a one to one mapping between way of doing thing in python with those of that we have in _javascript_.
Now about the myth that JSON or _javascript_ or XML for that matter, will have anything to do with my idea of AJAX implementation in Django. It wont: I completely love the work in rails, its extremely brilliant. When people think of AJAX they think of "oh I will put a onclick or something similar, call a _javascript_ methods provided by django-ajax support, get results not in XML but json which can be passed through eval and get _javascript_ values/objects, and "do some logic" and finally update some div". Now this is very wrong:
1) it makes you spend a lot of time in _javascript_, which I do not consider a good language for programming, or at least no as good as python2) Generating HTML becomes a mix of working with DOM that we do in client side _javascript_ world with the html template world in the django-python side.
Now the earth shattering revolution that rails did is say most of the time "do some logic" will just be "convert the _javascript_/xml passed returned by server call to dom/html". By this brilliant stroke they have completely eliminated the requirement to have to do anything with _javascript_ in AJAX, for most part. This is the reason people love Rails AJAX support. With that in mind they went ahead and said all server calls will lead to updating a div, these updates could one of the following: 'replace', 'append', 'prepend', 'insert_after', 'insert_before'.
If we agree with these, the views would be normal django views, returning html, which we generate using normal django templates, as we always do, and these html snippets will be used to update the above mentioned div.
So my proposed solution:We create the tags:<% dojo_include_tag %> it will expand to html/_javascript_ to include dojo related libraries. <% dojo_link_to_remote
"Delete this post", :url ="" { :action ="" "destroy", :id => post.id }, :update => { :success => "posts", :failure => "error" } %>
And so on, basically borrowing them from rails. We will probably need a little different naming convention than rails as rails names are adhoc-ish while django names are typically much more elegant.
Also we can have a similar set of mochikit_* and prototype_* functions and people can decide what they want to use.The advantages:1) Other than adding a set of tags, django is not touched.
2) You can add your set of tags deriving from the ones provided by django if you do not like the toolkit used by django, without losing anything at all, so its more like mysql-vs-pgsql, where we do not lose any thing, as against django orm vs sqlobject where we do lose many things.
3) Using AJAX for a large part with django will become an issue of modifying templates, and no user level _javascript_ programming is required for a large part, tho is
