Contribute to the development of the Core

You want to contribute to the development of the Jeedom Core ?

Here are the basics to know :

Before submitting a PR, update your alpha to verify that the bug has not already been fixed. And sync your github repository.

Check that what you are fixing does not cause other bugs. Most of the Core functions are called by different Front-End pages or by other Core functions and plugins. Do a search on the Core to see/understand where the functions are used and, if in doubt, expose the problem and your correction on Community.

Github branches

To participate in the development of Jeedom, you must have an account Github.

The Core code is Open-Source and available here.

The updates are made on these branches according to the configuration of Jeedom Settings → System → Configuration / Updates / Market.

PRs (Pull requests) should always be done on the alpha branch.

Likewise, in order to participate in discussions on Community, register as a developer : Jeedom dev.

Development

To help the development of the Core, you must master one or more of the following languages:

Knowledge of the Linux environment is also desirable.

Core tree

The code is distributed in different directories at the root of Jeedom (by default : /var/www/html) :

Front-end

Jeedom’s interface works like a website, from php interfaced with SQL and js / CSS.

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

Desktop

Jeedom’s interface works on the One-Page principle. Once loaded, the different 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_pageContainer div. This will also load the file / desktop / js / dashboard.js including the js functions specific to the display of this page (here, the Dashboard).

The / desktop / php / index file.php also takes care of :

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

So, the index files.php and utils.js provide the basic structure and functions of the interface. Then the content of the called page is loaded from desktop / php / page.php and desktop / js / page.js. These content files, purely interface oriented, can access Core functions (/ core / class classes) directly in php, or in js thanks to js classes ( / core / js) through ajax calls (/ core / ajax).

The internal functions of the Core are thus well separated, for internal operation (Back-end), but are accessible through the interface. Likewise, each page has its own php and js code. This allows you to better develop and maintain the code, but also to optimize performance by loading only the necessary classes and functions.

Core v4.2

Since Core v4.2, all js functions from desktop/common/js/utils file.js are isolated in a namespace jeedomUtils{}. For example, the function previously in the root window loadPage() becomes jeedomUtils.loadPage().

For reasons of backward compatibility for plugins, old functions are still declared and will be deprecated in a later version. See the list here.

Core v4.3

Continuing from version 4.2, the desktop front-end pages have been isolated to avoid referencing variables and functions in the root window. This secures against possible declaration collisions and makes the code easier to read, understand and debug.

The core/js/jeedom.class file.js declares 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 example for desktop/js/corepage.js :

"strict use"

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 namespace of the page will therefore not be recreated on return to this same page. Moreover, the variable jeeP allows to use jeeFrontEnd.corepage with a short syntax, it corresponds to a page-specific self.

jeephp2js[}

Used to pass variables from a php script to the js front-end. For example :

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

Puis

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

The jeephp2js{} namespace is emptied on page change to avoid any unexpected residual variable.

Mobile

The Desktop interface is responsive and adapts to the size of the browser. However, some things, like editing a scenario, would be complicated on a small screen. In addition, on a smartphone outdoors, in 3G or even 4G, it is important to optimize the speed of the display. This is why Jeedom has a Mobile interface, lighter and adapted to small screens.

The referring page is / mobile / html / index.html, which takes care of :

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

As for the Desktop interface, the page called consists of two files :

A notable difference in Mobile is the absence of php pages. The code generation is therefore based on the js classes, which can always call Core functions with ajax calls.

CSS files

Core CSS is mainly based on these files :

Themes contain CSS specific to each theme, including colors.css.

CSS loading order in Desktop :

Back-end

Running

The interface is one thing, but of course your Jeedom is always active, in order to run scenarios, crons, logs, histories etc.

The Back-end is based on the same php classes as the Front-end, present in / core / class /. Each part of Jeedom has its own php class, in particular :

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.