Borrowing functionality from Django Admin forms

[Justin Johnson]

I have a user who saw how new objects can be created using the Admin forms, 
and asked if I could reproduce some of that functionality.  I'm still new 
to Django, and even newer to building forms.  I'm wondering if there is a 
way to "borrow" elements from the Admin forms into my own forms and 
templates.  Particularly, I would like the ability to create a new related 
object by clicking the "+" sign next to that dropdown list on another form.

I have not been able to find much documentation on how the Admin forms are 
constructed for a given Django project.  I understand the basic form 
construction method, but I can't seem to find the equivalent workings in 
the Admin site.  Where is the equivalent of urls.py, where the links are 
mapped to specific Views?  Where are the equivalents of the Views, where a 
context is created and sent to the template?

I would like to get more familiar with the working code behind Django, and 
eventually contribute to the project, so feel free to get technical.

Thx.


-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/92f87737-2be9-4a04-8840-2edc14452b43%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

GeoDjango GDAL Slice Error in layer.py

[Justin Johnson]

I'm completely new to GeoDjango.  I'm working through the tutorial for 
Django version 2.0, and I am encountering an error when I follow the steps 
in the GeoDjango section.  

Specifically, when I attempt to slice a Layer object to extract Features, 
it gives me an error which looks like a possible bug.   I'll go through the 
steps here.


   1. 
   
https://docs.djangoproject.com/en/2.0/ref/contrib/gis/tutorial/#importing-spatial-data
   1. in this section of the tutorial, we import spatial data and use the 
  GDAL library to work with an imported shapefile of world borders
  2. Next, through the Django shell, I create a DataSource object 
  

 
  using the *django.contrib.gis.gdal *module
  3. I am able to retrieve, from this DataSource object, a Layer object 
   
  containing Features for each polygon
  4. I can work through the examples showing the properties of that 
  Layer object, and iterate through the Features in the Layer, so I know 
  that's working
   2. The problem is when I try to Slice a Layer, to extract a subset of 
   Features: 
  1. The example says I should be able to run  *>>> lyr[0:2]* and 
  receive two Feature objects
  2. However, what I get is an error message saying there is an 
  IndexError, and it mentions a TypeError
   

This is an image of the Traceback





And here is the traceback in text:



In [12]: lyr[0:2]
---
IndexErrorTraceback (most recent call last)
 in ()
> 1 lyr[0:2]

c:\projects\python\env\ENV3\lib\site-packages\django\contrib\gis\gdal\layer.py 
in __getitem__(self, index)
 49 # A slice was given
 50 start, stop, stride = index.indices(self.num_feat)
---> 51 return [self._make_feature(fid) for fid in range(start, 
stop, stride)]
 52 else:
 53 raise TypeError('Integers and slices may only be used 
when indexing OGR Layers.')

c:\projects\python\env\ENV3\lib\site-packages\django\contrib\gis\gdal\layer.py 
in (.0)
 49 # A slice was given
 50 start, stop, stride = index.indices(self.num_feat)
---> 51 return [self._make_feature(fid) for fid in range(start, 
stop, stride)]
 52 else:
 53 raise TypeError('Integers and slices may only be used 
when indexing OGR Layers.')

c:\projects\python\env\ENV3\lib\site-packages\django\contrib\gis\gdal\layer.py 
in _make_feature(self, feat_id)
 88 return feat
 89 # Should have returned a Feature, raise an IndexError.
---> 90 raise IndexError('Invalid feature id: %s.' % feat_id)
 91
 92 #  Layer properties 

IndexError: Invalid feature id: 0.



Again, I'm totally new to GeoDjango, so this could all be a user error.  I 
have restarted the tutorial 3 times and it always fails at the slice 
example.  The comment in the Traceback mentioning an IndexError has me 
wondering.

Thanks in advance.


-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/a8fb48a0-8bcd-41bb-a3ce-737c324d96cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: psycopyg setup error: no build_ext

[Justin Johnson]

I corrected the build_ext error and successfully built/installed by
adding the full path to pg_config in setup.cfg.

On Jun 23, 10:19 am, Chris Haynes  wrote:
> Using what I believe is the latest version of psycopyg, I get:
>
> 509 ~/Desktop/psycopg2-2.0.9$ python setup.py build
> running build
> running build_py
> creating build
> creating build/lib.macosx-10.3-fat-2.6
> creating build/lib.macosx-10.3-fat-2.6/psycopg2
> copying lib/__init__.py -> build/lib.macosx-10.3-fat-2.6/psycopg2
> copying lib/errorcodes.py -> build/lib.macosx-10.3-fat-2.6/psycopg2
> copying lib/extensions.py -> build/lib.macosx-10.3-fat-2.6/psycopg2
> copying lib/extras.py -> build/lib.macosx-10.3-fat-2.6/psycopg2
> copying lib/pool.py -> build/lib.macosx-10.3-fat-2.6/psycopg2
> copying lib/psycopg1.py -> build/lib.macosx-10.3-fat-2.6/psycopg2
> copying lib/tz.py -> build/lib.macosx-10.3-fat-2.6/psycopg2
> runningbuild_ext
> error: No such file or directory
>
> and easy_install doesn't work either (seems like the same problem):
>
> 510 ~/Desktop/psycopg2-2.0.9$ easy_install .
> Processing .
> Running setup.py -q bdist_egg --dist-dir /Users/home/Desktop/
> psycopg2-2.0.9/egg-dist-tmp-mYsMSq
> error: Setup script exited with error: No such file or directory

--~--~-~--~~~---~--~~
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, CherryPy and threading

[Justin Johnson]

Okay, maybe my text should have read "I've deployed Django with Apache 
and ModPython where each request *may* be serviced by a separate process."

Concurrent requests being handled within the same interpreter was my 
concern with Django.  After a quick look at the source code it seems 
that DatabaseWrapper is thread aware.  Hopefully it'll cope with 
sqlite3's threadsafety level which means you cannot share a connection 
object among multiple threads.

You're right in that there isn't any threading support with sessions.  
Writing session information back to the database is atomic though so the 
worst you'll get is data being overwritten by the last altered session.  
As you say, that's one to watch out for with concurrent Ajax operations 
which alter session information.  Wouldn't this still be an issue with 
the non-threading model?

The only way to ensure session integrity in these corner cases would be 
to lock on the session id during a request (somehow - probably not 
trivial).  That would mean that requests from the same source would be 
processed sequentially and not in parallel.  It's probably easier just 
to be very careful with parallel requests.

Justin
> On Aug 29, 1:39 am, Justin Johnson <[EMAIL PROTECTED]> wrote:
>   
>> I've managed to get Django working nicely with CherryPy using WSGI.
>> Previously I've deployed Django with Apache and ModPython where each
>> requested is serviced by a separate Python instance.
>> 
>
> How you think mod_python works is wrong, or at least the way you
> explain it is deceiving in its meaning.
>
> In mod_python, each request is not 'serviced by a separate Python
> instance'.
>
> In the case of prefork MPM in Apache, although it isn't threaded and
> so concurrent requests can't be handled at the same time within a
> single interpreter instance, successive requests do get handled in the
> same Python interpreter instance. In other words, the interpreter is
> not thrown away and instead persists until the process itself is
> killed, which may only be when Apache itself is shutdown or restarted.
>
> In the case of worker MPM in Apache, multithreading is used and so
> concurrent requests do get handled in the same interpreter at the same
> time. Again, the interpreter persists for the life of the process.
>
> Where confusion often arises and why this myth that a separate Python
> instance is used for each request persists is that Apache on UNIX is a
> multi process web server. Thus your requests aren't necessarily all
> handled in the same process, instead they can be distributed across
> multiple processes. The use of multiple processes by Apache and the
> fact that it can create more on demand as load rises, means that
> Apache is much better able to scale than solutions which use a single
> Python process with web server implemented in Python only.
>
> I really wish this myth about mod_python would die. :-(
>
> For a bit more information about the process/interpreter model in
> mod_python read:
>
>   http://www.dscpl.com.au/wiki/ModPython/Articles/TheProcessInterpreterModel
>
>   
>> This isn't the case with CherryPy though as it's thread based which
>> leads me to the following concern:  is it safe to serve Django with
>> CherryPy?
>> 
>
> If one takes the warning in mod_python documentation that only prefork
> MPM for Apache should be used and worker MPM should not, then it would
> follow that using the CherryPy multithreaded web server would not be
> safe. Similarly, it wouldn't be safe to run Django on Windows with
> Apache either.
>
> In practice, discussions in the past have indicated that there are no
> known multithreading problems in Django itself. Thus the warnings
> about avoiding worker MPM and thus multithreaded MPMs may not be
> strictly applicable. Now although Django may be safe for
> multithreading, you would still need to ensure that your higher level
> code implemented in Django is multithread safe. You would also need to
> ensure that you are using recent versions of any database adapters and
> that they declare themselves as multithread safe.
>
> Most importantly, you should rigorously test your application to
> ensure that it is truly safe to use in a multithreaded web server.
> Areas which I would suggest you look at closely are use of session
> objects as these from memory do not provide a locking mechanism, and
> so in an AJAX heavy application which issues lots of concurrent
> requests and each handler for them wants to manipulate the same
> session object, you might run into problems with the handlers and
> sequencing of operations against the session object.
>
> Graham
>
>
> >
>
>
>   

--~--~-~--~~~---~--~---

Django, CherryPy and threading

[Justin Johnson]

I've managed to get Django working nicely with CherryPy using WSGI.  
Previously I've deployed Django with Apache and ModPython where each 
requested is serviced by a separate Python instance.

This isn't the case with CherryPy though as it's thread based which 
leads me to the following concern:  is it safe to serve Django with 
CherryPy?

Cheers,

Justin

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: django built-in web server

[Justin Johnson]

I did spend some time looking at a third option - py2exe.  In general 
this works really well and means you can package up with a single 
install.  The only snag is that django has lots of dynamic imports which 
means you have to have a source file somewhere that imports statically.  
I ran out of time experimenting with that but I'd like to hear if anyone 
else has successfully deployed a django project with py2exe.

> I'm having a similar situation now.  The requirement is to pack my web
> app so that an average user without programming or network
> administration background can easily install it on windows.
>
> I'm considering:
>
> 1) pack the whole apache with default conf + sqlite + python + django
> + my project as a whole msi cabinet.
>
> 2) let them install python first (which is easy enough I think) then
> use something like python setuptools to install django and the
> project.  The http server must be run in python.  Have to install
> sqlite manually?
>
> It seems 2) is better but it might still be too complex to install.
> Still evaluating my options now...
>
> On Aug 10, 5:36 pm, Justin Johnson <[EMAIL PROTECTED]> wrote:
>   
>> Apache is the easiest and most documented route.  It is pretty easy to
>> set-up and config so don't let that put you off.
>>
>> However, I had a situation where I needed a single self-contained
>> install for deployment.  On that occasion I used CherryPy3 + WSGI and
>> ran the whole thing as a windows service using the Python Win32
>> library.  It worked out really well.  I also had a 'debug' mode where I
>> can run my server from the command line and see all requests etc - again
>> utilising CherryPy3.  IMHO, that worked out much better than using
>> Django's test server because it didn't require any extra URL information
>> for serving media.
>>
>> Django's test server isn't going to cut it for deployment and using
>> Apache is simple.  Just a few lines of config in httpd.conf and you're
>> done.  Avoiding Apache isn't going to make life easier for you.
>>
>> 
>>> hi,
>>>   
>>> Can I use the django's built in web server in an intranet enviroment
>>> where the maximum users could be not more than 50 users? I am just
>>> asking this for the purpose for easy deployment :). I am very newbie,
>>> and trying to avoid apache
>>>   
>>> THanks
>>> james
>>>   
>
>
> >
>
>
>   

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: django built-in web server

[Justin Johnson]

Apache is the easiest and most documented route.  It is pretty easy to 
set-up and config so don't let that put you off.

However, I had a situation where I needed a single self-contained 
install for deployment.  On that occasion I used CherryPy3 + WSGI and 
ran the whole thing as a windows service using the Python Win32 
library.  It worked out really well.  I also had a 'debug' mode where I 
can run my server from the command line and see all requests etc - again 
utilising CherryPy3.  IMHO, that worked out much better than using 
Django's test server because it didn't require any extra URL information 
for serving media.

Django's test server isn't going to cut it for deployment and using 
Apache is simple.  Just a few lines of config in httpd.conf and you're 
done.  Avoiding Apache isn't going to make life easier for you.

> hi,
>
> Can I use the django's built in web server in an intranet enviroment
> where the maximum users could be not more than 50 users? I am just
> asking this for the purpose for easy deployment :). I am very newbie,
> and trying to avoid apache
>
> THanks
> james
>
>
> >
>
>
>   

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: video uploads (like you tube)

[Justin Johnson]

Django really does need stream uploading.  IIRC, there's a patch to  
do this.

Does anyone know if that patch is ever going to make it into an  
official release?


On 25 Jan 2007, at 02:08, Jeremy Dunck wrote:

>
> On 1/24/07, Julio Nobrega <[EMAIL PROTECTED]> wrote:
>>
>>   Uploading a video is easy, just use the correct Field from Django.
>> The real work is converting the video to .flv (Flash Video). I've
>> never seen a Python module for this job but I bet there's one.
>
> Not true if the videos are large (say, > 10 MB).
>
> Django, as-is, is the wrong tool for that job.
>
> >


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: help with tagging app

[Justin Johnson]

There may be a performance issue for large object sets and retrieving 
all tags:

def tag_list(request):
all_tags = TaggedItem.objects.order_by('tag')
tag_names = {}
for tag in all_tags:
if tag.tag not in tag_names:
tag_names[tag.tag] = tag

names = sorted(tag_names.keys())

tag_list = [tag_names[tag] for tag in names]
print tag_list
return render_to_response('tags/tag_list.html',
{'object_list':tag_list},
context_instance = RequestContext(request))


The overhead maybe more than scanning through all objects in a database 
as multiple tags can be assigned to multiple objects.

IIRC, there are potentially two solutions to this.  Use 'distinct' in 
the first query which should remove duplicates at the database server, 
or have the tags themselves stored in a separate table and marked as 
unique.  In the second case the 'tag' field in TaggedItem would be a 
foreign key rather than the string tag itself.

If this is for something like a blog then it probably won't be a 
problem.  For large data sets, say several thousand users who may be 
tagged in various ways, it could be a performance issue.

Justin

plungerman wrote:
> greetings,
>
> i studied long and hard the tagging app from Luke Plant and the one
> from the bulletin board app called zyons (http://zyons.com/), and i was
> unable to wrap my head around neither.  granted i am not the sharpest
> tool in the shed, but the docs for Sr. Plant's app are a little
> confusing.  then again, it is really not his responsibility to provide
> it, so no worries there.  in the end, i integrated the tagging app that
> jay parlar developed for his website.  it uses the GenericForeignKey
> framework, so you can tag arbitrary objects and manage the tags quite
> easily with a little costomisation to the existing code base, which
> uses javascript and the django admin.  check it out:
>
> http://svn.jayparlar.com/website/trunk/
>
> laters,
>
> steve
>
>
> >
>
>
>   


--~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---