On Jan 4, 2012, at 9:57 PM, Joe Schaefer wrote: > ----- Original Message ----- > >> From: Dave Fisher <[email protected]> >> To: Daniel Shahaf <[email protected]> >> Cc: Joe Schaefer <[email protected]>; "[email protected]" >> <[email protected]>; "[email protected]" >> <[email protected]> >> Sent: Thursday, January 5, 2012 12:45 AM >> Subject: Re: suggested CMS workflows for ooo-site >> >> >> On Jan 4, 2012, at 5:00 PM, Daniel Shahaf wrote: >> >>> Joe Schaefer wrote on Wed, Jan 04, 2012 at 16:55:02 -0800: >>>> ----- Original Message ----- >>>> >>>>> From: Daniel Shahaf <[email protected]> >>>>> To: Joe Schaefer <[email protected]> >>>>> Cc: "[email protected]" >> <[email protected]>; [email protected] >>>>> Sent: Wednesday, January 4, 2012 6:57 PM >>>>> Subject: Re: suggested CMS workflows for ooo-site >>>>> >>>>> Joe Schaefer wrote on Wed, Jan 04, 2012 at 09:52:39 -0800: >>>>>> ----- Original Message ----- >>>>>> >>>>>>> From: Dave Fisher <[email protected]> >>>>>>> To: [email protected] >>>>>>> Cc: >>>>>>> Sent: Wednesday, January 4, 2012 12:40 PM >>>>>>> Subject: Re: suggested CMS workflows for ooo-site >>>>>>> >>>>>>> >>>>>>> On Jan 4, 2012, at 9:29 AM, Joe Schaefer wrote: >>>>>>> >>>>>>>> Also Dave get in the habit of checking buildbot for >> the >>>>>>>> build status of sledgehammer commits instead of >> waiting >>>>>>>> for svnmailer to figure out what to do with the >> massive >>>>>>>> diff it's trying to make sense of. The url is >>>>>>>> >>>>>>>> >>>>>>>> http://ci.apache.org/builders/ooo-site-site-staging >>>>>>> >>>>>>> I do do that, but tend to wait for the email anyway. If >> there is no >>>>> reason to >>>>>>> wait that will save time. >>>>>> >>>>>> Buildbot performs the commit back as the final step in the >> build, >>>>>> so if buildbot thinks the build has completed successfully, you >>>>>> do not need to wait for svnmailer to send out a notice to that >> effect. >>>>>> >>>>>> My experience is that the turnaround between sledgehammer >> commits >>>>>> and eventual publication is about 1 hour: ~20 min for each step >>>>>> along the way, all because of svn committing or merging >>>>> >>>>> Instead of: >>>>> >>>>> % cd production-wc >>>>> % svn merge $URL/to/staging >>>>> >>>>> can you: >>>>> >>>>> % svnmucc -mm rm $URL/to/production cp $somerev $URL/to/staging >>>>> $URL/to/production >>>> >>>> Not too fond of that approach as we'd lose the history of the >> production tree >>>> in the process. Not every change to staging winds up being promoted. >>>> >>> >>> No we won't. Just run 'svn log -qv' on the parent of the >> production tree. >>> >>>> There is an alternative approach that I am reluctant to mention but >> might >>>> be the best solution for everyone: to use SSI as part of your >> templating system. >>>> The downside is that it adds a bit of conceptual complexity to the CMS >>>> as well as to people doing local builds as they will now need an >> SSI-enabled >>>> server to inspect their build results. >>>> >>>> The upside is that sledgehammer commits would be a thing of the past as >>>> the Django templates would rarely need to be altered directly. >> You'd just >>>> be altering individual files in content/ containing >> (markdown-converted) >>>> html fragments that the server would dynamically include into every >> page >>>> based on the SSI calls in the Django templates. >> >> I can see your vision. Each file in templates and content get converted into >> content in the staging and production repos either assembled via SSI or as >> static "sledgehammer" content. > > All I'm saying is that by adding a bit more indirection (ala a C-style > pointer) > we can get better mileage out of the CMS for everyone. So in templates/, you > no longer put any extensive html/markdown prose directly in there, just point > at it with an SSI include directive with a url path in say content/ssi/... > The prose goes in content/ssi, which can be included directly into the file > by httpd which will scan your template-generated content for those include > directives. > > Changes to lib/* and templates/* will always have widespread effects on the > generated > content and there's no way around that. But we can stabilize those files a > lot > more quickly, and reduce the need for such changes, if we can get the > ever-changing > header and footer and nav *content* back into content/ssi/* and out of > templates/*. > > Do you see more clearly how I'm thinking now?
I think so. Essentially we would move out most mdtext and html content from templates leaving skeleton.html more of a list of includes. It would totally be possible to pull almost all the changeable content out of templates and lib. How would you mix using SSI vs. static content on the staging and production servers? Or does production also do SSI? Regards, Dave
