Re: FckEditor vs TinyMCE

[Jay Klehr]

It's certainly possible to implement FCK as a JS based editor, no python 
code necessary.  It'll simply act as a textarea replacement to the user, 
but will still post the source of the editor when the form is submitted.

Here's the integration guide for doing it this way:

http://docs.fckeditor.net/FCKeditor_2.x/Developers_Guide/Integration/JavaScript

If you want to do it in your django code, here's the Python integration 
guide:

http://docs.fckeditor.net/FCKeditor_2.x/Developers_Guide/Integration/Python

Jay

Cull wrote:
> We're just starting to consider text editing.
> What is our easiest path here?  TinyMce or FckEditor. The latter has
> been our choice previously, but is there a post somewhere that
> discusses who to do it?  I haven't been about to find more than bits
> and pieces.  If not, what about Tiny?
>
> Tips appreciated.
> >
>
>   


--~--~-~--~~~---~--~~
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: spam

[Jay Klehr]

Are the other lists powered by Google Groups?  Are they as active as 
Django's list?

Perhaps you should direct your complaints to Google, as I don't think 
the people on this list (or even the owners of the list) can do much 
about it (aside from moderating every new user/post).

Jay


Jeffrey Johnson wrote:
> This is the ONE list where I consistently get porn spam in gmail. What gives?
>
>   


--~--~-~--~~~---~--~~
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: Database optmization guru needed...

[Jay Klehr]

Tom Smith wrote:
> Hello.
>
> When in mysql I do a...
>
> explain select title from burningahole_product where ( price >10 and  
> price<20) order by random_number limit 10;
>
>
> ... I get...
>
> ++-+--+--- 
> +++- 
> +--++-+
> | id | select_type | table| type  |  
> possible_keys  | key| key_len |  
> ref  | rows   | Extra   |
> ++-+--+--- 
> +++- 
> +--++-+
> |  1 | SIMPLE  | burningahole_product | range |  
> burningahole_product_price | burningahole_product_price |  12 |  
> NULL | 209932 | Using where; Using filesort |
> ++-+--+--- 
> +++- 
> +--++-+
>
> ...which is VERY slow at times...
>
> Is it possible to do a ...
>
> force index (burningahole_product_random_number)
>
> ...in Django? Which seems to make the "Extra" = "Using where" rather  
> than "Using where filesort".
>
> Or does anyone else know how I can speed up the above query on a  
> table with close to a million records. I have tried adding indexes  
> all over the place, but in general mysql seems to look at ALL the  
> records (or close to) before doing a query.
>
>
>
> Thanks
>
> tom
>   
Mysql is telling you right there how many records it IS looking at.  
It's using a range index on your price column and reducing the number of 
rows it scans to 209,932 (from the million or whatever the total count 
is), no other indexes on that table will make a difference for this 
query.  The filesort is happening because of your Order clause. 

The second link posted in a previous message shows the ORDER BY RAND() 
LIMIT 10 syntax, which works, but in a large table it's still going to 
take some time to process (still shows filesort too).  In the comments 
of that page another person mentions to use something like WHERE RAND() 
 > 0.9 ORDER BY RAND() LIMIT 10, but I didn't see much added benefit 
when running it on my own large tables (same Explain result too as the 
previous one).

Give those a shot though and see if they help anything.  You may have to 
take this into the application to speed it up, but with 200,000 records 
to pick 10 random from, that may be expensive as well.  Is there no 
other reduction in records you can do?  Like a category, or date added?

Jay



--~--~-~--~~~---~--~~
 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: Online "beta" Book

[Jay Klehr]

Adrian Holovaty wrote:
> On 11/15/06, James Bennett <[EMAIL PROTECTED]> wrote:
>   
>> On 11/15/06, Robert Hicks <[EMAIL PROTECTED]> wrote:
>> 
>>> In the databases section, Oracle is listed as supported. I have been on
>>> hiatus for bit. Has Oracle made it into Django .95 or is that entry in
>>> anticipation of Django going 1.0 before the book is released?
>>>   
>> There was a pretty productive sprint not too long ago geared at
>> beating Oracle support into shape, and I think it's now passing most
>> of the unit tests, so hopefully it'll be stabilized and polished by
>> the time the book goes to press.
>> 
>
> Just to clarify this, this Oracle support was added to the Django
> development version, not the 0.95 release.
>
> Adrian
>   
And it's not in the development version's trunk, but in the " 
boulder-oracle-sprint"
 
branch.

Jay

--~--~-~--~~~---~--~~
 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: Storing images in the db

[Jay Klehr]

This is a huge religious debate that's probably not suited for this list.

I'd suggest reading the numerous topics available about this across the 
net.  Usually the best threads are in database specific lists, like 
lists.mysql.com

In those lists database admins usually jump in and speak their mind on 
the issue, which gives you another perspective on the issues at hand.

Jay


Panos Laganakos wrote:
> I'm going to work a small photo managment app for an LAN site here, and
> I wanted to hear some opinions.
>
> >From what I've seen people tend to store images outside the db and just
> keep their location field to grab em.
>
> What are the advantages/disadvantages of doing so? That way the httpd
> gets to serve them and if so, why is that important? Django keeps
> running, its not like it spawns something new like if I was doing so in
> PHP.
>
>
> >
>
>   


--~--~-~--~~~---~--~~
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: magic removal mean?

[Jay Klehr]

Check out the djangoproject site for more info:

http://code.djangoproject.com/wiki/RemovingTheMagic

Jay

Picio wrote:
> sorry guys for the boring question, what is the meaning , exactly, of the
> "magic removal"?
>
> Thanks.
> Picio
>
> >
>
>   


--~--~-~--~~~---~--~~
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: Creating graphs in Django application

[Jay Klehr]

If you don't mind using Flash as the output medium you could try this:

http://www.maani.us/xml_charts/

Works with anything that is able to output XML, I've used the PHP 
version a bit and really like a lot of the options.

Jay


Devraj wrote:
> Hi everyone,
>
> I am attempting to create graphs in my Django app.to provide reporting
> features. Are there any libraries available to do this in Python or
> Django?
>
> Something like http://www.qualityunit.com/postgraph/ for PHP
>
> Thanks
>
>
> >
>
>   


--~--~-~--~~~---~--~~
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: User Registration weirdness. Ian, help!

[Jay Klehr]

At least for a test, if it doesn't happen with a shorter URL, then it's 
clearly an encoding issue.  You could try going the other way too and 
making it longer, to see if more than the ending slash is bumped off.

Quoted Printable only uses 1 equal sign though, now that I think about 
it more, that random bit at the end of your URL, is it possible to have 
equal signs there?

Here's some info on the encoding, which mentions the 76 character line 
limit:

http://en.wikipedia.org/wiki/Quoted-printable

Jay


[EMAIL PROTECTED] wrote:
> Not handy, but maybe I'll try shortening the URL and see if that helps.
>
>
> >
>
>   


--~--~-~--~~~---~--~~
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: User Registration weirdness. Ian, help!

[Jay Klehr]

Looks to me like a "quoted-printable" email encoding issue, that's what 
the two equal signs on the end probably come from.

The line that the URL is on looks to exceed the allowed character limit, 
so the encoding has added the double equal sign, and bumped the text to 
the next line.

An email client capable of reading that encoding (most should be) should 
interpret it properly and join the lines that it has split like that.

Do you have the headers of the email?

Jay


[EMAIL PROTECTED] wrote:
> OK, the code I'm using came from Jeff Croft's Lost-Theories source,
> which in turn cribbed heavily from zyons... so with that background out
> of the way...
>
> When the user gets their verification email, the trailing slash isn't
> sitting on the same line as the rest of the link.. it looks something
> like this:
>
> http://test.com/account/register/dGltLmJheHRlckBzaWxwYWRhLmNvbQ==
> /
>
> If I understand what's going on correctly the view is creating a
> variable cryptString like this:
> verifyurl = cryptString(email)
>
> and the template is spitting it into the email like this:
> {% trans "To verify your e-mail address and continue the registration
> process, please click the link below:" %}
>
> http://{{ domain }}/account/register/{{verifyurl}}/
>
> I've gone through and stripped out every extra space I can find,
> thinking that was the problem, but still that dang trailing slash comes
> down to the next line. Ideas?
>
>
> >
>
>   


--~--~-~--~~~---~--~~
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: Unicode, unicode, more unicode

[Jay Klehr]

It shouldn't, if all you're doing is saving and redisplaying Unicode 
characters between the database and your site, you should be fine in 
that regard.  I believe a lot of the issues come up when you're trying 
to use string comparing and modifying functions that aren't Unicode safe.

PHP isn't Unicode ready and I've been saving and displaying Unicode 
Japanese, Chinese and Korean for a good while now (since I started using 
mysql 4.1.x).  But I don't do any comparison operations, or use anything 
that depends on the length of the Unicode string.

I'm currently displaying Unicode strings in my Django site, but haven't 
messed with editing the strings yet.

I'm no Unicode expert though, and I trust that the Django devs (and 
contributors) are much more familiar with the issues at hand than I am.  
Just wanted to chime in with my own experiences. :)

Jay


Sean Schertell wrote:
> I'm planning to do two large bilingual sites (english/japanese). Does  
> django's lack of unicode support mean that I won't be able to collect  
> form data from utf-8 pages?
>
> Sean
>
> >
>
>   


--~--~-~--~~~---~--~~
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: check for yourself (((;

[Jay Klehr]

Seems to me that robots.txt is the first place I'd look if I was looking 
to cause some trouble. :)

Jay

Ian Clelland wrote:
> I always
> assumed that all they would do is connect over port 80, and try to
> retrieve something like /admin/, or another platform-specific resource
> over http, and there's not much that excluding the URL through
> /robots.txt is going to do to stop that.


--~--~-~--~~~---~--~~
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.

[Jay Klehr]

When I run the dev server from my remote server, I do it like this:

python manage.py runserver my.domainname.com:8000

Then I can access it through http://my.domainname.com:8000

my.domainname.com isn't setup anywhere else either (like in Apache or 
anything), but www.domainname.com is.

Jay

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: Google-like API keys

[Jay Klehr]

Felix Ingram wrote:
> On 8/10/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>   
>> Just username+randomstring is good.
>> SHA better than md5.
>> 
>
> Choice of hashing algorithm means nothing here. The only thing about
> SHA is that you'll get a longer string (160 bit rather than 128).
>
> If all you want is a random string then just use a random string.
>
> Felix
>   
However, a longer string gives you more unique combinations before you 
have a collision.

I do agree that one small piece of non-random information will protect 
you more against duplicates though.  That way, if the same random number 
is generated for two different users, they wouldn't turn out to be the 
same hash (using either MD5 or SHA).

Say we have firstnames and two users get the same random bit added to 
the firstname when generating their key:

paul + 78uyy5jji = ADB01D7112EC1296DB1DFA87E37036B1 (md5)
julie + 78uyy5jji = A6EC2D3C8E0C831012F05E7A1EB4E080

Obviously if you only used the random bit, a duplicate key would be 
created here, both users would end up with the same key:

78uyy5jji = C5E9348386E8DECF6DDC879E7E914B92

Of course, you should use a longer random string than my example here, 
which would reduce the chances of getting a duplicate, but I still 
recommend using some part of the user's profile (or even a timestamp) if 
you're going to use MD5 or SHA. 

Really, using a 128 bit or 160 bit (recommended) random string is all 
you need to do, but MD5 and SHA make that step easier.
.
No matter what you do there is always a chance for a duplicate key to 
come up (something you should check in your system before assigning), 
but the longer the key, the less likely that will happen.  But too long 
and your users will hate you. ;)

Jay

--~--~-~--~~~---~--~~
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: get_for_model building bad SQL?

[Jay Klehr]

Malcom,  sorry about the reply, I use my email client to interact with 
google group and pressed reply so that it would use the right account to 
send from (since I'm not subscribed with my default account).  Won't 
happen again now that I know google groups is smarter than I though. ;)

I created a ticket:  http://code.djangoproject.com/ticket/2488

Thanks,

Jay

Malcolm Tredinnick wrote:
> Hi Jay,
>
> Please start a new thread for a new topic, rather than replying on an
> existing thread. Makes things easier to track both in threaded email
> clients and in the web view. Thanks. :-)
>
>   

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

get_for_model building bad SQL?

[Jay Klehr]

Hello,

Running Django's dev server on mysql 4.1.20 and trying to make use of 
the get_for_model method from the ContentTypes package to get the 
content type of a model (using the examples laid out in the 
GenericForeignKey documentation 
http://www.djangoproject.com/documentation/models/generic_relations/ )

Here's the example code from the documentation:

# However, excluding GenericRelations means your lookups have to be a 
bit more
# explicit.
>>> from django.contrib.contenttypes.models import ContentType
>>> ctype = ContentType.objects.get_for_model(quartz)
>>> TaggedItem.objects.filter(content_type__pk=ctype.id, 
>>> object_id=quartz.id)
[, ]


When I run this line:

ctype = ContentType.objects.get_for_model(quartz)


I get this SQL built:

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`.`model` = quartz 
AND `django_content_type`.`app_label` = myapp)

MySQL doesn't like having no ticks around the two values 'quartz' and 
'myapp' in this case. (My app is actually named "database" right now, 
which is a mysql reserved word as well.)

In the example docs quartz is actually an instance of a model, but in 
mine I'm doing something like this:

from site.myapp.models import MyModel

ctype = ContentType.objects.get_for_model(MyModel)

Which would generate sql similar to above, but "quartz" would be 
replaced with "mymodel".

I suspect I shouldn't be using it this way, but seeing SQL like that 
being run also concerned me.

Any ideas?

Jay

--~--~-~--~~~---~--~~
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: Tracking views or clicks

[Jay Klehr]

I'm interested in what the community suggests on this topic, as it's 
something I'd like to implement as well.  However, one word of advice if 
you're using MySQL and its Query Cache...  try to keep the "views" 
column outside of your models table since updating that table on every 
hit would basically make the query cache for that table irrelevant.  As 
I understand it, the Query Cache for a query is wiped if the table that 
is used in the cached query is changed after the query is cached.  In 
this case the table would be changed on every load, so the query would 
never be cached.  So perhaps a generic table like 'views' could be used 
with the GenericForeignKey setup that Django uses (like for "tags" or 
"comments").  This could possibly allow queries on that model to be 
cached (unless the query is hitting the "views" table in a join for 
every object load/hit).

Even if no cache benefit can be gained, I like the ability to add a 
"views" property to ANY object that you please just by setting up a 
Generic foreign key though, it's much easier to add that functionality 
to any object without having to modify your DB schema at all.

Jay

[EMAIL PROTECTED] wrote:
> Any suggestions on how I could track how many times an object has
> loaded and/or been clicked?
>
> I mean, obviously in my model I'd need something like
>
> class Item(models.Model):
>  views = IntegerField()
>
>
> but how would I update views when Item was loaded on a page?
>
>
> >
>
>   


--~--~-~--~~~---~--~~
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: Template widget size

[Jay Klehr]

Really the "size" of the form field should be controlled by the CSS, and 
not the hard coded HTML.  Though the "maxlength" attribute could be 
controlled by Django, and tied to the "maxlength" attribute that you 
define in Model (and it may be in the admin interface, I haven't 
actually looked myself).

Jay

Matt the Destroyer wrote:
> size=30 simply tells the browser to make the input field a size of 30
> characters wide.  it has no bearing on input data or transmission.
>
> in the past, i have simply hard-coded my own input fields into my
> templates so I can directly control the size and other attributes that
> i might want (such as onclick et al).
>   


--~--~-~--~~~---~--~~
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: CSS and JavaScript manager

[Jay Klehr]

I'm not sure I fully understand your suggestion, I just wanted to bring 
up the point of JS and CSS caching, and speed of loading.

In the PHP world (where I've had most of my experience) serving CSS 
files through a PHP script is always slower than just serving a static 
CSS file (even if the PHP script does nothing but spit out the CSS, no 
processing).  Having the interpreter handle CSS and JS files isn't 
ideal.  On pages that are under high traffic this plays an important 
role.  So I'd recommend that there be some sort of CSS and JS "build" 
process that builds a static file, rather than trying to generate a 
dynamic CSS or JS file for every request (perhaps Django's cache system 
is enough, perhaps not).

CSS and JS can't be too dynamic since the browser will cache the files 
(and sending a no-cache header on either file type is a terrible idea).  
Though it seems like you have this issue covered with the long numeric 
file names, changing depending on the file's contents.

Just my concerns. :)

Jay

[EMAIL PROTECTED] wrote:
> I'm thinking about making a simple JavaScript and CSS manager that
> would look like this:
> - It generates one JavaScript and one CSS file for a current
> page/template
> - It uses a database or a pickle/shelve/flat files (?) to store code
> snippets: id, code, comment, show_always
> - Extra code snippets can be added dynamicaly in the template,
> something like:
> 
> which would add code snippets with ids: 14, 52 etc.
>
> Why:
> - Organizes your JS/CSS code, specially when you have a lot of JS
> script. Comments and easy on/off "switch" makes the work faster.
> - Helps making JS "widgets" - add foo to your JS db and you can do
> wodo-ajax here and there.
> - Less static files to serve.
>
> What do you think about it? What are your suggestion? :)
>   

--~--~-~--~~~---~--~~
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: Intermediary M2M admin troubles

[Jay Klehr]

Here's the code used in the Tutorial example for collapsing in the admin 
interface:

class Admin:
fields = (
(None, {'fields': ('question',)}),
('Date information', {'fields': ('pub_date',), 'classes': 'collapse'}),
)


http://www.djangoproject.com/documentation/tutorial2/

This sets up two fieldsets, 'None' (the default) and 'Date 
Information'.  'Date Information' is given the class 'collapse' which 
would hide the pub_date field by default unless the fieldset is expanded.

This needs to go in your model class, so you'd have something like this:

class BakedGoods(models.Model):
name = models.CharField()
ingredient = models.ForeignKey( Ingredients , blank = True , core = True )
...
class Admin:
   fields = (
  (None, {'fields': ('name',)}),
  ('Ingredients', {'fields': ('ingredient',), 'classes': 'collapse'}),
   )


Jay


markguy wrote:
> As would showing me how to collapse the M2Mi
> fieldset.
>   

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---