hey all, This seems to be an itch I've had to scratch myself in the past - let me see if I understand the situation vaguely correctly:
You have a site that uses Django / database features for some things, but then you also have a lot of content that's being designed in some design tool and needs to be manually crafted into precise (sometimes hackish) html and uploaded, and you almost want to just work with plain html files on a file-system so you can use the tools you're used to - Komodo / vim, version control, etc. This content is in the form of "article bundles" which need to have some sequencing between pages. The 'new app for every article' definitely sounds like a clusterf.... it maybe an interesting experiment, but it just *feels* wrong at so many levels .. you do want some way to generalize this into a single app .. but my guess is you also are unable to wrap things into common templates and editing the html in the database / django admin is just too messy .. even if you let individual "articles" or "article bundles" have their own custom css that's specified some-how in the db, and their own custom html that you some-how populate from html files you upload. It may work, and it is perhaps the correct way to do this. I just know the situation where you're fighting with some silly html generated by a design tool and actually want simple html files and css resources, and the database "structure" can feel like its getting in the way .. So, here is my radical (?) suggestion :) - Have a simple model like this: class Item(models.Model): title = models.CharField(..) slug = models.SlugField(..) ... any extra metadata fields you need for the "article bundles" Then, for each item "slug" name, you create a new folder on the file-system in some path you define in settings.py or so like CUSTOM_HTML_PATH or anything - so, say you have a series of articles on "Why not to do webdesign in Indesign" with a slug like "why-not-indesign", you create a folder inside CUSTOM_HTML_PATH with the name "why-not-indesign". Then create the various articles in that "bundle" like 1.html, 2.html, 3.html, etc. and include all the css / js files that specific bundle needs inside a static folder in that directory. Then you just need a view which takes <item_slug>, looks for the appropriate folder on the file-system, and renders 1.html inside whatever master template you may have. The view can also check for all the <integer>.html files in the directory to handle next / previous. You would probably need to do a bit of magic with STATICFILE_DIRS or so to make sure each of the static file folders inside the directories are collected by collectstatic so you can still serve the static files through the web server and not through django. Of course, I don't know the details of your work-flow so I maybe missing something, but I do in general find the idea of storing some things just on the file-system quite interesting, and the code to manage it is generally pretty straightforward. Of course, this may also be a terrible idea, but I'd also love to hear why .. :) Cheers, Sanjay On Tue, Jan 8, 2013 at 9:52 AM, Lachlan Musicman <data...@gmail.com> wrote: >> >> There are some cases where they send me Indesign, but when I export to HTML >> some of the layouts break. So then I have to manually rig it until I feel >> its close enough (but then it turns out it wasn't, so I mod again). Some >> imagemaps made from sliced up Photoshops with some cute rollover effects >> added on. And then some of the Articles form sequential "stories", so they >> need linking in between to make them feel seamless. >> >> The major point is that I have small bundles of files that are very >> interconnected, and keeping them close and organized makes the >> reviewing/editing/handling process much easier. Most of my hacking has been >> from KomodeIDE, and then VIM/SSH (and thats even when Im doing the design >> work!). Im having a hard time breaking away from the direct editing. > > So it sounds like a model like this would work: > > def BundleFiles(models.Model): > file = models.FileField() > articlw = models.ManyToMany(Article) > # or maybe article = models.ForeignKey(Article) > > def Article(models.Model): > html = models.TextField() #for the end product > # or html = models.FileField() > cssfile = models.FileField() #this can be abstracted out to it's own > model if used across many articles > previous = models.FK(Article, blank = True, null= True) > next = models.FK(Article, blank = True, null= True) > > See how these are more like folders to hold each set of info. For the > final product/page, you would need to write appropriate views and > methods that extracted the important bits and put them in the > appropriate places. > > > >>> >>> > I think that splitting each article into it's own app sounds like a >>> > disaster waiting to happen. >>> >> >> I agree, thats why I posted here. I am already starting to see the >> problems... I have started breaking the DRY principle, and its not looking >> much better. The good news right now, is that my repeats are within close >> proximity on the filesytem, so Im not rooting all over the place just yet. >> The only major burden is a project-wide navigation map that has to be >> properly updated and sequenced (still doin that one by hand). >> >> On a good note: >> I did find an App called django-media-tree that made me feel a little >> better. It should be easy enough for my guys to feed the projects in there, >> and maybe I implement an Article-Bundler to help the push/pull process. And >> then when I need to do my editing, I can set up a temporary staging >> directory that checks out a bundle, I edit, and then it parses it back in. >> >> But I still find myself creating bare apps with some crazy model defined >> that only has 1 table row. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/django-users/-/mMaEbFr1I4QJ. >> >> 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. > > > > -- > ...we look at the present day through a rear-view mirror. This is > something Marshall McLuhan said back in the Sixties, when the world > was in the grip of authentic-seeming future narratives. He said, “We > look at the present through a rear-view mirror. We march backwards > into the future.” > > http://www.warrenellis.com/?p=14314 > > -- > 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. > -- 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.
