On Mon, Nov 24, 2014 at 1:45 PM, martin f krafft <madd...@madduck.net> wrote:
> also sprach Russell Keith-Magee <russ...@keith-magee.com> [2014-11-24 > 00:42 +0100]: > > The problem is that there isn't one. There's several :-) > > > > I'm aware of at least 3: > > > > https://pypi.python.org/pypi/GitPython/0.3.2.1 > > https://pypi.python.org/pypi/pygit2 > > https://pypi.python.org/pypi/dulwich > > I am aware of those and I was wondering more about the glue on the > Django-side of things, i.e. how the storage plugin/layer would work. > > I am pretty inexperienced with Django, hence I find it hard to even > figure out where the sensible place to do this would be. > The right place is in the view. At the simplest level, a view is just a function that converts a request into a response. "Normal" Django template rendering (i.e., return render(request, "mytemplate.html", {'object': obj}) ) hides a lot of detail - but all it's really doing is opening a file on disk (from one of a couple of a known locations - the template directories), parsing that template, rendering it with a context, and returning it to the user. A simple "hello world" view will develop "obj" by doing database queries - but the information can come from any other data source that is relevant. You might hit a non-relational store (such as Redis), or a search engine (like ElasticSearch), or do some sort of calculation based on the GET/POST arguments provided. In your case, you'll be taking the GET/POST values, plus the URL parameters, and using them to identify a "resource" in your Git tree; your git calls will extract that resource; and then you can either return that resource literally as your response (with an appropriate content type), or pass the resource to a template to be rendered. Thinking about the storage layer is going deeper than you need to go. The storage layer is an abstraction to enable reusable apps. If I write a "user profile" app that needs to store an avatar, then I don't care where that avatar comes from, as long as it's available. It could be on a local filesystem; it could be on a cloud file store (like S3). The storage API lets me do that. The storage API isn't there to abstract all possible concepts of storage that might exist, and just because you'll be accessing a notional file system, doesn't mean that access needs to be done through the storage API - it's fine to just open the file. While you probably *could* write a storage plugin that would read a git repository, that's not really what the storage API is for. If you're just looking to read the *current* value in a git repository, then just use normal filesystem storage over a normal git checkout. If you want to do "interesting" things like retrieve a specific file version, you're not going to be able to use the storage API, because most raw filesystems don't have a concept of versioning. 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/CAJxq848%2B46c7Hz1P9VCaiOoZqyoNekDGDdrH0iiDUaXUpCKcNw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
