Project

General

Profile

Actions

Architecture #4753

closed

Extract compliance calculus from RuleEditForm

Added by François ARMAND about 10 years ago. Updated over 9 years ago.

Status:
Rejected
Priority:
1
Assignee:
-
Category:
Web - Config management
Target version:
Effort required:
Name check:
Fix check:
Regression:

Description

In 2.10 and above, the calculus of compliance for a rule (or for a node) is done within the display code (RuleEditForm mainly).

That violates any best (or even good) practices I can think of, including:

- it mixes displaying and business logic, make change in one or the other both harder and more error prone than if the orthogonal subject where actually in different part of the code (try to drive an helicopter to understand that)
- the code is not reusable, so we can't build new services using the logic (API, component using it elsewhere...)
- it's not DRY, and so bugs are jumping from screen to screen
- we can't optimize the business logic performance
- and moreover, we can't make things impossible by construction, so we spend more time checking normally impossible to reach state
- we can't evolve the business logic (for example, #4750, knowing if a set of repaired report should be "repaired" or "error" (is pure business logic, not displaying)
- we can't build the UI from a stable datastructure / service layout

So we need to:

- specify what we NEED from a compliance point of view (by rule ? by node ? bulk ? only the last one ? etc)
- specify the datastructures in use now
- split anything dealing with displaying (human name, etc) from business logic (where we get data from ? When ? How do we transform them ? What are our contracts with the caller ? What are the datastructures ?)
- refactore RuleEditForm the use the new services


Subtasks 1 (0 open1 closed)

Architecture #4815: Split logic from RuleEditForm in separate filesReleasedVincent MEMBRÉ2014-05-05Actions
Actions #1

Updated by François ARMAND about 10 years ago

  • Description updated (diff)
Actions #2

Updated by François ARMAND about 10 years ago

A plugin was done to expose compliance information thought the API: https://github.com/Normation/rudder-plugin-itop/

The file https://github.com/Normation/rudder-plugin-itop/blob/master/src/main/scala/com/normation/plugins/itop/service/ItopNodeService.scala can be a good starting point to understand what is needed to build a compliance datastructure, define vocabulary, tests, etc.

Actions #3

Updated by François ARMAND about 10 years ago

  • Target version changed from 2.11.0~beta1 to 140

That is going on it's way with the refactoring done around ruleEditForm in http://www.rudder-project.org/redmine/issues/4770.

Now, we should clean up things and normalize services and data structure around Rudder.

Retargeting in 2.12.

Actions #4

Updated by Matthieu CERDA over 9 years ago

  • Target version changed from 140 to 3.0.0~beta1
Actions #5

Updated by Jonathan CLARKE over 9 years ago

  • Target version changed from 3.0.0~beta1 to 3.0.0~beta2
Actions #6

Updated by François ARMAND over 9 years ago

  • Status changed from 8 to Rejected

This ticket is no longer needed since it was done along with the change-only refactoring. Closing as "no more relevant".

Actions

Also available in: Atom PDF