Hello, 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 -- You received this message because you are subscribed to the Google Groups "Pinax Core Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pinax-core-dev?hl=en.
