Core development

Tree structure

The code is spread across various directories in the Jeedom root directory (/var/www/html default):

Front-end

The Jeedom interface works like a website, built using PHP integrated with SQL and JavaScript/CSS.

Initially, the browser loads the file /index.php :

Desktop

The Jeedom interface operates on the “One-Page” principle. Once loaded, the various pages are displayed by changing the content of a container.

The main file in Desktop is /desktop/php/index.php.

Each page has at least two parameters in the URL. Example:

https://my.dns1.jeedom.com/index.php?v=d&p=dashboard :

In this case, the file /desktop/php/index.php will load the file /desktop/php/dashboard.php in the div div_pageContainer. This will also load the file /desktop/js/dashboard.js including the JavaScript functions specific to the display of this page (in this case, the Dashboard).

The file /desktop/php/index.php also handles:

The file desktop/common/js/utils.js is therefore always present and loaded once. It allows you to:

Thus, the index.php and utils.js files provide the basic structure and functions of the interface. Next, the content of the requested page is loaded from desktop/php/page.php and desktop/js/page.js. These content files, which are purely interface-oriented, can access the Core’s functions (the classes /core/class) directly in PHP, or in JavaScript using JavaScript classes (/core/js) using AJAX calls (/core/ajax).

The Core’s internal functions are thus clearly separated for internal operations (back-end) but are accessible via the interface. Similarly, each page has its own PHP and JavaScript code. This makes it easier to develop and maintain the code, while also optimizing performance by loading only the necessary classes and functions.

Core v4.2

Starting with Core v4.2, all JavaScript functions in the file desktop/common/js/utils.js are isolated in a namespace jeedomUtils{}. For example, the function previously in the root window loadPage() is becoming jeedomUtils.loadPage().

For plugin backward compatibility, the old functions are still declared and will be deprecated in a future version. View the list here.

Core v4.3

Following on from version 4.2, the desktop front-end pages have been isolated to avoid referencing variables and functions in the root window. This prevents potential declaration conflicts and makes the code easier to read, understand, and debug.

The file core/js/jeedom.class.jsdeclares two new namespaces:

jeeFrontEnd

Some global variables are now in this namespace:

jeeFrontEnd = {
  __description: 'Global object where each Core page register its own functions and variable in its sub-object name.',
  jeedom_firstUse: '',
  language: '',
  userProfils: {},
  planEditOption: {state: false, snap: false, grid: false, gridSize: false, highlight: true},
  //loadPage history:
  PREVIOUS_PAGE: null,
  PREVIOUS_LOCATION: null,
  NO_POPSTAT: false,
  modifyWithoutSave: false,
  //@index.php
  serverDatetime: null,
  clientServerDiffDatetime: null,
  serverDatetime: null,
  serverTZoffsetMin: null,
}

Typical type for desktop/js/corepage.js :

"use strict"

if (!jeeFrontEnd.corepage) {
	jeeFrontEnd.corepage = {
		myVar: 'oneVar',
		init: function() {
			window.jeeP = this //root shortcut
		},
		postInit: function() {
			//Do stuff once page loaded
		},
		myFunction: function(_var) {
			var myFuncContextVar = this.myVar + ' -> ' + _var
			console.log(myFuncContextVar)
		}
	}
}

jeeFrontEnd.corepage.init()

$(function() {
  jeeFrontEnd.corepage.postInit()
})

$('#myButton').on('click', function() {
	jeeP.myFunction('test')
})

The page’s namespace will therefore not be recreated when returning to this same page. Additionally, the variable jeeP allows you to use jeeFrontEnd.corepage with a short syntax; it corresponds to a self specific to this page.

jeephp2js

Used to pass variables from a PHP script to the front-end JavaScript. For example:

sendVarToJS([
  'jeephp2js.myjsvar1' => init('type', ''),
  'jeephp2js.myjsvar2' => config::byKey('enableCustomCss')
]);

Then

$(function() {
  if (jeephp2js.myjsvar1 == '1') { ... }
})

The jeephp2js{} namespace is cleared when the page is refreshed to prevent any unexpected residual variables.

Mobile

The Desktop interface is responsive and adapts to the browser window size. However, certain tasks, such as editing a scenario, would be difficult on a small screen. Additionally, when using a smartphone outdoors on a 3G or even 4G connection, it’s important to optimize loading speed. That’s why Jeedom has a Mobile interface, which is lighter and optimized for small screens.

The reference page is /mobile/html/index.html, which handles:

The file mobile/js/application.js contains the functions common to all pages.

As with the desktop interface, the page being called consists of two files:

One notable difference in the mobile version is the absence of PHP pages. Code generation therefore relies on JavaScript classes, which can still call Core functions using AJAX requests.

CSS files

The Core’s CSS files are primarily based on these files:

The themes contain CSS files specific to each theme, including colors.css.

CSS loading order on desktop:

Back-end

in progress

The interface is one thing, but of course your Jeedom is always active to handle scenarios, cron jobs, logs, history, and so on.

The back end uses the same PHP classes as the front end, located in /core/class/. Each part of Jeedom has its own PHP class, including:

etc.

Nous utilisons des cookies pour vous garantir la meilleure expérience sur notre site web. Si vous continuez à utiliser ce site, nous supposerons que vous en êtes satisfait.