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