Global Project Linking - How to avoid double imports?

[Lydia]

I have 3 projects A,B,C.
1) A is the 'big master' containing some general css, cover pages, page layouts, etc.
2) B and C hold mainly content. They import from A.The import is fine here.
3) Occasionally C imports also from B. This gives problems.

If 3) occurs it can be that stuff that came from A into B is then imported from B instead of directly from A. I want to avoid this situation. How can this be set up? I just can't get the logics and/or logistics right here.

Before you throw a general "use conditions" at me - I'm using conditions already, but this does not work out so far. So, if you say conditions, please specify how to use them and where. Remember - when importing files the conditions will be imported with them and I cannot (without breaking stuff) apply a different condition to an imported file.

[ChoccieMuffin]

Ah, I sympathise and have had the same problem that I think I've solved. Yes, the answer is to "use conditions", and here's what I've done.

My generic project that gets imported into everything is called Globals. I don't apply conditions to any of the stuff in there because it all goes into everything. Content in the Globals project is not just dumped in the \Content folder, but in a named folder (This does mean that some of my target projects have stuff they don't use, but I can live with that.) Because I ONLY use Master Pages, Stylesheets etc from the Globals project I don't bother putting them elsewhere. This project also contains a condition tag set, globals.flcts.

I have another project, let's call it XLR, which is a standalone project that imports stuff from Globals using an import file. This project also contains a condition tag set, XLR.flcts, which contains the conditions XLR, PP and G. It also has relationship tables in the Advanced folder and various TOCs in the TOC folder.

I have a couple of other projects, let's call them PP and G, which import stuff from Globals and also different sets of stuff from XLR.

Now we get to the conditions, and also the folder structure in Content Explorer (which I find helps me to see what's been imported from where when I'm looking in PP and G projects - they have lots of other projects they take stuff from as well as XLR so it's important to me to recognise what's what.)

In my XLR Content Explorer I have several folders - XLR shared (topics used in both PP and G), XLR PP (topics used in PP only), XLR G (topics used in G only), XLR shared images, XLR PP images and XLR G images.
Topics and images in XLR shared (and XLR shared images) are conditioned with XLR.XLR, stuff in PP is conditioned with XLR.XLR and XLR.PP and stuff in G is conditioned with XLR.XLR and XLR.G.
In the Projects folder of XLR, relationship tables and TOCs that are needed in PP and G are all conditioned with XLR.XLR and possibly also with XLR.PP or XLR.G if they're only needed in one of the projects.
Note that I do NOT apply any conditions in XLR to any of the topics or other files that were imported from Globals.

In PP, I have the same globals.flimpfl file as in XLR. This imports everything (except stuff from the Advanced, Destinations, Exports or Reports folders) from the Globals project.
I want to import everything conditioned as XLR.XLR on its own or XLR.PP but not anything that's conditioned as both XLR.XLR and XLR.G so I also have XLR.flimpfl with the following import conditions in the Import Conditions box:
include[XLR.PP or XLR.XLR and not ( (XLR.XLR and XLR.G) )]
and the Auto-Exclude Non-tagged Files check box is selected.

To get these conditions you have to use the Advanced conditional text editor, which unfortunately isn't exactly the same as what you end up with: in the Conditional Text Editor, type XLR.PP or XLR.XL and not ( (XLR.XLR and XLR.G) )

In the G project the conditions are turned round.

Because you haven't applied any conditions in the XLR project to any of the stuff imported from Globals, they don't get imported when you import stuff into PP or G from the XLR project.

That should give you plenty to play with, hope that helps.

[NorthEast]

Before you throw a general "use conditions" at me - I'm using conditions already, but this does not work out so far. So, if you say conditions, please specify how to use them and where. Remember - when importing files the conditions will be imported with them and I cannot (without breaking stuff) apply a different condition to an imported file.

I use conditions for this, and I'd suggest setting up the project imports as follows.

1) In the 'big master' project A, set up a condition 'master', and apply that to all files that are shared by all your projects (CSS, page layouts, etc.)

2) In all projects that import files from the master project A (i.e. B and C), set the up the project import with the settings:
- Include files: All Files (*.*)
- Import conditions: include[ConditionFile.Master]
- Tick Auto-Exclude Non-Tagged Files

3) If you have projects that import content from each other, e.g. C imports files from B, set up that project import to:
- Include files: (whatever you want)
- Import conditions: exclude[ConditionFile.Master]


So, for your example, project C would have:
- An import from project A, that only includes files marked with ConditionFile.Master.
- An import from project B, that includes whatever files you want, but will exclude any file marked with ConditionFile.Master.

[Lydia]

What a swirl of information! Thank you so much for your insights.
The main lesson learned (for me) is that I either have to use a "General" condition on the stuff I import from the general project or I use no condition at all. That way I can exclude imported files from being imported by the next level import.
Now I'm using a number of conditions in the general project, but not all files are tagged. It is getting too complicated to build the logics, even when using the Advanced editor.
BTW- I'm also using folders to seperate stuff like General, Product Part A, Product Part B. Makes it indeed easier to track down stuff.

[ChoccieMuffin]

Does your General project ever get built as a project in its own right? As in, does it contain stuff that is not needed in any other projects? If this is the case, I suggest you split out the project-specific stuff into a separate project and leave the truly global stuff in a project that is only ever used for importing into other projects. That way your main source project (my Globals project) doesn't need to have any conditions applied to its files, making it a bit easier to use import conditions for other projects.

[Lydia]

Well, I use the general project to try out the layouts/styles etc, so there is some testing stuff in there. This gets build every now and then and it something I don't want to import somewhere else.
You're right, it is a good idea to move that out to a playground project or so. Until now this wasn't too important and time was an issue.

[Robotman]

1) In the 'big master' project A, set up a condition 'master', and apply that to all files that are shared by all your projects (CSS, page layouts, etc.)

I've been using GPL for a while now and was just wondering why you recommend the above? Is this purely a visual cue for when the files are imported into the child project or is there another reason for doing this? Is it to keep a tighter control over which files are imported?

Thanks, Dave. Really appreciate your contributions to the forum.

[NorthEast]

1) In the 'big master' project A, set up a condition 'master', and apply that to all files that are shared by all your projects (CSS, page layouts, etc.)

I've been using GPL for a while now and was just wondering why you recommend the above? Is this purely a visual cue for when the files are imported into the child project or is there another reason for doing this? Is it to keep a tighter control over which files are imported?

For both reasons.

It's mainly so that I can control which individual files are imported from the master project. I set up the import to include the 'master' condition, and exclude non-tagged files.

When it's set up like this, you can change which files are imported into all projects just by setting the 'master' condition on that file in the master project - you don't have to make changes to import settings in individual projects.

It also makes it very straightforward to set up the import file in new projects too; I didn't want to use complex settings for the import file, as this could lead to inconsistencies between imports in different projects.

I also colour the 'master' condition, so it's obvious which files in a project come from the import.

[deeptikorwar]

Thank you for share. I am experiencing similar problems and after reading this...looks like I have to redo the master project files into appropriate folders and set up all conditions.