Re: django pastebin
On Tuesday 21 Mar 2006 8:01 am, Julio Nobrega wrote: > I get Python already selected when I access > http://django.pastebin.com/ i get php -- regards kg http://www.livejournal.com/users/lawgon tally ho! http://avsap.org.in ಇಂಡ್ಲಿನಕ್ಸ வாழ்க! --~--~-~--~~~---~--~~ 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: Quick thanks to django team - I deployed my first app
I can't post the full code, it was written for a client and has some
secret sauce that I am not at liberty to share, but I'll try to find
the time to develop a santized example.
In the meantime here is the relevent model part. the thing being
reserved is the server, but it could really be anything.
Model class
class Server(meta.Model):
ip = meta.IPAddressField()
port = meta.IntegerField()
created_at = meta.DateTimeField(auto_now_add=True)
updated_at = meta.DateTimeField(auto_now=True)
active = meta.BooleanField(default=False)
name = meta.CharField(maxlength=200,default='unnamed')
def get_current_stat(self):
return self.get_serverstat(select_related=True,limit=1)
def __repr__(self):
if self.ip and self.port:
stat = ""
try:
stat = str(self.get_current_stat())
if len(stat)>2:
return "%s %s" % (self.name,stat)
except:
pass
return "%s:%s" % (self.ip,self.port)
else:
return self.name
class META:
admin = meta.Admin(
fields = (
(None, {
'fields': ('name','ip', 'port', 'active', 'updated_at')
}),)
)
class Reservation(meta.Model):
server = meta.ForeignKey(Server,edit_inline=meta.TABULAR)
trainer = meta.CharField(maxlength=200,default="Trainer")
start = meta.DateTimeField(core=True)
end = meta.DateTimeField()
def get_absolute_url(self):
return '''/trainer/obtain_url/%s/''' % self.id
def __repr__(self):
if self.trainer and self.start:
return "%s @ %s" % (self.trainer,
(datetime.timedelta(0,0,0,0,0,-5) + self.start).strftime("%a, %d %b %Y
%H:%M"))
elif self.id:
return "Incomplete Reservation %d" % self.id
else:
return "Unsaved and Incomplete Reservation"
def _module_get_future_reservations():
return get_list(start__gte=datetime.datetime.now())
def _pre_save(self):
'''A server is already reserved if there is another reservation
with a start of end date in the
same range as the new reservation'''
from django.models.regservers import AlreadyReserved,
reservations, servers
from django.core.meta import Q
server = servers.get_list(id__exact=self.server_id)[0]
blockers = server.get_reservation_list(complex=(
Q(start__range=(self.start,self.end)) |
Q(end__range=(self.start,self.end)) )
)
blockers = [b for b in blockers if b.trainer <> self.trainer]
if len(blockers)>0:
raise AlreadyReserved(blockers)
class META:
admin = meta.Admin()
ordering = ['start']
Here is the first view function that lists all of the available
servers. This could be more elegent. I pull in all of the active
servers and then iterate through each one looking for active
reservations. This give me a chance to add in more complex logic that
can't be easily done in SQL. Also for this application the number of
servers is in the 100's and this way is more then fast enough.
def select_server(request):
start = datetime.datetime.now()
end = start + datetime.timedelta(0,0,0,0,0,4)
server_list = []
all_server_list = servers.get_list(name__contains='RESERVEABLE',
active__exact=True)
for server in all_server_list:
if len(server.get_reservation_list(complex=(
Q(start__range=(start,end)) |Q(end__range=(start,end)==0:
server_list.append(server)
return render_to_response('regservers/select_server',
{'server_list': server_list})
Here is the function that saves a reservation. I don't use a
manipulator because the input data is pretty simple. Also the servers
can only be reserved for 1-4 hours, the code that looks like: if
duration.find('one')>=0 has a reason other then validating that the
duration is between 1-4.
def reserve_server(request,ip,port):
server = get_object_or_404(servers,ip__exact=ip,port__exact=port)
error = ""
if request.POST:
trainer = request.POST.get("trainer","")
if len(trainer) < 3:
error = "Please enter the name of the trainer"
if not error:
duration = request.POST.get("duration","one")
print duration
if duration.find('one')>=0:
duration = 1
elif duration.find('two')>=0:
duration = 2
elif duration.find('three')>=0:
duration = 3
elif duration.find('four')>=0:
duration = 4
else:
duration = 1
start = datetime.datetime.now()
end = datetime.timedelta(0,0,0,0,0,duration) + start
try:
new_reservation =
server.add_reservation(trainer=trainer,start=start,end=end)
except AlreadyReserved, e:
error = 'Please choose
Re: django pastebin
On 3/20/06, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote: > > hi, > dunno if it is possible, but could the default language in django > pastebin be set to python instead of php? > -- I get Python already selected when I access http://django.pastebin.com/ -- Julio Nobrega - http://www.inerciasensorial.com.br --~--~-~--~~~---~--~~ 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 pastebin
On 3/21/06, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote: > > hi, > dunno if it is possible, but could the default language in django > pastebin be set to python instead of php? I don't understand what you are talking about? -- I like python! My Blog: http://www.donews.net/limodou NewEdit Maillist: http://groups.google.com/group/NewEdit --~--~-~--~~~---~--~~ 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: OneToOneField
On Tuesday 21 Mar 2006 5:52 am, layik wrote: > Class member: > username = meta.foreignKey (users) > email = charfield this is not onetoone -- regards kg http://www.livejournal.com/users/lawgon tally ho! http://avsap.org.in ಇಂಡ್ಲಿನಕ್ಸ வாழ்க! --~--~-~--~~~---~--~~ 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: OneToOneField
bruno desthuilliers wrote: > layik wrote: > > is the bug fixed? > > Which one ? and in which version ? > > > I didnt quite understand the previous topics. > > could anyone please tel me what I need to be aware of when trying to > > extend tables and using OneToOneField > > > > many thanks > > > > > > > > > > > > > -- > bruno desthuilliers > développeur > [EMAIL PROTECTED] > http://www.modulix.com sorry, I am using 0.91, I was reading some posts regardin A bug in it and I was reading it is now fixed but I wasnt sure which one either! my problem with 1to1 is: Class user: username (UNIQUE) Class member: username = meta.foreignKey (users) email = charfield in my_view: u = user.get_object(pk=1) m = u.get_member() <<= error: table user has no attribute member m = member.get_object(username__exact= "me")<<= error: table user has no attribute username does it work for anyone? am I doing the wrong thing? will it work if I do it the other way?? 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: django problem at dreamhost
> Does the "apps" directory have an __init__.py file in it? Generally > that "no module named..." error signifies there's no __init__.py. ha! that may have been it. killed apps now so cant check, but this may have been it. thanks for the pointer. -- rgds, Jaanus --~--~-~--~~~---~--~~ 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: magick-removal: Suggestion
Viktor Kerkez wrote: > Glenn Tenney wrote: >> As a friend of mine reminded me, part of your perception feeding that >> conception is that you're still thinking of these as being columns in >> a table... when in fact they are classes derived from FormField (and >> you can derive your own classes from FormField or even from other >> field types). > > I think you didn't understood me... Classes from django.forms are > derived from django.forms.FormField, but classes in > django.db.models.fields aren't. They are derived from > django.db.models.fields.Field, and they are conceptually different but > still haveing the same naming convention *Field... This is fairly common in various languages that you should always treat things in different namespaces (django.forms vs. django.db.models.fields), regardless of naming scheme, as being conceptually different. In most cases you should keep in mind that the entire namespace is just as much a part of the naming scheme as the class name itself. There's no reason to add verbosity to your class names that is already in your namespace name(s). -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ 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: magick-removal: Suggestion
Glenn Tenney wrote: > As a friend of mine reminded me, part of your perception feeding that > conception is that you're still thinking of these as being columns in > a table... when in fact they are classes derived from FormField (and > you can derive your own classes from FormField or even from other > field types). I think you didn't understood me... Classes from django.forms are derived from django.forms.FormField, but classes in django.db.models.fields aren't. They are derived from django.db.models.fields.Field, and they are conceptually different but still haveing the same naming convention *Field... I was just talking about naming convetion. It doesn't metter if they are columns in tables or pigeons on trees :) (IntegerColumn... was just a dumb suggestion) I was taling about them beeing apples and pears but still beeing named same... Sorry, for continuing closed topic :( I'll get used to Django... Eventually... :) --~--~-~--~~~---~--~~ 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: magick-removal: Suggestion
On Mon, Mar 20, 2006 at 08:57:53PM +0100, Viktor Kerkez wrote: > Ok, I still think that its conceptually wrong to have two completely > different sorts of objects shareing the same name... As a friend of mine reminded me, part of your perception feeding that conception is that you're still thinking of these as being columns in a table... when in fact they are classes derived from FormField (and you can derive your own classes from FormField or even from other field types). So, you need to change your perspective to think of these as being objects, in an object-oriented sense, that happen to map onto tables and columns, rather than as columns and tables that happen to map onto field names. -- Glenn Tenney --~--~-~--~~~---~--~~ 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: magick-removal: Suggestion
Ok, I still think that its conceptually wrong to have two completely different sorts of objects shareing the same name... But You're the bosses ;) Thanks for the time. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
session auto-logout
A newbie question: I am using Django admin's authentication to do login/logout for my own application. I want to automatically log user out if no activity for 5 minutes. I read the session tutorial and played a bit with SESSION_COOKIE_AGE -- but it doesn't work for me. Any suggestion 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 -~--~~~~--~~--~--~---
Re: magick-removal: Suggestion
On 3/20/06, Viktor Kerkez <[EMAIL PROTECTED]> wrote: > The suggestion is to rename the classes from django/db/models/fields to, > for example: IntegerColumn, TextColumn or IntegerCol, CharCol... (thats > what they really are... columns in tables...) Hey Viktor, Thanks for taking the time to make the suggestion. I don't think this would be a change worth making, though, because it's not worth the hassle of backwards incompatibility and (as James mentioned) they don't necessarily map to database columns. My suggestion for you is to exploit Python's elegant importing system and do things like "from django.db.models import IntegerField as IntegerCol" if you're really concerned about the names. You could even create your own module of renamed field classes and import from there. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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: magick-removal: Suggestion
On 3/20/06, Viktor Kerkez <[EMAIL PROTECTED]> wrote: > The suggestion is to rename the classes from django/db/models/fields to, > for example: IntegerColumn, TextColumn or IntegerCol, CharCol... (thats > what they really are... columns in tables...) I'd be against it conceptually, because they don't all map to actual column types. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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: magick-removal: Suggestion
Viktor Kerkez wrote: >The suggestion is to rename the classes from django/db/models/fields to, >for example: IntegerColumn, TextColumn or IntegerCol, CharCol... (thats >what they really are... columns in tables...) > > I'd rather rename form field classes to *FormField. They are used less frequently and there would be less people forced to change their code. But actually I think that it's not worth it. It's in fact good idea to define models and form fields in different places. --~--~-~--~~~---~--~~ 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 problem at dreamhost
On 3/20/06, Jaanus <[EMAIL PROTECTED]> wrote: > I can understand this and this all makes sense. What doesn't make sense > though, is that if the app lives in the "apps" directory, Django tells > me "no module named apps" - although all the settings are correct and > it works in another host with the same settings. Does the "apps" directory have an __init__.py file in it? Generally that "no module named..." error signifies there's no __init__.py. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
magick-removal: Suggestion
Hi everyone, Before starting I want to give one Hip Hip Hooray for the m-r branch :) Now to start ;). There is one thing that bugs me with the naming convention in Django. All classes in the django/forms have the same *Field* ending, which is 100% OK because they really are fields. But also all classes in the django/db/models/fields have the same ending... In fact, they have absolutly same names :-/, which is pritty confusing and error prone (especially if you want to write your own fields (because of this naming convention you can't even put your classes in the same file :-/ )) The suggestion is to rename the classes from django/db/models/fields to, for example: IntegerColumn, TextColumn or IntegerCol, CharCol... (thats what they really are... columns in tables...) Please don't lynch me :), this is just a thought, because of the problems I had... (How to name them so I can put them in the same file? Whats this?! A forms field or a models field? and so on... ) Thanks for Your time. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
ManyToManyField corrupts headers
Situation:
Django 0.91, common CGI through WSGI, many-to-many fields with only one
available choice
(for example, use flatpages and try to add new flat page - you'll see
error)
Look at the line after #question target
fields.py:
ManyToManyField:
def flatten_data(self, follow, obj = None):
new_data = {}
if obj:
get_list_func = getattr(obj, 'get_%s_list' %
self.rel.singular)
instance_ids = [getattr(instance, self.rel.to.pk.attname)
for instance in get_list_func()]
if self.rel.raw_id_admin:
new_data[self.name] = ",".join([str(id) for id in
instance_ids])
else:
new_data[self.name] = instance_ids
else:
# In required many-to-many fields with only one available
choice,
# select that one available choice.
if not self.blank and not self.rel.edit_inline and not
self.rel.raw_id_admin:
choices_list = self.get_choices_default()
if len(choices_list) == 1:
#question target
print self.name, choices_list[0][0]
#end question target
new_data[self.name] = [choices_list[0][0]]
return new_data
This output occures before any legal HTTP header - so we get "Internal
Server Error"
May be it's just forgotten debug code?
--~--~-~--~~~---~--~~
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: OneToOneField
layik wrote: > is the bug fixed? Which one ? and in which version ? > I didnt quite understand the previous topics. > could anyone please tel me what I need to be aware of when trying to > extend tables and using OneToOneField > > many thanks > > > > > -- bruno desthuilliers développeur [EMAIL PROTECTED] http://www.modulix.com --~--~-~--~~~---~--~~ 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: on line chages
On 3/20/06, Mary Adel <[EMAIL PROTECTED]> wrote: > > Dear all, > > I need to ask a simple question and i hope u can help me :) > is their any facility that can let user of django cms see the changes > that he is doing and how the page will look like before clicking on save > changes button cause may be he will not like the change when he submit > it and he change his mind > I think you need do these things yoursef. -- I like python! My Blog: http://www.donews.net/limodou NewEdit Maillist: http://groups.google.com/group/NewEdit --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
on line chages
Dear all, I need to ask a simple question and i hope u can help me :) is their any facility that can let user of django cms see the changes that he is doing and how the page will look like before clicking on save changes button cause may be he will not like the change when he submit it and he change his mind Thanks, Mary --~--~-~--~~~---~--~~ 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 problem at dreamhost
limodou wrote: > It'll setup a app named appname in current directory, but not apps > directory. So if you want to create a new app in apps directory, you > should go into apps directory, and run the django-admin.py. Or create > the app manually it easy. I can understand this and this all makes sense. What doesn't make sense though, is that if the app lives in the "apps" directory, Django tells me "no module named apps" - although all the settings are correct and it works in another host with the same settings. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
