[coyotos-dev] Issues with Drupal

[David Chizmadia (Home)]

Shap,

    I've been looking at several CMS and Wiki systems as the base
for a proposal development system that would accommodate proposals
being developed with partner companies. As a result, my requirements
are very similar to yours.

    The Zope/Plone CMS consistently drifted to the top of my list
and it looks like it would meet all of your needs. (My only problem
with it was my additional requirement for the system to use SSL
mutual authentication as the login method.) It has a wide range of
plug-ins that provide for dynamic content and mature tools for
developing and managing more static content. It also has plug-ins
that allow it to work in conjunction with a couple of SCMs (I'm
pretty sure I saw both CVS and SVN support last time I looked - I
don't know about Mercurial).

    Good luck with your continuing search.

-DMC

PS: In consideration of the future, perhaps we should try to
    document these requirements and put them out as an OCap
    Challenge Problem. It would make for an interesting project in a
    software system engineering class being taught by someone
    interested in testing the hypothesis that one can build a
    complex system using an OCap foundation and OCap design
    patterns...

Jonathan S. Shapiro wrote:
> Well, it looks like we are in a serious world of hurt on the Drupal
> thing. I found out this weekend that Drupal doesn't handle SVG or any
> other vector format in anything like a sensible way. This means that we
> cannot use it as a CMS for anything that (a) needs to be able to go to
> print, and (b) includes diagrams that cannot look like shit in print.
> 
> The "needs to go to print" part is a known weakness of Drupal, but
> coming from the OSDoc experience I was pretty sure that I could solve
> that by building the world's ugliest XHTML->Latex transform via XSLT
> (which is basically how OSDoc does it).
> 
> Speaking exclusively for myself, I prefer xfig to SVG, mainly because
> the renders and the editors for SVG are both so cruddy. XFig is
> primitive, but you can render it consistently. SVG not so much, because
> you are tempted to believe that you can trust the browser, and you
> simply can't. The stuff that comes out of InkScape that gets called SVG
> really has to be seen to appreciate how bad it is.
> 
> It gets better: Drupal can't embed external content to save it's life.
> Ironically, Trac (which is very explicitly NOT trying to be an SCM
> system) does much better here.
> 
> Trac, of course, intentionally does not have a notion of a "product" in
> it's bug tracking system. Seems really silly to use a system whose main
> feature is its bug tracking stuff when it doesn't do the kind of
> tracking we need. We'll only have to disable it and resort to bugzilla.
> Sigh.
> 
> I had a long chat tonight on IRC with one of the core Trac guys. I don't
> like what he had to say, because (bottom line) it isn't going to solve
> our problem. On the other hand, I do respect his point of view: there is
> a niche that Trac serves very very well, and they are trying to keep it
> simple.
> 
> I have put two blog posts up on our Drupal site about this:
> 
> http://dev.eros-os.com/content/we-don-039-t-need-no-stinking-architecture
> http://dev.eros-os.com/content/still-search-cms
> 
> It is becoming pretty obvious that we are going to need to compromise in
> the end. Drupal can serve for community support, but we are going to
> need to maintain parts of our site in static form. I can't tell you all
> how much I hate that. I hate the idea of an inconsistent look, and I
> hate the idea of all of that static content that is just that little bit
> harder for people to comment on and improve as a community.
> 
> If you know anything about CMS systems, have a look at that second Blog
> entry and tell me what you know about.
> 
> 
> shap
> 
> 
> _______________________________________________
> coyotos-dev mailing list
> coyotos-dev at smtp.coyotos.org
> http://www.coyotos.org/mailman/listinfo/coyotos-dev
>