biblion proposal
Thomas Schreiber
Last spring I worked towards resolving two Pinax tickets for Biblion
#75 + #22. As I progressed I wrote many other features which may be
valuable to merge into Biblion. My discussions with @jtauber led me to
believe that they are in line with Biblion's goals, and I kept the
prospect of merging this work back into Biblion all along. At some
point, I had to stop developing #75 + #22 in separate branches because
it was getting overly complex as the features I was working on became
more intertwined, especially when I began to deploy the code to
production for my project. My work has since continued in the
`scenemachine` branch:
https://github.com/rizumu/biblion/tree/scenemachine
I'll go over the work and features I've written, then in this thread
or on #pinax-dev we can reach some 'design decision' conclusions.
Finally I will prepare focused pull requests for the parts with design
approval. I'd like to do this as soon as possible, especially now
while Biblion has momentum again and before things stray apart making
it no longer possible. Looking at the current work occurring in the
biblia branch, I think its reasonable that much of what I've done
could be brought in.
I'd also like to note that I wrote an application
https://github.com/rizumu/django-podcasting which is conceptually and
structurally similar to Biblion as described below. Working on both of
these applications simultaneously led me to think about the two
applications as a whole, which led to some interesting results.
-
Here are the tickets and the comparison of the last state of my
branches with the Biblia branch.
#75: Multiple markup types for blog posts (support of creole,
markdown, textile, html, and restructuredtxt) with Pygments
http://code.pinaxproject.com/tasks/task/75/
https://github.com/rizumu/biblion/compare/eldarion%3Abiblia...multi-markup
* Most of this work was taken directly from MightyLemon.
* Added a new field `markup_type` to models.Post, and renamed
`teaser_html` and `content_html` to teaser and content respectively.
* Created a new folder `utils` and added the `to_html` templatetag to
`utils/code_hilite.py`, and as a result moved twitter.py into the
`utils` subfolder.
* The `code_hilite.py` file contains the bulk of this feature.
* brought in the Pygments css files for easier deployment of the static media.
* install_requires=[ "creole==1.2", "docutils==0.8.1",
"markdown==2.0.3", "Pygments==1.4", "textile==2.1.5" ],
#22: multi-blog project
http://code.pinaxproject.com/tasks/task/22/
https://github.com/rizumu/biblion/compare/eldarion:biblia...rizumu:multi-blog
For multi-blog my goal was to allow multiple blogs per site utilizing
the sites framework. Adding a models.Blog with a `sites` field should
cover all cases of multi that people could come up with. In this
branch I also wrote detailed feeds.py for both Atom and Rss using the
newer syndication framework, trying best to match the official specs.
Additionally I Internationalized the application along the way.
* Used a UUID field as the ID for the blog and the post. The reasoning
behind this was that the podcasting iTunes feeds expect a UUID, and
while working on both I did the for Biblion in my fork. The field is
bundled in biblion.utils.fields.UUIDField. I struggled with the choice
behind going this route, but because the south migrations worked just
fine I went ahead with using the UUIDField.
* Made django-licenses a conditional dependency. Maybe it isn't
desired at all, but again, for podcasting, a license is a requirement
of the feed spec, and it was easy enough to do the same with a blog
post. I personally didn't find the harm in requiring people to have a
license field in their DB, and it is nice that it is it's own
application so that the license data can be shared with podcasting and
other applications that desire.
* Merged in Issac Kelly's branch for conditionally supporting
django-taggit and kept `can_tweet` as optional. This is the same way I
could make django-licenses optional.
* Kept the revision logic in place, and extended it to support the models.Blog
* Kept the section fields and functionality intact, but I wondered if
it could be dropped in favour of django-taggit.
* Split out only the feeds urls.py into a urls_feeds.py so they can be
added to the hierarchy differently. When serving multiple types of
feeds, blogs, podcasts, etc, it is much nicer to have this option out
of the box:
site.com/feeds/blogs/... & site.com/feeds/podcasts/...
* Changed author FKfield to authors M2M. This catches all possible
future scenarios of a post, or article having been written by multiple
people. Think research paper for example. This is in a feature branch
already: https://github.com/rizumu/biblion/compare/eldarion:biblia...rizumu:multi-author
* Added a `contributors` field which is part of the Atom spec.
* Added a `maintainers` M2M to User to build the link to Users that
are allowed to maintain the blog. This probably is not desired, as a
3rd party app such as guardian should be able to handle this better,
but it is there for those who want a simple way to do so. I'd like to
hear feedback on this, especially because in a multi-site, multi-blog
system permissions/roles are important.
* PEP8 and kept true to the Pinax style guide
* Podcasting uses Class Based View's from 1.3 and I'll do the same for
Biblion if desired.
FWIW, I took great care in combing over everything to make sure it
works, and my branch containing the combination of all these features
has been running in production since springtime. I've fixed any issues
that arose along the way. All markup types with pygments are currently
not working, and I probably didn't get RSS+Atom feed specs perfectly,
but that is something I am focused on resolving asap. In addition to
narrowing these commits down into pull requests for merge into Biblion
proper, in the coming weeks I will resolve any issues, write tests,
and give everything a full QA review.
I know this is a lengthy email, but it was indeed quite a bit of work
over many months and now is the time to see what can done with it.
Looking forward to you feedback.
All the best,
Tom
Thomas Schreiber
model internationalization, and a post_published signal.
Since I started this thread, the biblia branch already has already
gained multi-blog and CBV. Additionally with the addition of the
contributor class, it negates the contributor and maintainer questions
I had.
See the previous post for more details, but this is what now still
needs a design decision or discussion:
* Add the atom feed and a detailed cleanup of the feeds to match
the specs
* UUID field to match RSS/Atom spec or not?
* Conditional or required django-licenses support to match RSS/
Atom spec
* Internationalize everything else
* Add templates
* Change author FKfield to 'authors' as a M2M.
Once decisions are made, I can make pull requests for these.
best,
Tom
Thomas Schreiber
between biblion master biblia branch, and work I did in my older fork
off of master.
biblion.models.Biblion is a confusing name, it really should be
biblion.models.Blog. The app named biblion is enough, but naming the
Blog model Biblia makes for a very confusing set of url names and
template names.
Also, Biblia now has a multi-blog setup, but the url schema doesn't
reflect this. The way biblia is now, two posts with the same slug can
not exist, even when they are posted to different blogs.
Furthermore,"blog" could be replaced as (?P<blog_slug>[\w-]+)
Here is the way it is now:
urlpatterns = patterns("",
url(r"^$", biblion.views.BiblionList.as_view(),
name="biblion_list"),
url(r"^create/$", biblion.views.BiblionCreate.as_view(),
name="biblion_create"),
url(r"^blog/(?P<slug>[\w-]+)/$",
biblion.views.BiblionDetail.as_view(), name="biblion_detail"),
url(r"^blog/(?P<slug>[\w-]+)/update/$",
biblion.views.BiblionUpdate.as_view(), name="biblion_update"),
url(r"^blog/(?P<slug>[\w-]+)/post/$",
biblion.views.PostCreate.as_view(), name="biblion_post_create"),
url(r"^post/(?P<slug>[\w-]+)/$",
biblion.views.PostDetail.as_view(), name="biblion_post_detail"),
url(r"^post/(?P<slug>[\w-]+)/edit/$",
biblion.views.PostUpdate.as_view(), name="biblion_post_update"),
)
What do you think of a schema like this instead?
urlpatterns = patterns("",
# blogs
url(r"^$", biblion.views.BiblionList.as_view(),
name="biblion_blog_list"),
url(r"^create/$", biblion.views.BiblionCreate.as_view(),
name="biblion_blog_create"),
url(r"^(?P<blog_slug>[-\w]+)/$",
biblion.views.BiblionDetail.as_view(), name="biblion_blog_detail"),
url(r"^(?P<blog_slug>[-\w]+)/edit/$",
biblion.views.BiblionUpdate.as_view(), name="biblion_blog_update"),
# posts
url(r"^(?P<blog_slug>[-\w]+)/post/$",
biblion.views.PostCreate.as_view(), name="biblion_post_create"),
url(r"^(?P<blog_slug>[-\w]+)/(?P<post_slug>[\w-]+)/$",
biblion.views.PostDetail.as_view(), name="biblion_post_detail"),
url(r"^(?P<blog_slug>[-\w]+)/(?P<post_slug>[\w-]+)/edit/$",
biblion.views.PostUpdate.as_view(), name="biblion_post_update"),
# other post ideas
url(r"^(?P<blog_slug>[-\w]+)/(?P<year>\d{4})/(?P<month>\d{2})/
(?P<day>\d{2})/(?P<slug>[-\w]+)/$",
biblion.views.PostDetail.as_view(), name="biblion_post_detail"),
url(r"^(?P<blog_slug>[-\w]+)/(?P<post_uuid>[0-9a-f-]{36,36})/
$", biblion.views.PostDetail.as_view(), name="biblion_post_uuid"),
)