Fwd: GSoC Final Report: Django on Jython
-- Forwarded message -- From: Leo Soto M. <[EMAIL PROTECTED]> Date: Sun, Aug 24, 2008 at 2:53 PM Subject: GSoC Final Report: Django on Jython To: JythonDevelopers <[EMAIL PROTECTED]> Looks like many people already know about my SoC results. But I wanted to "officially" finish the SoC reports. Django works on Jython without special patching. The tutorial can be followed without any problems. And Django projects are extremely easy to deploy on a Java Application Server, thanks to modjy. I'd even say that deploying Django/Jython on Java appservers is easiest than Django/CPython on apache/fastcgi/whatever. On the test suite, I wasn't able to fix all of the failures. Django developers did a great job on the testing front, growing from ~200 tests when I started the SoC to more than 400 now. That's a good thing, as it made possible to spot some bugs on Jython, but it makes the task of having fully passing test suite a bit more difficult. By the end of the SoC coding period, we had 92% of Django tests passing. A good number anyway, but should be improved. There is also more work to do on the DB-backends front[1]. I think that we may be able to easy the deployment of projects which mix Django/Jython and Java code. I'm not disappearing now. I want to continue coding and growing the support of Django on Jython. That's why I've started the django-jython project[2]. By now, it doesn't have a separate mailing list, since I don't see why it should. I think we should keep the Django/Jython usage discussions on the jython-users list. Also, I'm now a Jython developer, and have a lot of pending tasks to do on the Jython front which were motivated by my work on Django integration. I won't have as much time as I had before, but I expect to be hanging around here for a long time. Thanks to everyone which helped me on this great experience! [1] http://code.google.com/p/django-jython/wiki/DevelopingNewDatabaseBackends [2] http://code.google.com/p/django-jython/ -- Leo Soto M. http://blog.leosoto.com -- Leo Soto M. http://blog.leosoto.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Exception swallowing in urls.py + admin.autodiscover() == a lot of frustration for developers
On Sun, Aug 24, 2008 at 2:26 AM, James Bennett <[EMAIL PROTECTED]>wrote: > > I stand by what I said in the dev channel yesterday: this is one > instance of a more general issue (there are lots of places where -- > because we need to import or check something -- we can end up > "swallowing" exceptions in this fashion), one which will require time > and thought to deal with, and which should not be tackled piecemeal. I don't understand this argument. At some point fixing this general issue is going to have to involve a piecemeal change of each instance where exceptions are currently swallowed. (Or at least each instance where the swallowing/transforming is causing problems.) How can this not be eventually fixed in a piecemeal fashion? It sounds like maybe you want to design something consistent to do instead and not do anything until that consistent design is developed...is that what you're getting at? > Given that, and the fact that there's a lot of much more critical work > to do, I think the appropriate time to do that is **after** Django > 1.0. This is simple prioritization (and, as others have pointed out to > you, the fact that there hasn't been a big flood of bug > reports/support problems related to this probably indicates it's not > as critical as you're making it out to be). > Except we did, in fact, see a definite spate of reports of this problem after newforms-admin landed in trunk with the recommendation to put admin.autodiscover() in urls.py. (How big is a spate compared to a flood? I don't know, and honestly I didn't keep a count or anything, and have zero interest in doing any archive searching to come up with one.) My sense is we saw a good deal of resulting confusion. If we don't do something to address this particular case of exceptions getting swallowed, I expect we'll see a bigger echo of that spate when 1.0 goes out and people who don't track trunk start updating. This one, I think, is worth fixing sooner rather than later. I don't even know if the others are worth worrying about, since I can't say I recall any people on the users list running into trouble with other cases of this exception-swallowing behavior. This one I definitely have seen causing problems, triggered by newforms-admin causing a lot more code to get executed when urls.py is loaded. Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: validator_list still in docs
Hi there, if this will be deactivated in 1.0, how do I have to replace this? I couldn't find an easy way like this in the docs yet. Regards, Dennis On 23 Aug., 18:43, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Sat, 2008-08-23 at 16:02 +0200, Alex Rades wrote: > > Hi, > > validator_list in model fields (and maybe in form fields too) isn't > > working at the moment. > > > Could we remove it from the docs? > > It will be removed eventually, when all the remaining oldforms stuff is > removed (before 1.0). Also, there's a temporary freeze on docs changes > at the moment until the docs refactor lands. > > Regards, > Malcolm --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
validator_list still in docs
Hi, validator_list in model fields (and maybe in form fields too) isn't working at the moment. Could we remove it from the docs? --~--~-~--~~~---~--~~ 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: validator_list still in docs
On Mon, 2008-08-25 at 05:08 -0700, Dennis Schmidt wrote: > Hi there, > > if this will be deactivated in 1.0, how do I have to replace this? I > couldn't find an easy way like this in the docs yet. Validators are really only used by the admin in 0.96 (there was no model-aware validation there). In 1.0, there will still be no model-aware validation -- we pushed that to post-1.0 a little while ago -- and the admin interface uses forms validation plus a couple of manual checks for things like unique-together. So there isn't a direct replacement for validator lists in 1.0. Regards, Malcolm --~--~-~--~~~---~--~~ 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 IntregrityError and get_or_create test case
Hi Malcolm, I can wrap the execute() and executemany() calls in oracle\base.py in a try/except that re-raises this specific error as an IntegrityError: try: return Database.Cursor.execute(self, query, self._param_generator(params)) except DatabaseError, e: # cx_Oracle <= 4.4.0 wrongly raises a DatabaseError for ORA-01400. if e.message.code == 1400 and type(e) != IntegrityError: e = IntegrityError(e) raise e This seems to work fine, fixes the get_or_create test case, and doesn't require changes outside the oracle backend. Let me know if you think that's acceptable. On Aug 23, 10:47 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Sat, 2008-08-23 at 08:07 -0700, Matt Boersma wrote: > > [...] > > > However, I grep'ed the Django source and found two cases where we > > catch IntegrityError specifically. cx_Oracle probably misbehaves > > there currently, but I'm not sure how common these code paths are and > > what errors could result. > > > Currently, our docs say we require cx_Oracle version 4.2.1 or later. > > It's not reasonable to expect Django users--especially ISPs and > > corporations-- to upgrade to svn trunk and build the driver. We could > > ask Anthony to do a hurry-up 4.4.1 release with this fix in it, but > > even so it's a lot to ask everyone to upgrade to a brand-new > > driver version. On the other hand, we're not talking about a large > > number of Django/Oracle users currently, but that should change when > > we have an official 1.0 release. > > > Opinions? > > I personally don't view this as being controversial. We should make it > work with the current cx_Oracle releases that are in common use. We've > done this before (e.g. MySQL releases, special handling based on version > numbers, etc). Not supporting the active userbase would be dumb. > > I'll have a think about what we can do to handle this properly: I would > definitely like to catch IntegrityError for those databases that support > it, so that other generic DatabaseError situations are *not* caught and > are passed onto whatever higher error handlers are in place. A > backend-specific function for checking the exception type (that is the > default for almost everybody and special for Oracle) and then reraising > if it's not what we want is one solution that comes to mind. Something > like that should be possible. > > Regards, > Malcolm --~--~-~--~~~---~--~~ 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: validator_list still in docs
On Mon, Aug 25, 2008 at 10:12 AM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > So there isn't a direct replacement for validator lists in 1.0. (other than just setting up the form used for your model in the admin to have the validation you want, which isn't terribly hard and is how this sort of stuff should have worked long ago) -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 IntregrityError and get_or_create test case
Hey Matt, On Mon, 2008-08-25 at 08:47 -0700, Matt Boersma wrote: > Hi Malcolm, > > I can wrap the execute() and executemany() calls in oracle\base.py in > a try/except that re-raises this specific error as an IntegrityError: > > try: > return Database.Cursor.execute(self, query, > self._param_generator(params)) > except DatabaseError, e: > # cx_Oracle <= 4.4.0 wrongly raises a DatabaseError for > ORA-01400. > if e.message.code == 1400 and type(e) != IntegrityError: > e = IntegrityError(e) > raise e > > This seems to work fine, fixes the get_or_create test case, and > doesn't require changes outside the oracle backend. Let me know if > you think that's acceptable. I hadn't thought of that, but it looks like the best solution by far. Everybody can then write natural-looking code that catches IntegrityError without having to remember to call some custom Django function to work around a problem they probably don't even know exists. My proposed was way over-engineered in light of this. Regards, Malcolm --~--~-~--~~~---~--~~ 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 IntregrityError and get_or_create test case -- MySQL also
On Mon, Aug 25, 2008 at 12:12 PM, Malcolm Tredinnick < [EMAIL PROTECTED]> wrote: > On Mon, 2008-08-25 at 08:47 -0700, Matt Boersma wrote: > > I can wrap the execute() and executemany() calls in oracle\base.py in > > a try/except that re-raises this specific error as an IntegrityError: > > > > try: > > return Database.Cursor.execute(self, query, > > self._param_generator(params)) > > except DatabaseError, e: > > # cx_Oracle <= 4.4.0 wrongly raises a DatabaseError for > > ORA-01400. > > if e.message.code == 1400 and type(e) != IntegrityError: > > e = IntegrityError(e) > > raise e > > > > This seems to work fine, fixes the get_or_create test case, and > > doesn't require changes outside the oracle backend. Let me know if > > you think that's acceptable. > > I hadn't thought of that, but it looks like the best solution by far. > Everybody can then write natural-looking code that catches > IntegrityError without having to remember to call some custom Django > function to work around a problem they probably don't even know exists. > > I just noticed that the MySQL backend also fails on this get_or_create test. It is returning an OperationalError instead of an IntegrityError. Looks like MySQL returns errno 1364 (ER_NO_DEFAULT_FOR_FIELD) in this case but this is not recognized as anything special in MySQLdb so it's just mapped to a general OperationalError. I don't see a corresponding place in the mysql backend to do the sort of catch & transform you have found to do with Oracle? Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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 IntregrityError and get_or_create test case
On Sat, 2008-08-23 at 08:07 -0700, Matt Boersma wrote: [...] > However, I grep'ed the Django source and found two cases where we > catch IntegrityError specifically. cx_Oracle probably misbehaves > there currently, but I'm not sure how common these code paths are and > what errors could result. > > Currently, our docs say we require cx_Oracle version 4.2.1 or later. > It's not reasonable to expect Django users--especially ISPs and > corporations-- to upgrade to svn trunk and build the driver. We could > ask Anthony to do a hurry-up 4.4.1 release with this fix in it, but > even so it's a lot to ask everyone to upgrade to a brand-new > driver version. On the other hand, we're not talking about a large > number of Django/Oracle users currently, but that should change when > we have an official 1.0 release. > > Opinions? I personally don't view this as being controversial. We should make it work with the current cx_Oracle releases that are in common use. We've done this before (e.g. MySQL releases, special handling based on version numbers, etc). Not supporting the active userbase would be dumb. I'll have a think about what we can do to handle this properly: I would definitely like to catch IntegrityError for those databases that support it, so that other generic DatabaseError situations are *not* caught and are passed onto whatever higher error handlers are in place. A backend-specific function for checking the exception type (that is the default for almost everybody and special for Oracle) and then reraising if it's not what we want is one solution that comes to mind. Something like that should be possible. Regards, Malcolm --~--~-~--~~~---~--~~ 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 IntregrityError and get_or_create test case -- MySQL also
On Aug 25, 10:51 am, "Karen Tracey" <[EMAIL PROTECTED]> wrote: > I just noticed that the MySQL backend also fails on this get_or_create > test. It is returning an OperationalError instead of an IntegrityError. > Looks like MySQL returns errno 1364 (ER_NO_DEFAULT_FOR_FIELD) in this case > but this is not recognized as anything special in MySQLdb so it's just > mapped to a general OperationalError. I don't see a corresponding place in > the mysql backend to do the sort of catch & transform you have found to do > with Oracle? OperationalError according to PEP 249 is for "errors that are related to the database's operation and not necessarily under the control of the programmer, e.g. an unexpected disconnect occurs, the data source name is not found, a transaction could not be processed, a memory allocation error occurred during processing, etc." That doesn't seem to fit an INSERT lacking a NOT NULL value (and no table default value). So at first glance, I'd say that's a bug in MySQLdb that should be rectified so it also raises IntegrityError. And following what I just committed in [8545], we should perhaps find a way to work around the driver so we can rely on IntegrityError in this situation. But since the MySQL backend isn't as customized as Oracle, there's no existing place to trap this. We could add execute() and executemany() to a new MySQLCursor class to fix it similarly, but as Senator Obama likes to say, "that's above my pay grade." > Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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 -~--~~~~--~~--~--~---
mark_safe, escape and conditional_escape
I don't know if this belongs on the dev board, but since it relates to
how the framework acts, I thought I'd give it a shot. Basically, I am
curious as to the function of escape vs. conditional_escape, and the
decision to use the former in the forms.as_x functions...
As far as I can tell, escape escapes a string unconditionally, even if
it's marked as safe (though I don't understand why this should be). I
am in a situation wherein I am trying to model a Dojo Widget as a
Django Widget, and need to make a javascript call with a string
argument. I have mark_safe'd the call in question
attrs['some_element'] = mark_safe("value with unsafe characters") at
the widget level. The problem is, when you get to the form rendering
level, even if a variable is marked safe, it gets escaped.
I've traced the execution and found the culprit to be the
django.forms.util.flatatt function. That is:
from django import forms
from django.utils.safestring import mark_safe
class MyWidget(forms.TextInput):
def __init__(self, *args, **kwargs):
attrs = kwargs.setdefault('attrs', {})
attrs['safe_string'] = "will o' the wisp"
attrs['normal_string'] = "cat o' nine tails"
super(MyWidget, self).__init__(*args, **kwargs)
w = MyWidget()
w.render("field_name", "")
#=> u''
You can see that both the unsafe and safe strings were escaped. I
don't know if this is intentional or not, but it prevents me from
making something like:
because it is always escaping my single-quotes. Is this the desired
behavior? Anyway, like I said, the culprit is:
# django.forms.util
def flatatt(attrs):
"""
Convert a dictionary of attributes to a single
string.
The returned string will contain a leading space followed by
key="value",
XML-style pairs. It is assumed that the keys do not need to be
XML-
escaped.
If the passed dictionary is empty, then return an empty
string.
"""
return u''.join([u' %s="%s"' % (k, escape(v)) for k, v in
attrs.items()]) # <-- right there, the escape(v) call... should this
be conditional_escape?
--~--~-~--~~~---~--~~
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: mark_safe, escape and conditional_escape
On Mon, 2008-08-25 at 10:29 -0700, Alex G wrote: > I don't know if this belongs on the dev board, but since it relates to > how the framework acts, I thought I'd give it a shot. Basically, I am > curious as to the function of escape vs. conditional_escape, and the > decision to use the former in the forms.as_x functions... Since you've just posted essentially the same question to django-users and received a response over there, let's leave the thread going there, rather than having it on two lists at once. Will make it easier for everybody to track. Regards, Malcolm --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
HttpResponse as a file-like object
Devels, I've noticed in the docs that HttpResponse objects, if initialised with an iterator, cannot be used as file-like objects. This could be fixed quite easily. At the moment, if the response was not initialised with a string, then an error is raised when you try to write to it. Instead, all that needs to be done is this (modified from HttpResponse.write() definition): def write(self, content): if not self._is_string: self._container = itertools.chain(self._container, [content]) else: self._container.append(content) In addition, HttpResponse.tell() doesn't allow you to get the position if the HttpResponse uses an iterator. This could be worked around like this: def tell(self): if not self._is_string: self._container, temp_iter = itertools.tee(self._container) else: temp_iter = self._container return sum(len(chunk) for chunk in temp_iter) Regards, Zack --~--~-~--~~~---~--~~ 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: HttpResponse as a file-like object
On Mon, 2008-08-25 at 12:26 -0700, zvoase wrote: > Devels, > I've noticed in the docs that HttpResponse objects, if initialised > with an iterator, cannot be used as file-like objects. This could be > fixed quite easily. There are lots of problems -- some subtle and some obvious -- when initialising HttpResponse objects with iterators. There isn't a single set of simple fixes for all of them, which is why the problems are there. In short, that behaviour isn't really well supported (and that will remain unchanged in 1.0). We might need to update the docs to reflect that fact, but changes to that area of code are out of scope for 1.0, certainly. Regards, Malcolm --~--~-~--~~~---~--~~ 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: HttpResponse as a file-like object
I've written a patch, and I could open a bug with post-1.0 milestone, if that's OK? It's probably a good idea to have a general bug for initialising HttpResponse objects with iterators. On Aug 25, 9:33 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Mon, 2008-08-25 at 12:26 -0700, zvoase wrote: > > Devels, > > I've noticed in the docs that HttpResponse objects, if initialised > > with an iterator, cannot be used as file-like objects. This could be > > fixed quite easily. > > There are lots of problems -- some subtle and some obvious -- when > initialising HttpResponse objects with iterators. There isn't a single > set of simple fixes for all of them, which is why the problems are > there. In short, that behaviour isn't really well supported (and that > will remain unchanged in 1.0). We might need to update the docs to > reflect that fact, but changes to that area of code are out of scope for > 1.0, certainly. > > Regards, > Malcolm --~--~-~--~~~---~--~~ 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: validator_list still in docs
That is neither a direct nor indirect replacement for model-level validation. Many applications receive input from sources other than forms. Validation at the form and model level are both valuable, but for different reasons. Michael On Monday 25 August 2008 11:54:31 James Bennett wrote: > On Mon, Aug 25, 2008 at 10:12 AM, Malcolm Tredinnick > > <[EMAIL PROTECTED]> wrote: > > So there isn't a direct replacement for validator lists in 1.0. > > (other than just setting up the form used for your model in the admin > to have the validation you want, which isn't terribly hard and is how > this sort of stuff should have worked long ago) signature.asc Description: This is a digitally signed message part.
Re: validator_list still in docs
On Mon, Aug 25, 2008 at 7:57 PM, Michael Hrivnak <[EMAIL PROTECTED]>wrote: > That is neither a direct nor indirect replacement for model-level > validation. > Many applications receive input from sources other than forms. Validation > at > the form and model level are both valuable, but for different reasons. > Yes, which is way ticket #6845 is still open. Model-validation hasn't been dropped, just pushed (with reluctance) to post-1.0. Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: validator_list still in docs
On Mon, 2008-08-25 at 19:57 -0400, Michael Hrivnak wrote: > That is neither a direct nor indirect replacement for model-level validation. > > Many applications receive input from sources other than forms. Validation at > the form and model level are both valuable, but for different reasons. It is an indirect way to achieve something very close. Nothing requires that the data you pass to a ModelForm class has to come from an HTML form submission, so the restriction you mention doesn't actually exist. :-) So you can create a ModelForm, pass in a model instance, check is_valid() and then carry on if things pass. Is it a bit of a hack? Yes. Will it suffice for the time being until model-validation is available? Also yes, since we don't have a choice. Regards, Malcolm --~--~-~--~~~---~--~~ 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: DjangoCon meetup Friday Sept 5
I tried to contact the TWID gusy through their website, but I haven't heard back from them. Anyone know if they're still planning a get together? On Aug 21, 2:01 am, "Mike Scott" <[EMAIL PROTECTED]> wrote: > err, link doesn't seem to work with www for me, so try: > > http://thisweekindjango.com/ > > On Thu, Aug 21, 2008 at 9:01 PM, Mike Scott <[EMAIL PROTECTED]> wrote: > > > On Thu, Aug 21, 2008 at 7:54 PM, Jonathan Nelson <[EMAIL PROTECTED]>wrote: > > >> TWID guys? I'd be happy to combine groups. I just don't know who > >> that is. > > > "This week in django" crew -http://www.thisweekindjango.com/only the > > premier podcast resource for django-aholics. > > > Get in touch with one of them, contacts details are available on said > > website. > > --~--~-~--~~~---~--~~ 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: Status Post of Django-newcomments
Any thoughts on when a beta is going to be released? On Aug 10, 8:50 pm, Thejaswi Puthraya <[EMAIL PROTECTED]> wrote: > Hello, > It's been more than three months since I started working on django- > newcomments. Ideally, I wished to complete most of my work by July but > for a relocation and lack of internet connectivity for a major period. > > In this post, I would like to summarize my work done on the comments > (which hopefully might make it as django.contrib.comments). > > Since, I was working on a codebase provided by Jacob, my aim was not > to make too many changes and at the same time wanted to incorporate > certain features (inspired from other projects). > > During the summer, I was able to work on: > * Updating the code from Jacob's repo [1] to get it in line with the > current trunk. > * Adding threaded comments feature. Thanks to Eric Florenzano's django- > threadedcomments [2] for the inspiration. > * Easy customization of comments app. > * Migration of the moderation queue to newforms-admin. > * Writing a transition script for the migrating comments from old- > comments to new-comments. > * Writing more tests and brief docs. > > The feature that didn't get in: > * I thought of quite a few ideas on how to integrate a spam-filter but > realized that comment-utils [3] handled it best. So, I sent out a mail > to James, requesting if I could use the CommentModerator class for > moderation (templatetags and other custom moderators would still be > with comment-utils, only the base functionality to be incorporated > into newcomments). I haven't received a reply from him (must be > slumped with work), so there is no spam filter for the moment. If I do > get a reply I would love to push it in. > > For the next week (or till before the first beta is out) I would like > to work majorly on bug-fixes, the spam filter and other small tweaks > required for integration. > > Blockers for integration as django.contrib.comments: > * newcomments shouldn't be pushed into trunk unless #7154 [4] is > fixed. > > That was not much work for a summer, but it was a nice learning > experience reading good code, interacting with my mentor and working > on the project. > > I would like to thank the following people: > * Jacob for writing some wonderful code that I could use > * Jannis Leidel (my mentor) for trusting me and giving me a free hand > in choosing the approach and constantly reminding of my goal. > * Eric Florenzano for the threaded-comments inspiration. > * Jonathan Buchanan's django-mptt for the two wonderful links on how > to store hierarchical data in a database, thus justifying the approach > taken for threaded comments. > * James for comment-utils. During the course of the project, I got to > check out his project and it's fabulous. I am thanking him in advance > hoping that he'll let me use part of his code ;-) > * Kenneth Gonsalves and NRCFOSS for helping me out with an internet > connection when I needed it the most. > * The other members of the community for their excellent work on nfa, > qs-rf, signals-rf and other general suggestions. > > Phew...that was a long list :) > > The code of the project lies athttp://code.google.com/p/django-newcomments/ > andhttp://gitorious.org/projects/django-newcomments/ > > [1]http://toys.jacobian.org/hg/django-newcomments/ > [2]http://code.google.com/p/django-threadedcomments/ > [3]http://code.google.com/p/django-comment-utils/ > [4]http://code.djangoproject.com/ticket/7154 > > -- > 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: Status Post of Django-newcomments
django-newcomments is now in trunk. On Aug 25, 8:41 pm, Jonathan Nelson <[EMAIL PROTECTED]> wrote: > Any thoughts on when a beta is going to be released? > > On Aug 10, 8:50 pm, Thejaswi Puthraya <[EMAIL PROTECTED]> > wrote: > > > Hello, > > It's been more than three months since I started working on django- > > newcomments. Ideally, I wished to complete most of my work by July but > > for a relocation and lack of internet connectivity for a major period. > > > In this post, I would like to summarize my work done on the comments > > (which hopefully might make it as django.contrib.comments). > > > Since, I was working on a codebase provided by Jacob, my aim was not > > to make too many changes and at the same time wanted to incorporate > > certain features (inspired from other projects). > > > During the summer, I was able to work on: > > * Updating the code from Jacob's repo [1] to get it in line with the > > current trunk. > > * Adding threaded comments feature. Thanks to Eric Florenzano's django- > > threadedcomments [2] for the inspiration. > > * Easy customization of comments app. > > * Migration of the moderation queue to newforms-admin. > > * Writing a transition script for the migrating comments from old- > > comments to new-comments. > > * Writing more tests and brief docs. > > > The feature that didn't get in: > > * I thought of quite a few ideas on how to integrate a spam-filter but > > realized that comment-utils [3] handled it best. So, I sent out a mail > > to James, requesting if I could use the CommentModerator class for > > moderation (templatetags and other custom moderators would still be > > with comment-utils, only the base functionality to be incorporated > > into newcomments). I haven't received a reply from him (must be > > slumped with work), so there is no spam filter for the moment. If I do > > get a reply I would love to push it in. > > > For the next week (or till before the first beta is out) I would like > > to work majorly on bug-fixes, the spam filter and other small tweaks > > required for integration. > > > Blockers for integration as django.contrib.comments: > > * newcomments shouldn't be pushed into trunk unless #7154 [4] is > > fixed. > > > That was not much work for a summer, but it was a nice learning > > experience reading good code, interacting with my mentor and working > > on the project. > > > I would like to thank the following people: > > * Jacob for writing some wonderful code that I could use > > * Jannis Leidel (my mentor) for trusting me and giving me a free hand > > in choosing the approach and constantly reminding of my goal. > > * Eric Florenzano for the threaded-comments inspiration. > > * Jonathan Buchanan's django-mptt for the two wonderful links on how > > to store hierarchical data in a database, thus justifying the approach > > taken for threaded comments. > > * James for comment-utils. During the course of the project, I got to > > check out his project and it's fabulous. I am thanking him in advance > > hoping that he'll let me use part of his code ;-) > > * Kenneth Gonsalves and NRCFOSS for helping me out with an internet > > connection when I needed it the most. > > * The other members of the community for their excellent work on nfa, > > qs-rf, signals-rf and other general suggestions. > > > Phew...that was a long list :) > > > The code of the project lies athttp://code.google.com/p/django-newcomments/ > > andhttp://gitorious.org/projects/django-newcomments/ > > > [1]http://toys.jacobian.org/hg/django-newcomments/ > > [2]http://code.google.com/p/django-threadedcomments/ > > [3]http://code.google.com/p/django-comment-utils/ > > [4]http://code.djangoproject.com/ticket/7154 > > > -- > > 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: Status Post of Django-newcomments
On Mon, 2008-08-25 at 17:41 -0700, Jonathan Nelson wrote: > Any thoughts on when a beta is going to be released? Thejaswi's code was reviewed and given a final polish by Jacob over the last couple of weeks and it was committed to trunk a few hours ago. It will be in the next release or you can update to subversion trunk and/or read the docs online at docs.djangoproject.com. Regards, Malcolm --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
