Hi all, I just noticed that I was being pinged on this list. Sorry for the delay in replying.
>> "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? I’m not against relying on dynamically generated content when it's appropriate. I’m advocating for an approach where we don’t default to using heavy content management systems for projects that don’t need them :) Avtar On Mar 14, 2014, at 7:57 AM, Justin Obara <[email protected]> wrote: > Thanks for the update, Colin and Avtar please see my comment below. > > Thanks > Justin > On Mar 13, 2014, at 12:19 PM, Colin Clark <[email protected]> wrote: > >> Hi Justin, >> >> On Mar 12, 2014, at 10:32 PM, Justin Obara <[email protected]> wrote: >> >>> Thanks Colin. Could you also add the reasoning behind the node.js criteria. >>> You were talking about this at the meeting today but some audio issue made >>> it hard to get all the details. >> >> I have updated the page with my thoughts about why it’s worth considering >> Node.js-based solutions ahead of those written for other platforms. >> >> http://wiki.fluidproject.org/display/fluid/Static+Site+Generators+Research >> >> The key point is this: >> >> "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? > >> Imagine, for example, of a static site that contained demos for Infusion, >> but also allowed users to submit Github links to cool demos they'd created >> of Infusion.” >> >> Imagine, too, a Grunt task that causes the Infusion documentation to be >> republished automatically any time a new supported API is added to the >> source code, or something like that. There are lots of potential >> possibilities. >> >> I hope this helps, >> >> Colin > _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
