what setup (urls/paths) are you using?

[patrickk]

I´ve started setting up a test environment for the django filebrowser
in order to eliminate errors with urls/paths.
now I´d like to know what (different) kind of setup people are using
when it comes to the following settings:
MEDIA_ROOT, MEDIA_URL and filebrowser-specific URL_WWW, PATH_SERVER.

within my environment, URL_WWW _always_ extends MEDIA_URL.
if MEDIA_URL is "/media/" or "http://media.myserver.com/"
URL_WWW is either equal to MEDIA_URL (if I want to my editors to be
able to see _all_ media files) or it extends MEDIA_URL with a subdir -
like "/media/uploads/" or "http://media.myserver.com/uploads/".

also, PATH_SERVER _always_ extends MEDIA_ROOT.

now, I´m interested in other possible setups.
the aim here is to create the most flexible settings. but it´s also
important (IMHO) to make the settings as clear as possible, since a
lot of questions regarding the filebrowser are related to these
variables.

note: it´s not about whether or not a specific setup currently _works_
with the filebrowser. my question is more about what kind of setup you
want to use ...

thanks,
patrick

[patrickk]

I´ve come up with different settings for the next version of the
filebrowser - I´m going to post them here in order for everyone to
read this beforehand.

we currently have settings for URL_WWW and PATH_SERVER both basically
extending MEDIA_URL resp. MEDIA_ROOT.

problem is: there are too many possibilites of defining different
stuff for URL_WWW and PATH_SERVER, e.g. someone could define an
absolute URL for URL_WWW or an URL relative to MEDIA_URL or (even
bigger problem) an URL overlapping MEDIA_URL.

in order to standardize the filebrowser-setup, this is the proposal
for re-defining URL_WWW and PATH_SERVER:
URL_WWW has to be relative to MEDIA_URL, e.g. extending MEDIA_URL in
order to limit the filebrowser to a certain directory.
PATH_SERVER has to be relative to MEDIA_ROOT.

the default changes from
URL_WWW = MEDIA_URL to URL_WWW being empty and
PATH_SERVER = MEDIA_ROOT to PATH_SERVER being empty

IF SOMEONE DOESN´T LIKE THIS BEHAVIOUR, THIS IS THE TIME & PLACE TO
RESPOND.

thanks,
patrick

[Maciej Harczuk]

I'm not really sure I like this idea. For instance, I want to have
uploaded media completely separated from site-media (css, javascript etc.),
at least on filesystem, as it makes my project more portable and also
makes version control easier (I know I could probably solve it with
svn:ignore).

For me it's just an ease of use issue, but I can think of people mounting
their media via nfs/cifs or sharing them between sites & forcing URL_WWW
and (especially) PATH_SERVER to be MEDIA_URL and MEDIA_ROOT relative would
certainly make their lifes harder or at least make their
code/filesystem layout look suspiciously like spaghetti.

Also, I don't really see a point in sacrificing flexibility for ease of
use. No matter how idiot-proof you make your software, sooner or later the
Universe will come up with better, bigger idiots ;)

Regards,
GrF

[patrickk]

would that be solved if we define MEDIA_ROOT and MEDIA_URL within
fb_settings?
something like this:
MEDIA_ROOT = getattr(settings, "FILEBROWSER_MEDIA_ROOT",
settings.MEDIA_ROOT)
MEDIA_URL = getattr(settings, "FILEBROWSER_MEDIA_URL",
settings.MEDIA_URL)

my main problem with the current solution is the naming convention,
since URL_WWW and PATH_SERVER doesn´t seem to be clear to most people
(at least my mail-inbox tells me that).

thanks for your opinion,
patrick

[Trent]

I agree with Maciej. I would prefer not to be restricted to using the
MEDIA_ROOT or a child directory. I would like to have the flexibility
of defining/overriding defaults in my settings files. But I think the
names of these settings are most confusing. Why not use something
like:

FILEBROWSER_MEDIA_URL
FILEBROWSER_MEDIA_ROOT

These files could then be overridden in my project's settings if
desired.

[patrickk]

that´s exactly the way I´ve done it - there´s already a branch for
filebrowser_3 and I´ll upload the files asap for testing.

thanks for your feedback,
patrick