Sharing the master stylesheet between projects?

[Centauri27]

I have three help projects all using the same master stylesheet. As these project were created at different times, I ended up with three copies of my master stylesheets. Keeping them all synchronized is a bit annoying when I tweak a stylesheet. Is there a way for each Flare proiject to use a stylesheet from a common location? Right now, it appears that the .css file must be located in the Contents\Resources\Stylesheets folder to be recognized.

Thanks.
Carl

[NorthEast]

For our projects, I use a project import for this (also called global project linking).

I have a 'master' project with all my shared elements (stylesheet, table styles, page layouts, etc.), and I import the files from this into all my projects. So I just make any changes in the master project, and they're updated in all my projects after a re-import (which you can do automatically or manually).

[ccardimon]

What magic must be performed before we attempt to link our projects and stylesheets globally?

[Nita Beck]

What magic must be performed before we attempt to link our projects and stylesheets globally?

First, set up the global/parent project that will contain the common items. Besides the stylesheets, you might want also to include page layouts (for print output) and master pages (for Help output), images such as your company logo, and boilerplate contents such as logal notices, either as whole topics or as snippets. You could even have a common skin (and the toolbar button images that go along with it) if all of your Help projects have the same look-and-feel.

Then, in each of the local/child projects, create an import file and specify that first project as the source of the imported file. Also specify which types of files you want to import (likely any type from the global/parent project). Then run the import to pull in those files. After they are imported, you'll notice a little "chain link" image beside each in the Content Explorer, the Project Organizer. This indicates that said files are imported from elsewhere. If you ever try to edit any of them within a local/child project, you'll be prompted to break the link in order to continue editing, if you decide to continue.

I hope this is enough to get you started...

[Centauri27]

First, set up the global/parent project that will contain the common items ... I hope this is enough to get you started...

This procedure appears to be geared toward creating new child projects off a parent project--will it work for hooking up three well established projects?

Life would be much easier if Flare simply allowed you to browse for the master stylesheet rather than forcing you to choose from a fixed dropdown list.

[ccardimon]

First, set up the global/parent project that will contain the common items ... I hope this is enough to get you started...

This procedure appears to be geared toward creating new child projects off a parent project--will it work for hooking up three well established projects?

This is what I should have asked. I have a ton of well established projects that I'd like to link together using the same stylesheet at least. Can global project linking be used for this?

[LTinker68]

This procedure appears to be geared toward creating new child projects off a parent project--will it work for hooking up three well established projects?

There is a difference between project linking that Dave and Nita were talking about and actual parent/child projects -- ones that are merged together at build time. Do you want to use the same stylesheet in three projects (project linking) or do you want to merge the three separate projects into one output to be delivered to the customer?

Life would be much easier if Flare simply allowed you to browse for the master stylesheet rather than forcing you to choose from a fixed dropdown list.

But think of how much more streamlined it is having the stylesheet in the project itself. Project linking actually imports a copy of the stylesheet into your project. If you didn't have the stylesheet in the project -- if the stylesheet existed in a folder on a different drive -- then a lot of Flare's processes would be slowed down because it would have to travel the network to do its tasks. For instance, if you wanted to apply a style -- Flare would have to travel the network to get the list of styles to populate the Styles pane and drop-down list, and if you switched from a paragraph to a list then it would have to rerun the query to change the styles listed. Even just doing the WYSIWYG in the XML Editor would require it to go over the network to get the styles to set up the display. And that's assuming you have one writer doing the work.

[ccardimon]

I want to use the same stylesheet in different projects that are already established.

[Centauri27]

Yep, me too.

But Lisa does raise a good point about allowing Flare fish information from a remote stylesheet. I seem to recall earlier versions of RoboHelp having horrible performance problems when certain resources were on a network drive. Don't want to go there again. Maybe in the end, the current method of remembering to manually update the stylesheets in each directory may prove to be the most straightforward solution after all.

Carl

[ccardimon]

Well...pooh. That does sound sensible.

[Centauri27]

Yeah, just get one of those dual-pane Explorer replacements and just drag'n'drop the stylesheet. I don't think Flare offers any other easy alternatives. Project import is not the solution.

[ccardimon]

get one of those dual-pane Explorer replacements

Cool. I got EF Commander Free. Maybe that will work.

[LTinker68]

Project import is not the solution.

If you mean project linking, then it is an option, it just changes how you think about things. Nita has a good write-up somewhere about how she uses the project linking, but I couldn't find the post. Nita, could you add a link to it?

Basically, she has her "master" project where she has a stylesheet and other items that are common across all her projects. When she creates a new project (or modifies existing projects), she links to the common items in the master project. Doing so imports the items into the new project, but locks them so you can't edit them in the new project. I believe it warns you if you try to modify them, so you remember to modify the file in the master project. I believe the only downside is that it's not an active link. That is, if you make the change in the master project you have to re-link (re-import) the file into the child project. I would hope it would do that automatically at build time, but if you make a change in the master then you wouldn't necessarily want to have to build the project just to relink to the modified common file.

[Nita Beck]

There's not really the performance issue that someone wrote about earlier in this thread. The child project imports a COPY of the master stylesheet, so there's no slowdown in building the style selection lists, once it's imported that is. And Lisa's right: If you try to edit the COPY of an imported file in a child project, Flare will warn you. You can either abandon trying to edit it or break the link and edit it or... some third option that I can't think of right now.

Regarding having the child project updated with the latest stylesheet (and other items from the parent project), I make it a best practice that, upon starting to work on a given child project on a given day, I open the import file and manually reimport everything. But just to be on the safe side, I also have Flare automatically reimport linked stuff from the parent whenever I build a target in the child project.

Regarding a link to my previous musings on global project linking, I'll go look that up and get back to y'all.

OK, I'm back:

I found two of my posts that might be helpful:
http://forums.madcapsoftware.com/viewto ... =6&t=10206
http://forums.madcapsoftware.com/viewto ... 75&t=10723

[Nita Beck]

This procedure appears to be geared toward creating new child projects off a parent project--will it work for hooking up three well established projects?

Of course you could use this procedure for established projects, though you'll need to do a little "re-engineering" of those projects.

For my first Flare project for one of my clients, I created a standalone project. That's where I developed the early instances of things that eventually I knew I would use for other of this same client's projects. But I just had one project to start with.

Later, when I was about to start project B, I first created a global project and moved to it the "common" things from project A, things like the stylesheets, the page layouts, legal and other pub language, variable sets, conditional tag sets, snippets, images, topics, and so forth. Then I created project B and included an import file that would pull in those common things.

At the same time, I also had to go back to project A and "re-engineer" it so that it too had an import file that would pull in those common things, rather than having those things reside locally.

Hopefully, I'll soon be migrating this client's products C, D, and E's documentation to Flare, and for each product I'll have a separate child project that uses the same batch of common stuff from the global project.

My guiding principle in using Flare is to design my projects such that I have just one instance of any given thing to maintain. For instance, I have just one master stylesheet for PDF outputs, just one instance of the client's corporate logo, just one set of page layouts, etc. Global project linking has given me those maintenance efficiencies.

[SteveS]

I remember asking this question way back in Flare 1 days...

Unfortunately no-one came up with a viable alternative and I managed my 'common' files using a spreadsheet. If I changed something I'd then hunt down all other places the file was used and manually update all instances. What a pain.

The only shining light is the more 'mature' stylesheets become the less likely they need tweaking...

I use project linking to maintain this sort of thing now, but I'm not using Flare to the same extenty as I was back then. I've set the import to update every build to make sure I'm using the latest version of the common files. It seems to work fine, but I'm not pushing the boundaries with it.

The disadvantage with something that does a seek and change on a hard drive for files with the same name (ie stylesheets) is the sheer number of stylesheets it will find, remembering they will be in your browser cache, temp files, project files, builds, targets, and (probably) recycle bins. All the seek and change programs I liiked at list the matches and ask you to select the ones you want to overwrite.

[ccardimon]

Later, when I was about to start project B, I first created a global project and moved to it the "common" things from project A, things like the stylesheets, the page layouts, legal and other pub language, variable sets, conditional tag sets, snippets, images, topics, and so forth. Then I created project B and included an import file that would pull in those common things.

How do we "move" stylesheets and page layouts into "Project Global?" Is this a copy and paste job?

[Nita Beck]

How do we "move" stylesheets and page layouts into "Project Global?" Is this a copy and paste job?

Yes, it's that simple, at least for getting things into the global project. But be sure, back in what will now be a local project, to remove those items; and, yes, that'll break whatever links to have to them (and you may or may not want to remove the links... keep reading). In that local project's import file, you'll specify that you want to import the global versions of those items. Depending on how you set up the import file, Flare might import them back into the exact same location, so those links should then work again.

ACTUALLY, let me contradict myself. I bet you don't even have to remove the items from the local project, provided that you plan to put the imported global items into the exact same place in the lcoal project. I bet that Flare will just overwrite them with the global items, and you're good to go. (I haven't tested this myself, though! Check out carefully first!)

Start slowly. "Move out" just one or two items to your global project. Then create your local import file to pull these items back in. Once you're satisfied with these, "move out" some more items to the global project and update the local import file to pull those items back in.

[ccardimon]

I bet you don't even have to remove the items from the local project, provided that you plan to put the imported global items into the exact same place in the lcoal project.

So far, so good. I know how to include stylesheet files (*.css), but how do I exclude everything else for now?

[Nita Beck]

If you know how to import the stylesheets, then you know how to import the other items. It's the same process.

I assume you created an import file in your local project that would import the .css file(s) from your global project.

Now let's say you want to import snippets and variable sets. In the local project, open the import file. In the Project Import Editor, click Edit next to the Import Files field. Select Snippet and click Add. Then select Variable Set and click Add. Click OK to save and return to the Project Import Editor. Now click Reimport to import those additional items. (The stylesheets will also be reimported.)

Just repeat this process to import files of other file types from the global project.

[ccardimon]

Do you use one import file for everything (and keep adding to it), or do you create a new import file for each item you import?

[Nita Beck]

I would have just one import file and keep adding to it. That way, once you get your import rules all set up the way you want them in local project A, you can literally cut and paste (though perhaps through Windows Explorer, not Flare; can't remember) that import file into local project B, local project C, and so forth.

[LTinker68]

Plus you then have just one import file you need to update before building the output instead of multiple import files.

[ccardimon]

Many thanks, Nita and Lisa. Your suggestions make sense. I will do as you recommend.