from:"Martin F"

also sprach Russell Keith-Magee  [2014-11-25 01:16 
+0100]:
> 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.

Yeah, and I think you have me 99.5% convinced that I want
a filesystem backend.

> 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.

Because the static content is used inside dynamic apps, and certain
parts of the website would be offered instead by apps and not static
files at all. As I said in my initial e-mail, we currently have
a Django app with Apache-level overrides of certain static pages
that are trying hard to look just like and integrate well with the
output Django renders and this is ugly.

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
normaliser unix c'est comme pasteuriser le camembert.
 
spamtraps: madduck.bo...@madduck.net

-- 
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/20141125054104.GA5859%40fishbowl.rw.madduck.net.
For more options, visit https://groups.google.com/d/optout.


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Obtaining content from Git

also sprach Russell Keith-Magee  [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.

> 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. ;)

> > 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.

Thanks for your help thus far!

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
don't hate yourself in the morning -- sleep till noon.
 
spamtraps: madduck.bo...@madduck.net

-- 
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/20141124114316.GA19818%40albatross.lehel.madduck.net.
For more options, visit https://groups.google.com/d/optout.


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Obtaining content from Git

also sprach Tim Chase  [2014-11-24 11:19 +0100]:
>   urlpatterns = patterns('',
> url(r'^blob/([0-9a-f]{40})/$', 'myapp.views.render_blob', ...),
> )

… this is straight-forward, thanks. I'd probably try not to expose
the SHAs to the user but request from the Git library a blob
identified by a path such as /path/to/file which the Git
library should then map to the blob, given a treeish to use as
a base (e.g. 'master', this could come from config).

> In theory, you could also set the cache control headers in the
> response so that they're ludicrously far in the future (assuming
> you don't plan to change your my_template.html) because the blob
> shouldn't ever change without having a different SHA1.

Two problems I see with this:

  1. If the SHA is not exposed, then a request path (see above) may
 well return different content on subsequent calls, so
 expiration-based caching isn't ideal;

  2. aren't the cache-control headers for the caches downstream?
 Wouldn't this mean that if 1,000 clients requested a page, the
 reStructuredText processor would have to do the same work 1,000
 times? I'd love to cache the result and serve that while the
 source file's pre-processing mtime hasn't changed.

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"i like wagner's music better than anybody's. it is so loud that one
 can talk the whole time without other people hearing what one says."
-- oscar wilde
 
spamtraps: madduck.bo...@madduck.net

-- 
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/20141124104910.GA11742%40albatross.lehel.madduck.net.
For more options, visit https://groups.google.com/d/optout.


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Obtaining content from Git

also sprach Russell Keith-Magee  [2014-11-24 07:16 
+0100]:
> The right place is in the view.
[…]
> 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

Interesting perspective you have there, which I can follow very
well. Thanks!

But let me dig a bit further, nevertheless:

> 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.

It could come from Git! After all, Git is really a database by
itself, just like the filesystem could be viewed as a database. So
somewhere in my idealist brain there's this theory that I could just
add a Git-storage-plugin to the storage layer and that would cause
content to be fetched from Git auto-magically if the
request-for-data by the view (not the HTTP request) matches certain
criteria and those data are available in Git. If not, then the
lookup goes to the next storage plugin.

So my view might call some sort of lookup() function, e.g.

  lookup_description(event_id)

which just returns a string. Ordinarily, this string comes from
pgsql at the moment. What I'd like to see is a way to override this
function so that instead the data are fetched from
  git.example.org/myrepo.git, branch=live, file=events/$event_id

Obviously, I could just as well call the Git-specific stuff straight
from the view, but that would inevitably tie the view to Git. Maybe
this is what I want, I am just trying to explain how I approached
this and what led me to ask the question the way I did.

> 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.

Yeah, this might well be the best option, also in terms of
performance, unless I want to keep track of blob hashes to avoid
doing the whole branch→tree→blob lookup every time, which the
filesystem "caches" for me.

Do you know of a simple example that fetches data from the
filesystem? I am being lazy here as I am sure there's plenty, so
feel free to RTFM me! ;) However, maybe you know a very good example
that makes everything so clear and then I'd really appreciate this
over wading through the various means. I know Django has provisions
for serving static files, but somehow it seems like that's not what
I want… (since the files are not actually static and a given path
could return different data on subsequent calls)



Furthermore, I'd actually like to post-process the data. The Git
repo would contain reStructuredText files and I'd like to render
them before filling the result into template slots.

This makes me think that there ought to be a cache involved at this
level. Sure, I could make a simple expiration-based cache, but I'd
really rather make the cache depend on the mtime of the underlying
source file on the filesystem (but include the post-processing step
in between).

Have you seen something like this done? Is this also still best done
in a view?

Thanks a lot for your patience and helpful replies!

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
review of a chemistry paper:
  "paper should be greatly reduced or completely oxidized."
-- frank vastola
 
spamtraps: madduck.bo...@madduck.net

-- 
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/20141124090640.GA30500%40albatross.lehel.madduck.net.
For more options, visit https://groups.google.com/d/optout.


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Obtaining content from Git

2014-11-23 Thread martin f krafft

also sprach Russell Keith-Magee  [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.

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"there are two major products that come out of berkeley: lsd and unix.
 we don't believe this to be a coincidence."
 -- jeremy s. anderson
 
spamtraps: madduck.bo...@madduck.net

-- 
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/20141124054512.GA14198%40fishbowl.rw.madduck.net.
For more options, visit https://groups.google.com/d/optout.


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Obtaining content from Git

2014-11-22 Thread martin f krafft

Hello,

we have a Django project with a few pages that come from Git.
Currently, Apache rewrite rules serve those files statically (and
they make use of the same template/CSS as Django does, so the user
does not actually notice), and it's a massive hack and pain to keep
up-to-date.

Hence I was thinking: how much trouble would it be to have Django
reach into Git rather than its database and obtain data there to be
filled into template slots? Ideally, there'd be the possibility of
running a filter (e.g. reStructuredText) between Git and the
template rendering.

I've seen http://luispedro.org/software/git-cms, but that does way
more than just sourcing from Git. And it's not immediately obvious
to me how it even does the Git interaction.

What I envision is a storage layer (with optional caching) that
either fetches from the filesystem (with a Git checkout, using mtime
for cache expiration), or directly from a local Git repo (using
either commit or blob hash for cache expiration).

Does anyone know of such a module? Would it be hard to write? Where
would one start?

Thanks,

--
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/

"imagine if every thursday your shoes exploded if you
tied them the usual way. this happens to us all the time
with computers, and nobody thinks of complaining."
-- jeff raskin

spamtraps: madduck.bo...@madduck.net

--
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/20141122212847.GA26476%40fishbowl.rw.madduck.net.
For more options, visit https://groups.google.com/d/optout.

digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Obtaining content from Git

2014-11-21 Thread martin f krafft

Hello,

I've seen http://luispedro.org/software/git-cms, but that does way
more than just sourcing from Git. And it's not immediately obvious
to me how it even does the Git interaction.

Does anyone know of such a module? Would it be hard to write? Where
would one start?

Thanks,

--
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/

mulutlitithtrhreeaadededd s siigngnatatuurere

spamtraps: madduck.bo...@madduck.net

--
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/20141121222930.GA15206%40fishbowl.rw.madduck.net.
For more options, visit https://groups.google.com/d/optout.

digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Django and sessions race condition

2013-12-11 Thread Martin F



I have lost one day with struggling with django sessions and it seems that 
I am not really able to resolve it without coding my own sessions 
middleware or using some locking. The problem is, sessions are not stored 
even if the saving is triggered manually. It happens now and then, because 
of race condition which occurs when multiple simultaneous AJAX requests are 
sent from the client side. I'm using db backend. The thing is, everything 
is ok when calling only one start() dajaxice call from the javascript side.

So the question, why session is not stored sometimes? Should I lock the 
segment, where session is being stored? I double checked session_key is 
still the same. Should not be this resolved in the session middleware 
module?

Settings: SESSION_SAVE_EVERY_REQUEST = True

def print_session_keys(request, tmp):
session_key = request.session.session_key
session = Session.objects.get(session_key=session_key)
a = session.get_decoded()
print tmp+str(a.keys())
@dajaxice_registerdef start(request):
dajax = Dajax()

searchHash = os.urandom(16).encode('hex')

data = 1

print_session_keys(request, 'Before: - hash: '+searchHash+' ')
request.session.set_expiry(0)
request.session[searchHash] = data
request.session.modified = True
request.session.save()
print_session_keys(request, 'After: - hash: '+searchHash+' ')

*LOG:*

1 or 2 requestes of 3, are stored fine:

Before: - hash: 05f22e8e828a0e6145519e0bb0778357 
[u'b0d0d5e4ebe846c4e3ffa66bfbd2e7e3', u'usermode', u'_session_expiry']
After: - hash: 05f22e8e828a0e6145519e0bb0778357 
[u'09cf89e0cbe5fb6a179e1f658d452c6b', u'05f22e8e828a0e6145519e0bb0778357', 
u'usermode', u'b0d0d5e4ebe846c4e3ffa66bfbd2e7e3', u'_session_expiry']

BUT:

Before: - hash: 071e79041aba16a82a32fe4a77c3b4e0 
[u'b0d0d5e4ebe846c4e3ffa66bfbd2e7e3', u'usermode', u'_session_expiry']
After: - hash: 071e79041aba16a82a32fe4a77c3b4e0 
[u'09cf89e0cbe5fb6a179e1f658d452c6b', u'05f22e8e828a0e6145519e0bb0778357', 
u'usermode', u'b0d0d5e4ebe846c4e3ffa66bfbd2e7e3', u'_session_expiry']

-- 
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/55f6db0a-340a-4f08-b192-e8d95ffdb4b6%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deployment Tool Recommendation

2009-07-15 Thread martin f krafft

also sprach Shawn Milochik  [2009.07.15.1722 +0200]:
> > Any reason why you can't do 'sudo -u otheruser bash -l' or even  
> > 'sudo su
> > - otheruser'? Seems strange to be able to sudo to root, but unable to
> > sudo to a role account.
> 
> 
> No, I don't see a reason not to do it that way. I just can't directly  
> su to the other user due to the lack of a password.

sudo -u otheruser -i

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
if voting could really change things, it would be illegal.
 -- revolution books, new york
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: de-facto tagging (was: When do snippets get into Django?)

also sprach James Bennett  [2009.05.25.2047 +0200]:
> And, really, this is the sort of thing that leads me to say it
> shouldn't be in contrib right now. We do need to have some sort of
> document outlining criteria, but I'd like to think that commitment to
> a stable API (e.g., the author is willing to call it "1.0"), and to
> support and updates are absolute requirements.

I completely agree, and it was a poor choice of example. After all,
I started "using" Django three days ago, have never used
django-tagging, but it /seemed/ a good example, since it /seemed/ to
fit Jacob's criteria perfectly well.

In the end, at the core of my question was the quest for a document
outlining the criteria, which I think is an important asset for
anyone evaluating Django.

Thank you for getting me/us back on the ground wrt django-tagging.
I'll take a look and since this is a core feature I am seeking,
maybe I can put time into it.

But how do we go about a document to specify what goes into contrib,
beyond Jacob's three criteria?

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"da haben wir es also: eine kirchliche ordnung mit priesterschaft,
 theologie, kultus, sakrament;
 kurz, alles das, was jesus von nazareth bekämpft hatte..."
 - friedrich nietzsche
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: validation and the ORM layer

also sprach Alex Gaynor  [2009.05.25.1945 +0200]:
> Django does not currently support model-validation, there is
> a google summer of code project being done by Honza Kral to add
> support for this.

Good to know, thanks.

This means that the feature won't be in 1.1 though, right?

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
life is a sexually transmitted disease with 100% mortality.
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: de-facto tagging (was: When do snippets get into Django?)

also sprach Dougal Matthews  [2009.05.23.1823 +0200]:
> Fair enough. I don't really have an issue with the idea, could be
> quite handy.
> 
> I can just imagine them saying no :) so thought I would question
> it as a move/idea.

Look what I found! Check out the fifth point, labeled #1, top-most
annoyance with Python, in

  http://jacobian.org/writing/hate-python/

I think this is strong leverage. ;)

> Also, might be a good idea to wait until 1.1 is out the door so
> they have time to consider it properly...

I couldn't resist the blog comment, but this is good advice.

Thanks,

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"my experience is that as soon as people are old enough to know better,
 they don't know anything at all."
-- oscar wilde
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

validation and the ORM layer

Hey folks,

while playing around with the DB API last night, we discovered that
the ORM layer does not enforce content validation.

Since the blank field option defaults to False, we expected to be
unable to save ORM objects with empty fields, but the DB API will
let us do just that:

  class BeersOfTheWorld(models.Model):
beer = models.CharField(max_length=256)

  b = BeersOfTheWorld()
  b.save()

and the record was created with an empty string title.

Then we found

  http://code.djangoproject.com/ticket/497

which is marked invalid with a pointer to form manipulators.

Does this reflect the roadmap of Django? Is content validation
expected from higher layers and the ORM layer won't do it?

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"one should never do anything that
 one cannot talk about after dinner."
-- oscar wilde
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: de-facto tagging (was: When do snippets get into Django?)

2009-05-23 Thread martin f krafft

also sprach Dougal Matthews  [2009.05.23.1103 +0200]:
> I don't think tagging is a particularly hard or non-trivial.

No. All the more reason to push for a standard and prevent dozens
of different implementations, no?

> Anyway, this conversation is a bit irrelevant because; Core
> developers want contrib to be slim, so its going to have a really
> strong usecase to get in.

I probably won't be hard to make a use-case for this, given how tags
are omnipresent in the Web 2.0 and part of the "Semantic Web" idea.
They are also incredibly useful at structuring information. Sure,
it's easy to do, but why should't the feature be in Django?

I think I'll collect some more information and then take this to the
-devel list.

> If you start adding 'tagging' a huge number of other things start
> to feel like they need to be added too. It because a case of well,
> you added tagging, so why not this?

If there are strong use-cases, why not?

> Also, what benefit do we really get from having it in contrib? Ok,
> so it means everybody has it but by the sounds of things everybody
> uses it anyway...
> 
> The difference between it being in contrib and being external is
> very minimal to the developer that uses it.

I disagree. For me, it's the difference of having to track it
myself, or letting my distro do that.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"love is a grave mental disease."
 -- platon
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: de-facto tagging (was: When do snippets get into Django?)

2009-05-23 Thread martin f krafft

also sprach Kai Kuehne  [2009.05.23.1048 +0200]:
> > Pretty must everybody does seem to use django-tagging unless
> > they have some special weird use-case.
> 
> Huh? Can you remove that "everybody", please? I've never used
> tagging and I'm confident - many others too.

I think he implicitly meant "everybody who uses tagging does so with
django-tagging". But of course, it's still optional, as
all the apps in django.contrib should be. You won't be forced to use
it, but those who want tagging support need not look any further.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"a man who does not realise
 that he is half an animal
 is only half a man."
-- thornton wilder
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: de-facto tagging (was: When do snippets get into Django?)

2009-05-23 Thread martin f krafft

also sprach Dougal Matthews  [2009.05.23.0232 +0200]:
> It doesn't. Why should it?

Well, because django-tagging is, quote Jacob:

  - optional
  - de-facto standard
  - the implementation of a common pattern

Tagging is a very common feature nowadays, isn't it? Having tag
support integrated with Django contrib would help create a tagging
standard across Django sites.

Or did I misunderstand?

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"prisons are built with stones of law,
 brothels with bricks of religion."
  -- william blake
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: de-facto tagging (was: When do snippets get into Django?)

also sprach Dougal Matthews  [2009.05.22.2352 +0200]:
> Pretty must everybody does seem to use django-tagging unless they have some
> special weird use-case.
> 
> I've used it every time I've needed tagging and don't have a gripe with it
> yet.

So how would it find its way into contrib?

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"geld ist das brecheisen der macht."
 - friedrich nietzsche
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

de-facto tagging (was: When do snippets get into Django?)

also sprach Alex Gaynor  [2009.05.22.1545 +0200]:
> http://jacobian.org/writing/what-is-django-contrib/  here is
> a description of what one of the core developers see as the role
> of django contrib.  It should be noted that 2 of the core devs
> said at euro django con that that they prefer the core of django
> to remain slim.

Sounds good, and something like django.contrib is a great way
forward.

It does leave me wondering what the "de-facto standard" way to tag
contents is…

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"a kiss may ruin a human life."
-- oscar wilde
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

caching generated content from the filesystem with Django

Hi folks,

I am new to Django, and trying to figure out if Django could be used
for a new project which is similar to a news site (stories
& syndication feeds), as well as more permanent content.

The twist is that we already have thousands of such stories stored
as Markdown or RST files on the filesystem, and maintained with
a version control system. We would like to keep it that way: stories
are written on the filesystem, committed to the VCS, and published
by Django.

This is hardly rocket science, and there are probably apps or
snippets that already do this. I have not looked too closely yet,
because I was concentrating on the issue of caching so far.

Rather than processing markup on the fly for each request, one would
like to cache the result. I found that the Textpattern CMS seems to
use a database for that:

  http://code.djangoproject.com/wiki/UsingMarkup

this gave me the following idea:

  For a given request, if it maps into the filesystem storage space,
  obtain the mtime of the file and compare it to a timestamp stored
  in a database table. If the mtime is newer, process the file and
  store the result in the database. Then return the contents of the
  database.

Compared to Django caching, this is purely on-demand, there is no
maximum age, but instead you get mtime queries into the filesystem
for every request (those could be cached…).

Does anyone know of an app or plugin which already does this?

Can anyone imagine a way to re-use the existing cache framework as
much as possible for this?

Any other thoughts or concerns?

Thanks,

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"i can stand brute force, but brute reason is quite unbearable. there
 is something unfair about its use. it is hitting below the
 intellect."
-- oscar wilde
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

When do snippets get into Django?

Hi folks,

I am new to Django and could not find the answer to a very important
consideration I need to make before diving into Django more. I used
to work with Zope and Plone, and one of the major problems were
upgrades, not of Zope or Plone, but of all the products that were
needed for a particular site.

Django also uses pluggable apps. Between djangopluggables and
code.google.com (and possibly other sites), there's a lot of
external applications providing great functionality. However, I am
reluctant to rely on those, mainly due to my experience with Plone
and Zope.

What's Django's strategy to integrate external pluggables into the
main distribution and support it across upgrades? For instance,
django-tagging[0] seems like a good candidate for core
functionality. Does it stand a chance?

0. http://djangoplugables.com/projects/django-tagging/

What's the process for integrating such external functionality into
Django's core?

PS: Django seems a lot thinner and more elegant than Plone/Zope, so
upgrades are likely to be less of a problem, but still...

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; n...@madduck
 
"security here. yes, ma'am. yes. groucho glasses. yes, we're on it.
 c'mon, guys. somebody gave an aardvark a nose-cut: somebody who
 can't deal with deconstructionist humor. code blue."
  -- http://azure.humbug.org.au/~aj/armadillos.txt
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

caching generated content from the filesystem with Django