Hello, maybe someone with better insights into the Zine internals can help me: I’m currently looking into possibilities to extend post properties via plugins in Zine 0.1.2. The idea is to add a "license" attribute to posts using a plugin, and allow to select a license from a list of licenses, and then render a license information block in the post. While it is easily possible to add global configuration vars to the Zine admin interface, I haven’t found a way to add configuration vars to individual posts. From the PostForm and the edit_entry.html template, it looks like the post attribute are a hardcoded set of attributes. So is there a way to extend post attributes using plugins without too much effort? Thanks, Frederik
Hi Frederik, I am currently working on a book review blog based on Zine and added an ISBN13 field to posts. The ISBN13 field is used to automatically add a cover image, current price, and a link to a webstore. As I was told that Zine is essentially an abandoned project, then I didn't bother with creating a plugin, but dove right into the main sources. This was actually a pretty good idea and doing what I described above didn't take more than 2-3 days total, starting with zero knowledge of Zine. If you wish, then I can add a license field as per your spec to Zine rather cheaply :) Best, Elver elver.loho@gmail.com +372 5661 6933 http://memeresearch.com/ skype: elver.loho On 26 August 2010 19:18, Frederik Elwert <frederik.elwert@web.de> wrote: > Hello, > > maybe someone with better insights into the Zine internals can help me: > I’m currently looking into possibilities to extend post properties via > plugins in Zine 0.1.2. The idea is to add a "license" attribute to posts > using a plugin, and allow to select a license from a list of licenses, > and then render a license information block in the post. > > While it is easily possible to add global configuration vars to the Zine > admin interface, I haven’t found a way to add configuration vars to > individual posts. From the PostForm and the edit_entry.html template, it > looks like the post attribute are a hardcoded set of attributes. > > So is there a way to extend post attributes using plugins without too > much effort? > > Thanks, > Frederik > >
Hi Elver, Am Donnerstag, den 26.08.2010, 19:48 +0300 schrieb Elver Loho: > If you wish, then I can add a license field as per your spec to Zine > rather cheaply :) That would be really great! Thanks, Frederik
Hi, First off, If you do any hacking, you probably want the latest Zine trunk, not version 0.1.2. Beside that, what you are trying to do is indeed very well achievable. I would disagree with Elver on the subject of "hack the source" vs. "add a plug-in". Maybe it is just me that likes to keep things modular, but I think it depends whether you think this functionality may be useful to others. If so, I would encourage to make it a plug-in. It may be that a signal or processing logic needs to be added in a place or two in the Zine core, but the rest should fit well into a plug-in. There are the "before-contents-rendered"/"after-contents-rendered" signals which can be used as triggers to add HTML to the page. That goes for the user pages. Similarly, there are the "before-admin-contents-rendered"/"after-admin-contents-rendered" for admin pages. These can be used to add elements to the user and admin views of the website. There are the "modify-admin-navigation-bar" and "before-admin-response-rendered" signals to modify the admin side nav-bar and context. These can be used to inject your plug-in configuration pages to the admin view along with possible javascript, css, etc... There is the "after-post-saved" signal which can be used to process your custom widget values and record them to the database. All that is missing is "before-post-saved" if you need to do custom validation and show error messages. I am planning to add this at least for my own fork as plug-ins often need this functionality. I for one need this to extend the RST parser to warn of parser errors before saving the page content. 'd be glad If someone adds this functionality to their fork before me... Regards, Artem On Thu, Aug 26, 2010 at 7:18 PM, Frederik Elwert <frederik.elwert@web.de> wrote: > Hello, > > maybe someone with better insights into the Zine internals can help me: > I’m currently looking into possibilities to extend post properties via > plugins in Zine 0.1.2. The idea is to add a "license" attribute to posts > using a plugin, and allow to select a license from a list of licenses, > and then render a license information block in the post. > > While it is easily possible to add global configuration vars to the Zine > admin interface, I haven’t found a way to add configuration vars to > individual posts. From the PostForm and the edit_entry.html template, it > looks like the post attribute are a hardcoded set of attributes. > > So is there a way to extend post attributes using plugins without too > much effort? > > Thanks, > Frederik > >
Hi, thank you for your comments, really helpful! Am Freitag, den 27.08.2010, 09:44 +0300 schrieb Artem Egorkine: > First off, If you do any hacking, you probably want the latest Zine > trunk, not version 0.1.2. The problem I see with trunk is that it requires really new versions of some packages. I want to run Zine on a standard Ubuntu 10.04 server where we already run a large site, so upgrading individual packages is not an option. > Beside that, what you are trying to do is > indeed very well achievable. I would disagree with Elver on the > subject of "hack the source" vs. "add a plug-in". Maybe it is just me > that likes to keep things modular, but I think it depends whether you > think this functionality may be useful to others. If so, I would > encourage to make it a plug-in. If it is possible, I also like the plugin approach. I just am not sure if it really is possible to implement this as a plugin. If it requires major changes within the Zine core, and I’m using the ancient 0.1.2 version, I might just tweak the core directly, since adding the required plugin interfaces would not be of any benefit, given that core development happens in trunk. > It may be that a signal or processing > logic needs to be added in a place or two in the Zine core, but the > rest should fit well into a plug-in. I currently think one would have to implement three steps: 1. Modify the post form to provide an additional license dropdown. 2. Store the chosen license per post somewhere (probably not possible with the default post model, since that is hardcoded). 3. Given the post license, inject some additional content when displaying the post. This part is probably the easiest, using "before-entry-rendered" or something. > There are the "before-contents-rendered"/"after-contents-rendered" > signals which can be used as triggers to add HTML to the page. That > goes for the user pages. Similarly, there are the > "before-admin-contents-rendered"/"after-admin-contents-rendered" for > admin pages. These can be used to add elements to the user and admin > views of the website. Would it be possible to modify the post form in the admin area with "before/after-admin-contents-rendered"? That would solve point 1. > There are the "modify-admin-navigation-bar" and > "before-admin-response-rendered" signals to modify the admin side > nav-bar and context. These can be used to inject your plug-in > configuration pages to the admin view along with possible javascript, > css, etc... But I think this only helps for per-plugin settings, not for per-post settings. Or did I overlook something? > There is the "after-post-saved" signal which can be used to process > your custom widget values and record them to the database. Ok, I’ll look into that. I’d probably have to create an additional database Model for this? Would solve point 2. > All that is missing is "before-post-saved" if you need to do custom > validation and show error messages. I am planning to add this at least > for my own fork as plug-ins often need this functionality. I for one > need this to extend the RST parser to warn of parser errors before > saving the page content. 'd be glad If someone adds this functionality > to their fork before me... Yes, that definitely makes sense. I’m on vacation for two weeks now, but once I’m back I’ll dive back into Zine and see if the plugin approach works out or if Elver’s approach is better suited for my needs. Regards, Frederik
Hi, You're on the right track! On Sat, Aug 28, 2010 at 2:08 PM, Frederik Elwert <frederik.elwert@web.de> wrote: > Hi, > > thank you for your comments, really helpful! > > Am Freitag, den 27.08.2010, 09:44 +0300 schrieb Artem Egorkine: >> First off, If you do any hacking, you probably want the latest Zine >> trunk, not version 0.1.2. > > The problem I see with trunk is that it requires really new versions of > some packages. I want to run Zine on a standard Ubuntu 10.04 server > where we already run a large site, so upgrading individual packages is > not an option. > The easiest way to get Zine trunk running on a Ubuntu 10.04 without being destructive to the system is a virtualenv setup. I often have multiple projects on the same host requiring the a great variety of versions of a certain package. I couldn't imagine how it would work out without virtualenv. It surely helps that Ubuntu 10.04 has a recent-enough version of virtualenv (python-virtualend package). Although I cannot say the same for pip, which is so useful together with virtualenv, but is so ancient in Ubuntu. Luckily you can just easy_install it. >> Beside that, what you are trying to do is >> indeed very well achievable. I would disagree with Elver on the >> subject of "hack the source" vs. "add a plug-in". Maybe it is just me >> that likes to keep things modular, but I think it depends whether you >> think this functionality may be useful to others. If so, I would >> encourage to make it a plug-in. > > If it is possible, I also like the plugin approach. I just am not sure > if it really is possible to implement this as a plugin. If it requires > major changes within the Zine core, and I’m using the ancient 0.1.2 > version, I might just tweak the core directly, since adding the required > plugin interfaces would not be of any benefit, given that core > development happens in trunk. > One reason I'm suggesting trunk is that plugins are so much easier with it. Furthermore, you would need a database table to store your data and database migrations support in Zine trunk is a blessing! >> It may be that a signal or processing >> logic needs to be added in a place or two in the Zine core, but the >> rest should fit well into a plug-in. > > I currently think one would have to implement three steps: > > 1. Modify the post form to provide an additional license dropdown. > 2. Store the chosen license per post somewhere (probably not > possible with the default post model, since that is hardcoded). > 3. Given the post license, inject some additional content when > displaying the post. This part is probably the easiest, using > "before-entry-rendered" or something. > >> There are the "before-contents-rendered"/"after-contents-rendered" >> signals which can be used as triggers to add HTML to the page. That >> goes for the user pages. Similarly, there are the >> "before-admin-contents-rendered"/"after-admin-contents-rendered" for >> admin pages. These can be used to add elements to the user and admin >> views of the website. > > Would it be possible to modify the post form in the admin area with > "before/after-admin-contents-rendered"? That would solve point 1. Yes, that is what I was thinking too. > >> There are the "modify-admin-navigation-bar" and >> "before-admin-response-rendered" signals to modify the admin side >> nav-bar and context. These can be used to inject your plug-in >> configuration pages to the admin view along with possible javascript, >> css, etc... > > But I think this only helps for per-plugin settings, not for per-post > settings. Or did I overlook something? Yes, this is per-plugin. I thing if you have a list of licenses you may want to add and remove licenses and you'd need to navigate to the page where you can do that. That's where the navigation bar comes in. > >> There is the "after-post-saved" signal which can be used to process >> your custom widget values and record them to the database. > > Ok, I’ll look into that. I’d probably have to create an additional > database Model for this? Would solve point 2. > >> All that is missing is "before-post-saved" if you need to do custom >> validation and show error messages. I am planning to add this at least >> for my own fork as plug-ins often need this functionality. I for one >> need this to extend the RST parser to warn of parser errors before >> saving the page content. 'd be glad If someone adds this functionality >> to their fork before me... > > Yes, that definitely makes sense. > > I’m on vacation for two weeks now, but once I’m back I’ll dive back into > Zine and see if the plugin approach works out or if Elver’s approach is > better suited for my needs. > Good luck with your project! It would be great to hear about your progress and the issues you face with Zine internals. Sincerely, Artem