 |
 |
I second Jason's approach. Even though I'd have more fun using a framework, I'm currently implementing a CMS (Drupal) for our main site content. If your non-technical library colleagues are anything like mine, they will want LibGuides-level simplicity for editing content. My thinking is that it's worth a little extra pain now to make sure I'm not the only one who can make changes to our content in the future; that can be a huge time suck, and prevent you from moving on to other projects. Sarah On Fri, Feb 14, 2014 at 10:08 AM, Scott Turnbull <[log in to unmask] > wrote: > We used Django and Python extensively while I was at Emory. > > First let me answer your question. If Django interests you then > DjangoCMS is a pretty good choice https://www.django-cms.org/en/ > > I know a few folks who use it and like it quiet a bit. That said I > know a lot of the community is trending toward Flask for simple apps > in python so it depends on how deep you want to go with what you need > to develop. > > In terms of what I'd add, I would reflect what a lot of people have > already said here. My own philosophy is that the CMS problem has > already been solved and it's not a great fit for a custom framework > unless you have very strong use cases that prove it isn't. I suggest > you consider taking care of straight up content with whatever CMS you > want to use (Drupal, Wordpress, etc) and reserve Django and python for > custom apps that need to sit under it. > > You can theme the sites so they look the same, leave the CMS to the > CMS and put your django apps under an app. subdomain to make the > experience more ore less seamless. > > Just my thoughts, I hope that helps some. > > Good luck and let us know what you end up doing, > > - Scott > > On Fri, Feb 14, 2014 at 10:35 AM, Jason Bengtson > <[log in to unmask]> wrote: > > I agree with Josh. In the end it's really going to come down to > balancing priorities. On my personal site I don't use any kind of content > management system and have no interest in adopting one. This has left me > free to do as I please without jumping through hoops to try and get things > work with an often intentionally limiting CMS. At my last University we > started with nothing but moved institutionally to Cascade Server (a > horrible mistake if ever there was one). Still, as rotten as CS is, I was > able to shoehorn a lot of web code through various mechanisms and the > campus web team simply kept all the good apps and such on an application > server and linked to them as needed. Of course, that meant that the pages > of the site itself were pretty static and standardized, in most cases, to > the point of McDevelopment, but it also allowed departmental admins to make > changes without knowing a stitch of web code. I was in bad position there > because I had little access to anything but t! > he CMS, so I had to find ways to shoehorn web apps I built into the CMS > and get them to work within its strictures. It didn't help that we had an > upper leadership element that didn't understand the difference between a > web page on our site and a purpose-built web app. > > > > Here at RMB, we don't currently use a CMS, but my predecessor built > what, in some ways, amounted to a kind of CMS for some of the content using > ColdFusion. We're evaluating a move to a CMS to put broader content editing > in the hands of departments so that they can take charge of more than news > items and the addition of database links. We'll see how that goes. Needless > to say, the good stuff will be kept far away from the CMS. The biggest > advantage to that arrangement on the computing side is that someone coming > in to replace me wouldn't really need to have an in-depth understanding of > php (which is the main server-side script I use) to get a handle on the > majority of the site. When I was hired I quickly discovered that it was > fortunate I had some ColdFusion in my background, or a lot of what our site > did and how it worked would have been inaccessible until I got up to speed > on the language. > > > > I guess what it comes down to for me, as we look at this decision, is > how much CMS flexibility and tweakability I need for the main site, vs what > I want in place for the real web apps that have been built or are underway > (which I can locate separately and build using whatever framework I see > fit). As such you may want to use Django as your framework on a separate > application server, while employing a more normative CMS for most of your > site content. > > > > Hopefully at least some of that wasn't too trite. > > > > Best regards, > > > > Jason Bengtson, MLIS, MA > > Head of Library Computing and Information Systems > > Assistant Professor, Graduate College > > Department of Health Sciences Library and Information Management > > University of Oklahoma Health Sciences Center > > 405-271-2285, opt. 5 > > 405-271-3297 (fax) > > [log in to unmask] > > http://library.ouhsc.edu > > www.jasonbengtson.com > > > > NOTICE: > > This e-mail is intended solely for the use of the individual to whom it > is addressed and may contain information that is privileged, confidential > or otherwise exempt from disclosure. If the reader of this e-mail is not > the intended recipient or the employee or agent responsible for delivering > the message to the intended recipient, you are hereby notified that any > dissemination, distribution, or copying of this communication is strictly > prohibited. If you have received this communication in error, please > immediately notify us by replying to the original message at the listed > email address. Thank You. > > > > On Feb 14, 2014, at 8:30 AM, Joshua Welker <[log in to unmask]> wrote: > > > >> There are two conflicting issues here. If you want ease of development, > >> you want a framework. If you want ease of content creation, you want a > >> CMS. As a developer, it's always my preference to go for ease of > >> development and use a framework. Designing plugins and modules just > sucks. > >> A simple plugin like displaying dates on a page is stupidly complicated > >> when you have to integrate it with the entire CMS rendering engine. But > I > >> have to acknowledge that it is better for me as the developer to do a > >> little extra legwork than requiring all the non-techie content creators > to > >> do the extra legwork. That said, it isn't _too_ hard to implement a > basic > >> wysiwyg editor like CKeditor in most frameworks that would eliminate > much > >> of the difficulty for content creators. > >> > >> The bigger issue for me is that, when you use a framework, you more or > >> less guarantee that anyone inheriting your code is going to be facing a > >> steep learning curve, possibly insurmountable depending on their level > of > >> programming knowledge. With a CMS, there is built-in documentation and a > >> support community for 95% of functionality, and then you just have to > >> document the 5% or so of code that you custom wrote. > >> > >> Having said all that, I have to point out the amazing Yii PHP framework. > >> It is so extremely easy to build a data-driven app. If you ever want a > PHP > >> framework, use that. For Python, I'd go with Django just because it has > a > >> better support community and is slightly easier than Flask for database > >> functionality like ORM. > >> > >> Josh Welker > >> > >> > >> -----Original Message----- > >> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of > >> Coral Sheldon-Hess > >> Sent: Thursday, February 13, 2014 6:14 PM > >> To: [log in to unmask] > >> Subject: [CODE4LIB] Python CMSs > >> > >> Hi, everyone! > >> > >> I've gotten clearance to totally rewrite my library's website in the > >> framework/CMS of my choice (pretty much :)). As I have said on numerous > >> occasions, "If I can get paid to write Python, I want to do that!" So, > >> after some discussion with my department head/sysadmin, we're leaning > >> toward Django. > >> > >> Here's a broad question, re: Python and Django: If you've made the > switch, > >> what has your experience been? Has Django (or any other Python > framework) > >> given you something cool that was lacking in your previous > >> language/framework/CMS? Has it helped you build something awesome? Have > >> you found it enabling or limiting in any way? If you were going to sell > >> people on (or against) using it, what would your arguments be? I'm a > >> relative newbie to Python, and a total newbie to Django, so even if > there > >> was a tutorial you found useful, or some caveat you learned along the > way, > >> I'm interested. :) > >> > >> And then a more specific question: Given the following requirements, do > >> you have a Django-based CMS you'd recommend? (Of course, I'll also do my > >> own research, but I'd love to see what other libraries' experiences have > >> been and what's popular, right now.) > >> * There's a chance we'll want to offer other editors access to it, at > >> some point, so it would be nice if I can provide a WYSIWYG interface, > >> which I also am going to want the option to *turn off*, for my own > sanity. > >> * We're a Springshare-heavy library with Summon and big secret API-based > >> plans, so easy JavaScript (preferably jQuery) integration is a must. > >> * It should play nicely with MySQL. > >> * Because I probably won't be here forever, it's of the utmost > importance > >> that whatever we end up with is easy to maintain. > >> * I'm used to MODx's page-ID model, where I can move pages around, and > as > >> long as I don't delete/recreate a page (thereby changing its ID), I > don't > >> have to change any links anywhere else in the CMS. I'd really like > >> something that will work equally well, since the odds that I'll nail the > >> information architecture on the first try are probably slim. :) (Maybe > >> this one should go without saying, since I know WordPress and many other > >> CMSs do this, but if you have to err, err on the side of being explicit, > >> right?) > >> * A nice forms-builder plugin (module?) would be a great thing to have, > as > >> well. We use FormIt in MODx, and now I'm spoiled. > >> > >> And, I mean, if there's a CMS on top of another Python framework you > think > >> I should be considering, feel free to throw that out as a possibility, > >> too! > >> > >> Thank you! > >> > >> -- > >> Coral Sheldon-Hess > >> http://sheldon-hess.org/coral > >> @web_kunoichi > > > > -- > Scott Turnbull > APTrust Technical Lead > [log in to unmask] > www.aptrust.org > 678-379-9488 > -- Sarah Thorngate Digital Services Librarian North Park University [log in to unmask] 773-244-4562