Is it possible to copy a section from doc 1 and paste it to doc 2? Say you had a library of pre-built components that were sectionalised and wanted to add those to docs as needed. Thanks.
Ctrl+A, Ctrl+C, Ctrl+V.
i.e. just select all content in the section of doc A and copy-paste it into a section of doc B. Should preserve links between components.
Ahh right, yeh as in the section inline content on the doc right? Is it possible to copy at the section level though? This is a workable workaround however
AFAIK no, not at the moment. But copying section contents will copy all tables and formats and data as well.
Just an idea, don’t have the chance to test.
What if we have such content in a Gdoc with the ability to import it over and over
As earlier requested, it would be great to make your own templates
This is an unfortunate limitation of Coda, but I suspect it is temporary. The issues and observations with building a seamless (Coda-native) management system …
- Ideally, makers should be able to build a library of boiler-plate content fragments in Coda, even small snippets that can be added to other Coda documents arbitrarily. Indeed, a drag and drop of snippets onto document registry in a table that updates the drop targets. If Packs were open, I’d build something like this tonight.
- Coda currently provides no event handlers to make a drag-and-drop experience possible, although, something clever with buttons might suffice if other issues are overcome.
- Coda does not currently support an HTTP POST action making this possible (i.e., posting the section fragment to a NodeJS service that updates the target document/section).
- The Coda API should support GET/POST of section content as it does table/row/field content. This would also allow in-place transformations and insertions.
This is actually possible now (and automatically) and all without using the new doc importer. It requires some abstraction and content management infrastructure external to Coda. You can even use rich-text formatting or Markdown if you pre-process the content with a Markdown transformation.
There are huge advantages to this approach and I’ve employed it with two clients thus far. One even uses a few integration services to extract and use content from other systems.
- Build all your section/snippet texts in Google Docs (discrete naming convention is required - these are “objects”)
- Establish a snippet registry in a Coda doc; this will contain a list of all of the snippets under management in Google Drive (or a sheet).
- Establish section and even paragraph or sentence-level formula placeholders in a Coda document template that pull from the registry.
- Update the snippet registry from GDrive to Coda using the API and Google Apps Script.
- Updates to the registry from Google should be performed using the Google Apps Script event handlers so changes are near-real-time.
- Create a streamlined process for Makers to “assign” the value of any snippet to any document placeholders; now, your Coda templates and even new Coda documents can render snippets dynamically and fully formatted.
CAUTION - there are numerous formatting, font management, and wrapping issues that abound with an approach like this but it works really well if you leverage the automation possibilities and define a clear process and formatting guidelines for your team.
@Bill_French why use Google Docs for this and require the API and Google Apps Script when Coda could just have a table? Some advantage I’m not seeing for all that overhead?
It’s a good question and I think you could implement this idea natively in Coda with some effort. I tried exactly that approach early on with poor outcomes, perhaps because Coda was an earlier version and/or I just stink at building complex formulas.
But the challenges become more apparent as soon as you try to author all your snippet and section content in table cells. It’s very tedious work. Your decision to build, manage, and preprocess your content library external to Coda will be gated by the volume, reuse patterns, and formatting you (and your team) engage in.
There are a variety of non-productive aspects that emerge in this content development process including – but not limited to – these four points (there are about a dozen reasons in all).
#1 Productivity, Collaboration, and Flexibility
We can probably all agree that your content should be freely authored and maintained in a word-processing environment. In-so-doing, you will become dependent on the document editor to wrap sentences, apply formatting styles that are not available in Coda cells, perform spell and grammatical checking, etc. Then there’s the concurrent editing requirement along with commenting about specific words and sentence fragments, a granularity that is ruled out in a table cell.
All things considered, you need an environment where you can carefully preprocess the text to shape it for inclusion into a document via formula. Perhaps you haven’t noticed, but formulas dump text from cells without any regard for line-length formatting. Sure, you might be able to use formulas and wrangle some level of control, but not like you can in a scripting language.
#2 Blending Text and Data
In many cases, you may want to pull data into your text. This is one of the cool features of Coda - the embedding of formula results into text. You lose this capability when you abstract content by reference through formulas. The only way to overcome this - given the design constraints - is to perform an early-binding of the data with the content via the API.
#3 Inclusion by Reference, Not by Value
There are cases where content item (a) may need to include and embed content item (x) because content reuse sits at the pinnacle of a well-designed model for sustainable and maintainable resources. A powerful preprocessing step makes this possible, whereas it becomes prohibitively complex in native Coda formulas.
#4 Integration Agility
Content resources are extremely important in some organizations and such that they typically do not get built for one purpose. Ideally, you want to build a CMS solution that can engage with many services - not just one document-centric system like Coda.
By building your content snippets and preprocessing logic external to Coda, you can surround this resource with many services such as AI, NLP, ML, lookups, web-scapring, etc. Additionally, you can use the same system to support content rendering in platforms that do not have the same technical formatting requirements that Coda has.
@Bill_French great points. I understand now how that would provide much more flexibility which is paid by the setup. Its cool to see you lead the way in what can be done technically - Coda is listening and learning from the examples from the community here.