>From my perspective, this can't just be about static sites in isolation from >how we might use this tool later. Otherwise we run the costly risk that we >commit to something that was fine for some things but doesn't fit our needs >anymore. We should think of this as a tool we can grow into.
Notably, too, we've got several sites that sit in between this binary of static site vs. cms (ie mostly static sites but with some dynamic features). We should consider an approach that will let us iteratively replace more of these with a unified solution. If these kinds of sites are already here, we should take them into account. Colin > On Mar 14, 2014, at 8:33 AM, Justin Obara <[email protected]> wrote: > > I'm really just trying to refocus on the main point of this being about > static site generators and not CMSs. > >> On Mar 14, 2014, at 8:07 AM, Colin Clark <[email protected]> wrote: >> >> Hi Justin, >> >> On Mar 14, 2014, at 7:57 AM, Justin Obara <[email protected]> wrote: >> >>>> "A static site generator written in Node.js could be easily extended with >>>> features written using Infusion and other tools we already use every day >>>> (e.g. Grunt). Even more interestingly, we might consider the long-term >>>> possibility of integrating static site generation features into Kettle, so >>>> that developers could easily deploy blended sites that consistent mostly >>>> of static HTML but also include JSON feeds or some dynamically-generated >>>> pages. >>> >>> I worry that this could start bringing us back to our heavy maintenance and >>> security issues. If the dynamically generated pages are still read only >>> (fully controlled by the server without user input from the client) it may >>> be okay. Avtar, you're in a better position than I to know if this is a >>> legitimate concern. Could you please weigh in on that? >> >> A static site generator won't do everything for us. I'm suggesting a smooth >> path from static sites to light dynamicity when it's needed (and only when). >> Can you elaborate on how you think this is any more of a security or >> maintenance issue than if we were, say, writing our own custom Drupal >> modules from scratch? >> >> Colin > _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
