Add admin actions to the CommentsAdmin [#11625]
When comments made it into trunk, there was one feature (moderation queue) that was not documented because it was quite un'django'ic and I was hoping someone would come up with a neat way of implementing it within the admin. But with admin actions integrated into trunk, this job was made easier. There is a ticket open for this [1]. I have worked on a patch [2] for adding admin actions into CommentsAdmin. This patch removes the necessity to have a separate moderation queue for administering comments because now comments can be administered from within the admin itself. All the changes are backwards-compatible. At the same time, I wish to assist James on his 'big' patch [3] and hope that we can make some headway before the final feature freeze. [1] http://code.djangoproject.com/ticket/11625 [2] http://code.djangoproject.com/attachment/ticket/11625/11625.3.diff [3] http://code.djangoproject.com/ticket/10878 -- Cheers Theju --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: deprecate and remove django.contrib.comments
On Thursday, March 7, 2013 10:18:11 PM UTC+5:30, Jacob Kaplan-Moss wrote: > > Hi folks -- > > This one's simple: I'd like to deprecate `django.contrib.comments`, > scheduling it to be removed in a couple of releases. [snipped] > Any objections? > As the student (back then) who worked on Jacob's code, I too have no objections and support the move to deprecate comments and translocate it into a separate repo. On a related note, can we also move a lot of the other contrib apps (except for auth and contentypes) into the separate repo? > > Jacob > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Could the comments framework be more generic?
Hi, I am the student who worked on improving the comments framework a couple of years back and have been absconding since then ;-) Personally, I would love to see the comments app out of contrib because of the need to maintain backwards compatibility especially for an app with very few users. On Nov 28, 4:55 am, Kevin Renskers wrote: > Hi, > > I'd like to make a suggestion about the build in comments framework. > Right now, even though you can write your own extension to the > comments framework, it is always tied to database models. I am trying > to build an extension that uses the API offered by Disqus, meaning I > don't want to use the local database to do a count of comments, get > the list of comments, etc. Can you be specific on how the current setup is preventing you from getting it done? > > If Django's comments framework would offer an API that is one level > above the database models, we could write our own functions that > implement getting comments, saving them, do a count of comments for > the object, etc. Apart from a model backend what other backends are we looking at to store comments? > > I understand that a logical reaction to this suggestion would be to > just not use Django's comments app, but roll my own. But I want to > integrate the Disqus comments with existing apps, that already use > Django's system to, for example, show the count of comments on blog > articles in the admin interface. Django-blog-zinnia does this. > > I am looking forward to any comments and ideas. Is something like this > even possible without completely breaking backwards compatibility? If it is a clean proposal, it might be possible to convince the core devs to break the backwards compatibility rule. You can count me in for any kind of help regarding this task. -- Cheers Theju -- 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.contrib.comments - No reference to commented object in preview
Hi,
On Jul 13, 1:42 am, Tomáš Ehrlich wrote:
> Hi there,
> why there is no reference to commented object in preview?
>
Any specific use-case? Specifying it can make it easier to decide.
> django/contrib/comments/views/comments.py:95
> return render_to_response(
> template_list, {
> "comment" : form.data.get("comment", ""),
> "form" : form,
> "next": next,
> },
> RequestContext(request, {})
> )
>
The line of thinking was that preview would perform form-level
validation and the model-level validation (that of checking for
duplicates etc) would be done on save.
> It would be nice to have "object" variable with commented object.
> Views knows about it using content type and pk. Thanks to lazy
> evaluations of querysets, there won't be any hits to database unless
> necessary.
There would be one query, that for checking duplicate comments if the
object is sent through the context.
I think this is a valid request to open a ticket and marked as DDN so
that the core team may decide.
--
Cheers
Theju
--
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: RFC: Django 1.0 roadmap and timeline
On Jun 12, 7:23 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > On Wed, Jun 11, 2008 at 9:13 PM, Russell Keith-Magee > On comments > --- > > ``django.contrib.comments`` is a bit of special case here: ideally, Django 1.0 > will ship with *no* core use of oldforms. However, refactoring the comment > system -- not just replacing forms -- is overdue, and is the subject of a > Summer > of Code project. > > So we'd like to deal with that situation a bit specially. I've unfortunately > not > had a chance to ask Thejaswi (the student working on comments) or Jannis (his > mentor) about this, so obviously they'll need to be OK with the idea. But, > assuming this works, I'd like to do the following: I will try to get most of the code done by the first alpha 1.0 release, so that some of us can sit down and work on it during the sprints. I know it sounds a little unrealistic but I will try my best. I am in the process of relocating to another city and don't have regular access to an internet connection but I can assure you that work is still going on(at a slower pace but I have quite a few items of the ToDo list that Jacob wrote about sorted). I would also love people to suggest new features or code changes apart from help during sprints. -- Cheers Thejaswi Puthraya --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
{GSoC 2008} Django-Newcomments Suggestions Solicited
Hello folks, It's been a very long time since I posted an update because I have relocated to another city and don't have an internet connection but work has been going on. After a reply [1] from my previous update mail I decided to check out the method suggested. Another reason for pursuing the method was the response from folks on IRC. I have worked on the method and conducted a benchmark test on the previous method (that had a parent field and a level field embedded [2] into the model slightly like django-mptt) and the current method that uses recursion [3]. The benchmark test result is on http://dpaste.com/59754/. Going by the benchmark results the second method is logical but not efficient. After a long discussion with my mentor we decided to put it up for discussion here. Please suggest changes if any. The items in the To-Do list are: 1) Migration to newforms-admin 2) Migration script from old-comments to new-comments 3) Registration of Spam Filter 4) Improvements to the moderation queue (move to newforms-admin?) I plan to tackle 1 and 3 during the weekend and the rest at the sprint during Europython. [1] http://groups.google.com/group/django-developers/msg/2cf9d0170883d73e [2] http://code.google.com/p/django-newcomments [3] http://thejaswi.puthraya.googlepages.com/my_patch_5.diff (patch against current trunk of newcomments) -- Cheers Thejaswi Puthraya http://thejaswi.info/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
{GSoC 2008} Django-Newcomments
Hello all, Midterm evaluation is soon approaching and here is my last update before it. Here is what I have been able to accomplish so far: * Threaded-comment support without too much of modification to Jacob's initial code * Transition to newforms-admin * Demos and ability to have custom comments Things left to be done after midterm-eval are: * Migration script * More tests and docs * Move Moderation UI to NFA(??) * Add Spam Filter registration aka Session or Auth-backend registration style. Over the past two to three weeks, I set out to try out another method for handling threaded comments (ie using recursion). But benchmark tests proved that recursion was way too slow. So I have stuck to the mptt-style method. >From the next week onwards, I should be able to post code and updates regularly (provided I get an internet connection). Till then, I will have to send patches to my mentor who will keep uploading them. Thank Jannis for that idea and help. Hopefully, I will be able to see you folks at the Europython sprint where we can work on a few more features. -- Cheers Thejaswi Puthraya --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Comment templatetags should be independent of Comment Model
Hi, I was going through the patch by carljm for #8630 [1] and decided to give it a try. I ran into troubles but not with the patch. The reason being comment templatetags reference 'is_public' [2] and 'is_removed' [3] fields of the Comment Model. The idea for comments customization was to push essential fields onto BaseCommentAbstractModel and then inherit from this model. This would reduce the need to rewrite templatetags but I screwed this while sending patches just before the merge into trunk. I can think of two solutions to solve the problem. The first one being http://dpaste.com/82448/ and the second one (http://dpaste.com/82449/) to push the 'is_public' and 'is_removed' fields onto the BaseCommentAbstract Model. Both these changes are backward-compatible. I prefer the first method but would love to hear from you. I have opened a ticket for this at #9303 [4]. Please do post your thought either here or on this thread. [1] http://code.djangoproject.com/ticket/8630 [2] http://code.djangoproject.com/browser/django/trunk/django/contrib/comments/templatetags/comments.py#L83 [3] http://code.djangoproject.com/browser/django/trunk/django/contrib/comments/templatetags/comments.py#L86 [4] http://code.djangoproject.com/ticket/9303 PS: I have made quite a few mistakes and I am really sorry about them but if you believe I deserve to be spanked, please do ;-) -- Cheers Thejaswi Puthraya --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Contrib-02, 03] Comments Extensibility and inclusion of Comment-utils
I have worked on tickets * #8630 [1] : Improved customizability of django.contrib.comments * #9282 [2]: Inclusion of comment-utils moderators I am hoping someone will have time to review these tickets and provide suggestions and/or criticize the implementations. [1]: http://code.djangoproject.com/ticket/8630 [2]: http://code.djangoproject.com/ticket/9282 -- Cheers Theju --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: #9282 (comment moderation features) and Akismet removal
On Mar 23, 6:42 am, James Bennett wrote: [snipped] > Is there any reason behind that? I know there's always some wariness > when it comes to relying on a third-party service for a Django > feature, but Akismet seems to be the gold standard for this and > providing at least a CommentModerator subclass which supports it would > probably be a big win for ease of use (if it's not there, writing one > will likely be the first thing most people do when setting up > moderation). The only reason I can think of is that it relies on a third-party service. I will leave the decision to you folks on it's inclusion. I am a -0 on this because the feature can be easily used without much effort. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: Database Constraints
On Wednesday, April 2, 2014 4:09:37 AM UTC+5:30, simonb wrote:
>
> Hi
>
> Just FYI: back in 2007 GSOC there was a project to add constraints. The
> syntax was as follows:
>
The code is at https://github.com/theju/django-check-constraints/
I doubt it works as is after the SQL compiler changes. It worked well on
Postgres and SQLite. MySQL doesn't seem to support check constraints as of
date.
>
> class Manufacturer(models.Model):
> mfg_name = models.CharField(maxlength=50)
> car_sale_start = models.DateField()
> car_sale_end = models.DateField()
> quantity_sold = models.IntegerField()
> car_price = models.IntegerField()
>
> class Meta:
> constraints = (
> ("check_name”, Check(mfg_name__like = 'Merc*')),
> ("check_date”, Check(car_sale_start__between = [date(2007,1,1),
> date(2008,1,1)])),
> ("check_end_date”, Check(car_sale_end__gte = 'car_sale_start')),
> ("check_quantity”, Check(quantity_sold__gte = 0)),
> ("check_price”, Check(car_price__between = [0, 1])),
> )
>
>
> So a list of constraint name and a Check() pairs. I think the idea was
> that Check() could be ANDd or ORd together a bit like the Q() object.
>
> It worked with Postgres AFAIR.
>
> Simon
>
>
>
> On Tue, Apr 1, 2014 at 7:07 PM, schinckel
> > wrote:
>
>> Some years ago, I discussed adding database-level check constraints into
>> django:
>> https://groups.google.com/forum/#!topic/django-developers/OJN5kpcseAg
>>
>> There is also an issue: https://code.djangoproject.com/ticket/11964
>>
>> I'm thinking about revisiting this, and wanted to get some discussion
>> going about if this is a viable thing to do, and what it might look like.
>>
>>
>> Django already uses check constraints with PositiveIntegerField and
>> friends, and at first blush I thought we might be able to co-opt some of
>> that (indeed, I've got an internal monkey-patch that does, with some level
>> of success). However, other than the fact there is already a
>> 'sql_create_check' string, the actual python code that creates the check
>> constraint probably isn't that usable in this context. Also, I like the
>> idea of having more complex constraints (postgres has EXCLUDE constraints,
>> but I don't know if there is an equivalent for other backends).
>>
>>
>> The approach that I am thinking of could see a syntax similar to:
>>
>>
>> class MyModel(models.Model):
>> start = models.DateField()
>> finish = models.DateField(constraints=[('check', '> start')])
>> user = models.ForeignKey('auth.User')
>>
>> This maps directly to creating a check constraint on the table:
>>
>> ALTER TABLE "myapp_mymodel" ADD CONSTRAINT CHECK (finish > start)
>>
>> And, on the same model, a more complex constraint could look like:
>>
>>
>> class Meta:
>> constraints = [
>> ('exclude', [
>> ('overlaps', ['start','finish']),
>> ('equal', 'user')
>> ])
>>]
>>
>> I'm still unsure of the best way to describe this: it's supposed to mean:
>>
>>ALTER TABLE "myapp_mymodel" ADD EXCLUDE USING gist
>> (daterange(start, finish) WITH &&, user_id WITH =)
>>
>> (but the python syntax is obviously immaterial at this stage).
>>
>>
>> Obviously, we can't just rely on the database to do the validation for
>> us: it will just raise DatabaseErrors when something fails to validate
>> anyway, so we would want to handle this stuff in django's validation
>> framework.
>>
>> One possibility, at least with the field-based check constraint, would be
>> to automatically add a field validator in the case of a CHECK constraint,
>> however in the case of an EXCLUDE constraint, we can't really validate
>> _without_ hitting the database. Does this mean we should treat EXCLUDE-type
>> constraints as something that is beyond the scope of Django?
>>
>>
>>
>> With the new migrations framework, it's actually trivial to write a
>> migration to add this type of constraint (or the check constraint), and a
>> pre_save signal handler in conjunction with that would get 90% of the way,
>> but it's still going to be open to a race condition anyway - the only way
>> to actually do that is to try to save the object and see what the database
>> says.
>>
>>
>> So, I guess I'm asking: is it worth pursuing this further, either in part
>> or full?
>>
>> Matt.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to
>> django-d...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/250ed272-198a-478f-b2ce-920afcf533a2%40googlegroups.com
GSoC 2007: Check Constraints Update
Hello everyone, It's been a good week, I have been able to make quite some progress (about the quality of work, you'll have to comment). Here is the brief procedure that I adopted to implement Check constraints. 1) Created a Check field that inherits the Field Class and here I wrote the various attributes and methods for it (like for cascading check conditions etc). Currently this Check Field has been added in the django.db.models.fields.__init__.py file (at the end) and I'll move it onto a separate file soon. 2) All the SQL creation statements have been left to the management.py (I haven't modified the code but only added my code in the management.py). I have not added the SQL statements in the class itself because of the discussion here http://groups.google.com/group/django-developers/browse_thread/thread/6186dc6aa6e49ad/98cf3eef8cbad58e?lnk=gst&q=check&rnum=1#98cf3eef8cbad58e). 3) As of now, I have only tested the check constraints on Postgresql database server (it might also work on SQLite). One small modification that has to be done to get the constraints thing working is to add a 'CheckField' : None entry in the django.db.backends.postgresql.creation.py file. Problem: The check constraints got added successfully (after a syncdb) but the problem is when I go to the admin page and to the model's page in it, I get an error (link for the error page here http://thejaswi.puthraya.googlepages.com/error.html). This error vanishes when I comment the check fields in the models.py. I don't understand why the Check (pseudo) field is getting (trying to get) rendered in the Admin section. Caveat: There is currently no way to verify that all of the CHECK constraints are mutually exclusive. Care is required by the database designer. (I don't think it is possible to implement it because Postgresql also isn't sure of how this is to be handled.) Presently I am placing the files (outside the Google Hosting) and will upload them after I get comments and sanction from the group to go ahead. django.db.models.fields.__init__.py --> http://thejaswi.puthraya.googlepages.com/__init__.py django.core.management.py --> http://thejaswi.puthraya.googlepages.com/management.py Insert a line in django.db.backends.postgresql.creation.py --> "CheckField" : None The 'like','between','upper' and 'lower' constraints haven't been implemented as yet. That would be in the next phase of this project. The Project is hosted on http://code.google.com/p/django-check-constraints Features page is http://code.google.com/p/django-check-constraints/wiki/Features Waiting for some constructive criticism. PS: The next time I'll add more documentation to my work. (Totally neglected it...extremely sorry). Thanking You Thejaswi Puthraya http://thejuhyd.blogspot.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
GSoC Update: Implementing Check Constraints
Hello Django Developers, This post is to announce a change in the method of implementing check constraints. Previously I had used the method of subclassing the Field Class to achieve my goal. But after some convincing conversations from my mentor Simon Blanchard and other developers I decided to drop the above method because the Check Object is never a field. Though this change is slightly late (and I believe it is better to be late than never), I confirm that this method will confirm to the best practices followed by the Django community and will not be a cheap and dirty hack. The new method requires the user to add the constraints in the Meta Class (in the django.db.models.options.py rather than as a field (as in the former method)). There are small API changes and the Features Wiki will be updated soon. Also I plan to start uploading the patches soon. Thanking You Thejaswi Puthraya --~--~-~--~~~---~--~~ 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 Update: Implementing Check Constraints
I have updated the Features Wiki Page. Here is the features page: http://code.google.com/p/django-check-constraints/wiki/Features and the project page at: http://code.google.com/p/django-check-constraints Thanking You Thejaswi Puthraya --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
GSoC Update: [Check Constraints] Finally Some Code and Screencasts
Hello Django Developers, A week after changing my approach, I have been able to make some progress. Also this week, I am posting screencasts to showcase my work. This week I tackled both Value based and Range Based constraints. The things left to do are : -> Implementing 'like' and 'between' check conditions. -> Deciding whether to support 'upper' and 'lower' functions(requires me to study if all databases support it) -> Implementing Datetime -> Testing on Oracle and Firebird (Can someone who has oracle help test the constraints?) -> Write more apps to test functionality. -> Catch Bugs. -> Add i18n support. -> PEP-8 Compliance. Screencast 1 (http://thejaswi.puthraya.googlepages.com/ screencast_1.ogg) (9MB, 12 Minutes) This screencast deals with downloading Django and Check Constraints from the Subversion repository and applying the patches downloade d. It also deals with creating a model with the various checks. Screencast 2 (http://thejaswi.puthraya.googlepages.com/ screencast_2.ogg) (6MB, 5 Minutes) It deals with syncing the database and observing the output in PgAdmin. Screencast 3 (http://thejaswi.puthraya.googlepages.com/ screencast_3.ogg) (8MB, 7 Minutes) Using the Django admin to add data and to verify if the checks are working. Screencast 4 (http://thejaswi.puthraya.googlepages.com/ screencast_4.ogg) (4MB, 4 Minutes) This screencast gives an idea of the various exceptions raised by the check constraints models. Also a weird bug (not sure if it is a bug) at the end of the video. These screencasts have been created by Istanbul (http://live.gnome.org/ Istanbul) Hope you folks will assist me in testing Django Check Constraints and get issues to the fore, thus making Django Check Constraints usable and useful. Thanking You Thejaswi Puthraya --~--~-~--~~~---~--~~ 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 Update: [Check Constraints] Finally Some Code and Screencasts
By the way, the project is at http://code.google.com/p/django-check-constraints --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
GSoC Update: [Check Constraints] Testing and some regular stuff
Hello Django Developers, After the Oracle branch got merged into trunk, the django check constraints patch code had broken. So I had to fix it (just a one line change). Also this week I decided to test the work with databases like SQLite and Oracle. It worked perfectly with SQLite but there is a small issue with Oracle. The issue is with Oracle's date field which uses an unconventional format. I will work on it later but currently am writing doctests for the Check Class. The Google Code Hosting page for Django Check Constraints now contains a test django project with test apps, readme and install files. Also screenshots (mainly for those Mac users who could not view my screencasts). I was wondering if I should move all the SQL creation code from management.py to within the SQL Class itself (ie by overriding the __str__ method. So the SQL code is printed out everytime the __str__ method is called.). Please help resolve this confusion. The project hosting page is at http://code.google.com/p/django-check-constraints Cheers Thejaswi Puthraya --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
GSoC Update: [Check Constraints] Unicode Compatible, Doctests and a lot more...
Hello Django Developers, This week saw a lot of change in the Check Constraints project. First, most of the SQL generation code has moved from the management.py to the Check class. Initially I was very reluctant to move the code from management.py to the Check Class (because I had the feeling that most of the SQL code ought to be in the management.py along with the other SQL code). After a discussion with my mentor, I realized that it ought to be placed in the class because: 1) Lower number of lines in the main code. 2) Easier to write tests. With the unicode branch being merged into trunk, I had the opportunity to make the project unicode compatible. I also wrote doctests this week. Hope you folks use the project (and love it) and let me know of your suggestions. Cheers Thejaswi Puthraya http://code.google.com/p/django-check-constraints --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
GSoC Update: [Check Constraints] New features and using it with Newforms.
Hello Django Developers,
This week I worked on getting the 'like' and 'between' check
conditions into the project and also writing a lot of doctests.
So here is how to use 'like' and 'between' check constraints
class Manufacturer(models.Model):
mfg_name= models.CharField(maxlength=50)
car_sale_start = models.DateField()
car_sale_end= models.DateField()
quantity_sold = models.IntegerField()
car_price = models.IntegerField()
class Meta:
constraints = (
("check_name",Check(mfg_name__like =
'Merc*')),
("check_date",Check(car_sale_start__between =
[date(2007,1,1),date(2008,1,1)])),
("check_end_date",Check(car_sale_end__gte = 'car_sale_start')),
("check_quantity",Check(quantity_sold__gte = 0)),
("check_price",Check(car_price__between = [1000,1])),
)
In the 'like' check data '*' matches 0 or more characters whereas '+'
matches a single character. (might go for a change, replacing '+' for
a '.')
'between' expects a two-element list which give the bounds for the
field.
The output SQL is:
CREATE TABLE "appname_manufacturer" (
"id" serial NOT NULL PRIMARY KEY,
"mfg_name" varchar(50) NOT NULL,
"car_sale_start" date NOT NULL,
"car_sale_end" date NOT NULL,
"quantity_sold" integer NOT NULL,
"car_price" integer NOT NULL,
CONSTRAINT "check_name" CHECK ("mfg_name" like 'Merc%%'),
CONSTRAINT "check_date" CHECK ("car_sale_start" between date
'2007-01-01' AND date '2008-01-01'),
CONSTRAINT "check_end_date" CHECK ("car_sale_end" >=
car_sale_start),
CONSTRAINT "check_quantity" CHECK ("quantity_sold" >= 0),
CONSTRAINT "check_price" CHECK ("car_price" between 1000 AND
1)
)
;
Here is a way of using Newforms and Django Check Constraints
http://thejuhyd.blogspot.com/2007/07/django-newforms-and-django-check.html
This week I will work on adding support for the datetime field and
decide on whether to support the upper and lower functions.
Cheers
Thejaswi Puthraya
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Oracle and Unicode Errors
I have Django SVN version 5788 and just installed cx_Oracle version 4.3.1. When I try to use the manage.py sql command I get a weird error. (Looks like the oracle backend is still not unicode compatible.) Here is the output that I get: Traceback (most recent call last): File "manage.py", line 11, in execute_manager(settings) File "/usr/lib/python2.5/site-packages/django/core/management.py", line 1745, in execute_manager execute_from_command_line(action_mapping, argv) File "/usr/lib/python2.5/site-packages/django/core/management.py", line 1704, in execute_from_command_line output = action_mapping[action](mod) File "/usr/lib/python2.5/site-packages/django/core/management.py", line 117, in get_sql_create known_models = set([model for model in _get_installed_models(_get_table_list()) if model not in app_models]) File "/usr/lib/python2.5/site-packages/django/core/management.py", line 71, in _get_installed_models return set([m for m in all_models if converter(m._meta.db_table) in map(converter, table_list)]) TypeError: descriptor 'upper' requires a 'str' object but received a 'unicode' I searched code.djangoproject.com for any similar problems but was unsuccessful and hence have posted it in the list. Hope you address the problem (if it is a problem) at the earliest. Cheers Thejaswi Puthraya --~--~-~--~~~---~--~~ 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: Oracle and Unicode Errors
> Can you please file a ticket so we don't loose this? Ticket filed: http://code.djangoproject.com/ticket/5075 Cheers Thejaswi Puthraya --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
GSoC Update: [Check Constraints] Datetime,Time,i18n support and PEP-8 Compliant
Hello Django Developers, Over the past week and half I have been working on adding support for the datetime and time fields and also adding support for i18n and making the code PEP-8 compliant. Now 'in' check condition is supported better Earlier if I used Check(tax_payment_date__in = (date(2007,01,01),date(2007,03,31),date(2007,06,30))) I would get an error but now it is working satisfactorily. I have written another blog post on using Django Newforms, Django Check Constraints and how to raise useful error messages which was missing in my earlier blog post. Here is a link to the blog post http://thejuhyd.blogspot.com/2007/08/django-newforms-and-django-check.html For the last week, I will work on catching bugs and fixing them and probably writing more documentation and test applications. Cheers Thejaswi Puthraya --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
GSoC Update: [Check Constraints] Django Developers stump me, Final Update as GSoC Project
Hello Django Developers, On August 20th ie tomorrow, Google Summer of Code 2007 will officially close and all students are required to commit the code written over the past two odd months. As I was preparing to commit my code I was stumped to see that my project's code broke post revision 5923. The reason was that the manage.py file has now been diversified (check changeset 5923 and 5925). This happened too close to the project's final deadline and this gave me a few anxious moments. I thought I had to literally start from scratch because I was patching the management.py. On closely studying the new pattern of the management I realized that all the functions had been neatly divided. This is a welcome sign but there was hardly any prior communication of such a shakeup...a small warning atleast on the devel list would have helped. By the way, I have to congratulate the developers for finally diversifying code and making the code more organized. Now regarding my project's goals. I have completed all except two goals one being implementing the "upper" and "lower" methods on check fields and the second, integrating django-check-constraints with the Django Admin. The reason for not implementing the "upper" and "lower" methods currently is that they are not fully "unicode"-compatible in Sqlite (because they use C's tolower and toupper routine). The current way of integrating django-check-constraints with admin would be by using manipulators (which is not recommended because newforms is going to be the de-facto standard from the next release). So I will integrate with the admin as soon as newforms-admin is merged into the trunk. (When I talk of integrating with django-adminI mean displaying neat errors.) I have tested the project extensively writing around 50 doc tests and testing with various cases and databases. The databases used for my test were: Postgresql 8.2.4 Sqlite 3.3.13 Oracle 10g Haven't checked for other versions but should work for all versions that support and enforce check constraints. I had written two blog entries showing how to use django-check- constraints. http://thejuhyd.blogspot.com/2007/07/django-newforms-and-django-check.html http://thejuhyd.blogspot.com/2007/08/django-newforms-and-django-check.html Hope they give an indicator. I would also like to thank all Django developers especially Jacob, Adrian and Malcolm for all the support. A special "thanks" to my mentor Simon Blanchard for guiding me through this project even through his busy schedule and for keeping up with all tantrums that I threw at him ;-) I would also like to thank Kenneth Gonsalves for having given me this idea at the start of Summer of Code. Hope you use and love Django-Check-Constraints http://code.google.com/p/django-check-constraints PS: Don't mistake this for my last mailI hope to contribute lot more to Django...and would like to sign off by screaming "DJANGO ROCKS!!!" (so does POSTGRESQL) ;-) Cheers Thejaswi Puthraya --~--~-~--~~~---~--~~ 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 Update: [Check Constraints] Django Developers stump me, Final Update as GSoC Project
> To be fair (to us), this > threadhttp://groups.google.com/group/django-developers/browse_frm/thread/4f...was > all about exactly that. It mentioned management.py in the title, so that > counts as a clear warning in Open Source mailing list terms (sometimes > threads veer wildly off course from their titles). Woops...looks like I overlooked the threadso a warning was given and I missed it. Cheers Thejaswi Puthraya --~--~-~--~~~---~--~~ 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: validation aware models? or check constraints?
On Aug 21, 3:54 pm, pk11 <[EMAIL PROTECTED]> wrote: > As far as I see we could > > 1) add a simple method like this to the db > api:http://code.djangoproject.com/ticket/5101 There are two ways you could implement validation...one at the database level and the other at the application level. My personal choice would be validation at the application level(through newforms...am eagerly awaiting its stabilization and the release of newforms-admin) because it would be database independent. But for better data-integrity database level validation would be best. So managing validation is a trade-off. > 2) merge the check constraints project to trunk (is it going to > happen?) It is only when people start using the project in production environment and report about the satisfaction (if any) will it be merged into trunk. I would agree with Malcolm that my project is too too young to be merged. I would love if people like you come forward and use the project and give me feedback. Cheers Thejaswi Puthraya --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Django Check Constraints Update
Hello Django Developers,
It's just been 5 days since Google Summer of Code closed and I have
been feeling jobless. So I decided to complete the pending work I had
and as a result Django Check Constraints now has support for upper and
lower string functions.
Now you could do something like below:
constraints =
(
("check_first_name",Check(first_name__in__upper =
("GEORGE","JOHN"))),
("check_last_name", Check(last_name__in__lower =
("bush","brown"))),
)
The field data received for first_name is converted to uppercase and
then tallied if present in ("GEORGE","JOHN").
and the equivalent sql code generated is:
CONSTRAINT "check_first_name" CHECK (upper(first_name) in
('GEORGE','JOHN')),
CONSTRAINT "check_last_name" CHECK (lower(last_name) in
('bush','brown'))
The caveat here is that since SQL is not such a strict enforcing
language
constraints =
(
("check_first_name",Check(first_name__in__upper =
("george","john"))),
("check_last_name", Check(last_name__in__lower =
("BUSH","BROWN"))),
)
will be accepted but will give an error when a row is created or
edited. I am trying to figure out if I should add validation in my app
by which the above code snippet when run should generate an error.
The next item on my to-do list is to integrate django check
constraints with newforms-admin.
Cheers
Thejaswi Puthraya
--~--~-~--~~~---~--~~
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 with model or database level validation
On Sep 5, 11:37 am, james_027 <[EMAIL PROTECTED]> wrote: > Is there a plan on making newforms be able to validate on the model or > database level like unique=true? although is can be done customizing > the cleaning methods of the newforms but I think it could be nice to > have such capability built in Did you mean something like check constraints? You might find this helpful then http://code.google.com/p/django-check-constraints and a blog post on how to use newforms and django-check-constraints together http://thejuhyd.blogspot.com/2007/08/django-newforms-and-django-check.html Hope you find it useful. Cheers Thejaswi Puthraya --~--~-~--~~~---~--~~ 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,contrib.admin and validation
On Sep 14, 3:03 pm, Mike H <[EMAIL PROTECTED]> wrote: > Hi all, > > I've have a few models that need a bit more complex validation than the > Validators can handle. (They have a start and end date and need to check > in the database that no other record has an overlapping start / end > date.) The validation I need to do would be easy to do if the validators > accepted the primary key of the model they were validating for, if they > were validating for an existing instance. But as far as I can see, they > don't. Why don't you make both your start date and end date primary keys? Or you could probably try Django Check Constraints http://code.google.com/p/django-check-constraints. By using Django Check Constraints you could also make sure that start date is less than the end date and also give a range for start date. Check the Features page for more details http://code.google.com/p/django-check-constraints/wiki/Features Hope it helps. Cheers Thejaswi Puthraya --~--~-~--~~~---~--~~ 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: Would a web search be a good addition to the contribs framework?
On Oct 2, 12:30 am, "shabda.raaj" <[EMAIL PROTECTED]> wrote: > It looks to me that a api to get web search functionality in Django > would be good idea. Yes, a full-text search functionality is really cool and there has been considerable effort that has been put into this. Check out http://code.google.com/p/django-sphinx/ http://code.djangoproject.com/wiki/searchengine http://code.djangoproject.com/wiki/TextIndexingAbstractionLayer > (I just plan to add convinient api for webservices found at > http://developer.yahoo.com/search/ ) Django has been a neutral web-framework without showing bias to any database, external apps etc. To use the Yahoo Web API's and then incorporate them as contrib apps would not be recommended. I would agree with Russell Keith-Magee on Django's philosophy to accept contrib apps. Cheers Thejaswi Puthraya --~--~-~--~~~---~--~~ 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 Persian Local language file
On Oct 5, 4:06 pm, Milad <[EMAIL PROTECTED]> wrote: > Could you clue me how can I send files for you and accept process First refer to the archives on the Django-i18n. This question has been posted numerous number of time. If you can't locate it then post it to the Django i18n list and you'll get a better response. http://groups.google.com/group/django-i18n/ Cheers Thejaswi Puthraya --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Template variables in filter arguments not parsed correctly
Whenever a variable is used in a filter's arguments (have checked for
slice only...might be applicable for other filters also) it is wrongly
parsed and we get a TemplateSyntaxError which says "slice requires 1
arguments, 0 provided". From the traceback here is what I received on
the output:
The token being
u'some_item.var2|slice:":{{ forloop.counter0'
Notice the missing "}}"
Here is the test code:
{% for some_item in many_items %}
{{ some_item.var1 }} {{ some_item.var2|slice:":
{{ forloop.counter0 }}" }}
{% endfor %}
I have opened a ticket and here it is http://code.djangoproject.com/ticket/5874
Cheers
Thejaswi Puthraya
--~--~-~--~~~---~--~~
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: Template variables in filter arguments not parsed correctly
> There's really no need to open a ticket and report it here. We already > get mail for every ticket opened, so the net effect is just increasing > the amount of email we get. Please don't do that -- I have enough to > read already. :-( Sorrydidn't know that. Will keep this in mind. > You are trying to do something that is out of scope for the template > system. You cannot use variables inside other variables. Looks like I got too many things wrong. Thanks for pointing it out. -Thejaswi Puthraya --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django weekly updates?
> Wow, that's great. Sounds good too. If we did set up a mailing list > we all could collaborate on the changeset picks, blog post picks, etc. Why not have something like digg? True user generated democracy :) Cheers Thejaswi Puthraya http://thejaswi.info/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Button on website to show version of trunk
Very often I hear people discouraging the use of Django because the latest version is 0.96 and has been there for quite long (almost an year, I guess). Many corporates too do not favour software that is a pre-1.0 version (though their generalization does not hold true for Django :) I want to propose a separate button for download that links to the trunk source and has the svn version number on the label. It would also be good if we could have the revision number of the 0.96 version on the download button on the main page to show the amount of progress that has been made by the project. Such small cosmetic changes will help in the promotion of Django and people will give it a proper look (and will not cite the version as the reason for not giving it a try). If sufficient people are up for this we could open a ticket and get this change done. -- Cheers Thejaswi Puthraya http://thejaswi.info/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[GSoC Proposal] PAM Auth backend for Django
Hello django devs, Here is the proposal I have submitted for the Google Summer of Code. I just wanted to know your comments/suggestions. Overview == Introduction to PAM Pluggable Authentication Modules are the backbones of authentication in most POSIX systems like Linux, Solaris, AIX and BSD (through OpenPAM). Various userland applications like MTAs and several authentication protocols like Kerberos, RADIUS etc can talk with PAM. My Project --- My project will cover "writing a pam auth-backend for django". By doing so, integration of system services with the web framework will be possible. How do I plan to go about the project? The project is divided into 3 parts: * Improving the existing bindings: The existing bindings (http:// www.pangalactic.org/PyPAM/) are bug-ridden with lot of memory leaks, hasn't been tested with python2.5 and don't expose the full C API. This part of the project will involve rectifying the above mentioned. * Writing the backend for django: Writing an auth-backend for django using PAM isn't going to be straightforward because issues like overriding the Django User Model will creep in. These issues have to be dealt appropriately. * Writing docs, tests and a proof-of-concept application: Every project's success is based upon the strength of it's documentation, the coverage of it's test suite and tutorials it can offer. For this project, I plan to write a proof-of-concept applications apart from the docs, tests and tutorials. Eg: --- Webmail interface that authenticates with the MTA via PAM. ((or)) Timed-login or a restricted authentication application. Applications - * If successfully completed, then django has a chance of becoming the defacto framework for building web-based GUI for system services based on PAM. * Authentication against popular authentication protocols like RADIUS, Kerberos etc. * Multi-platform deployment on Linux, Solaris, BSD etc. -- Cheers Thejaswi Puthraya http://thejaswi.info/ --~--~-~--~~~---~--~~ 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: PAM Auth backend for Django
On Mar 26, 10:04 pm, "Sage La Torra" <[EMAIL PROTECTED]> wrote: > Thanks for the proposal! > > For what it's worth, I'm not a Django mentor, but I am a two-time > Summer of Coder. I just wanted to know if you had a timeline in mind? > One of the harder parts of Summer of Code is the 'Summer' part, so it > can pay off to have a proposed timeline. It also gives your mentor an > idea of what they should expect and when. Of course the timeline will > change, but it's a good idea to have. [snipped] Yes I have a timeline in mind. Will share it very soon on the list. Just have to confirm when my exams end (I guess may 5th or 9th), so that I can start coding before GSoC starts ;-) -- Cheers Thejaswi Puthraya http://thejaswi.info/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
GSoC Proposal: PAM Auth backend for Django
On Mar 27, 7:07 am, Thejaswi Puthraya <[EMAIL PROTECTED]> wrote: > On Mar 26, 10:04 pm, "Sage La Torra" <[EMAIL PROTECTED]> wrote: > > > Thanks for the proposal! > > > For what it's worth, I'm not a Django mentor, but I am a two-time > > Summer of Coder. I just wanted to know if you had a timeline in mind? > > One of the harder parts of Summer of Code is the 'Summer' part, so it > > can pay off to have a proposed timeline. It also gives your mentor an > > idea of what they should expect and when. Of course the timeline will > > change, but it's a good idea to have. > > [snipped] > > Yes I have a timeline in mind. Will share it very soon on the list. > Just have to confirm when my exams end (I guess may 5th or 9th), so > that I can start coding before GSoC starts ;-) Here is my timeline: May 5th : Exams get over May 7th - May 26th : Preparation for SoC May 27th - June 10th : Work on the bindings June 11th - June 24th : Work on the auth-backend June 25th - July 7th : Buffer time July 8th - July 22nd : Write docs and tests July 23rd - July 29th : Write a proof-of-concept application July 30th onwards : Buffer time -- Cheers Thejaswi Puthraya http://thejaswi.info/ --~--~-~--~~~---~--~~ 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 Proposal: PAM Auth backend for Django
On Mar 29, 6:44 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Hi! > > On Mar 27, 3:12 pm, Thejaswi Puthraya <[EMAIL PROTECTED]> > wrote:> May 27th - June 10th : Work on the bindings > > There already exist new pam bindings based on > ctypes:http://atlee.ca/software/pam/module-index.html Wasn't aware of this at all. > > June 11th - June 24th : Work on the auth-backend > > import pam > from django.contrib.auth.models import User > > class PamBackend: > def authenticate(self, username=None, password=None): > # Check the username/password and return a User. > if pam.authenticate(username, password, service='login'): > try: > return User.objects.get(username=username) > except User.DoesNotExist: > pass > return None > > Done :) Yes, writing an auth-backend is very easy, I realized after reading the documentation. > Or did I understand anything wrong? Perfect. Thanks for making me realize that this is not a SoC project and can be done in a few minutes. Will have to start searching for a new idea :-) -- Cheers Thejaswi Puthraya http://thejaswi.info/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Unfair ticket management
On Mar 31, 5:19 pm, Ivan Illarionov <[EMAIL PROTECTED]> wrote: > > There are people doing triage regularly to check for duplicates; > > however, there are a large number of tickets and this one -- as > > mentioned above -- happened during the development sprint when there > > was already a large amount of ticket activity. Try not to take it > > personally or allege unfairness; in all likelihood, it was just a > > mix-up that happened in the clamor of the sprint. > > Thank you for explanation. Now I see that it's all about sprint. But > it's still feels very bad when you see some other patch merged when > you have the same thing (even that small) done earlier. First, I am very sorry to have caused so much of pain to you. I totally overlooked your ticket (just missed it) in an urge to contribute during the sprint. Will be careful from the next time. The patch for ticket #6789 too was pushed in after lot of reluctance from the devs because it still did not solve the problem of preventing the name clash during deployment. Second regarding getting rid of the INVALID_PROJECT_NAMES. I agree with James Bennett. Another thing is that your current patch (as on 31/3/08) let's people name their project "test" which the INVALID_PROJECT_NAMES was preventing earlier. Sorry once more. -- Cheers Thejaswi Puthraya --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Unfair ticket management
On Mar 31, 9:08 pm, Ivan Illarionov <[EMAIL PROTECTED]> wrote: > On Mar 31, 7:36 pm, Thejaswi Puthraya <[EMAIL PROTECTED]> > wrote:> First, I am very sorry to have caused so much of pain to you. I > > totally overlooked your ticket (just missed it) in an urge to > > contribute during the sprint. Will be careful from the next time. The > > patch for ticket #6789 too was pushed in after lot of reluctance from > > the devs because it still did not solve the problem of preventing the > > name clash during deployment. > > It's ok. It really wasn't so painfull :) > > > Another thing is that your current patch (as on 31/3/08) let's people > > name their project "test" which the INVALID_PROJECT_NAMES was > > preventing earlier. > > No, it won't. 'test' is a standard python package and it will be > detected by __import__ in try/except/else clause. > INVALID_PROJECT_NAMES is unnecessary - every single name in it is > handled by __import__ - I checked and tested this when created my > patch. Sorry to prolong this discussion. Though I can see the test module http://docs.python.org/modindex.html, it is not installed on my system and hence I was able to create a project by name 'test'. I am using python2.5.1 taken directly from the fedora rpm repository. Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) [GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import test Traceback (most recent call last): File "", line 1, in ImportError: No module named test >>> -- Cheers Thejaswi Puthraya --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
GSoC 2008: Rewrite the Django Comments framework - Django Newcomments
Hello Django Developers, Just checked my mail and saw that I have been selected for Google Summer of Code, 2008. This is the second time I am participating in the contest and for the second time I have got a chance to contribute to the Djangoproject :) My mentor for this project is Jannis Leidel. Here is a little bit more about my project: Purpose of the project --- Django comes with a comments framework that makes embedding comments in apps very easy. Jacob Kaplan Moss is writing a replacement for the comments framework that is intended to replace the current comments framework. The newcomments framework offers more features and will also integrate the best features from third-party projects like James Bennett's comment-utils and django-openidconsumer. My Project --- I plan to assist Jacob complete a major portion of the ToDo [1] list that he has at the current moment. Hopefully by the end of this summer, the django-newcomments framework will be able to make quite a lot of progress and will be closer to finding itself in the trunk. How do I plan to go about the project? The project is divided into four parts: * Decide with the mentor what are the things in the ToDo that I plan to complete by the end of the summer. * Coding the stuff decided in the previous step. * Migration script for old comments. * Writing docs and tests. Documentation is quite important because the comments framework is one of the least documented features of the framework. Since this project's goal is to be integrated into the trunk, work will continue beyond summer till the integration is complete. [1] http://toys.jacobian.org/hg/django-newcomments/file/8b5972213fc4/TODO.txt Newcomments is marked as a feature for Version one of django: http://code.djangoproject.com/wiki/VersionOneFeatures I will soon update you folks with more details about my project after discussions with my mentor. Also wishing luck to all my fellow SoCers. Have a great summer!!! -- Cheers Thejaswi Puthraya http://thejaswi.info/ --~--~-~--~~~---~--~~ 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 2008: Rewrite the Django Comments framework - Django Newcomments
On Apr 22, 12:15 pm, SmileyChris <[EMAIL PROTECTED]> wrote: > On Apr 22, 1:15 pm, Thejaswi Puthraya <[EMAIL PROTECTED]> > wrote: > > > Hello Django Developers, > > > I plan to assist Jacob complete a major portion of the ToDo [1] list > > that he has at the current moment. Hopefully by the end of this > > summer, the django-newcomments framework will be able to make quite a > > lot of progress and will be closer to finding itself in the trunk. > > Great! I (and a lot of others surely) look forwards to your progress > reports. > Hang out on IRC when you have the chance, it's good to do a bit of > chatting about these things with some of the community in a less > formal environment :) Thanks. I am on the IRC whenever online. I can be found on #django and #django- dev with the nick 'theju'. -- Cheers Thejaswi Puthraya http://thejaswi.info/ --~--~-~--~~~---~--~~ 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: Manager-model reassignment on abstract subclassing
On May 17, 5:38 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > I've opened up a ticket 7252 [1] with patch, but I'm not sure my patch > addresses the problem from the right angle, so if someone knows a > better way to go about fixing it, I'd like to open the discussion here > for better ways to fix this. There's a similar ticket to this at 7154 (http:// code.djangoproject.com/ticket/7154). It has a patch that works but I am not sure if it is the most elegant method. > Essentially what's happening is that the manager is being inherited > properly from the abstract model, but each manager has a reference to > its parent model class, and that reference is not being updated. My > solution is to check in the descriptor if the calling model instance > matches the manager's reference, and if it doesn't, assign it. This > feels flimsy, as we probably shouldn't have to make this check at > all. > > As far as I can tell, this can't be done in ModelBase.__new__, as the > reference is not yet set and therefore can't be checked. > > Thoughts? Suggestions? > > [1]http://code.djangoproject.com/ticket/7252 -- Cheers Thejaswi Puthraya http://thejaswi.info/ --~--~-~--~~~---~--~~ 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: Manager-model reassignment on abstract subclassing
On May 17, 10:57 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > There's a similar ticket to this at 7154 (http:// > > code.djangoproject.com/ticket/7154). It has a patch that works but I > > am not sure if it is the most elegant method. > > Whoops! Sounds like we're talking about the same thing. I thought > based on the summary that it was a different problem, because the > manager actually _does_ get copied over, but it just needs a slight > modification. > > I do tend to like the implementation on that ticket better, as it gets > closer to the root of the problem. Are there any disagreements about > whether that patch should be applied? I do not know if there are any disagreements (I found qsrf very complicated to understand) but I am using the patch for the newcomments project. There are a couple of other quirks with Abstract Models which I was assured were trivial and would be done with the nfa merge. -- Cheers Thejaswi Puthraya http://thejaswi.info/ --~--~-~--~~~---~--~~ 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: drop down box in django-admin interface UI?
On May 22, 4:02 pm, "ravindra goyal" <[EMAIL PROTECTED]> wrote: > hi > i want to make one of my field taking value as drop down box on django-admin > UI. > how can i define a field in model such that it takes value from a specific > set of values in django-admin interface. > i am using django-admin interface for one of my database. > in a certain table in a particular field i want that field to be like > > example- my field is lanuage which takes value only from > 'hindi,english,french,german' > > so i need one drop down box for the same. > > what modification are required for the same in model. This is a list dedicated for the development of django and not for general usage questions. Please take your discussion to the django- users mailing list. -- Cheers Thejaswi Puthraya http://thejaswi.info/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
{GSoC 2008}Django-Newcomments : A preview
Hello folks, My exams got done in the first week of May. I was feeling quite bored and so started working on the project. I completed a few items from the Todo list but need to complete the documentation and write more tests. The code for my project is at http://code.google.com/p/django-newcomments/ and at http://gitorious.org/projects/django-newcomments I also have put up the four demos in the source at: Demo-1: Using django-newcomments as a standalone app. http://sandbox.thejaswi.info/example1/authors/ Demo-2: Using django-newcomments placing it in django.contrib.comments (after removing the current django.contrib.comments) http://sandbox.thejaswi.info/example2/books/ Demo-3: A simple threaded comments demo (inspired from Eric Florenzano's project). http://sandbox.thejaswi.info/example3/comics/ Demo-4: A custom comments demo http://sandbox.thejaswi.info/example4/messages/ Current Problems faced: * Abstract models don't allow custom managers. Tickets 7154 and 7252 handle that (I am running trunk patched with ticket 7154). * Abstract models don't allow the inheritance of the inner admin class. After a discussion on IRC, I was assured that this was a small issue that newforms-admin would cover after it supports model- inheritance. Till then an abstract model designer cannot pass on a neat admin UI to the user :( Please do let me know of any suggestions/criticisms and/or feedback. -- Cheers Thejaswi Puthraya http://thejaswi.info/ --~--~-~--~~~---~--~~ 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 2008}Django-Newcomments : A preview
Sorry for getting back to you so late. Was unwell.
On May 22, 8:47 pm, "Nicolas Lara" <[EMAIL PROTECTED]> wrote:
> Hello,
> I was checking out the project.. So far it looks very good =)
>
> A question though:
> I noticed the comments retreived by {% get_comment_list ... %} are
> ordered by pk. Is there any plan to include custom ordering? I believe
> the default ordering should include replies to old comments after the
> objet it refers since I dont see any case in which it would make sense
> to have the replies away from the objects being replied upon.
The ordering is not done by pk. For the default models it is done by
submit_date. For custom models the ordering is whatever you specify
(in the Meta inner class). From your suggestion I've implemented a
setting COMMENTS_ARRANGE_BY_THREAD which arranges the list by thread
rather than by chronological order.
Also included a demo...check out
http://sandbox.thejaswi.info/example5/authors/1/
> I'll try to play around with your project when I get the time :)
>
> good luck,
Thanks...wish you the same for your project.
--
Cheers
Thejaswi Puthraya
http://thejaswi.info/
--~--~-~--~~~---~--~~
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 2008}Django-Newcomments : A preview
On May 23, 5:00 pm, akaihola <[EMAIL PROTECTED]> wrote: > So it would be great to have the flexibility to make both approaches > possible. Now it is possible to do both. -- Cheers Thejaswi Puthraya http://thejaswi.info/ --~--~-~--~~~---~--~~ 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 2008}Django-Newcomments : A preview
On May 23, 7:08 am, arthur debert <[EMAIL PROTECTED]> wrote:
> Hi Thejaswi.
>
> A couple of suggestions:
>
> Any reasons for having CommentFlag.flag being a string, and not a
> foreign key to a FlagType model ? Having them as strings makes it
> easier to end up with bad data (misspelling and so forth). Of course
> there is always the performance penalty, but it seems worth it.
Well...this is something that Jacob wrote...so he's the best person to
answer the question.
I could guess and give the answer but I might be wrong.
> Also, many times it is useful to keep a "raw" body for a comment (as
> the user sent it), but also for performance reasons, a "processed"
> version such as html (from markdown or something else). Maybe keeping
> both in the db allows for speedier rendering. Then an application can
> define somewhere (maybe a settings) which function to process the
> comment (markdown, textile, some home made tag removing routine), and
> have that run and then persisting both at the database.
You can always write yourself a filter and render the markup when
required like:
{% get_comment_list for app.model as comment_list %}
{% for comment in comment_list %}
{{ comment.name|escape }}
{{ comment.comment| some_markup }}
{% endfor %}
It doesn't make sense to keep two versions of comments in the
database...but if your's is a specific or a specialized requirement
you are free to write your own custom comments using the same
templatetags (or your own).
--
Cheers
Thejaswi Puthraya
http://thejaswi.info/
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
