Skip to main content
Home  ›  Docs › App Explained

Apps - the new way to create simple modules

Warning ⚠️: New Docs Available

These are old docs and we haven't found the time to completely move them. You will find comprehensive new docs on docs.2sxc.org.

Introduced in Version 06.00.00

This is a new feature which works as follows

  1. Inside each portal you'll find a folder called "2sxc"
  2. Each app has another folder inside that - which could be called anything like "Gallery"
  3. The main system Content is also treated like an app, it resides in .../2sxc/Content/

The system already works in the database but the UI is still missing and should be delivered in v. 05.05.xx or 05.06.

Some more features/functionalities to understand

  • Apps have own Content-Types, own Entities etc.
  • They share the language configuration of the Zone that they are in (so enabling languages in a portal enables it on all Apps in that portal).
  • You will be able to install an App multiple times. By this you can...
    • Install a News App
    • Modify it to become your customized Photo-Blog
    • Install the News-App again, but with a different name
    • ...and use that App without modification as your News-App
  • The System will allow Admins (without Host-Permissions) to add Apps which don't contain server code (Token/JS-only Apps)
  • Deleting an App removes everything...
  • ...so it should be easy to install an App, try it, and kill it again if you don't like it - just like with the iPhone :)

The quick-install-catalog http://2sexycontent.org/apps 

To enable this, new Data-Suppliers are needed, amongst others:

  1. App - for [App:Path] or @App.Path etc. for tags like <img src="[App:Path]/images/logo.gif" />
  2. App Setting for the configuration - [AppSetting:{title from the settings-entity}] or @App.Setting.EnableRetina
  3. App Resource for Multilanguage resources - [AppResource:Sort] or @App.Resource.Sort

What are Apps for?

  • Bundle things into logical units
  • Redistribute your (more complex) work
  • Standardize the way we create functionality in DNN (using MVC-patterns) - allowing quick redistribution, multilanguage, etc.

What's with the App-Guid and should I reset it?

Each app has an unique ID across all systems. For example, the blueimp App has an ID like "bc0d9887-6214-48dc-bcf7-16bfc4597c71". These long, random-looking IDs are called Guids and are generated in a way that the number should be unique across the world. This helps in various cases - for example when you install the blue-imp app there is a gettings-started-page shown and it needs this GUID to identify which App it should show infos about. It will also be used in the future to tell users if there is an upgrade for their App and more. 

Reset the Guid ONLY when you have a tutorial/demo/template App

In general when you export-import Apps you want to keep the Guid just like it is - because it's the same App, maybe just different versions. But there is one case where you want to set the Guid back to 0000... This is the case with template-apps, which will be installed and modified to create different Apps. For example, a "Learn AngularJS-App" will often be installed and modified a few times to become a real-app - and should then have an own GUID. The way to ensure this is that the template-App should have an empty 0000-ID, because then every time someone installs this app, that copy will get a new GUID. 

Don't reset the Guid in any other case

If you have other reasons to reset the Guid - don't. You're breaking a identity-information which will result in a working app, but any copies of the app will never be linked to the original set any more - so various management features (like security warnings, upgrade-infos etc.) will fail in the future. 

How to show the right Infos/Getting Started if the GUID has been changed?

Even a template app should show a good Getting-Started when installed, which would fail if the GUID had been reset. So there is a setting in each app called the Original Guid. If this is set to the ID the App has in the catalog (the original ID) then new installs - which have a new guid - will still show the getting-started etc. from the old app. This is also important because it allows us to add security warning or something for this specific app if ever necessary. 

History

  1. Added beta in 05.05
  2. Stable in 06.00