Re: inserting multiple images EASILY
On 11/29/05, Emanuele <[EMAIL PROTECTED]> wrote: > > Maybe it's a little off-topic, but I'm thinking about a problem I need > to solve for a future application I want to code using django. And I > think many of you can help me. > Basically users will need to insert multiple images associated to an > object and its features (images are pictures of that object). So I'll > have a form to enter some features of that object (date, size etc.) and > a proper way to insert multiple images EASILY. Easily means that typing > each path or browsing to reach each image location for uploading is not > ok for my future users; is there an easier way? > I know that drag and drop is not possible. I'm a newbie in this field. > > Any ideas? > I assume you would like the user to point to a directory on their machine and have it automaticly select all img files within for upload or something like that. The problem is that the browsers access to the file system is very limited for obvious secerity reasons, so this kind of thing generally doesn't work so well. I imagine that is why online photo services (flickr) offer client side apps for batch uploading etc. Hmm, I wonder if one could utilize an API from one such app for this sort of thing - could be interesting. Or am I missunderstanding your situation? -- Waylan Limberg [EMAIL PROTECTED]
Re: Exception Location: C:\soft\django_src\django\templatetags\adminmedia.py
On Wednesday 30 Nov 2005 2:12 am, kmh wrote: > The work-around is to manually delete any orphaned > .pyc files such as adminmedia.pyc (or just all .pyc files as they > will be regenerated as needed). better delete the whole thing and do a fresh svn co -- regards kg http://www.livejournal.com/users/lawgon tally ho! http://avsap.org.in ಇಂಡ್ಲಿನಕ್ಸ வாழ்க!
Quoting in tables clause
Hi all,
When you use a "tables" kwarg in a database query method (get_list,
etc), you provide a list of strings which correspond to the database
names of the tables you want to have joined. You can then specify a
"where" clause to narrow the join.
When the provided table name is used in the generated SQL query, it is
quoted. This preserves case, etc, in the table name, and all is good
with the world..
However, this quoting behaviour does prevent some other tricks. If the
table name was unquoted, you could nominate a subselect query as a join
point, rather than just naming a table. To give an artificial example
using the Django tutorial database:
polls.get_list(
tables=[
"(SELECT * FROM polls_choices
WHERE polls_choices.votes > 10) AS popular_choices"
]
where=[
"polls_polls.id=popular_choices.poll_id"
]
)
As Django stands, the quoting process puts the entire subselect inside
quotes, which turns into a syntax error in SQL. If the quoting was
removed from 'tables' strings, this would be a valid SQL query
operating over an inner join with a subselect.
I can see why the quoting is beneficial, as it removes leakage of SQL
quoting syntax from Python code space. However, you already have to
nominate SQL names ('polls_choices', not just 'choices') in order to
use the tables and where clause, so there is already partial leakage.
1) Is the quoting behaviour a feature or a bug? (I suspect feature, but
I thought I'd check)
2) Is there room for a smarter quoting scheme? - e.g., don't quote a
table name if the first character is a '('
3) Is there room to add a distinct 'subselect' kwarg to queries? This
kwarg would be identical to 'tables', but wouldn't quote its contents
4) Is there some other way to construct a subselect join that I am
missing (including, ideally, a left outer join)?
Many thanks,
Russ Magee
inserting multiple images EASILY
Maybe it's a little off-topic, but I'm thinking about a problem I need to solve for a future application I want to code using django. And I think many of you can help me. Basically users will need to insert multiple images associated to an object and its features (images are pictures of that object). So I'll have a form to enter some features of that object (date, size etc.) and a proper way to insert multiple images EASILY. Easily means that typing each path or browsing to reach each image location for uploading is not ok for my future users; is there an easier way? I know that drag and drop is not possible. I'm a newbie in this field. Any ideas? Thanks in advance, Emanuele
FormField.prepare
Hello, django.core.formfields.FormField has a method 'prepare' which is described as a "Hook for doing something to new_data (in place) before validation." which sounds very useful. But as far as I can tell it never gets called. Am I missing something? Daniel
Re: customizing admin
On 11/29/05, Medium <[EMAIL PROTECTED]> wrote:
> I don't think it has anything to do with skill or their ability to pick
> it up and get use to it over time. You can say that about any syntax
> (good or bad). My main point i guess was that if someone saw django
> template at a glance (which is usually how I evaluate things initially)
> the more familiar it seems the more chance of me trying it out because I
> don't have to reconfigure my brain too much. You name it and most
> popular templating solutions use this syntax, which means more designers
> as well are also familiar with ${} syntax.
I don't know, I've only ever seen that syntax in PHP- or Perl-based
systems. ASP never used it, so far as I know, and Rails doesn't use
it.
> Personally, I don't find this a major issue, just a thorn in the side,
> but I wanted to ask the question on the very far chance that django can
> be made even more popular because I like it alot.
I don't really see it as something that inhibits adoption, and pretty
much my entire background is in PHP and Perl, so hopefully that counts
for something :)
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
Re: Exception Location: C:\soft\django_src\django\templatetags\adminmedia.py
Hi Olivier, Django is undergoing some rapid changes before the 1.0 release and some of the files are being relocated in the source tree. Unfortunately the byte-compiled .pyc files are not managed by subversion and can get left hanging about in places they aren't meant to be, but where Python will still find them. The work-around is to manually delete any orphaned .pyc files such as adminmedia.pyc (or just all .pyc files as they will be regenerated as needed). Kieran
Exception Location: C:\soft\django_src\django\templatetags\adminmedia.py
Hello, when I try to access the admin site Django is complaining aout missing adminmedia.py which is true. There is a adminmedia.pyc instead. svn up does not retrieve the file. Debug message is: AttributeError at /admin/ 'module' object has no attribute 'register_tag' Tequest Method: GET Request URL:http://127.0.0.1:8000/admin/ Exception Type: AttributeError Exception Value:'module' object has no attribute 'register_tag' Exception Location: C:\soft\django_src\django\templatetags\adminmedia.py in ?, line 16 What is wrong ? Olivier.
Re: customizing admin
> I don't think it has anything to do with skill or their ability to pick
> it up and get use to it over time. You can say that about any syntax
> (good or bad). My main point i guess was that if someone saw django
> template at a glance (which is usually how I evaluate things initially)
> the more familiar it seems the more chance of me trying it out because I
> don't have to reconfigure my brain too much. You name it and most
> popular templating solutions use this syntax, which means more designers
> as well are also familiar with ${} syntax.
>
> >dollar-sign based syntax (which in turn feels alien and Perl-ish to
> >me).
This really hits the nail on the head for me. Variables are of the
form: 'SomeVariable' in Python, not '$SomeVariable' like Perl, PHP
ect. So why should a template language developed in and used with
Python be any different? Sure, when I first came to python, variable
names that looked like function names etc was a little difficult to
wrap my head around, but once I understood why; it was no problem
(overly simplified reason: everything is an object so we don't need to
differentiate). Adding $ back in for variables in the templates just
throws the whole "python way" out the window and adds unnecessary
confusion to those familiar with python syntax (since the brain
reconfiguration (as you put it) is happening anyway, it might as well
be consistent). In other words, your request will get much resistance
from most every python programmer out there. Although, I suppose if
enough (read: alot) people requested it, some might consider it as an
alternate secondary syntax. Just my 2cents (which could be way off).
--
Waylan Limberg
[EMAIL PROTECTED]
Re: Error With /media In URL?
On 11/29/05, JA <[EMAIL PROTECTED]> wrote: > > OK, think I may have found the problem with this. In the settings.py, > ADMIN_MEDIA_PREFIX is set to /media/ by default. I'm going to sort > through the code, but I think that's the starting point. > > Comments? > According to the docs(http://www.djangoproject.com/documentation/settings/#admin-media-prefix) ADMIN_MEDIA_PREFIX is "The URL prefix for admin media -- CSS, JavaScript and images." and yes, it is set to '/media/' by default. I'm guessing that if you want the /media/ url to point to something other than the Admin CSS, JS and images etc, you need to change this value to something else. How this will affect Django's admin pages, I have no idea. Perhaps there are other settings for that - or maybe that one change will cover your bases. -- Waylan Limberg [EMAIL PROTECTED]
Re: replaces_module
On Nov 29, 2005, at 10:26 PM, Adrian Holovaty wrote: class META: db_table = 'anastas_users' replaces_module = 'auth.users' admin = meta.Admin() # field names to remove from parent model remove_fields = ['password', 'is_staff', 'is_superuser'] Would you please elaborate this new meta option 'replaces_module', which I couldn't find in the doc? Thanks. - Cheng
Re: replaces_module
Hello Adrian Holovaty! On Tue, 29 Nov 2005 08:26:11 -0600 you wrote: > To "remove" fields in the parent class, use "remove_fields". For > example: [...] >class META: >db_table = 'anastas_users' >replaces_module = 'auth.users' >admin = meta.Admin() ># field names to remove from parent model >remove_fields = ['password', 'is_staff', 'is_superuser'] How to be with field 'id'? -- Всего наилучшего! greg [at] anastasia [dot] ru Григорий.
Re: replaces_module
On 11/29/05, Grigory Fateyev <[EMAIL PROTECTED]> wrote: > as you see, lots of fields have the same fields from auth.users table. > How to escape double of fields, and auth can work like in forum and in > django? To "remove" fields in the parent class, use "remove_fields". For example: class User(users.User): user_id = meta.IntegerField() user_active = meta.CharField(maxlength=1) username = meta.CharField(maxlength=25) user_password = meta.CharField(maxlength=32) user_session_time = meta.IntegerField() user_session_page = meta.IntegerField() user_lastvisit = meta.IntegerField() user_regdate = meta.IntegerField() user_level = meta.CharField(maxlength=4) user_posts = meta.IntegerField() [...] class META: db_table = 'anastas_users' replaces_module = 'auth.users' admin = meta.Admin() # field names to remove from parent model remove_fields = ['password', 'is_staff', 'is_superuser'] Hope this answers your question, Adrian -- Adrian Holovaty holovaty.com | djangoproject.com | chicagocrime.org
Re: customizing admin
Tom Tobin wrote:
On 11/29/05, Medium <[EMAIL PROTECTED]> wrote:
Robert Wittams wrote:
Medium wrote:
4. Can we change the template {{ variable }} to something like
${variable} I don't mind the {% %} but {%starttag%}{{var}}{%endtag%}..
You can assume this is not going to change, it would break too much for
very little benefit. I guess you could monkey patch
django.core.template.VARIABLE_TAG_START and
django.core.template.VARIABLE_TAG_END if you wanted to. It would be kind
of silly though.
You're right about the little benefit, but this syntax ${var} or $var is
very widely used in many template solutions across all languages and
provides a level of familiarity to most template users. Easier migration
and therefore wider adoption may prove a benefit which isn't as obvious now.
I'm sorry, but I can't help but think that a user who is skilled
enough to be comfortable with a alternate but not-wildly-different
syntax, yet who would face major difficulties adjusting to Django's
syntax, has other problems than the syntax at hand. :-) FWIW, I
actually find Django's template syntax easier to read and use than
dollar-sign based syntax (which in turn feels alien and Perl-ish to
me).
I don't think it has anything to do with skill or their ability to pick
it up and get use to it over time. You can say that about any syntax
(good or bad). My main point i guess was that if someone saw django
template at a glance (which is usually how I evaluate things initially)
the more familiar it seems the more chance of me trying it out because I
don't have to reconfigure my brain too much. You name it and most
popular templating solutions use this syntax, which means more designers
as well are also familiar with ${} syntax.
Personally, I don't find this a major issue, just a thorn in the side,
but I wanted to ask the question on the very far chance that django can
be made even more popular because I like it alot.
Cheers,
Huy
Re: Error With /media In URL?
OK, think I may have found the problem with this. In the settings.py, ADMIN_MEDIA_PREFIX is set to /media/ by default. I'm going to sort through the code, but I think that's the starting point. Comments? J
replaces_module
Hello! I have forum on phpbb (about 2 users), and now want to integrate auth with django. Went throgh legasy database doc and have this table: class User(users.User): user_id = meta.IntegerField() user_active = meta.CharField(maxlength=1) username = meta.CharField(maxlength=25) user_password = meta.CharField(maxlength=32) user_session_time = meta.IntegerField() user_session_page = meta.IntegerField() user_lastvisit = meta.IntegerField() user_regdate = meta.IntegerField() user_level = meta.CharField(maxlength=4) user_posts = meta.IntegerField() [...] class META: db_table = 'anastas_users' replaces_module = 'auth.users' admin = meta.Admin() as you see, lots of fields have the same fields from auth.users table. How to escape double of fields, and auth can work like in forum and in django? Thanks a lot! -- Всего наилучшего! greg [at] anastasia [dot] ru Григорий.
