#django

<link rel="stylesheet" type="text/css" href="/path/to/file.css">

works for me

cardboard: scratch that, just use <link rel="stylesheet" type="text/css" href=".."> everywhere

twoolie, Thanks! I can finally move on to something else, haha

cardboard: did you collect the static files to the path for static?

xeberdee, no, what does that mean?

cardboard: put the css and fstatic in the folder you name in the settings file, and then do - python manage.py collectstatic, which will pull all the static files and put them into the path mentioned in your settings file

there are two paths - the one for static files, and the one the server uses to serve static files. collect - moves them where they need to go

cardboard: put the full path to the Static root in your settings too -

xeberdee, I'm planning putting this project on Heroku

So I'm not sure what to put for the full path..

xeberdee: that wasn't his problem. He won't have to deal with that until he's ready to put it on heroku

;)

If django is using my settings then MEDIA_ROOT is set, how do I reference it in views.py? I can do full path but MEDIA_ROOT fails, settings.MEDIA_ROOT also

o/

anyone? the docs are looooong and not clear for a total newbie, all the steps involved for something that I would have thought simple - display a list of files. Obviously not that simple.

you don't reference your media_root directly

you'll want to interact with it through a storage engine

xeberdee: especially if you're deploying to heroko, which doesn't let you store media on your worker box

check out django-storages

xeberdee: also, if this is a toy project, reconsider using heroku. It's expensive and restrictive. Find a nice django-friendly VPS host, like webfaction.

twoolie: I'm rather trying to just manage files with a browser, attach some metadata and do some simple os related stuff at media_root. So it's not really cloud based type of application.

twoolie: on a closed network serving 5 machines with large storage area.

wait, where did cloud stuff come into the discussion?

FunkyBob: I supposed that Amazon, Apache Libcloud, Rackspace cloudfiles etc were cloud based services

even if you're not, you should work through the storage engine API

FunkyBob: I'm really a beginner with this, as you might have noticed. I've used python scripts to manage video files before, I'm hoping to integrate django so that I can keep track of file status with a database.

xeberdee: well, you can just use os.path and os.listdir and so on to get a list of files...

the advantage of Django's storage API is that when, in the future, you start using remote storage [sounds like you already are?] your code won't need to change

FunkyBob: that's what I'm doing now, django and apache server has a samba share media root over gigabit, and I just put in the full path. I was kinda hoping to store paths to media in django admin and pull them out of the DB.

xeberdee: so this is separate from MEDIA_ROOT / MEDIA_URL... being where Django would expect to [by default] store user uploads, etc ?

xeberdee: sorry, i got you confused with cardboard who said he was going to deploy to heroko

FunkyBob: I'm not so worried about uploads, and I don't want to involve the webserver with anything bigger than paths and css files etc. I want python to do all the work moving files between storage islands on the LAN

cardboard: that advice above was for you

twoolie, sweet, thanks

xeberdee: are these files at all served by the web server to users?

xeberdee: the way you're speaking makes me think there's some lurking complexity to your query I'm not understandig

FunkyBob: No

ok

so as yet, no particular advantage to using the storage api, except avoiding future pains which may never occurr

FunkyBob: I'm just wanting to serve info about the files on storage, group them into projects, move them around etc

FunkyBob: around 'on the server'

FunkyBob: Ie. I get dumped tetabytes of files into a path on the server - then I transcode with FFMPEG scripts using python - I need a web end to make the whole thing a little more user friendly.

ok

so which part is troubling you?

FunkyBob: well I just started with Django and I'm just struggling with the whole model, template thing

xeberdee: what part exactly are you struggling with?

xeberdee: request comes in, url patterns maps it to a view, view generates response

this is the core of django

as you'll notice, no mention of templates or models in that

your view may choose to use a template to help generate the response content...

your view may also use models to help accessing data in your DBMS

FunkyBob: My view can do lots of other stuff too - I was hoping to get the view to do the scripting I have now.

well, since it's all just python, it can

FunkyBob: So I need to sort out what response (info) is kept in the database and available for the server

why is anything kept in the DB?

FunkyBob: right now I have transcode logs, dates etc.

ok

FunkyBob: I suppose they are ok as files still

I've used django before with no DBMS... just flat files for everything

but if you have reason to store stuff in a DB, by all means

so, you've done the tutorial in the docs, right?

FunkyBob: Yep - it was a while ago though, it goes as far as form post and get.

FunkyBob: which is probably all I need... :)

even once you start using web-based APIs, get/post still go a long way