Re: ImportError at/ No module name
We just tripped across something similar here as well. The person doing the
tutorial had flipped the 'startup' and 'put "blog" in the INSTALLED_APPS'
steps of the tutorial. She commented out 'blog' from INSTALLED_APPS and
startapp worked as intended.
-scott
On Sunday, August 11, 2013 at 8:11:11 PM UTC-4, Pranay Shah wrote:
>
> I just want to thank everyone. I had an error "no module name image" since
> yesterday nite. I googled and found out that I need to install python image
> library. I did that. I still continued getting error. Just then I came
> across this post where someone was getting "no module... blog". I read it
> and found out the prob. Initially I had an "image" view which I deleted
> last nite as I was no longer gonna use it. But I didnt remove its mapping
> form the urls.py. I commented the lines for image - views and it worked.
>
> Thank you all. Now I shall start working on the actual stuff which I was
> supposed to work from last nite. Its actually my internship homework.
>
> Thank you once again.
>
> On Thursday, 20 December 2012 05:27:42 UTC-8, djangobie wrote:
>>
>> Hi, I have just started practicing a tutorial for buidling a basic blog
>> (
>> http://www.djangorocks.com/tutorials/how-to-create-a-basic-blog-in-django/starting-your-application.html
>> )
>>
>> Did exactly the same (except, using 'djangopractice' as project name
>> instead of 'djangorocks')
>> Actually It also did run twice, but than started showing ImportError.
>>
>> My files:
>>
>> ***settings.py***
>>
>> # Django settings for djangopractice project.
>> #import os, django
>> #DJANGO_ROOT = os.path.dirname(os.path.realpath(django.__file__))
>> #SITE_ROOT = os.path.dirname(os.path.realpath('__file__'))
>>
>> DEBUG = True
>> TEMPLATE_DEBUG = DEBUG
>>
>> ADMINS = (
>> # ('Your Name', 'your_...@example.com'),
>> )
>>
>> MANAGERS = ADMINS
>>
>> DATABASES = {
>> 'default': {
>> 'ENGINE': 'django.db.backends.mysql', # Add
>> 'postgresql_psycopg2', 'mysql', 'sqlite3' or 'oracle'.
>> 'NAME': 'djangopractice', # Or path to
>> database file if using sqlite3.
>> 'USER': 'root', # Not used with sqlite3.
>> 'PASSWORD': '1290', # Not used with sqlite3.
>> 'HOST': '', # Set to empty string for
>> localhost. Not used with sqlite3.
>> 'PORT': '', # Set to empty string for
>> default. Not used with sqlite3.
>> }
>> }
>>
>> # Local time zone for this installation. Choices can be found here:
>> # http://en.wikipedia.org/wiki/List_of_tz_zones_by_name
>> # although not all choices may be available on all operating systems.
>> # In a Windows environment this must be set to your system time zone.
>> TIME_ZONE = 'Asia/Karachi'
>>
>> # Language code for this installation. All choices can be found here:
>> # http://www.i18nguy.com/unicode/language-identifiers.html
>> LANGUAGE_CODE = 'en-us'
>>
>> SITE_ID = 1
>>
>> # If you set this to False, Django will make some optimizations so as not
>> # to load the internationalization machinery.
>> USE_I18N = True
>>
>> # If you set this to False, Django will not format dates, numbers and
>> # calendars according to the current locale.
>> USE_L10N = True
>>
>> # If you set this to False, Django will not use timezone-aware datetimes.
>> USE_TZ = True
>>
>> # Absolute filesystem path to the directory that will hold user-uploaded
>> files.
>> # Example: "/home/media/media.lawrence.com/media/"
>> MEDIA_ROOT = ''
>>
>> # URL that handles the media served from MEDIA_ROOT. Make sure to use a
>> # trailing slash.
>> # Examples: "http://media.lawrence.com/media/";, "
>> http://example.com/media/";
>> MEDIA_URL = ''
>>
>> # Absolute path to the directory static files should be collected to.
>> # Don't put anything in this directory yourself; store your static files
>> # in apps' "static/" subdirectories and in STATICFILES_DIRS.
>> # Example: "/home/media/media.lawrence.com/static/"
>> STATIC_ROOT = ''
>>
>> # URL prefix for static files.
>> # Example: "http://media.lawrence.com/static/";
>> STATIC_URL = '/static/'
>>
>> # Additional locations of static files
>> STATICFILES_DIRS = (
>> # Put strings here, like "/home/html/static" or
>> "C:/www/django/static".
>> # Always use forward slashes, even on Windows.
>> # Don't forget to use absolute paths, not relative paths.
>> )
>>
>> # List of finder classes that know how to find static files in
>> # various locations.
>> STATICFILES_FINDERS = (
>> 'django.contrib.staticfiles.finders.FileSystemFinder',
>> 'django.contrib.staticfiles.finders.AppDirectoriesFinder',
>> #'django.contrib.staticfiles.finders.DefaultStorageFinder',
>> )
>>
>> # Make this unique, and don't share it with anybody.
>> SECRET_KEY = '@io!2+0*rw1o0tjq%t5zb8e$v(wf3p#yk_8#lb^%hrerzijwt1'
>>
>> # List of callables that know how to import templates from various
Re: Question about static file serving strategy with S3 and Cloudfront
This is what we do, although we don't use query strings as some network
appliances don't respect them with respect to caching.
We use a virtual directory instead:
//example.com/static//images/blancmange.png
Where is obtained like this:
$ git log --oneline | wc -l | awk '{ print $1; }'
And nginx removes the virtual directory like this:
location ~ /static/([0-9]+)/ {
rewrite ^/static/([0-9]+)/(.+)$ /static/$2 last;
}
Static files are cached for a year:
location /static {
alias {{ web_static_dir }};
expires 1y;
add_header Cache-Control
"no-transform,public,max-age=31557600,s-maxage=31557600";
gzip on;
}
So a static file will be cached "forever" unless we do a release, at which
point the virtual directory changes to the new version and clients start
requesting (to them) a completely new static file.
Also note we don't copy to S3 as there's no way to do the virtual directory
without having a real directory for every release. CloudFront will read
files from a web site as well, and we don't need the extra deployment
complexity.
Regards,
-scott
On Wednesday, July 2, 2014 3:20:34 PM UTC-4, Cal Leeming [Simplicity Media
Ltd] wrote:
>
> You also have to consider client side caching, despite if you use the
> correct headers or not.
>
> One option is to use a cache buster using a value which changes on each
> release, but I'd advise against using random() cache buster as your caching
> efficiency will be impacted.
>
> //example.com/static/images.jpg?release=1000
> //example.com/static/images.jpg?release=1001
>
> Cal
>
>
> On Wed, Jul 2, 2014 at 7:08 PM, Chen Xu >
> wrote:
>
>> Hi Everyone,
>>
>> I am currently using the following strategy to serve my static files,
>> basically I run collectstatic to copy all my files to my static files
>> directory, and then move it to s3, and cloudfront will pick it up from
>> there. However, I wonder if I set the cache period to be 1 day in my
>> cloudfront, and I upload new updated files to s3, are the files still going
>> to be the old ones until next time the cache expires?
>>
>>
>> Thanks
>>
>> --
>> ⚡ Chen Xu ⚡
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-users...@googlegroups.com .
>> To post to this group, send email to django...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/django-users.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-users/CACac-qYBa0Pg0eYQfoVGNTk2jHXC2Y100-xkHAo0AA7%2Bk3cw_w%40mail.gmail.com
>>
>>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/1adfeb0a-8735-4d21-9d8d-4c8a97e8e7c2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: django-php - yeah, it happened.
On Feb 28, 2014, at 1:51 PM, Rafał Pitoń wrote: > You should give Jinja and projects like django-jinja a look then. They are > exactly what you want: Twig like template system for Django. Thanks, but that’s not the piece I need. I’m happy with Django’s templates and I want to use them in JavaScript like Twig allows. Unfortunately Twig is just different enough to Not Work out of the box. Swig might get us there (http://paularmstrong.github.io/swig/), but I haven’t looked into it enough. -scott -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/2D879821-F290-493E-A8AC-9A02C64C320C%40gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: django-php - yeah, it happened.
Well, things like Twig are based on Django templates. We're currently migrating from PHP to Django, and if something like Django-PHP made that easier I would most definitely use it. To be honest I wish there were a Twig-like solution for Django. We're going to try adding the missing tags to the Django template system to match what we're using in Twig. -scott On Thursday, February 27, 2014 6:30:49 PM UTC-5, Cal Leeming [Simplicity Media Ltd] wrote: > > Clearly this should be considered for merge into the core; > https://github.com/mvasilkov/django-php > > The really sad part: someone somewhere *will* use this in production, and > be totally srs about it. > > Excuse me whilst I cry myself to sleep. > > Cal > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/766ce944-4af5-41e0-9b68-c9175c9d1aff%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Terrible performance when dropping into raw SQL Oracle
Are you timing the query in the view specifically, or the entire view? That
is, do you know for sure that it is *only* the query that is taking 16
seconds and not the rest of the view?
-scott
On Wednesday, February 26, 2014 5:53:15 PM UTC-5, Shawn H wrote:
>
> I said that before testing it. The exact same code using cx_Oracle takes
> ~4 seconds outside of the django environment, but still takes ~16 seconds
> when running in the django view. What the heck is going on? Updated
> portion of code below
>
> cnxn = cx_Oracle.connect('notification/notifydev@landmgm')
> cursor = cx_Oracle.Cursor(cnxn) #connections['landtest_11'].cursor()
> print datetime.datetime.now()
> cursor.execute('SELECT count(1) from (SELECT DISTINCT RECORDNUMB FROM
> DEVGIS.NOTICED_PARCELS WHERE CASE_NUMBER = &s AND RECORDNUMB > 0 UNION \
> SELECT DISTINCT RECORDNUMB FROM DEVGIS.CONDONOTICE WHERE CASE_NUMBER = &s
> AND RECORDNUMB > 0)', [case_number, case_number])
> print datetime.datetime.now()
> number_count = cursor.fetchone()
>
>
> On Wednesday, February 26, 2014 4:41:06 PM UTC-6, Shawn H wrote:
>>
>> Because this worked so well, I've gone directly to cx_Oracle in my django
>> view and used that to get the result in the 4 seconds. There is definitely
>> a problem with the Django implementation - I wonder if perhaps the indexes
>> on the tables aren't being used properly.
>>
>> On Wednesday, February 26, 2014 3:49:47 PM UTC-6, Shawn H wrote:
>>>
>>> 3.8 seconds. It seems to be django, not cx_Oracle.
>>>
>>> On Wednesday, February 26, 2014 2:50:58 PM UTC-6, Shawn H wrote:
Good idea. I'll try that and report back
On Wednesday, February 26, 2014 1:22:52 PM UTC-6, Tom Evans wrote:
>
> On Wed, Feb 26, 2014 at 6:16 PM, Shawn H wrote:
> > Yes. I've tested with several case numbers, and I'm using a similar
> > parameterized approach in my gui Oracle client as well, with the
> same
> > results. It's always about 3 to 4 times slower running via django.
> I've
> > tried it both on my local development web server as well as my
> production
> > apache linux box, and it always takes much longer running via
> django.
> >
> >
>
> If you write a standard python program, ie not using django, but still
> using whatever oracle DB adapter Django uses, that connects to your
> oracle server and executes the query, is it still slow?
>
> IE is the problem something django does, or how the adapter works.
>
> Cheers
>
> Tom
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/23506457-089b-4b1c-815c-c5ddbad79e32%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: new to Django and building web applications. Advice with postgresql
On May 21, 2013, at 8:04 AM, Tom Evans wrote:
>
> The purpose of using an ORM is to make your application database
> agnostic. You should not find that changing DB engine is overly
> taxing.
Theoretically, yes. The difference between theory and practice is very small in
theory, and not so much in practice. ;-)
Theoretically, the ORM should protect you from differences between databases.
In practice, this doesn't always happen.
There *are* real world differences between running different databases on the
same ORM. Quoting the purpose of an ORM and telling someone they "should not"
have a problem is naive, sorry.
While some of these differences can be avoided, doing so requires the developer
to know that they exist in the first place, thus negating the purpose of using
an ORM. Given the character of the question by the original poster, I suspect
he might have issues with this.
PostgreSQL is very strict by default. SQLite is very forgiving.
You can also run into problems with South migrations working on one and not the
other.
> Not all of these statements are wholly accurate, mysql will re-use
> keys when necessary (but doesn't try to 'back fill' the set of used
> ids), and
The statements don't need to be "wholly accurate". The behavior is different in
practice.
> mysql is also perfectly happy with 0 as a primary key, but
> will replace it with the next auto increment id if the field is an
> auto increment field.
class Moo(models.Model):
name = models.CharField(max_length=50)
moo.json:
[
{
"pk": 0,
"model": "test.moo",
"fields": {
"name": "Test"
}
}
]
Running as MySQL:
anderson$ python manage.py loaddata moo.json
ValueError: Problem installing fixture
'/Users/anderson/src/.../fixtures/moo_genre.json': The database backend does
not accept 0 as a value for AutoField.
Running as Sqlite:
anderson$ python manage.py loaddata moo.json
Installed 1 object(s) from 1 fixture(s)
If your real world dataset includes a row with 0 as the primary key, you need
to be aware of this.
> There is no 'natural ordering' of un-ordered
> results, the order is undefined, and undefined behaviour is undefined.
In theory, yes. However, the naive developer may observe that this ordering is
actually implementation-specific under the hood and write code based on that
fact, and in doing so tie the code to a particular implementation. Yes, you
should always include an order_by if your use case depends on ordering. No, not
everyone realizes that.
> The point is, installing and learning the ins and outs of an RDBMS is
> not necessary to using Django. If you think you are stuck trying to
> install or understand postgres, just ignore it and use sqlite. You can
> always change at a later date.
And my point is that there remain ins and outs of the various database backends
that prevent seamless migration between them.
At some point you will need to install and test on your production database.
Why not do it first and avoid possible incompatibilities between dev and
production down the way?
If you're just learning, that's fine. No need. But as soon as you're on an
actual project, do yourself a favor and develop on the platform you plan on
using in production.
Regards,
-scott
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: new to Django and building web applications. Advice with postgresql
On Sunday, May 19, 2013 11:18:07 AM UTC-4, WongoBongo wrote: > You don't have to become an expert with postgres to use Django. You can do > most of the db development using SQLite and hold off on postgres until you > are ready to deploy. I highly recommend *against* waiting for PostgreSQL until deployment. There are significant differences between SQLite, PostgreSQL, and MySQL. If you wait until deployment to test on your production database you will find yourself fixing and changing things at the last minute. Start testing on your production deployment database as soon as possible. Even if you are using an ORM there are enough differences between the databases (and/or their drivers!) that you can run into issues. Four examples of MySQL vs. SQLite, but the same recommendation holds true for PostgreSQL as well: 1) MySQL truncates DateTimeFields to the second; SQLite stores the milliseconds. 2) SQLite can re-use keys if a row is deleted; MySQL will not. This can affect unit tests. 3) Each database may use a different natural order when no ORDER BY is used. 4) SQLite allows 0 as a PK, MySQL does not. Also, you'll benefit from the exercise of setting up and using the same database you'll see in production. Regards, -scott -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: How many workers do you run on one machine using django celery?
You can't test a system like this by sending one message: you're just testing the latency, not throughput. Latency is the end-to-end time it takes for a single message to make its way through the system. Throughput is the number of total messages per second that can make their way through. As long as your tasks are not sensitive to delays (SMS messages are not, generally), a queueing system can help greatly increase the overall throughput. Queueing systems are for spreading work around so they can be completed *in aggregate* more quickly and reliably. They're not for reducing the latency of a single message. SQS in particular is architected for massive scale and reliability. To achieve this the latency for a single message is very high, but it can handle millions and millions of messages per second overall. If you test with a single thread feeding and a single thread reading (as in the amazon-sqs-vs-rabbitmq blog) you're strictly testing queue latency, not throughput. Time taken to process all of the messages will look something like this, where: Nm= number of messages Ts = SQS latency, or 3 to 4s from your tests Te = time to process a message for enqueuing Td = time to process a dequeued task Ne = number of enqueue workers Nd = number of dequeue workers *As long as Ne * Te <= Nd * Td (ie. the enqueue workers can keep up with the dequeuing workers)*, the total time to process Nm messages will look like this: Te + Ts + (ceil(Nm / Nd) * Td) Or: You can starve a queueing system on the front as well as the back (which is what that blog post does). So here's a more appropriate test: Nm = 100,000 messages Ts = 4s Te = 20ms, time to ready a message to send Td = 200ms, time for the task to process a message Ne = 1 thread putting messages on the queue Nd = 10 threads pulling messages from the queue You'll probably find that the entire thing will take this much time: 20ms + 4s + (ceil(100,000 / 10) * 200ms), or just over 2004s. Up the enqueue threads to 10, and dequeue workers to 100: 20ms + 4s + (ceil(100,000 / 100) * 200ms), or just over 204s. Note that the SQS latency is a constant, however. In other words, it will take 3-4 seconds to get a message through the queue, and then whatever your task execution time is, all for any individual message. But you'll be processing 10 at a time through this pipeline. Increase the number of enqueuers and dequeuers and your throughput will scale linearly, assuming you spread the workers amongst enough EC2 instances to handle the load of the tasks themselves. You're trading end-to-end latency for higher throughput. If you only send 1 message though, it looks like this with 1, 10, and 100 dequeue workers: 20ms + 4s + (ceil(1 / 1) * 200ms) == 4020ms + (1 * 200ms) == 4.22s 20ms + 4s + (ceil(1 / 10) * 200ms) == 4020ms + (1 * 200ms) == 4.22s 20ms + 4s + (ceil(1 / 100) * 200ms) == 4020ms + (1 * 200ms) == 4.22s So, at a single message you're testing latency only, not throughput. For the visual folk out there, in this amazingly well-rendered ASCII representation of a parallel communication system each line is a message, the distance between Start and End is the latency, and the height of the stack is throughput, and the distance from the first start to the last end is the amount of time it takes to process all of the messages. What you tested: (Start == End) < 4s > What you would test with 5 workers enqueuing and dequeuing in parallel: (Start == End) (Start == End) (Start == End) (Start == End) (Start == End) (Start == End) <- 4s + N > Where N is based on the parallel execution time of individual tasks by the dequeue workers. A single RabbitMQ system will have much lower latency but won't be able to handle the high aggregate throughput of SQS, and at higher message rates will fall behind. (Start = End)(Start = End)(Start = End) (Start = End)(Start = End)(Start = End) <--> Obviously this is neither to scale nor truly representative, but hopefully it helps to illustrate the point. The takeaway is that the more dequeue workers you have, the more overall throughput a system like SQS can give you (modulus EC2 time for RabbitMQ vs. SQS costs, which is a completely different discussion). That said if you feel like maintaining your own RabbitMQ cluster with the maintenance that it would entail, for lower message throughputs RabbitMQ may be cheaper for the same throughput. Regards, -scott On Sunday, April 21, 2013 5:47:40 AM UTC-4, sparky wrote: > > One last thing to add, the task it's self does not seems to be the issue, > 'got message from broker' is the 3-4 second wait I can see. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr
Re: Django-Registration/Custom Authentication Issue
That's good to know. How stable is it? -scott Via mobile phone On Apr 17, 2013, at 3:52 AM, James Bennett wrote: Current hg tip is actually 1.5-compatible, in the sense that if you want to use your own User model, you just subclass the provided stuff and plug in your model, either importing directly or using the helper function in Django 1.5. django-registration does not do this itself because 1. Using Django 1.5's helpers requires either extra complication of the imports, or a break with Django 1.4 compatibility, and 2. If you're using a custom User model, you will by definition be wanting to subclass and override the default fields, validation logic, etc., since only a User model identical to django.contrib.auth.models.User works with the defaults. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Django-Registration/Custom Authentication Issue
Django registration is not compatible with custom user models in Django 1.5, as it directly references django.contrib.auth.models.User in several places. If you want to maintain your own copy you can swap those refs for those of your own User model. -scott Via mobile phone On Apr 16, 2013, at 9:59 PM, Rainy wrote: On Sunday, April 14, 2013 9:49:32 PM UTC-4, Lee Hinde wrote: > > I'm trying to do a 'simple' registration with just a user email and > password required to create an account. I'm using django-registration with > django 1.5.1 and have created a custom model and the custom model manager. > > I can hit all the registration forms just fine and have copied the example > from the django docs (ignoring, temporarily, the admonition not to do > that.). > > I've created a custom backend in django-registration, basically to remove > the username requirement. In fact, my custom backend is identical to the > default, minus any references to the username. > > When I try to create a new user (i.e, submit the form), from > /accounts/register/ I get the following error: > > AttributeError at /accounts/register/ > Manager isn't available; User has been swapped for 'letters.PCSUser' > > The full trace back is: > > File "/Library/Python/2.7/site-packages/django/core/handlers/base.py" in > get_response > 115. response = callback(request, > *callback_args, **callback_kwargs) > File "/Library/Python/2.7/site-packages/django/views/generic/base.py" in > view > 68. return self.dispatch(request, *args, **kwargs) > File > "/Users/leehinde/Documents/Clients/ProfessionalCreditSolutions/pcs/pcs/registration/views.py" > in dispatch > 79. return super(RegistrationView, self).dispatch(request, > *args, **kwargs) > File "/Library/Python/2.7/site-packages/django/views/generic/base.py" in > dispatch > 86. return handler(request, *args, **kwargs) > File > "/Users/leehinde/Documents/Clients/ProfessionalCreditSolutions/pcs/pcs/registration/views.py" > in post > 35. return self.form_valid(request, form) > File > "/Users/leehinde/Documents/Clients/ProfessionalCreditSolutions/pcs/pcs/registration/views.py" > in form_valid > 82. new_user = self.register(request, **form.cleaned_data) > File > "/Users/leehinde/Documents/Clients/ProfessionalCreditSolutions/pcs/pcs/registration/backends/pcs/views.py" > in register > 80. > password, site) > File "/Library/Python/2.7/site-packages/django/db/transaction.py" in inner > 223. return func(*args, **kwargs) > File > "/Users/leehinde/Documents/Clients/ProfessionalCreditSolutions/pcs/pcs/registration/models.py" > in create_inactive_user > 78. new_user = User.objects.create_user( email, password) > File "/Library/Python/2.7/site-packages/django/db/models/manager.py" in > __get__ > 256. self.model._meta.object_name, self.model._meta.swapped > > > No doubt I've left out some needed component to show why this error is > coming up, but I'm not sure what. I'm grateful for any pointers on where I > should be looking. > > > I believe the issue is that you need to define usermanager on your custom user, and you will possibly need to inherit from django usermanager and override it to not use username anywhere. But at the very least, you need to do something like: import UserManager from wherever class CustomUser(User): objects = UserManager() -ak -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: make_template_fragment_key is in what version?
Derp, my fault, thanks. I don't know how I missed that. Odd that that was the page that showed up first in the search results too. Regards, -scott On Apr 11, 2013, at 8:24 PM, James Bennett wrote: > Notice that your URL marks the version of Django as 'dev' -- that means it's > the documentation for the next, and as-yet-unreleased, version of Django, > which will be 1.6. > > For the documentation for 1.5, change 'dev' in the URL to '1.5' (which is > also what will happen when you click the 'Documentation' link on > djangoproject.com; it points to the most recent released version): > > https://docs.djangoproject.com/en/1.5/topics/cache/ > > Which, you'll notice, does not mention this function since it doesn't exist > in 1.5. > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-users+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@googlegroups.com. > Visit this group at http://groups.google.com/group/django-users?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > smime.p7s Description: S/MIME cryptographic signature
make_template_fragment_key is in what version?
Hello all,
The public current version cache docs reference make_template_cache_key:
https://docs.djangoproject.com/en/dev/topics/cache/
django.core.cache.utils.make_template_fragment_key(fragment_name, vary_on=None)
If you want to obtain the cache key used for a cached fragment, you can use
make_template_fragment_key. fragment_name is the same as second argument to the
cache template tag; vary_on is a list of all additional arguments passed to the
tag. This function can be useful for invalidating or overwriting a cached item,
for example:
>>> from django.core.cache import cache
>>> from django.core.cache.utils import make_template_fragment_key
# cache key for {% cache 500 sidebar username %}
>>> key = make_template_fragment_key('sidebar', [username])
>>> cache.delete(key) # invalidates cached template fragment
As created for this ticket a few months ago:
https://code.djangoproject.com/ticket/19253
I've got the most recent version of Django (1.5.1) but this code is nowhere to
be found:
(moo)bigberet:~/src/tmp/moo anderson$ django-admin.py startproject blancmange
(moo)bigberet:~/src/tmp/moo anderson$ cd blancmange/
(moo)bigberet:~/src/tmp/moo/blancmange anderson$ python manage.py shell
Python 2.7.1 (r271:86832, Jul 31 2011, 19:30:53)
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> from django.core.cache.utils import make_template_fragment_key
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named utils
>>> import django
>>> django.VERSION
(1, 5, 1, 'final', 0)
>>>
Regards,
-scott
smime.p7s
Description: S/MIME cryptographic signature
Re: Arithmetic operations in a templete
Yes, that's always the fall back, isn't it? I'll look at Jinja, as I didn't realize there was such a fork. Apparently I'm not the only one who thinks this way. I'm concerned with how well a solution like this tracks the Django release. However, simply dodging the question doesn't address the original point: why does Django adhere to such a nannyish philosophy, and how do you solve the problem I presented *within Django* in a reasonable way? Thanks and regards, -scott anderson On Thu, 2007-09-13 at 23:46 -0500, James Bennett wrote: > On 9/13/07, Scott Anderson <[EMAIL PROTECTED]> wrote: > > What I'm hoping, however, is that this missive was moot, because you'll > > say, "no, Scott, you should just do *this*:", followed by an elegant and > > reasonable solution that I, as a relative newcomer to Django, have not > > yet considered. Here's to your reply, and cheers! > > OK, here you go: > > Use another template system, either site-wide or for the cases where > the Django template system isn't doing what you need. It's not hard to > do this, and it opens up the possibility of using any or all of the > vast number of Python template systems available. > > The Django template system, at this point, will almost certainly > *never* include the type of functionality you're asking for, so use > another template system that does or that's more willing to bend its > philosophy to suit what you want. If you like the rest of the Django > template system I'd suggest you try Jinja, which started as a fork of > Django's template system and so is nearly feature-for-feature > identical, but adds arbitrary Python expressions. > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Arithmetic operations in a templete
Thank you, but that's exactly what I said I *didn't* want to do, because it's silly. :-) Why should my *data model* know *anything* about the presentation? And what happens when I want a parrot row ID, or a parrot foo ID, or a parrot cheese ID? Suddenly I have a proliferation of things in my data model that have jack all to do with the data, and everything to do with a particular implementation of a particular view. And then don't forget the Sloth Button ID as well... so if I have two different data objects with similar presentation needs (but no other similarities beyond that), I have to either a) introduce an inheritance dependency that really makes no sense or b) duplicate a lot of code. And then there's the fact that I can't use my nice generic button tag with anything other than data that understands how it's supposed to be displayed by a particular tag. Regards, -scott anderson On Fri, 2007-09-14 at 09:14 +, Samuel Adam wrote: > no, Scott, you should just do *this*: > > In your Parrot model, you could add a property that displays your DOM > id. > > class Parrot(models.Model): > # fields > > def _domid(self): > return ''parrotButton-%s" % self.id > domid = property(_domid) > > and use parrot.domid in your templates. > > On 14 sep, 06:46, "James Bennett" <[EMAIL PROTECTED]> wrote: > > On 9/13/07, Scott Anderson <[EMAIL PROTECTED]> wrote: > > > > > What I'm hoping, however, is that this missive was moot, because you'll > > > say, "no, Scott, you should just do *this*:", followed by an elegant and > > > reasonable solution that I, as a relative newcomer to Django, have not > > > yet considered. Here's to your reply, and cheers! > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Arithmetic operations in a templete
ep this particular construction as close to where it is
used as possible. I also don't want a function on the Parrot itself that
knows to create "parrotButton-" + self.id... that's just silly. In fact,
my view code really shouldn't care if it's using an HTML template with
"Choose me!" buttons, an Excel template with a "Choose me!" macro, an
email with a "Choose me!" link, or a pigeon-carrier-wave cuneiform
tablet template with, er, "Choose me!" sticky notes made of Leicester
cheese and tar. It provides data, and whiz-bango
ala-peanut-butter-sandwiches-with-mayo, the *template* takes care of the
*formatting* specific to the task at hand.
Now what I'd like to do is this:
{% myButton '${"parrotButton-" + parrot.id}' %}
Problem sorted, and astute (but possibly mentally-scarred) readers who
have used a certain language and framework will note that this is how
JSP solved this particular problem: by adding the EL language to JSP
tags. Things got much simpler and nicer at that point in JSP Land (which
is still populated by a number of trolls, ogres, and generally
foul-smelling beasties, but at least not this particular foul-smelling
beastie). Tags encapsulate reusable logic, templates call those tags
with whatever they feel like, and life goes on quite smoothly as long as
the tags call the proper parsing routines to make sure the EL gets taken
care of.
Now since we're in Python Land (which for the most part is populated
only by a number of very pleasant and polite snakes), this should be
quite easy. In fact if I wanted to I'm sure I could come up with a
parser for my tag that ran every parm through a special "try to execute
this as Python" thinger. Well. That's what JSP went through... however,
the final, logical step, was to place that parsing *in the template
parser* so that every tag didn't have to be responsible for anticipating
how the template writer wished to use it. Et voila. Tags are easy,
templates are easy, and stuff gets reused where it ought to be reused.
Now of course, people could possibly misuse this functionality (*shock*
*horror*!) to do nasty things like writing Django templates to calculate
their income taxes. So? Let them. You're not their mother, they're big
boys and girls (if a bit daft), and the people who know enough not to
misuse such a feature to do their taxes will get on grandly by using it
properly to create selectable Parrots and Sloths instead.
Sorry for the long-winded semi-diatribe, but in my defense I've been
beating my head against this exact problem for a good while now. I'd
love to use template tags to reduce my repetition and reuse solid code
all over the place, but I'm being frustrated by this singular lack of
functionality. I will say this, however: it is only because the rest of
the Django template functionality is so darn good that I'm not just
throwing up my hands and using Cheetah or what have you. I love {%
extends %}, and filters, and being able to parse my tags any way I wish.
I just need a bit more...
What I'm hoping, however, is that this missive was moot, because you'll
say, "no, Scott, you should just do *this*:", followed by an elegant and
reasonable solution that I, as a relative newcomer to Django, have not
yet considered. Here's to your reply, and cheers!
Regards,
-scott anderson
> Yours,
> Russ Magee %-)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: javascript options
On Tue, 2006-08-15 at 10:34 +0200, Steven Armstrong wrote: > > and prototype [rails fame] > > - extends builtins (e.g. Object) which kills for in loops and has other > ugly implications This hasn't been true for a few releases now with respect to exending Object, but yes, that was probably the most annoying "feature" of Prototype. Array, Function, and String are still extended, but in practice I don't find those nearly as problematic. Regards, -scott --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Django neophyte question.
Gloria, Try: python manage.py runserver dev.blah.server.com: or python manage.py runserver 11.22.33.44: where 11.22.33.44 is the external numeric IP address of dev.blah.server.com. Regards, -scott On Mon, 2006-08-14 at 20:11 -0700, Gloria wrote: > Hi. I am a Python geek who has been in the CherryPy/PythonPaste world > for the past year. I have decided to give Django a serious look, and I > have a simple question. > > After running this command: > > [EMAIL PROTECTED] wi_2> python manage.py runserver > Validating models... > 0 errors found. > > Django version 0.95, using settings 'wi_2.settings' > Development server is running at http://127.0.0.1:/ > Quit the server with CONTROL-C. > > I expect to get to this URL from a remote machine, like this: > > http://dev.blah_server.com: > > This works in cherryPy and PythonPaste from behind the firewall, so I > know it's not a port issue. > > I'm sure I'm missing something simple. Please let me know what url > parameter to set to access my page from a remote machine. > > Thank you, > Gloria > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: how can I build this query?
Not a problem, Eric, glad to be of help.
You could also do this:
ContentType.objects.filter(app_label__exact='aiyo',
model__in=('content', 'product'))
which is more concise and may treat the query optimizer in your database
better.
Regards,
-scott
On Sat, 2006-06-24 at 17:00 +, nkeric wrote:
> >>> ContentType.objects.filter((Q(app_label__exact='aiyo') &
> >>> Q(model__exact='content')) | (Q(app_label__exact='aiyo') &
> >>> Q(model__exact='product')))
> [, ]
> >>> c.queries [{'time': '0.000', 'sql': 'SELECT
> >>> "django_content_type"."id","django_content_type"."name","django_content_type"."app_label","django_content_type"."model"
> >>> FROM "django_content_type" WHERE ((("django_content_type"."app_label" =
> >>> aiyo AND "django_content_type"."model" = content) OR
> >>> ("django_content_type"."app_label" = aiyo AND
> >>> "django_content_type"."model" = product))) ORDER BY
> >>> "django_content_type"."name" ASC'}]
> >>>
>
> wow! that works, perfect! big thanks to Scott, you've been a great
> help!
>
> Regards,
>
> - eric
>
>
> >
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---
Re: how can I build this query?
Try:
ContentType.objects.filter(
(Q(app_label__exact='aiyo') & Q(model__exact='content')) |
(Q(app_label__exact='aiyo') & Q(model__exact='product'))
)
Regards,
-scott
On Sat, 2006-06-24 at 09:06 -0700, nkeric wrote:
> sqlite> select * from django_content_type where (app_label='aiyo' and
> model='content') or (app_label='aiyo' and model='product');
> 17|Product|aiyo|product
> 24|Content|aiyo|content
>
> hi all,
>
> I've tried:
>
> ContentType.objects.filter(Q(app_label__exact='aiyo',
> model__exact='content') | Q(app_label__exact='aiyo',
> model__exact='product'))
>
> result in:
>
> SELECT
> "django_content_type"."id","django_content_type"."name","django_content_type"."app_label","django_content_type"."model"
> FROM "django_content_type" WHERE (("django_content_type"."app_label" =
> aiyo OR "django_content_type"."model" = content OR
> "django_content_type"."app_label" = aiyo OR
> "django_content_type"."model" = product)) ORDER BY
> "django_content_type"."name" ASC
>
> it just OR'd everything together;
>
> and:
>
> ContentType.objects.filter(Q(app_label__exact='aiyo',
> model__exact='content'), Q(app_label__exact='aiyo',
> model__exact='product'))
>
> which ends with:
>
> SELECT
> "django_content_type"."id","django_content_type"."name","django_content_type"."app_label","django_content_type"."model"
> FROM "django_content_type" WHERE (("django_content_type"."app_label" =
> aiyo AND "django_content_type"."model" = content AND
> "django_content_type"."app_label" = aiyo AND
> "django_content_type"."model" = product)) ORDER BY
> "django_content_type"."name" ASC
>
> now it AND'd everything :(
>
> what I need is:
>
> ...WHERE
> ("django_content_type"."app_label" = aiyo AND
> "django_content_type"."model" = content)
> OR
> ("django_content_type"."app_label" = aiyo AND
> "django_content_type"."model" = product)...
>
> how could I do that?
>
> TIA :)
>
> regards,
>
> eric
>
>
> >
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---
Re: Using offset and limit to produce a blog archive
You should find what you're looking for here:
http://www.djangoproject.com/documentation/url_dispatch/#example
Regards,
-scott
On Tue, 2006-06-20 at 12:18 +, [EMAIL PROTECTED] wrote:
> Hi All,
>
> I'm in the process of learning Django by example - creating a blog
> application.
> SO, I have my blog up and running using the date based generics but
> would like to limit the number of posts that appear in the main archive
> (/path/to/site/blog/) to 10, which i've done in the urls.py like so:
> blog_dict = {
> 'queryset': Post.objects.all().order_by('-publish_date')[:10],
> 'date_field': 'publish_date',
> }
> urlpatterns = patterns('',
> (r'^/?$', 'django.views.generic.date_based.archive_index',
> blog_dict),
> #etc.
> )
>
> Now what I'm trying to figure out is how to have a view that will
> display a certain number of posts (i.e the main page shows the 10
> latest, a link on the page shows you the 10 before that, etc.)
>
> What's the best way to go about this?
> I know I'll have to use a queryset like 'queryset':
> Post.objects.all().order_by('-publish_date')[a:b],
> but how can I have the values of a and b taken from the url? (e.g.
> /path/to/site/blog/11-20/ would show posts 11 to 20)
>
> Any help greatly appreciated
> --
> bb
>
>
> >
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---
Re: Root URI in templates
On Tue, 2006-06-13 at 18:59 -0500, James Bennett wrote: > On 6/13/06, ChrisW <[EMAIL PROTECTED]> wrote: > It's not that "media" and "structure" are separated, it's that with > Apache/mod_python it's better for performance reasons to use a > separate web server for media files, stylesheets and JavaScript unless > those files are being constructed by Django; why incur the overhead of > a process with Django and your app in memory just to read a file off > disk and send it down the pipe? Why is this? I currently have Apache serving static content directly from my Django directory while other URIs are shunted to the development server via a rewrite proxy. Why is the equivalent not possible with FastCGI and mod_python in Apache as well? Regards, -scott --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Serious Noobie question, what the $ for in urlpatterns.
$ in a regular expression means "match the end of the line." What this means is that the first one, ^polls/$, means "match any url that starts and ends with polls/". If you omit the $, it means "match any url that starts with polls/, but ends with anything". So in your second example, the first regexp will always match, and nothing will ever make it to the second one. Regards, -scott On Mon, 2006-06-05 at 19:26 -0700, John M wrote: > Ok, so im gong through the turtorial and trying to adopt it to my own > project, and I see this in urlpatterns: > > (r`^polls/$'), > (r'^polls/(\d+)/$') > > how does that differ from > > (r'^polls/'), > (r'^polls/(\d+)/$') > > Note the $ is missing from the first line of the second example. > > When you don't have a $ in the polls/ setup, it doesn't scan down to > the other entries. > > Since I'm so new to python and web stuff, was wondering if anyone could > explain this. > > Sorry for such a noob question. > > Thanks > > John > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Ajax support, there is no need for reinventing the wheel
This is endemic with all asynchronous Javascript work, no matter what the back-end. You have to make sure to trap both successes and failures in the Javascript code -- I don't know how mochikit does that, but with prototype you need to specify an onFailure hook to get errors. Regards, -scott On Sat, 2006-06-03 at 11:23 -0400, Jay Parlar wrote: > I was playing around with mochikit and Django yesterday, and was > getting really frustrated by one particular aspect: > > In any view code that was only responding to async requests, if I had > a typo or error in my Python code (anything that would raise an > exception), I wasn't seeing any exceptions *anywhere*. Usually of > course, Django sends the exception information back to the client, to > be displayed on screen. Doesn't work so well when some JS is expecting > the response. > > This was using the dev server and DEBUG=True. Maybe I missed something > in terms of how to get useful output, but it'd be nice if there were a > decorator or something that could tell Django that the client > expecting a response is *not* going to be able to display that > response, and the exception info should be displayed on the terminal. > > Just my two cents, > Jay P. > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Ajax support, there is no need for reinventing the wheel
I'm sorry, but I can't agree. I've used DWR as well, and the "server generates your Javascript to include" model really creates a lot of problems, both with versioning and performance. Simple is best. I've had the best luck with straightforward use of the prototype.js Ajax class. Regards, -scott On Sat, 2006-06-03 at 12:05 +0100, Derek Hoy wrote: > I used DWR for a java project I finished last year - > http://getahead.ltd.uk/dwr/ > > It really simplifies the client-server ajax stuff. It lets you fetch > an object from the server and have it available in the client as a js > object, with properties and methods all available in your client code. > DWR serverside code generates the js files for download to the client > that handles all the marshalling stuff, so you don't see any of it. > > It would make a great model for ajax support in Django. You call a DWR > js function, giving it a callback to your js function. This function > gets an object as a param, you use the object to fill bits of your > page etc. > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Rich Text Editor for BBCOde?
On Thu, 2006-06-01 at 11:43 +, [EMAIL PROTECTED] wrote: > > All this may sound a bit (very?) paranoid for a small community portal > site. The large number of comment spamming, SPAM and exploits against > phpBB sites, etc. show that some people just don't play fair. You don't > really want these people to go and write arbitrary HTML on your page. > And the potential for abuse is such that if you DO allow HTML in > postings, you have a lot of filtering to do. > > Daniel You're going to have to filter on the server side no matter what the browser editor produces. ie. if you want to allow someone to post a link, you'll still have to filter the href of the link posted via BBCode or someone can just bypass the editor and post the code directly by not using your interface. The only surefire way, of course, is to completely disallow HTML (via quoting < characters) and just allow text. The next best thing is to use a whitelisting filter that only allows the tags you want it to allow. I have such a filter, and if there's interest I'll clean it up and post it somewhere. For now there's a prototype version at http://z.iwethey.org/forums/SourceCode/src/htmlparse.py that needs some work. It scrubs everything by default. Tags are detected and filtered for allowed markup only (eg. you can only put http:// in an href). There are some BBCode-like markup elements (a number of which are specific to my forums code only), and it's fairly trivial to add more. There's also a two-step processing system: scrubbing first, during which links and the like are converted to an interim format before being stored in the database, then a second step which takes links and converts them to actual tags according to the preferences of the user (some users like all links to open a new window, for example) just before display. Regards, -scott --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Improper quoting using extra() in Postgres
Great, thanks Adrian!
Works perfectly, and man that was quick. ;-)
Regards,
-scott
On Wed, 2006-05-31 at 23:49 -0500, Adrian Holovaty wrote:
> On 5/31/06, Scott Anderson <[EMAIL PROTECTED]> wrote:
> > The problem is that either Django or the driver is quoting the function
> > instead of inserting it directly at the docs state it should:
> >
> > SELECT "app_table"."field_name",...,("nlevel(hierarchy)") AS "level"
> > FROM "app_table"
> >
> > Notice the quotes around nlevel(hierarchy). Postgres doesn't like this,
> > and pitches an error. :-)
> >
> > So, have I missed a setting somewhere to turn off quoting for specific
> > fields, or is there something else I'm missing?
>
> Hey Scott,
>
> As of just now, this is fixed in the latest Django development version
> (trunk). "svn update" your code, and Django will no longer quote
> "nlevel(hierarchy)". Thanks for the report!
>
> Adrian
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---
Improper quoting using extra() in Postgres
Hi all,
I'm using the extra() method to add a calculated field to my object:
Table.objects.extra(select={'level':'nlevel(hierarchy)'})
where nlevel is a function defined in my PostgreSQL database.
The problem is that either Django or the driver is quoting the function
instead of inserting it directly at the docs state it should:
SELECT "app_table"."field_name",...,("nlevel(hierarchy)") AS "level"
FROM "app_table"
Notice the quotes around nlevel(hierarchy). Postgres doesn't like this,
and pitches an error. :-)
So, have I missed a setting somewhere to turn off quoting for specific
fields, or is there something else I'm missing?
Thanks in advance,
-scott
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---
Re: Please help with project setup
TinyMCE (http://tinymce.moxiecode.com/) is an RTE that was extremely easy to integrate with Django for me. There are processors which can convert HTML to PDF, as well, but how well they work depends on the HTML and CSS being used. Regards, -scott On Tue, 2006-05-30 at 11:22 +, Kristoffer wrote: > >The author was also able to add images elsewhere using the rich text > >editor we provided him with. > > This seems like what I want for this project. > However, if there isn't a rich text editor available that is easy to > plug in with Django, this option isn't for me. > > I suppose it would be ok for my article authors to mark up their > articles using simple HTML tags, like H1 and IMG, and save the entire > article as a TextField. It would be really great, though, if articles > could be converted to PDF files automatically, and using HTML tags > would ruin this, correct? > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Adding a specialized database type
Hi all, I'd like to add a specialized data type for PostgreSQL: the contrib/ltree type. I've found the DATA_TYPES hash in the backend creation objects, but my question is this: What's the least intrusive, best way to add this mapping for my application? I could: 1) modify the Django source directly (ick) 2) modify the DATA_TYPES hash in my manage.py before anything else runs (hacky?) 3) some other, better way that some kind person will let me know :-) Thanks in advance, -scott --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Tagging app
Luke, I'm definitely interested, since I've been thinking about doing this very thing. Regards, -scott On Fri, 2006-05-26 at 00:57 +0100, Luke Plant wrote: > Hi all, > > I've been writing some tagging functionality for my site, and I've > developed it in a way that is reusable and generic, similar in some > ways to the 'comments' app in contrib. Would anyone be interested in > me tidying it up for release as a Django app? It would require a > little bit of tidying up (mainly fixing Python 2.3 incompatibilities), > and if popular, it could do with a bit of community input. I'd be > happy to release it under a BSD license. > > Below is an overview of what is included. > > Tag model > = > - The central model. A *simplified* version is below: > > class Tag(models.Model): > text = models.CharField() > target = GenericForeignKey() > creator = GenericForeignKey() > added = models.DateTimeField() > > GenericForeignKey works like a foreign key field except that it is > identified by two pieces of information - an 'id' (stored as a string > for maximum generality), and a ContentType id. (The model actually > requires other parameters and other fields to be present, not shown). > For the most part, however, you can ignore this implementation detail. > Externally, you just set/get mytag.target or mytag.creator to any > Django ORM object and it will work. > > Tag objects also have other methods to do efficient SQL queries for > summarising Tag information. e.g. .count_tagged_by_others() returns > the number of other 'creator' objects that have tagged the same object, > and there are other methods on the TagManager for doing this kind of > thing (see below). > > If you want, you can have different types of object that are taggable, > so: > > [t.target for t in Tag.objects.all()] > > could be a heterogeneous list. In templates that show lists of Tag > objects in detail, this could be a problem, since you don't know what > type of object mytag.target is, and you might want to customise how you > display a tagged target object. So I've added a 'render_target' method > which is pluggable i.e. you can provide different ways of rendering > different types of target objects, and then just use tag.render_target > in the template. > > (You could also have different types of 'creator' object, but in my case > I haven't used this, so haven't tested it much, but I'm not aware of > any problems). > > Tag Manager > === > The Manager class for Tag has various methods to return database > information about tagged objects. It uses efficient SQL to do so, > which means that most of them can't build up queries the way you > normally do in Django, but instead the methods provide optional > parameters that should cover most of the kind of queries you want to > do, including searching for objects that are tagged with multiple text > values. > > The methods tend to return either simple values, or 'partially > aggregated' versions of the Tag object: > > TagSummary > -- > Contains 'text' and 'count', where count is the number of Tag objects > with that 'text' value. > > TagTarget > - > The 'text' + 'target' half of a 'Tag' object, used for answering the > question: "What objects are the target of a certain 'text' value (or > values) and how many 'creator' objects have tagged it like that?" > > The tag manager methods also work correctly in a 'related' context (see > below). > > Tag relationships > = > A Tag is essentially two foreign key fields (plus metadata), but since > it isn't actually a ForeignKey object, and can point to multiple > models, it doesn't appear on the 'pointed to' models automatically (e.g. > as in mypost.tags.all() or myuser.created_tags.all()). However, you can > set this up with the add_tagging_fields() utility method, which allows > you add attributes to models with complete flexibility. You don't > define the tags as part of your model, but use this utility method > after creating the model to add the attributes. > > This has been done like this mainly for ease of implementation, but it > also keeps your model decoupled from 'tagging' -- after you've defined > your model, or imported someone else's, you can add tagging fields very > easily. > > In this related context, you also get methods that parallel normal > foreign keys i.e. mypost.tags.create() and mypost.tags.add(), which > work as expected. > > Finally, the Tag Manager methods for advanced queries also work > correctly in the 'related' context e.g. > mypost.tags.get_distinct_text() limits itself to the relevant Tag > objects. > > Views > = > A simple tagging facility will allow users to tag objects, and then > display those tags inline on the object that is tagged (e.g. a post or > a topic etc). To enable this, a 'create_update' view is provide, with > a sample template -- a del.icio.us style form for ed
Re: Problem with Django Captcha
Thanks for the reply, Ian.
I have those libraries installed. I'm sure it's just some configuration
I've done improperly.
I've sent you a gmail contact (scottanderson42); since you're in
Australia I'm sure I'll have to wait for the daylight terminator to come
back round your way again. :-)
Regards,
-scott
On Fri, 2006-05-19 at 16:42 +1000, Ian Holsman wrote:
> Hi.
>
> I wrote that app, and it does work (for me at least)
>
> some of the main problems I have had in the past with it is the lack
> of dependant libraries.
> you need
>
> pycaptcha
> and
> Imaging
> and
> pycrypto (if you want to use the register app in that SVN)
>
> If you want, feel free to ping me on irc (my nick is firemansam) or
> Skype: iholsman / gtalk: kryton _at_ gmail.com
> and we'll get it sorted out for you. (and post back the answer here
> for next time)
>
> On 19/05/2006, at 12:47 PM, Scott Anderson wrote:
>
> >
> > Hi all,
> >
> > I'm a new Django user trying to get the captcha app working with svn
> > Django.
> >
> > I've done the following:
> >
> > 1) Placed the captcha app in my site directory (which is named
> > 'craft')
> > 2) Added a reference to "craft.captcha" to INSTALLED_APPS in
> > settings.py
> > 3) Placed {% load captcha %} and {% captcha %} in my template (in
> > user/templates/register.html)
> > 4) Included the craft.captcha.urls reference in the site's urls.py for
> > ^captcha/
> >
> >
> > When I visit the register template, however, I get the following
> > error:
> >
> > 'captcha' is not a valid tag library: Could not load template library
> > from django.templatetags.captcha, cannot import name template
> >
> >> From the "load captcha" line in the template.
> >
> > I'm sure I'm missing something simple, but I'm not familiar enough
> > with
> > Django yet to figure out what it is. I've also tried "load
> > craft.captcha", but no dice.
> >
> > Thanks for any help in advance,
> > -scott
> >
> >
> >
> > >
>
>
> >
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---
Problem with Django Captcha
Hi all,
I'm a new Django user trying to get the captcha app working with svn
Django.
I've done the following:
1) Placed the captcha app in my site directory (which is named 'craft')
2) Added a reference to "craft.captcha" to INSTALLED_APPS in settings.py
3) Placed {% load captcha %} and {% captcha %} in my template (in
user/templates/register.html)
4) Included the craft.captcha.urls reference in the site's urls.py for
^captcha/
When I visit the register template, however, I get the following error:
'captcha' is not a valid tag library: Could not load template library
from django.templatetags.captcha, cannot import name template
>From the "load captcha" line in the template.
I'm sure I'm missing something simple, but I'm not familiar enough with
Django yet to figure out what it is. I've also tried "load
craft.captcha", but no dice.
Thanks for any help in advance,
-scott
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---
