Skip to main content
Home  ›  Docs › Feature

Sharing App Parts (Views, Content-Types, Assets)

Introduced in Version 02.00.00

There are cases where certain parts of an app should be shared across multiple zones / portals. Here are the most common options.


Things you may want to share are:

  1. Views / Templates
  2. Assets like JavaScripts, CSS-Styles, Images, Fonts and similar resources
  3. Content-Type definitions
  4. Content-items / data
  5. The entire App as is
  6. The entire App but without unique content-items per portal

Before we Start

Remember that shared resources only really make sense if the designers/developers have superuser access (aka Host) to all systems. Otherwise you'll have a lot of overhead to coordinate who and how changes will be applied. 

Shared Views / Templates

This is very common. Basically each App hat its views in this folder:

  • [current-portal]/2sxc/[app-name]

You can also store views in this folder:

  • [default-portal]/2sxc[app-name]
    which usually maps to
  • /Portals/_default/2sxc/[app-name]

IF the current user has super-user permissions, then he can select or create template-files in the shared folder - in the UI like this:


If the user is not a super-user, then the second dropdown will stay empty, and you won't be able to create any files in the shared locations. 

Shared Assets

Using shared assets would be things like

  1. JavaScript files
  2. Fonts, icon-fonts and images
  3. CSS styles
  4. src stuff like LESS, SASS, Gulp, Grunts etc.

In the normal case, you would usually use the [App:Path] or @App.Path to point to this file, but in the shared case, this doesn't work and doesn't make sense, since the folder doesn't change from portal to portal. 

So in these cases, you should use the fixed address in your scripts, without placeholders. 

Shared Content-Type Definitions

This is a very advanced topic and is handled with Ghost-Content-Types. Read more about them in this blog post.

Shared Content-Items / Data

There are a lot of ways you may want to share your data, and a lot of solutions for each need. I'll write more about it some day, but if you're in a hurry, google it or post it on stackoverflow.

Sharing the Entire App with all Data

This is not documented yet, and there are various options. Probably the easiest way is to simply show the module from Portal 1 on Portal 2 and you're ready to go. 

Sharing the Entire App but without the Content = Ghost-App

This has been a wish for a while but is not implemented yet. There's a fairly nice workaround to do it in the meantime, as follows:

  1. Create your primary app which will be the master - let's call it "Showcase Master". Add all templates and assets to the shared repository. 
  2. In another portal, create an app which is to be the ghost-app, let's call it "Showcase"
  3. In this new app, add all the content-types of the master as ghosts of it's content-types, so changes in the original content-types are always mirrored. 
  4. in this new app, add a definition to all templates (also pointing to the shared repo)
  5. This new app is now basically a ghost-app of the master, and will automatically reflect modifications to the content-types. The only things missing are that new-content-types must be added manually, and new templates as well.
  6. You can now export this ghost-app "Showcase" and re-install it in all other portals
Loading Comments...