Re: image servers?

2011-01-11 Thread kRON
What your looking for is exactly achieved by providing a custom
default file storage class.

Have a look at:
http://docs.djangoproject.com/en/1.2/ref/settings/#default-file-storage
http://docs.djangoproject.com/en/1.2/topics/files/#file-storage

Here's a simple example of how it might work in your case:

# settings.py
DEFAULT_FILE_STORAGE = 'core.models.ImageStorage'
FILE_STORAGE_LOCATION = os.path.join(os.path.dirname(__file__),
*('media', 'images'))
FILE_STORAGE_BASE_URL = MEDIA_URL + 'images/'

# models.py
class ImageStorage(FileSystemStorage):

def __init__(self, location=None, base_url=None):
location = location or settings.FILE_STORAGE_LOCATION
base_url = base_url or settings.FILE_STORAGE_BASE_URL
super(DocumentStorage, self).__init__(location, base_url)

So now `ImageStorage` is the default storage class for all your model
file fields and, by default, all uploaded files are stored in '/media/
images/'.

On Jan 11, 6:25 pm, Eric Chamberlain  wrote:
> You might want to look at django-storages 
> .  We use it with S3.
>
> On Jan 10, 2011, at 4:55 PM, garagefan wrote:
>
>
>
> > so i bit the hype and got myself a rackspace cloud account. i also got
> > a rackspace file account for image serving. i would like to write
> > something that overrides where all images are saved, regardless of the
> > model that requests the save.
>
> > what would this be? would i make this a middleware? I assume i need to
> > extend and "replace" the default "save file to MEDIA_ROOT directory"
>
> > i havent had to extend or replace django's default behavior, so before
> > i start digging in to this, i need to know the best place for this...
> > which, i assume would be middleware. yes?
>
> > 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-us...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-users+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-users?hl=en.
>
> --
> Eric Chamberlain, Founder
> RF.com -http://RF.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-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.



Re: Configure LAMPP with Django

2011-01-10 Thread kRON
I wager that Javier already has the best possible answer, but,
nonetheless, I'll try to elaborate it a just a bit more.

When a client requests a resource from your Web server that's handled
by PHP, what happens is that an instance of PHP is fired that
initializes the request data in the globals (like $_POST, $_SERVER)
and sequentially creates a flattened view of your Web application code
necessary to handle that request.

Take PHP MVC frameworks as a good example. All of your requests (like
'/user/evstevemd/') get rewritten to `index.php?r=/user/evstevemd/`.
`index.php` includes a certain `routing.php` that then figures out
that all requests beginning with `/user/` are handled by a controller
that resides somewhere in `users/controllers.php` and so it includes
that, the code there includes something else and so forth until
there's no more code to execute. The fact remains that you also had
several dozens of other PHP files that were never executed, because
that code was never needed to process the particular request that was
received.

Django is a bit different, but that actually has everything do with
the nature of executing Python applications. To process requests that
Django needs to handle, your Web server will actually be communicating
with an instance of a Python interpreter, through the WSGI protocol.
WSGI is just a very small standard that practically says: because
every Web server that accepts HTTP requests has the liberty of
constructing and processing request data to their preferences, this is
the interface that defines how those requests should be passed to a
Python Web application.

Configuring PHP with your Web server is straightforward and it just
works OOTB instantaneously for all your PHP files. Although it's
execution model is simple and popular, if you acknowledge the
drawbacks there's a lot more to benefit from communicating with a long-
running Python process. First off the top is that after initialization
everything is already loaded into the memory, everything is
precomputed for future requests (such as URL routing) and all the
necessary connections to other parts of the system are created, so
subsequent requests become very cheap and are processed "blazingly"
fast.

I'm not an expert on the topic, but if you already have a LAMP stack,
what I'd do is set up nginx as a reverse proxy (approx. 30-ish lines
of code that's hard to get wrong) to your Apache Web server and a WSGI
server. You get the added benefit of not having to recompile/
reconfigure your Apache instance with mod_wsgi (which can easily be
misconfigured) and you can use a Python WSGI server such a Gunicorn or
Spawning that is more Pythonic (i.e. it works and understands Python
code better than mod_wsgi) to handle your Django Web applications.



On Jan 10, 5:17 pm, Thomas  wrote:
> Am 10.01.2011 um 16:56 schrieb evstevemd:
>
> > I have LAMPP on Ubuntu and I use it fine with PHP. Now I have to add
> > Django so that I can do PHP and Django projects together. I will have
> > more than one Django project. I have read of mod_wsgi but I cannot
> > understand.
>
> what exactly is the problem?
>
> I found these explanations 
> helpful:http://code.google.com/p/modwsgi/wiki/IntegrationWithDjangohttp://blog.dscpl.com.au/2008/12/using-modwsgi-when-developing-django...
>
> good luck
>
> > In PHP I just put my project as subdirectory of /var/www/
> > and then access them viahttp://localhost/
> > How do I do with Django?
> > Thanks a lot!
>
> > --
> > 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 
> > athttp://groups.google.com/group/django-users?hl=en.
>
>

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



Custom model field validation with `clean_fields()`

2010-05-26 Thread kRON
I've recently read about `clean_fields()` and decided to move some
stuff to I that I was doing in my `pre_save` handler previously. My
tests failed and then I noticed that neither `clean_fields()` nor
`full_clean()` was ever called before saving the model.

The documentation says that only `clean()` needs to be explicitly
called on the model by the user, so I'm wondering when is
`clean_fields` invoked?

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



Re: URL design - why the trailing slash?

2010-01-28 Thread kRON
Nope, no caveat there. You'r perfectly free to design your own URLs as
you like.

Ultimately, means you can also have a conflicting situation where you
decide you don't want to have a trailing `/` but you include URLs from
a 3p django application that do.

On Jan 28, 1:54 am, Brett Thomas  wrote:
> Most of the URLConf examples I run across use a trailing slash on all 
> URLs:www.example.com/profile/
>
> I'm not sure why, but I don't like this. I think it looks nicer 
> without:www.example.com/profile
>
> Are there any performance or security reasons to use the trailing slash in
> Django? Seems like there could be some quirk with regular expressions that
> I'm not thinking of...
>
> Thanks --
> Brett

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



Distributing a Django site along with Apache and MySQL

2009-11-01 Thread kRON

I have a web application developed as a Django site that I'd like to
distribute along to my clients on Windows; their production
environment won't have Apache and MySQL preinstalled. To avoid having
to manually deploy Apache and MySQL and look silly if I run into any
hiccups whilst configuring them, I thought it it would be fun to learn
how to automate the process, since I've never done it before.

I've looked at the Python `distutils` docs, but found myself greatly
overwhelmed with all the information. I gained an impression that I
could do something like this by doing a clean deployment of Apache and
MySQL within my package; package everything; write a post-install
script that would then configure the servers (edit Apache's configs to
set it's paths based on where it's located on the production server,
create a MySQL root account, the database for Django) and also use
pywin32 to install Apache and MySQL as services on the account that
was used for the installation. Later I can test everything by
installing it on my virtual machine running Windows.

It would really help if anyone could share on how do you do your build
automation with such requirements? How to best layout your project's
structure to build the package?


--~--~-~--~~~---~--~~
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 methodologies and best practices

2009-10-19 Thread kRON

I really like Mike's post and I think it all boils down to what he's
said. There's not much to add except other personal preferences and
delicacies you take onto a new project.
--~--~-~--~~~---~--~~
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: PyDev users: how do you manage tabs?

2009-07-01 Thread kRON

One thing you can do is turn on the option 'Link with editor' on your
package\project explorer view. You have the *down arrow* ['View Menu'
tooltip] and an option at the bottom--'Link with Editor'.

That way, any active file in the editor will highlight the file in
your view, and you can keep track of which file you editing by it's
location in your project structure. The only problem with this is
that, if you have a deep/long project structure that you'll notice
that your view will be jumping all over to focus on the entries, but
it's a behavior you can get used to, albeit it can get annoying at
times.

On Jul 1, 7:42 am, Rex  wrote:
> Kind of a petty question:
>
> I've been using PyDev to do my Django work and find it to be great.
> However, my only gripe is that it's hard to keep track of tabs, since
> they display only the (non-qualified) file name, which is a problem
> given Django's very regular naming scheme. So for example I'll often
> have 4+ tabs that are all named "views.py", and I have to mouse over
> each to find which one is the one I'm looking for.
>
> For those of you who use PyDev, have you found this to be an issue as
> well? Are there any solutions, like a plugin that adds the parent
> directory name to the tab?
--~--~-~--~~~---~--~~
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: Feedbacks and recommendations about test coverage tools

2009-06-06 Thread kRON

Thanks for posting the links, I'll be sure to try and test it during
the weekend.

On Jun 5, 1:37 pm, Michelschr  wrote:
> Hello everyone,
>
> What are the current trends about the best test coverage tools to use
> with Django?
> Do you have feedback or recommendations for me?
>
> Up to now, I founded this links:
>
> http://opensource.55minutes.com/trac/browser/python/trunk/django/apps...http://pypi.python.org/pypi/django-test-coverage/
>
> and I would be happy if I can receive some light from the community
> before digging further.
>
> Thanks in advance,
>
> Michel
--~--~-~--~~~---~--~~
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: Problem with importing widget media

2009-05-07 Thread kRON

Problem solved, my fault - just noticed it was expecting to traverse a
tuple;
js = ('js/international_slug.js',)  fixed the problem

On May 7, 10:16 am, kRON <filip.dupano...@gmail.com> wrote:
> Sorry for the repost, somehow I've submitted the form.
>
> I just wanted to add that my media url looks as MEDIA_URL = '/media/'
>
> Can anyone steer me the right way for fixing 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: Problem with importing widget media

2009-05-07 Thread kRON

Sorry for the repost, somehow I've submitted the form.

I just wanted to add that my media url looks as MEDIA_URL = '/media/'

Can anyone steer me the right way for fixing 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
-~--~~~~--~~--~--~---



Problem with importing widget media

2009-05-07 Thread kRON

I've set up my Media class for a widget as such:

class InternationalSlugWidget(forms.TextInput):
class Media:
js = ('js/international_slug.js')

The problem is Django keeps pumping out the following import
statements:







...etc

My media root string looks
--~--~-~--~~~---~--~~
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 on Google app engine

2009-04-24 Thread kRON

Basically, you can't use Django models on Google App Engine. So, in
brief, all Django applications that interact with a datastore will not
work on Google App Engine.

But - don't despair. There are two Django distributions ported for
Google App Engine that I'm aware of:

- http://code.google.com/p/app-engine-patch/
- http://code.google.com/p/google-app-engine-django/

I haven't played much with them, and I'm pretty green myself with
Django and Python, so I hope someone provides a better conclusion.
But, as far as the docs go, App Engine Patch provides the source for
Django and a set up project, and comes with Django 1.0 support. You'll
be able to access all Django's applications, such as django-admin.

Google App Engine Django has been developed by Django employees.
They've developed models that are compatible with Django's models, but
I don't know if any gotchas and caveats come packed with it. Also,
most Django apps (I believe) don't get support on Google App Engine
with the Google App Engine Django.

So, basically, I think the major issue with Google App Engine is that
you'll have to use the models provided with the SDK. Also, if you
previously deployed Django, you shouldn't have any trouble following
the guidelines for deploying Django on Google App Engine, so you
should definitely give it a try.

On Apr 24, 9:04 am, Joshua Partogi  wrote:
> Hi all,
>
> I came accross this 
> article:http://code.google.com/appengine/articles/django.html
> Which made me interested how far can you go with django on app engine?
> Because reading that article there are several things that you must
> turn off from the django configs namely session & database.
>
> Are we only able to deploy "Toy django application" with google app engine?
>
> Has anyone used it before and would like to share their experience?
>
> Thank you very much in advance.
>
> --
> If you can't believe in God the chances are your God is too small.
>
> Read my blog:http://joshuajava.wordpress.com/
> Follow us on twitter:http://twitter.com/scrum8
--~--~-~--~~~---~--~~
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: conventions for adding pluggable apps to Django

2009-04-21 Thread kRON

I haven't used that many pluggable Django apps, but I'd say it really
depends as you go from application to application. The first step is
to decide where your pluggables will live. I like to keep pluggables
that are used by my project specific apps under %project%.apps.contrib
for clarity's sake.

I guess there are two distinct steps involved with installing a
pluggable: one is hooking the pluggable with Django, the other is
hooking your project with the pluggable itself.

Hooking the app with Django will involve registering the pluggables
content -- middleware, context processors, template paths, inclusions
within your root url.py etc. This should be pretty straightforward.

Some pluggables will use relative imports -- and that just takes one
thing off your mind -- but others don't. If that's not the case, or if
you want a shorter way to access the pluggable resources other than
project.apps.contrib.pluggable, you'll have to add it to sys.path.

In short, key points of best practices are:

- have pluggables live under a common root package, so you can always
easily identify where you have 3rd party app dependencies
- maintain settings such that it's clearly separated where are the
Django hooks for 3rd party apps and where 3rd party apps settings are
located within your settings file so you can easily debug your project
if  a certain app starts breaking 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: Multi app project and inter app communication

2009-04-07 Thread kRON

I guess you've cleared up what Django is and is not for me.

I sat down today and finally chewed through the documentation without
giving up at any point. I guess I was assuming Django would be doing a
lot of magic in the background and the 'one Django project composing
of multiple Django apps' bit made me go off on an overly imaginative
roll. I can't be blamed nor held responsible :)!! The documentation
doesn't make it readily available that all that Django does that could
concern us is chew the initial urlconf and from then on it's our show.
Viewing Django more as a library, the applications as simply packages
and focusing on the Python imports for linking it all up made
everything perfectly clear in the end.

Thanks for hitting me with it Malcom!

On Apr 7, 2:56 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> On Tue, 2009-04-07 at 04:36 -0700, kRON wrote:
> > Hello everyone. I've only recently started developing app with Django
> > and in Python as well. I have a fair experience in developing web apps
> > on frameworks in PHP and I'm really trying to make a commitment on
> > doing my first Django app properly (all the good methodologies and
> > practices included)
>
> Remember to learn to crawl before you can walk. Your first (and even
> second and third, most likely) Django application isn't going to be
> production quality. Spend some time learning to use Django, then spend
> some time looking at options (and there are always options -- no single
> best way to do any of this) for splitting up applications and working
> with configuration options, etc.
>
> > The first bit I can't figure out are Django applications. I know that
> > they are, in essence, Python modules, but it doesn't say what does
> > Django do once it encounters an application. Does it add it to the
> > sys.path? Does it automatically load certain files, or does that have
> > to be explicitly specified somewhere?
>
> Thinking about this as Django "encountering an application" is probably
> going to lead to confusion. Django is more of a library than a
> framework, from the perspective of somebody writing an application. That
> is, you pull things from the Django modules (and your application
> modules) as required -- there's relatively little usage of Django
> calling something of yours (the exception being the passing of requests
> to view functions). The point being that, generally, if you need to use
> code from a particular application, you import the appropriate Python
> module(s) and use it, just like in normal Python code.
>
> Django certainly doesn't do any modification of sys.path for particular
> applications. Quite the reverse: it is assumed that applications are
> importable using the name you specify in the INSTALLED_APPS list. That
> is, your Python path has to already be set up so that you can import all
> those things using those names.
>
> The main reason (from an import perspective) that Django needs to know
> about the installed applications (the INSTALLED_APPS list) is so that it
> can work out reverse relations automatically. If you specify that model
> A in application XYZ has a many-to-one relation to model B in
> application PQR, Django will also set things up so that model B can
> refer back to model A, without needing to also specify something in the
> source for model B. This means that when importing model B, Django needs
> to look at all the other models in all the installed applications to see
> if there are any field pointing to model B (this is done through some
> caching, the computation isn't something onerous on every request).
>
> By and large, though, that last paragraph isn't important. The important
> part is the first think I mentioned: if you need to use some code from
> an application, import it as per normal.
>
>
>
> > Another question I have is with custom settings. I'd like to have each
> > application have it's own settings file. How is this then accessed by
> > the application? Do I have to import /proj/myapp/settings.py in my
> > main /proj/settings.py file? I figure that this would make the
> > settings globally available, so /proj/myapp2 can access the settings
> > from /proj/myapp1, but what if I want to have some application
> > specific settings that I do not wish to be accessed by other
> > applications too?
>
> Life doesn't really work like that.
>
> Django's "settings" are, intentionally an essentially globally visible
> object that anything can read. The reason it's read via a single file is
> because there are potentially highly complex interactions between
> settings when you're involving multiple applications and we require a
> human -- the installing user -- to set things up in an 

Multi app project and inter app communication

2009-04-07 Thread kRON

Hello everyone. I've only recently started developing app with Django
and in Python as well. I have a fair experience in developing web apps
on frameworks in PHP and I'm really trying to make a commitment on
doing my first Django app properly (all the good methodologies and
practices included)

The first bit I can't figure out are Django applications. I know that
they are, in essence, Python modules, but it doesn't say what does
Django do once it encounters an application. Does it add it to the
sys.path? Does it automatically load certain files, or does that have
to be explicitly specified somewhere?

Another question I have is with custom settings. I'd like to have each
application have it's own settings file. How is this then accessed by
the application? Do I have to import /proj/myapp/settings.py in my
main /proj/settings.py file? I figure that this would make the
settings globally available, so /proj/myapp2 can access the settings
from /proj/myapp1, but what if I want to have some application
specific settings that I do not wish to be accessed by other
applications too?

Also I was wondering if there was a Pythonic analogue for the
alternative shorthand conditional syntax '(cond) ? true : false'. I
wanted to do something like:

DEBUG, DATABASE_USER, DATABASE_PORT = if gethostname='development-
server' : True, 'dev-user', '1047' else: None, 'prod-user', '3306'

Thanks a lot, I appreciate any sort of help :)!

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