Can I just say, how nice it is to read this thread and not see Microsoft SharePoint mentioned?
Have a great weekend, //Ed On Feb 14, 2014, at 3:14 PM, Cary Gordon <[email protected]> wrote: > Random comments and crackpot remarks. > > --- > > I like to think of myself as a programer and architect, not a PHP developer > or a Python developer (Rails, JS, Scala, APL. Java, C/+/+...). In 2005, I was > either going to build a new CMS in ColdFusion or move to Django, when Drupal > presented itself as a possibility. I was no fan of PHP, and I was skeptical. > > My first Drupal project was not a CMS. It was putting a user-freindly face on > a dSpace library. Drupal won me over because it had well documented APIs and > it was XML friendly. Drupal was written in PHP, but avoided the excesses of > that language by adopting strong coding standards. Even then, the community > was thinking of it as a content management framework. > > Since then and across 5 major releases, Drupal has picked up thousands of > contributed modules, and, notably, moved to test-driven development. It has > kept its tight coding standards, and added tools to help developers maintain > those in their own modules. > > Coming soon(ish): Drupal 8 we will be based on a framework. Symfony started > life as a "Rails for PHP" and has evolved into a movement. What Symfony and > Rails (and Drupal) have in common are passionate, dedicated communities. The > move to Symfony is expensive for the community, but we feel it is worth the > effort, as it will lower the entry bar for Drupal developers who have a > background in PHP, Symfony or even Rails and Rails-ish frameworks. > > --- > > As was pointed out earlier, the selling point for using a full-on CMS is > support and maintenance. > > You can build the coolest, most specific site and/or CMS in the world in > Unlambda, Piet or Lolcode, but unless you have a dedicated amanuensis, or > perhaps your own reality TV show, whoever owns it had better have a really > good insurance policy on you, just in case you get hit by a truck before you > get to the documentation step. If they have both the insurance policy AND a > truck, watch out. > > --- > > I really like Python, but I seldom use it for anything other that > systems-related jobs. Day-to-day, I use Drupal (API-as-language), Symfony, > Node, and occasionally Rails. Java drags me in once in a while. > > Thanks, > > Cary > > > On Feb 14, 2014, at 8:39 AM, Sarah Thorngate <[email protected]> > wrote: > >> 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 <[email protected] >>> 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 >>> <[email protected]> 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) >>>> [email protected] >>>> 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 <[email protected]> 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:[email protected]] On Behalf Of >>>>> Coral Sheldon-Hess >>>>> Sent: Thursday, February 13, 2014 6:14 PM >>>>> To: [email protected] >>>>> 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 >>> [email protected] >>> www.aptrust.org >>> 678-379-9488 >>> >> >> >> >> -- >> >> Sarah Thorngate >> Digital Services Librarian >> North Park University >> [email protected] >> 773-244-4562
