On Mon, Nov 24, 2014 at 7:43 PM, martin f krafft <madd...@madduck.net>
wrote:
> also sprach Russell Keith-Magee <russ...@keith-magee.com> [2014-11-24
> 11:38 +0100]:
> > Perhaps I wasn't clear.
>
> No, you were. I am just pushing back a little bit because I come
> from another angle and I greatly appreciate your explanations in
> helping me understand the Django way of thinking. So in the hope
> that you now don't feel exploited… ;)
>
> > You might be able to write a mapping to Storage that did some sort
> > of naming trick (e.g., split off a colon at the end of a filename
> > for read, so you could request "/my/file.txt:deadbeef" to request
> > the "deadbeaf" hash of /my/file.txt") - but my point is that the
> > storage API doesn't contain a *natural* endpoint for version
> > information.
>
> Arguably, the ref/hash/date could come from the config, not from the
> file, and suddenly there'd be a 1:1 mapping between a filesystem
> store and a storage that uses Git directly.
>
>
Sure - that could work too. Although I'd question why you'd do this, rather
than just checking out the relevant hash onto the filesystem, and doing a
direct filesystem read.
> And, even if you did this, what you're going to get is a view of
> > your Git repository that tries *really* hard to make it look like
> > just a normal file system.
>
> Yeah, this is an excellent point, especially since I'd probably not
> allow pushes to that Git repository but instead set up some sort of
> polling or regular interval pulling. Then I might just as well use
> a filesystem.
>
> > def myview(request):
> > with open('filename.txt') as datafile:
> > data = datafile.read()
> > return render(request, 'my template.html', {'data': data})
> >
> > You're possibly getting lost by thinking that this is a "Django" thing -
> it
> > isn't. Basic Python is always an option.
>
> Yeah, but I would like to assume that this has been wrapped for
> Django at least one "canonical" time, with all error handling done
> and proper cache integration taken care of.
>
> Because to just start off with a myview() view like you suggest
> above is quickly going to become a full-time project, if you know
> what I mean. ;)
>
Unless I'm missing some important detail, I don't see why. It's a fairly
simple caching layer, and a fairly simple rendering layer. The only
complexities that I can see are the ones related to accessing the Git
repository - and that's the bit that isn't part of a "common" use case.
> > > Have you seen something like this done? Is this also still best
> > > done in a view?
> >
> > Well... yes, I've seen this done before. It's called GitHub :-)
>
> Hehe, that was funny.
>
> But seriously: forget about all of the Git stuff, let's just look at
> the filesystem… at least in my universe, I'd like to assume that the
> idea of reading marked-up data from disk, processing it, caching it
> and then making the data available to templates is such an intuitive
> and standard thing to do that it could even be in Django core — if
> not there, then there ought to be an existing plugin for this.
>
Again - the reason that this isn't in Django is because it's not really
Django's bailiwick. Response-level caching is something that should be
handled at the web server level, and web servers have various ways to
handle this. And if you're going to be even more ruthless about it, I'd be
questioning why you've got a live Django server in the loop at all - if
it's static files, "post processed", then why not pre-render the Github
files to a "rendered" form (possibly in response to a commit trigger), and
simply serve the pre-rendered files as static content.
Yours,
Russ Magee %-)
--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/CAJxq84-HogDjdv_w03qVCnv-KnNd3_9_VEce-ogCbQje8BOXMg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
