Hosting Common Content (Skin, Stylesheet, etc.) Separately

[LawvL]

Hi folks,

My dev team has struggled to understand Flare and the way it builds outputs. Getting them out of an individual page help mindset has been a challenge. Of all the places I've worked and used Flare, I've never had this much trouble working with dev to implement help.

The latest question I've received is about the potential to separately host common/shared content (the skin, stylesheet, etc.) from application-specific content (the individual topics, TOC, etc.). Has anyone ever done something like this for their online help?

The concern from dev is that, if we implement this design but then want to make changes in the future, we'll need to update the design within every application. They want to be able to update it once and have it change everywhere.

I understand their concern, but they don't seem to understand me when I explain the design would update for an application each time we made a change to the documentation for that application, which would likely be every few months at a minimum.

All that said, should I be telling them this flat out isn't possible within Flare? Or has it been done before?

Thanks!

[Dave Lee]

I handle it this way:

1) Create a separate 'master' project that contains any common resources that may be used in all projects - e.g. stylesheets, skins, master pages, page layouts, snippets, scripts, etc.
2) In the master project, mark all these common files with a condition, e.g. Template.Common.
3) In your regular projects, create a Project Import. Set up the import to get files from the master project. Choose to import all files (*.*). Set the conditions to include Template.Common and auto-exclude non-tagged files (so it only imports files with that condition).

Then when you change files in your master project, you can open the regular projects and do a reimport to get the updated files. If you don't want to manually reimport, you can set the target to automatically reimport (auto-sync) each time you do a build.

The trick is to try and set things up so that none of these imported files will need to be edited in your regular projects, because these files will be overwritten when you next reimport from the master project.

[doloremipsum]

@Dave Lee, I think the question is about hosting the *output* files in separate locations, rather than global linking the input...

I suspect it's possible, but you'd probably have to do lots of find/replace as part of the build process to make sure, for example, all of the topics referenced the stylesheet in its new web location instead of Flare's build location. If I were you, I'd turn it back on them and say they'll need to program the 'splitter' tool themselves.

[Dave Lee]

Maybe - but I read it as being source files, since a skin only exists in the source and not the output.

Besides, I wouldn't recommend attempting this with output. The files Flare generates as part of the build are not static, and what it builds in the output can vary. For example, what the CSS files contain will vary between projects depending on features that you use in topic content (it doesn't add CSS for features you don't use), CSS mediums, skin settings.

[LawvL]

Thanks all! Helpful input.

I was indeed asking about the output files, although I probably could have stated it better. I didn't think it was a good idea or something worth attempting, but for the dev team's sake I figured I'd ask. My plan has always been to use project linking as Dave described.

Dave, for my own knowledge when I discuss with the dev team, I want to better understand your point about varying output files. I'll throw out an example and maybe you can help me understand what I'm missing.

I've got two online helps: Help A and Help B. Both Helps use the same stylesheet, skin, and master page. Let's assume that, aside from the individual topics, they are using the exact same files and settings.

What you're saying is, depending on what's inside of the topic files, the output files for each Help may be different? Is this more about the underlying stylesheets and files in Flare? The behind the scenes content that I wouldn't ever touch but that's integral to the build? If so, it's pretty interesting to know those files aren't static.

[Dave Lee]

Yeah, the CSS files in the output can vary quite a lot, and it depends on several factors such as the skin settings, mediums, and the content in your topics.

When Flare builds your output:

• Your own source CSS files are present in the output, but they are modified.
  For example, if the target uses a medium, the CSS for that medium is effectively copied/pasted into the CSS (Flare's mediums aren't real media types, so they're processed at build time and not by the browser).
  
• Flare adds a lot of extra CSS files, for things like skin styles and the content used in your topics. For example, in Skins/Default/Stylesheets/Topic.css, Flare adds some default CSS for dropdowns and togglers, but only includes this if a dropdown or toggler actually exists in your topic content.

Therefore, I don't think it's a good idea to try and "share" any of the output files from two separate targets, as those output files can be different due to a number of reasons (none of which are documented). Also, bear in mind the output will change when using a new version of Flare, so it's something you'd need to constantly re-check and update.

It's much safer and easier to share common resources like skins and CSS in your project source (using project imports), and leave the output well alone. Also, MadCap will support you doing this, but not for tinkering with the output.