TabularInlineAdmin queries waaaaaayyyyyy too much.
I have an admin with 1 row in the tabular inline. I have a custom queryset in class ExtensionTabularInlineFormSet(BaseInlineFormSet): def get_queryset(self) -> QuerySet[Extension]: qs = super().get_queryset() This gets called 20 times to display that one row. When you have more rows, it gets called 20 times/row. The culprit is calls to this method: def initial_form_count(self): """Return the number of forms that are required in this FormSet.""" if not self.is_bound: return len(self.get_queryset()) return super().initial_form_count() The solution would be to cache this value, but admin views seem like singletons way too often for this to work. Anyone else seen this? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-users/f4bacbd9-b519-45af-8e5b-826c4b5d9c88n%40googlegroups.com.
Re: Django tests appear to be getting substantially slower
Ah, but the slowdown is happening from 1.8 forward, each version of Django make things just a bit slower. It's a gradual slowdown. I do think I've got 3.2x libsqlite though. So we can account for the slowdown on 2.1 -> 2.2 /usr/lib/libsqlite3.0.dylib /usr/lib/libsqlite3.dylib /usr/local/Cellar/sqlite/3.27.1/lib/libsqlite3.0.dylib /usr/local/Cellar/sqlite/3.27.1/lib/libsqlite3.a /usr/local/Cellar/sqlite/3.27.1/lib/libsqlite3.dylib /usr/local/Cellar/sqlite/3.28.0/lib/libsqlite3.0.dylib /usr/local/Cellar/sqlite/3.28.0/lib/libsqlite3.a /usr/local/Cellar/sqlite/3.28.0/lib/libsqlite3.dylib On Sat, Jun 15, 2019 at 8:16 AM Simon Charette wrote: > I meant Django 2.0 -> 2.1. As long as you are using Django 2.2 with SQLite > 3.20+ > the slowdown I mentioned should be effective. > > Simon > > Le samedi 15 juin 2019 08:32:56 UTC-4, Mark Jones a écrit : >> >> Maybe that's the case, I didn't build the python2.7 or 3.7, but I used >> pyenv to install 3.4, 3.5, and 3.6 and they are all using the same version >> of SQLite. And with each version of python, the tests slow down as the >> version of django increases. Could this still be the SQLite v2.1->v2.2? >> >> Django isn't getting slower as the version of python increases, it's >> getting slower as the version of Django increases. >> >> On Sat, Jun 15, 2019 at 7:20 AM Simon Charette wrote: >> >>> Hi Mark, >>> >>> It's hard to tell exactly what's going on without more details but >>> assuming you are running tests >>> against SQLite the 2.1 to 2.2 slowdown is likely caused by the fact >>> database constraints are >>> now checked of each TestCase[0]. >>> >>> Cheers, >>> Simon >>> >>> [0] https://docs.djangoproject.com/en/2.2/releases/2.2/#tests >>> >>> >>> Le samedi 15 juin 2019 07:26:35 UTC-4, Mark Jones a écrit : >>>> >>>> I was fixing up a Django app >>>> https://github.com/mark0978/django-softdelete and setting up tox to >>>> make sure it worked with all the listed versions because of issues opened >>>> on the original repo. While I was running tox locally I noticed that with >>>> every version of Django, the tests ran slower, and from 1.8 -> 2.2 the test >>>> time was nearly doubled. This was true for every version of python tested >>>> from 2.7 - 3.7. >>>> >>>> If you want to check this on your machine, just grab the repo and run >>>> tox. I'm including the minimal tox output to show this phenomenon. >>>> >>>> py27-A installed: DEPRECATION: Python 2.7 will reach the end of its >>>> life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't >>>> be maintained after that date. A future version of pip will drop support >>>> for Python 2.7.,Django==1.8.19,-e git+...@github.com: >>>> mark0978/django-softdelete.git@72b46b0a7823a4fdcb43489663e90713ca7d698d >>>> #egg=django_softdelete >>>> -- >>>> Ran 14 tests in 2.821s >>>> >>>> py27-B installed: DEPRECATION: Python 2.7 will reach the end of its >>>> life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't >>>> be maintained after that date. A future version of pip will drop support >>>> for Python 2.7.,Django==1.9.13,-e git+...@github.com: >>>> mark0978/django-softdelete.git@72b46b0a7823a4fdcb43489663e90713ca7d698d >>>> #egg=django_softdelete >>>> -- >>>> Ran 14 tests in 3.036s >>>> >>>> py27-C installed: DEPRECATION: Python 2.7 will reach the end of its >>>> life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't >>>> be maintained after that date. A future version of pip will drop support >>>> for Python 2.7.,Django==1.10.8,-e git+...@github.com: >>>> mark0978/django-softdelete.git@72b46b0a7823a4fdcb43489663e90713ca7d698d >>>> #egg=django_softdelete >>>> -- >>>> Ran 14 tests in 3.198s >>>> >>>> py27-D installed: DEPRECATION: Python 2.7 will reach the end of its >>>> life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't >>>> be maintained after that date. A future version of pip will drop support >>>> for Python 2.7.,Django==1.11.21,-e g
Re: Django tests appear to be getting substantially slower
Maybe that's the case, I didn't build the python2.7 or 3.7, but I used pyenv to install 3.4, 3.5, and 3.6 and they are all using the same version of SQLite. And with each version of python, the tests slow down as the version of django increases. Could this still be the SQLite v2.1->v2.2? Django isn't getting slower as the version of python increases, it's getting slower as the version of Django increases. On Sat, Jun 15, 2019 at 7:20 AM Simon Charette wrote: > Hi Mark, > > It's hard to tell exactly what's going on without more details but > assuming you are running tests > against SQLite the 2.1 to 2.2 slowdown is likely caused by the fact > database constraints are > now checked of each TestCase[0]. > > Cheers, > Simon > > [0] https://docs.djangoproject.com/en/2.2/releases/2.2/#tests > > > Le samedi 15 juin 2019 07:26:35 UTC-4, Mark Jones a écrit : >> >> I was fixing up a Django app >> https://github.com/mark0978/django-softdelete and setting up tox to make >> sure it worked with all the listed versions because of issues opened on the >> original repo. While I was running tox locally I noticed that with every >> version of Django, the tests ran slower, and from 1.8 -> 2.2 the test time >> was nearly doubled. This was true for every version of python tested from >> 2.7 - 3.7. >> >> If you want to check this on your machine, just grab the repo and run >> tox. I'm including the minimal tox output to show this phenomenon. >> >> py27-A installed: DEPRECATION: Python 2.7 will reach the end of its life >> on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be >> maintained after that date. A future version of pip will drop support for >> Python 2.7.,Django==1.8.19,-e git+...@github.com: >> mark0978/django-softdelete.git@72b46b0a7823a4fdcb43489663e90713ca7d698d >> #egg=django_softdelete >> -- >> Ran 14 tests in 2.821s >> >> py27-B installed: DEPRECATION: Python 2.7 will reach the end of its life >> on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be >> maintained after that date. A future version of pip will drop support for >> Python 2.7.,Django==1.9.13,-e git+...@github.com: >> mark0978/django-softdelete.git@72b46b0a7823a4fdcb43489663e90713ca7d698d >> #egg=django_softdelete >> -- >> Ran 14 tests in 3.036s >> >> py27-C installed: DEPRECATION: Python 2.7 will reach the end of its life >> on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be >> maintained after that date. A future version of pip will drop support for >> Python 2.7.,Django==1.10.8,-e git+...@github.com: >> mark0978/django-softdelete.git@72b46b0a7823a4fdcb43489663e90713ca7d698d >> #egg=django_softdelete >> -- >> Ran 14 tests in 3.198s >> >> py27-D installed: DEPRECATION: Python 2.7 will reach the end of its life >> on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be >> maintained after that date. A future version of pip will drop support for >> Python 2.7.,Django==1.11.21,-e git+...@github.com: >> mark0978/django-softdelete.git@72b46b0a7823a4fdcb43489663e90713ca7d698d >> #egg=django_softdelete,pytz==2019.1 >> -- >> Ran 14 tests in 3.609s >> >> py34-A installed: DEPRECATION: Python 3.4 support has been deprecated. >> pip 19.1 will be the last one supporting it. Please upgrade your Python as >> Python 3.4 won't be maintained after March 2019 (cf PEP >> 429).,Django==1.8.19,-e git+...@github.com: >> mark0978/django-softdelete.git@72b46b0a7823a4fdcb43489663e90713ca7d698d >> #egg=django_softdelete >> -- >> Ran 14 tests in 2.733s >> >> py34-B installed: DEPRECATION: Python 3.4 support has been deprecated. >> pip 19.1 will be the last one supporting it. Please upgrade your Python as >> Python 3.4 won't be maintained after March 2019 (cf PEP >> 429).,Django==1.9.13,-e git+...@github.com: >> mark0978/django-softdelete.git@72b46b0a7823a4fdcb43489663e90713ca7d698d >> #egg=django_softdelete >> -- >> Ran 14 tests in 3.066s >> >> py34-C installed: DEPRECATION: Python 3.4 support has been deprecated. >> pip 19.1 will be the last one supporting it. Please upgrade you
Django tests appear to be getting substantially slower
I was fixing up a Django app https://github.com/mark0978/django-softdelete and setting up tox to make sure it worked with all the listed versions because of issues opened on the original repo. While I was running tox locally I noticed that with every version of Django, the tests ran slower, and from 1.8 -> 2.2 the test time was nearly doubled. This was true for every version of python tested from 2.7 - 3.7. If you want to check this on your machine, just grab the repo and run tox. I'm including the minimal tox output to show this phenomenon. py27-A installed: DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7.,Django==1.8.19,-e git+...@github.com:mark0978/django-softdelete.git@72b46b0a7823a4fdcb43489663e90713ca7d698d#egg=django_softdelete -- Ran 14 tests in 2.821s py27-B installed: DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7.,Django==1.9.13,-e git+...@github.com:mark0978/django-softdelete.git@72b46b0a7823a4fdcb43489663e90713ca7d698d#egg=django_softdelete -- Ran 14 tests in 3.036s py27-C installed: DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7.,Django==1.10.8,-e git+...@github.com:mark0978/django-softdelete.git@72b46b0a7823a4fdcb43489663e90713ca7d698d#egg=django_softdelete -- Ran 14 tests in 3.198s py27-D installed: DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7.,Django==1.11.21,-e git+...@github.com:mark0978/django-softdelete.git@72b46b0a7823a4fdcb43489663e90713ca7d698d#egg=django_softdelete,pytz==2019.1 -- Ran 14 tests in 3.609s py34-A installed: DEPRECATION: Python 3.4 support has been deprecated. pip 19.1 will be the last one supporting it. Please upgrade your Python as Python 3.4 won't be maintained after March 2019 (cf PEP 429).,Django==1.8.19,-e git+...@github.com:mark0978/django-softdelete.git@72b46b0a7823a4fdcb43489663e90713ca7d698d#egg=django_softdelete -- Ran 14 tests in 2.733s py34-B installed: DEPRECATION: Python 3.4 support has been deprecated. pip 19.1 will be the last one supporting it. Please upgrade your Python as Python 3.4 won't be maintained after March 2019 (cf PEP 429).,Django==1.9.13,-e git+...@github.com:mark0978/django-softdelete.git@72b46b0a7823a4fdcb43489663e90713ca7d698d#egg=django_softdelete -- Ran 14 tests in 3.066s py34-C installed: DEPRECATION: Python 3.4 support has been deprecated. pip 19.1 will be the last one supporting it. Please upgrade your Python as Python 3.4 won't be maintained after March 2019 (cf PEP 429).,Django==1.10.8,-e git+...@github.com:mark0978/django-softdelete.git@72b46b0a7823a4fdcb43489663e90713ca7d698d#egg=django_softdelete -- Ran 14 tests in 3.232s py34-D installed: DEPRECATION: Python 3.4 support has been deprecated. pip 19.1 will be the last one supporting it. Please upgrade your Python as Python 3.4 won't be maintained after March 2019 (cf PEP 429).,Django==1.11.21,-e git+...@github.com:mark0978/django-softdelete.git@72b46b0a7823a4fdcb43489663e90713ca7d698d#egg=django_softdelete,pytz==2019.1 -- Ran 14 tests in 3.564s py34-E installed: DEPRECATION: Python 3.4 support has been deprecated. pip 19.1 will be the last one supporting it. Please upgrade your Python as Python 3.4 won't be maintained after March 2019 (cf PEP 429).,Django==2.0.13,-e git+...@github.com:mark0978/django-softdelete.git@72b46b0a7823a4fdcb43489663e90713ca7d698d#egg=django_softdelete,pytz==2019.1 -- Ran 14 tests in 5.515s py35-A installed: Django==1.8.19,-e git+...@github.com:mark0978/django-softdelete.git@72b46b0a7823a4fdcb43489663e90713ca7d698d#egg=django_softdelete -- Ran 14 tests in 2.603s py35-B installed: Django==1.9.13,-e git+...@github.com:mark0978/django-softdelete.git@72b46b0a7823a4fdcb43489663e90713c
Re: Accessing Django project models from CGI
Can't imagine why you would want to do this via CGI, it can't perform very well. There is a TON of stuff that gets setup during initialization for wsgi/runserver, etc.. Syntax wise your import is way off since your models do not live in the Django folder, you can't import them like this. I'd take a look at deploying mod_wsgi and running the app there. On Sunday, April 7, 2013 10:11:00 PM UTC-5, Pradeep Kumar wrote: > > Hi, > > I am creating a widget for one of our projects for the first time. The > script file used calls a python file in cgi-bin/widget.py > > Is there a way I can access models of a particular project in widget.py > using import ? > > say : from django.*projectname.appname.models* import * > > > I tried relocating the cgi-bin/ folder inside one of the project folders > but it wasn't recognizing the import as it didn't recognize the modules. > > > Currently I am using REST api provided by tastypie and getting the > required info used for widget. Is there a better way to do it? > > > Please let me know the available options for creating such widget backend > scripts and any good links will be helpful (found very few but none > addressing my issue). > > > > Thanks, > Pradeep > -- 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: Problems creating django project in Windows 7
I use WingIDE and one license covers all 3 platforms for a developer. And the guys that make it are incredibly nice and helpful with features and how to use. I Highly recommend it. (30 day free trial too) -- 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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Problems creating django project in Windows 7
I've created a manage.cmd and put it on my path so I can type less while on windows the command is just @echo off python manage.py %* this makes it more like linux The "@echo off" part is important because mange dumpdata >filename doesn't want to see the command line echoed into the json file. -- 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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Saving the query object for later
I was thinking I could pickle/unpickle the request then run it thru with an extra flag of (send email) thru the same code that wsgi uses. If I jsonify the data, how would I get that back into a python object? Is it really as simple as str=json.dumps(request) and request = json.loads(str) I don't see how json keeps track of the object it is dumping, and not sure how to construct a request object from the json return value. I can see how easy that part would be in C++, but my python skills are a good deal weaker I guess I'm hunting for "how to do this in python" -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Saving the query object for later
When someone searches for something on the site and finds nothing, I want to save that query for later reuse (so I can run it each night to see if anything new matches their request, and email what is found to the user). What is the best way to go about this? 1. Save the SQL that is generated and just run it later? If so, how? I'm going to want the ORM to be involved in this since I will be templating the emails. 2. Pickle the lookup? Thanks in advance. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Django Filter parser slightly less than intuitive
{{ datevar|date: dateformat}}
won't parse.
You get the error:
Could not parse the remainder: ': dateformat' from 'datevar|date:
dateformat'
Turns out that unlike most other places, spaces ARE significant here.
It could be fixed by changing the filter_raw_string on line 448 of
django/template/__init__.py to eat the whitespace before and after the
variable or constant or i18n string with something like
\s* added to this portion of the regex for parsing
(?:%(arg_sep)s\s*# Added here
(?:
%(i18n_open)s"(?P%(str)s)"%(i18n_close)s|
"(?P%(str)s)"|
(?P[%(var_chars)s]+)
)\s* # and here
It should probably either be fixed or at least documented.
I'm posting this here so that others can find it quickly and
understand the cause of the error message. I wasted over an hour
because the error message wasn't clear enough to say, hey stupid,
white space all of a sudden matters with filter arguments.
--~--~-~--~~~---~--~~
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
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Trying to understand Django and Python from a C++ perspective
Yea, I'm not wanting to use stuff.objects, but I'm wanting to pull some of the same voodoo, probably not safe for a python novice like myself :-) On Jun 29, 5:24 pm, Alex Gaynor wrote: > On Mon, Jun 29, 2009 at 5:19 PM, Mark Jones wrote: > > > I can't seem to reason out why/how this works. > > > I have a class Named Stuff > > > I can say Stuff.objects.filter(.) and that will return valid set > > of data. > > > What I can't understand is what exactly is objects, and why is it I > > can call it with Stuff.objects, but I can't call it with stuff.objects > > (an instance of Stuff). > > > >>> dir(Stuff) shows me 'objects' > > >>> dir(stuff) shows me 'objects' > > > >>> type(Stuff.objects) > > > > >>> type(stuff.objects) > > Traceback (most recent call last): > > File "", line 1, in > > File "...manager.py", line 151, in __get__ > > AttributeError: Manager isn't accessible via Stuff instances > > > What is the python Magic going on here to make this possible? > > > I'm asking because I want to make something like 'objects' in that it > > doesn't need an instance, but it is scoped within the model of Stuff. > > > My background is C++ and these look like methods/objects that are > > static to the class, not part of the instances. I just can't figure > > out how to declare and instantiate them in python. > > Django uses an advanced python feature called descriptors in order to > prevent you from accessing a manager (which is what "objects" is) from an > instance. My understanding of the reason for this is somewhat conceptual: > asking for all the objects that are "Stuff"s makes sense, but asking for all > the objects that are "some object" doesn't make as much sense. > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right to > say it." --Voltaire > "The people's good is the highest law."--Cicero --~--~-~--~~~---~--~~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Trying to understand Django and Python from a C++ perspective
I can't seem to reason out why/how this works. I have a class Named Stuff I can say Stuff.objects.filter(.) and that will return valid set of data. What I can't understand is what exactly is objects, and why is it I can call it with Stuff.objects, but I can't call it with stuff.objects (an instance of Stuff). >>> dir(Stuff) shows me 'objects' >>> dir(stuff) shows me 'objects' >>> type(Stuff.objects) >>> type(stuff.objects) Traceback (most recent call last): File "", line 1, in File "...manager.py", line 151, in __get__ AttributeError: Manager isn't accessible via Stuff instances What is the python Magic going on here to make this possible? I'm asking because I want to make something like 'objects' in that it doesn't need an instance, but it is scoped within the model of Stuff. My background is C++ and these look like methods/objects that are static to the class, not part of the instances. I just can't figure out how to declare and instantiate them in python. --~--~-~--~~~---~--~~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: How can one template extend multiple templates?
It seems like maybe I don't understand the question but it will extend
an infinite number of templates
Just add {% extends "base.html" %} into every template you want to
extend.
You can even do {% extends "derived.html" %} which extends base.html
On Feb 24, 8:41 am, lzhshen wrote:
> Suppose I have base template called "base.html", can it extend more
> then two other template, such as "a01.html" and "a02.html"?
>
> Thanks in advance!
--~--~-~--~~~---~--~~
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
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Securely storing passwords
How about integrating with something like OpenID? Not sure if it would do the trick, but it might be a step in the right direction, assuming the sites you are interoperating with are 'friendly' On Feb 24, 5:49 am, LaundroMat wrote: > Hi - > > I'm working on a small django app that allows users to interact with > other websites where they have an account. Ofcourse, using this app > means providing your username and password for the other website. > > What are the most secure ways of handling this information? I suppose > encrypting the passwords is one option, but are there any ways to > prevent people who have access to the app's source code and database > of retrieving user's names and passwords? > > Thanks in advance, > > Mathieu --~--~-~--~~~---~--~~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django App build - the right process?
The first 2 saves are overly complex: def save(self): if self.unit_price and not self.price_discount == '0': adjust = float(self.price_discount / 100.0) val_result = str(adjust) discount = Decimal(self.unit_price - (Decimal(val_result) * self.unit_price)) self.product_id.product_selling_price = discount self.product_id.save() super(ProductSellingPrice, self).save() else: self.product_id.product_selling_price = self.unit_price self.product_id.save() super(ProductSellingPrice, self).save() There is no need for an if here, the math works out, so you just lose the if and do the computations every time. I would still move the code to something like: self.product_id.product_selling_price = adjust_price(self.unit_price) which of course would just be written as self.adjust_selling_price() The last one looks like a complicated business rule in the first place, not sure how you fix it, other than to refactor that code out of save into an adjust_pricing() so that the save logic is reasonable. This does just move the glob that is the discounting to somewhere else, but it makes it easier to follow the save logic while it is happening. --~--~-~--~~~---~--~~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Not understand help_text
I occurred to me last night right before sleep that I can patch this in my code by deriving all my forms from my MyForm, fixing it in one place and remaining DRY. Nice to see I'm not the only one that found this to be a bit strange. --~--~-~--~~~---~--~~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Not understand help_text
That is exactly the kind of WET I was talking about. as_p() with appropriate CSS styling will render really nice forms as is, with the exception of the help_text. I even think that could be fixed without any major rework, just a change in the as_p() string from def as_p(self): "Returns this form rendered as HTML s." return self._html_output(u'%(label)s %(field)s%(help_text) s', u'%s', '', u' %s', True) to def as_p(self): "Returns this form rendered as HTML s." return self._html_output(u'%(label)s %(field)s%(help_text)s', u'%s', '', u' %s', True) similar changes would be needed for as_ul() and as_table() --~--~-~--~~~---~--~~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Not understand help_text
When a model field has help_text, that text will be show in the form. I'm a little bothered by this because effectively the model is doing something that really belongs in the view, but I understand the point is to make it easy to create forms based on a model and I can just live with it. What bothers me about this is that it seems pointless to have this shortcut if the help_text isn't identified in some way when it is output using as_p() so that I end up with: Username: Required. 30 characters or fewer. Alphanumeric characters only (letters, digits and underscores). If I have an error I get: This field is required. Username: Required. 30 characters or fewer. Alphanumeric characters only (letters, digits and underscores). where the error is styled in such away that I can draw attention to it. I could just go in and hand code my forms in the template so I have TOTAL control over rendering, it just seems strange I have to go from drop dead easy as_p() to WET (opposite of DRY) to get my forms out, or I have to go and overload as_p() in all my forms Here is to hoping I'm just stupid and don't see the method behind the madness --~--~-~--~~~---~--~~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Is safe unsafe?
Kind of sucks that you are worried about your server, but not worried about the people that might use your site. I'd answer your question regarding JS except for the fact I think the server and the clients should be safe for the general public, and I don't want to make it that easy on you. Allowing some script kiddie to load JS into a field that will play back on someone else's machine is reprehensible, even if those users aren't smart enough to install noscript. On Feb 23, 1:32 pm, Michael Repucci wrote: > Hi Django'ers, this will probably sound like a silly question, but > normally I haven't had to think about server security (that's been > someone else's job). However, on my current project I do need to > consider this, and I just wanted to double-check that I understand the > risks of using the "safe" tag in HTML templates. > > I've got users that I shouldn't entirely trust, who have access to a > TextField in a model, and that field is displayed in the resultant > HTML with the safe filter. Now, I understand that that means the user > could put JavaScript (or similar) in this field, and it will be > triggered when the page loads. But this doesn't present a threat to > the server security does it? PHP includes won't be interpreted, so > that's not a problem, and JavaScript doesn't have access to the server > file system, right? I'm just not sure whether there is potential HTML > code that could be used to actually damage the server, access its > files, or cause a DoS attack. > > Any help would be greatly appreciated! Thanks in advance!! --~--~-~--~~~---~--~~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: CheckboxInput widget has a flaw when used with an IntegerField
Maybe because I have a list of values that I want the user to be able
to select between. A list of 4 or so things that I want the user to
be able to choose one or more of. Is there some better way to get
this accomplished?
On Feb 19, 11:43 am, Karen Tracey wrote:
> On Thu, Feb 19, 2009 at 11:56 AM, Mark Jones wrote:
>
> > forms.IntegerField(widget=forms.CheckboxInput(attrs={'value':1}),
> > required=False)
>
> > won't work because
>
> > def value_from_datadict(self, data, files, name):
> > if name not in data:
> > # A missing value means False because HTML form submission
> > does not
> > # send results for unselected checkboxes.
> > return False
> > return super(CheckboxInput, self).value_from_datadict(data,
> > files, name)
>
> > returns False when the box is unchecked, and False is not one of the
> > EMPTY_FIELDS so you end up with required=True even when you specify
> > required=False
>
> Huh? The field doesn't become required. Rather the IntegerField is unable
> to validate the value returned in the case where the check box is unchecked:
>
> Python 2.5.1 (r251:54863, Jul 31 2008, 23:17:40)
> [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> (InteractiveConsole)>>> from django import forms
> >>> class OBF(forms.Form):
>
> ... x = forms.IntegerField(widget=forms.CheckboxInput(attrs={'value':1}),
> required=False)
> ...>>> f = OBF({})
> >>> f.is_valid()
> False
> >>> f.errors
>
> {'x': [u'Enter a whole number.']}
>
> The error is not that the field is required, but that the value returned by
> the widget cannot be interpreted by the IntegerField.
>
> > Not sure how to fix this for real, I've created a CheckboxInteger that
> > returns None instead of False
>
> > Any better ideas?
>
> Don't try to marry a widget that returns one sort of data to a field that is
> expecting something else? Seriously, why are you trying to hammer in your
> nail with this screwdriver?
>
> Karen
--~--~-~--~~~---~--~~
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
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
CheckboxInput widget has a flaw when used with an IntegerField
forms.IntegerField(widget=forms.CheckboxInput(attrs={'value':1}),
required=False)
won't work because
def value_from_datadict(self, data, files, name):
if name not in data:
# A missing value means False because HTML form submission
does not
# send results for unselected checkboxes.
return False
return super(CheckboxInput, self).value_from_datadict(data,
files, name)
returns False when the box is unchecked, and False is not one of the
EMPTY_FIELDS so you end up with required=True even when you specify
required=False
Not sure how to fix this for real, I've created a CheckboxInteger that
returns None instead of False
Any better 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
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: checkboxInput values
and you do that like so:
answer0 = forms.IntegerField(label='', widget=forms.CheckboxInput
(attrs={'value':0}))
for the next bloke that doesn't want to have to figure it out.
--~--~-~--~~~---~--~~
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
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: can't clear form data in runserver (works in shell)
I guess I wasn't thinking completely clearly in regards to that, I'm guessing the only failures that could happen might be failure to connect to the server guess I'll need to dig into what failures could be returned and what they might mean. I did solve the problem with this one line added to clearsent: self.data._mutable=True # this doesn't seem right, but what the heck its 1am On Feb 3, 1:21 am, Malcolm Tredinnick wrote: > On Mon, 2009-02-02 at 23:05 -0800, Mark Jones wrote: > > I have a form that is working well. However I want to allow them to > > reuse the form multiple times. Each time they submit the form, I will > > send up to 6 emails. Then, if an email is sent successfully, > > Right there you have your first problem. Emails aren't necessarily sent > immediately. What does "sent" mean? Accepted by your server? Received at > the target end and not bounced? There are lots of way an email can fail. > Further, it can take some time to send email (connection times and so > on), even just to a local system. So blocking the web response based on > some "success or fail" measure in the email system is a bit fragile. > > Maybe you've carefully evaluated all the steps in the pipeline and have > your risks worked out. I'd consider whether you're really solving the > right problem, however. > > > > > I want > > to remove that email address from the form that I present to them. If > > the email isn't successfully sent, I want to move that field up the > > list. > > > The problem comes when I get to > > > self.data[friend] = '' > > > inside clearsent > > > When I work thru this in the shell, it works as expected, but when > > runserver is going, it generates the error: This QueryDict instance is > > immutable > > > I don't want to clear all the fields, I want to leave the email > > subject and body alone and clear the 'To' fields and present the form > > for another round of emails to be sent. How do you do this? > > Copy the data dictionary: request.POST.copy() is the usual idiom when > you want to change something like that. You can't change Django's copy > of the data, but you can certainly make your own copy and change that. > > Regards, > Malcolm --~--~-~--~~~---~--~~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
can't clear form data in runserver (works in shell)
I have a form that is working well. However I want to allow them to
reuse the form multiple times. Each time they submit the form, I will
send up to 6 emails. Then, if an email is sent successfully, I want
to remove that email address from the form that I present to them. If
the email isn't successfully sent, I want to move that field up the
list.
The problem comes when I get to
self.data[friend] = ''
inside clearsent
When I work thru this in the shell, it works as expected, but when
runserver is going, it generates the error: This QueryDict instance is
immutable
I don't want to clear all the fields, I want to leave the email
subject and body alone and clear the 'To' fields and present the form
for another round of emails to be sent. How do you do this?
class AnnounceForm(forms.Form):
friend1 = forms.EmailField(label='1st Friend', required=True,
help_text='Enter the first friend you want to tell about this')
friend2 = forms.EmailField(label='2nd Friend', required=False)
friend3 = forms.EmailField(label='3rd Friend', required=False)
friend4 = forms.EmailField(label='4th Friend', required=False)
friend5 = forms.EmailField(label='5th Friend', required=False)
friend6 = forms.EmailField(label='6th Friend', required=False)
cc_myself = forms.BooleanField(label='cc myself', required=False)
emailsubject = forms.CharField(label='Email Subject')
emailbody = forms.CharField(widget=forms.Textarea, label='The
email will say:')
friends =
('friend1','friend2','friend3','friend4','friend5','friend6')
def recipients(self):
data = super(AnnounceQuizForm, self).clean()
recipients = []
for friend in self.friends:
if data[friend]:
recipients.append(data[friend])
return recipients
def clearsent(self, sentto):
"""
Clear the form of all the emails that are contained in sentto
and repopulate the fields from the top down with the ones that did not
send successfully
"""
again = []
for friend in self.friends:
if self.cleaned_data[friend] not in sentto:
again.append(self.cleaned_data[friend])
self.data[friend] = ''
if len(again):
fields = list(self.friends)
fields.reverse()
for email in again:
self.data[fields.pop()] = email
--~--~-~--~~~---~--~~
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
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Changing database fields
This is where Rails rocks and DJango doesn't. I haven't been able to find any kind of DB Migrations in Django like those in Rails. Sad too, because other than that, Python is a lot nicer than Ruby (Syntax wise for an old C++ programmer) On Jan 28, 3:29 pm, Oleg Oltar wrote: > Hi! > I am creating my first application. Which is to be a small publishing > system. > > I defined a model, which represent a single article, and also added about 15 > articles to my database (which is sqlite3). > > Now I understand that I should extend my models with few more fields (e.g. > need to add categories and date_published). I thought that can simply > add those to my models, but then realized that I need to modify already > created fields... > > Is there a common practice to do it? Maybe some recipe? > > Thanks, > Oleg --~--~-~--~~~---~--~~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: changing form field rendering dependent on field type
That almost sounds like you will have to write the renderer for that
class. I don't think this will be easy to do in the template, but if
you override django.forms.widgets.Select.render. you can probably make
it work.
On Jan 26, 11:51 am, mattsouth wrote:
> I wish to customise a form template so that I produce forms like:
>
>
> my text field :
>
> my select field : ...
> my multiline text field :
>
>
>
> i.e. forms in a single column of paragraph tabs where usually the
> field label and input field are in separate blocks, except when the
> field is a select box (i.e. it's widget is a
> django.forms.widgets.Select object). I'd like to iterate through the
> form fields to draw the template, following the documentation,
> using something like this:
>
>
> {% for field in form %}
> {{ field.label_tag }} : {% if field.is_select %} {{ field }} {%
> endif %}
> {% if not field.is_select %}{{ field }}{% endif %}
> {% endfor %}
>
>
> but I'm having difficulty detecting the selection field. Does anyone
> have any suggestions for doing this?
--~--~-~--~~~---~--~~
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
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Strange Model behavior
I guess I was just too tired when I wrote it, I just forgot the * and ** on the 2 arguments. I have some initialization that I'm doing in __init__ but had removed that to make the example shorter and was still seeing the problem. Thanks for the help, those 3 *'s fixed the whole problem On Jan 26, 5:50 am, Steve Holden wrote: > Dj Gilcrease wrote: > > What do you need to do in __init__ > > You don't actually need to fo anything at all! As you have the code now > you're calling the superclass's __init__ with two arguments: the newly > created instance, a tuple of the other positional args (if any) and a > dict of the keyword arguments (if any). > > Change the method to > > def __init__(self, *args, **kwargs): > super(Fails, self).__init__(*args, **kwargs) > --~--~-~--~~~---~--~~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Strange Model behavior
Sample.py includes the following: == from django.db import models class Good(models.Model): code = models.CharField(max_length=64) quizid = models.IntegerField(null=False, blank=False) published_on = models.DateTimeField(auto_now_add=True) class Fails(models.Model): code = models.CharField(max_length=64) quizid = models.IntegerField(null=False, blank=False) published_on = models.DateTimeField(auto_now_add=True) def __init__(self, *args, **kwargs): super(Fails, self).__init__(args, kwargs) === python manage.py shell >>> from Sample import Good,Fails >>> g = Good() >>> f = Fails() >>> type(g.id) >>> type(f.id) Why-O-Why does the type(f.id) != type(g.id) The reason this matters is because when I call Fails.save(), I get this message: Exception Type: TypeError Exception Value:int() argument must be a string or a number, not 'tuple' What I can't understand is why overriding __init__() causes this behavior. My code needs to do something in __init__(), but even when I remove all that it is doing, the model underneath changes the type of the id column. --~--~-~--~~~---~--~~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Putting pieces back together again
Thanks, formsets was the answers, and smartly enough, they didn't name
all the fields the exact same name, but reassemble them afterwards.
On Jan 12, 9:04 am, Jeff FW wrote:
> Mark,
>
> You should really use Forms and FormSets--they'll make this problem
> essentially go away.
>
> http://docs.djangoproject.com/en/dev/topics/forms/#topics-forms-indexhttp://docs.djangoproject.com/en/dev/topics/forms/formsets/
>
> -Jeff
>
> On Jan 12, 12:46 am, Mark Jones wrote:
>
> > I have some fields on my page that have more than one attribute for
> > simplification, lets say two attributes
>
> > answer = {'txt':'something', 'allowblank':0}
>
> > laid out on the page as:
> > {% for answer in quiz_question.answers %}
> >
> > > value="{{ answer.allowblank }}" />
> > {% endfor %}
>
> > the first is pulled from an input field, and if !allowblank, needs to
> > have some text.
>
> > I write some OnSubmit() javascript on my page to check this field, and
> > if it is blank, check the allowblank attribute in the following hidden
> > field to see if this is OK. If is isn't ok, I ask the user "you sure
> > you wanna leave this field blank?" If the user says "YES, I want to
> > leave it blank, the JS changes allowblank to 1 and we submit the form.
>
> > If the backend gets the form and the field is blank, but the
> > allowblank is true, then I know the user said OK, no problem, I let it
> > be blank, otherwise I validate it on the server side (in case they use
> > noscript like I do) and if allowblank=0 and the field is blank, I send
> > the form back to them with a checkbox like this
>
> > {% for answer in question.answers %}
> >
> > > value="{{ answer.allowblank }}" /> I
> > really want to leave this field blank
> > {% endfor %}
>
> > My problem comes about because a nice list of dict objects has been
> > broken apart by the html form and needs to be reassembled. While I
> > can do this like so:
>
> > for i in range(len(qqanswers)-1,0, -1):
> > qqanswers[i] = {'txt':answers[i], 'allowblank':int
> > (allowblank[i])}
> > if answers[i] == '' and allowblank[i]:
> > del qqanswers[i]
>
> > I don't like how ugly this looks. I tried changing the names of the
> > input objects to:
>
> > answers.txt and answers.allowblank, but that didn't work, I got POST
> > lists back that were names answers.txt and answers.allowblank that
> > looked like:
>
> > > u'answers.answer': [u'1', u'2', u'3', u'4']}>
>
> > of course all of this ignores the fact that checkboxes that aren't
> > checked aren't sent back to the server anyway which is where the need
> > for a more elegant solution comes from in the first place..
>
> > Is there a nice elegant way to solve this, or does it just have to be
> > done the way I've done it..
--~--~-~--~~~---~--~~
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
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Putting pieces back together again
I have some fields on my page that have more than one attribute for
simplification, lets say two attributes
answer = {'txt':'something', 'allowblank':0}
laid out on the page as:
{% for answer in quiz_question.answers %}
{% endfor %}
the first is pulled from an input field, and if !allowblank, needs to
have some text.
I write some OnSubmit() javascript on my page to check this field, and
if it is blank, check the allowblank attribute in the following hidden
field to see if this is OK. If is isn't ok, I ask the user "you sure
you wanna leave this field blank?" If the user says "YES, I want to
leave it blank, the JS changes allowblank to 1 and we submit the form.
If the backend gets the form and the field is blank, but the
allowblank is true, then I know the user said OK, no problem, I let it
be blank, otherwise I validate it on the server side (in case they use
noscript like I do) and if allowblank=0 and the field is blank, I send
the form back to them with a checkbox like this
{% for answer in question.answers %}
I
really want to leave this field blank
{% endfor %}
My problem comes about because a nice list of dict objects has been
broken apart by the html form and needs to be reassembled. While I
can do this like so:
for i in range(len(qqanswers)-1,0, -1):
qqanswers[i] = {'txt':answers[i], 'allowblank':int
(allowblank[i])}
if answers[i] == '' and allowblank[i]:
del qqanswers[i]
I don't like how ugly this looks. I tried changing the names of the
input objects to:
answers.txt and answers.allowblank, but that didn't work, I got POST
lists back that were names answers.txt and answers.allowblank that
looked like:
of course all of this ignores the fact that checkboxes that aren't
checked aren't sent back to the server anyway which is where the need
for a more elegant solution comes from in the first place..
Is there a nice elegant way to solve this, or does it just have to be
done the way I've done it..
--~--~-~--~~~---~--~~
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
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: NewBie Question about ForeignKey relationships
Thanks for the pointer, I had read all around that. The short version is: maker.auto_set.all() There was was Dry(er) more elegant method to be found. --~--~-~--~~~---~--~~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
NewBie Question about ForeignKey relationships
Ok, here is some simple code: class Maker(models.Model): name = CharField(max_length=20) class Auto(models.Model): name = CharField(max_length) maker = ForeignKey(Maker) maker = Maker.objects.get(pk=1) How do I get all the Autos made by this maker I don't see a maker.autos (railsish) All I have been able to figure out for this is: Auto.objects.filter(maker=maker.id)# this works Auto.objects.filter(maker=maker)# this works too Is that all there is, or is there some maker.autos abstraction that I just don't see. The last method 2 methods both work, but it seems awkward to use them given the fact that I have a Maker, and the relationship between Maker and Auto is known in the models but via the Manager interface requires restatement in (maker=maker.id) or alternately (maker=maker) --~--~-~--~~~---~--~~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: to understand MEDIA_URL
Are you closing the file after you write to it and before you try to send it? Why do you have to write it to a file to deliver it as a static file, why not just render it to a response directly? On Jan 5, 4:13 am, Alan wrote: > Hi List, > Because I couldn't find any idea better I am using "MEDIA_URL = '/static/'" > as a repository for the output of my application so I can see the results in > the web interface and download them. > > However, I noticed for a particular case where I open and read a file > content to be viewed in a web page that I get this error: > > - > IOError at /ccpngrid/call_status_func > > [Errno 2] No such file or directory: > '/Users/alan/workspace/webapps/static/grid/alan_20090105T094321/static/grid/alan_20090105T093444/Results_1brv_ccpngrid/DOCS/last_it/report' > > Request Method: POST > Request URL:http://localhost:8000/ccpngrid/call_status_func > Exception Type: IOError > Exception Value: > > [Errno 2] No such file or directory: > '/Users/alan/workspace/webapps/static/grid/alan_20090105T094321/static/grid/alan_20090105T093444/Results_1brv_ccpngrid/DOCS/last_it/report' > > Exception Location: /Users/alan/workspace/webapps/src/webAppsRoutines.py in > callStatusFunc, line 518 > - > > If I stop and restart the sever (manager.py runserver) it seems that my > static folder gets refreshed and then the server is now aware of this > 'report' file and then I can see it. If during this runserver session, I > submit another job, the new report will failed as show above. > > So, is it possible to "refresh" my "MEDIA_URL = '/static/'" in runserver > session without needing to restart it, or better rethink all the way I did > for presenting results (not using "MEDIA_URL = '/static/'" basically)? > Suggestions are welcome. > > Many thanks in advance. > > Alan > > -- > Alan Wilter S. da Silva, D.Sc. - CCPN Research Associate > Department of Biochemistry, University of Cambridge. > 80 Tennis Court Road, Cambridge CB2 1GA, UK. > > >>http://www.bio.cam.ac.uk/~awd28<< --~--~-~--~~~---~--~~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: I would like to report a bug but I can't log in
Well, I think we can all see where you get your nickname. On Jan 4, 12:03 am, Friendless wrote: > On Jan 4, 2:42 pm, "Karen Tracey" wrote: > > > I'll admit your tone here is starting to make me lose interest in your > > problem report. > > Admit it, you weren't very interested in the first place. You've given > me all sorts of reasons as to why the bug shouldn't be fixed, despite > (a) evidence that it is a bug, and (b) at least a clue as to how to > fix it. The simple fact of the matter is that Django failed on the > very first thing I did with it, your website doesn't work (yes, I did > try logging in using the link as Ramiro suggested), and my first > encounter with the community has been hostile. Django's doing nothing > for me, and I refuse to get involved with a community that won't even > believe me, let alone help. I've given you a good bug report, but now > I'm out of here. Do whatever you like. --~--~-~--~~~---~--~~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: File Download
Are you trying to get your source code off a server, and instead find it being executed by the webserver? If you have shell access, tar the files up and download that, create a folder where the files aren't executable and download them that way. If it is your source, I would assume you have some sort of source code repository that should have the source.. The question is a tad vague. On Jan 3, 10:21 pm, Sparky wrote: > Hello. This is probably a silly question but I have files being stored > onto a server and strangely getting them there was very easy but how > can I get them back down? > > Thank you for your patience in advance, > Sam --~--~-~--~~~---~--~~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Do sth on time ?
You need a process running outside the bounds of the webserver that reads the database every so often, and then sleeps with a wakeup every so often, and a list of when things "expire". It updates the database, the webpage reflects the update. You could of course do this via a wget driven by crontab, so that all the logic is on the webserver. On Jan 4, 4:50 am, makka...@gmail.com wrote: > Hi list, > > I have a web app which is a kind of arbitration application. Users bid on some > products or projects and the one who gives the biggest price gets the > project. Every project has some bidding expiration time. What i need is how > can i handle the situation to change the status of the project on a specific > time? For example , i submit a project and it should expire after 2 hours. > > Some solutions i can think are : > - Cronjobs , which checks the db every minute , but that will be very > expensive i think > - Twisted , but if server gets restarted i may loose the track of the > deferreds > > Does anyone solved a problem like that before ? Any suggestions ... --~--~-~--~~~---~--~~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Redirect parent from within iframe without losing session
are you redirecting to the same port? I think redirection to a
different domain OR port would keep the cookie from getting back to
the server, thus killing your session.
On Jan 3, 10:33 am, Berco Beute wrote:
> My page shows a (logged in) user an iFrame but when the iframe
> redirects the browser after it's done, the session is lost. The
> redirecting of the parent (by the iframe) is done as follows:
>
> =
>
>
> function load() {
> parent.location.href='http://localhost:8000/somewhere';
> }
>
>
> ==
>
> Is there a way to keep the session alive (e.g. keep the user logged
> in)?
>
> Thanks,
> 2B
--~--~-~--~~~---~--~~
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
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Could someone help me understand the finer points of import
For the discussion below, ALL the code is in .../intomec/tenq I wrote some code in tests.py like so: from tenq.models import * self.expectedValue = Answers((1,2,3,4)) within the to_python() method of AnswersField in models.py: def to_python(self, _value): print "_value.__class__ =",_value.__class__ if isinstance(_value, Answers): return _value isinstance(_value, Answers) fails for the object created in tests.py because the >>>_value.__class__ = >>>_value.__class__ = when I change tests.py to from intomec.tenq.models import * self.expectedValue = Answers((1,2,3,4)) I get >>>_value.__class__ = >>>_value.__class__ = and isinstance doesn't fail. What I can't figure out is, why do both imports work, and why do they generate different results. It seems to me the name of the class is the name of the class, and either the import should fail or they should both yield the same name. Anyone have any ideas on why this is? I'm not even sure why the second from statement works, since I'm already in the intomec folder when I run python manage.py test --~--~-~--~~~---~--~~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
