Component properties shouldn't be inlined into zul page

The high-level description with a diagram (a bit outdated) is located on Components Configuration Vision
This relates to the properties of different components of the JTalks. So at the web page you should choose Components -> Components.
At the moment we have such lines in the EditCompViewModel:

componentName = valueOf(currentComponent.getName());
name = valueOf(currentComponent.getProperty(componentType + ".name"));
description = valueOf(currentComponent.getDescription());
caption = valueOf(currentComponent.getProperty(componentType + ".caption"));
postPreviewSize = valueOf(currentComponent.getProperty(componentType + ".postPreviewSize"));
sessionTimeout = valueOf(currentComponent.getProperty(componentType + ".session_timeout"));

We have those properties inlined into the class and into the zul page. This will clutter the source code when the amount of properties become bigger, so we need a solution.
The suggested solution:

• Change org.jtalks.common.model.entity.Property class to contain private String validationRule; which will contain a regular expression pattern and add the migrations for these fields to be updated.
• In the hibernate mapping of this class you should include new information to be loaded and saved with Hibernate.
• Right now the default values of the component properties are stored in properties file. We won't have an ability to store a rule there so we'll need to move to another format. We don't want to move to XML since it will be hard to keep regexps in it (it will contain a lot of symbols not compatible with XML and you'll need to escape them). But also would be great to easily add those properties by anyone. So keeping them in DB looks as best solution. For these purposes a new table should be created (didn't check the correctness of the script):

  CREATE TABLE `DEFAULT_COMPONENT_CONFIGURATION` {
    `ID` bigint(20) NOT NULL AUTO_INCREMENT,
    `UUID` varchar(255) NOT NULL,
    `LABEL` varchar(255) NOT NULL,
    `NAME` varchar(255) NOT NULL UNIQUE CONSTRAINT,
    `DEFAULT_VALUE` varchar(255) DEFAULT NULL,
    `VALIDATION_RULE` varchar(255) DEFAULT NULL,
    `COMPONENT` varchar(255) NOT NULL VALUES IN('ALL', 'JCOMMUNE', 'ANTARCTICLE' ,'POULPE') 
  }

  Note, that ALL was added as a possible value for the configuration so that we don't duplicate rules applicable to all components (like name, session timeout). Also note, that POULPE appeared here since we actually will need to configure this app as well for administrators.
  The table for particular component configuration will look like this:

  CREATE TABLE `COMPONENT_CONFIGURATION` (
    `PROPERTY_ID` bigint(20) NOT NULL AUTO_INCREMENT,
    `UUID` varchar(255) NOT NULL,
    `NAME` varchar(255) NOT NULL,
    `VALUE` varchar(255) DEFAULT NULL,
    `DEFAULT_LABEL` varchar(255) NOT NULL,  
    `VALIDATION_RULE` varchar(255) DEFAULT NULL,
    `COMPONENT_ID` bigint(20) DEFAULT NULL,
    PRIMARY KEY (`PROPERTY_ID`),
    UNIQUE KEY `UUID` (`UUID`),
    KEY `FK_COMPONENT` (`CMP_ID`),
    CONSTRAINT `FK_COMPONENT` FOREIGN KEY (`COMPONENT_ID`) REFERENCES `COMPONENTS` (`COMPONENT_ID`)
  );
  

• Those properties that we have for JCommune already should be placed in the migration SQL scripts.
• A new class DefaultComponentConfiguration should be created and mapped to the above created table. It should be kept in Poulpe since no other project will need it.
• A hard question to answer here is what to do with i18n. Possible solution would be to name the labels with some pattern we'll name the component configuration (like configuration.jcommune_amount_of_posts_per_page) and then put this value into the i18n resolver. This would effectively mean that changing the value in the database we'll need to make sure we change them in the properties files (we can check it while starting the app and log warnings) and if there is no analogue in the Poulpe, then a LABEL should be used.

NB: Steps that are related to jtalks-common should be done in synch with common team: either you should do this in Poulpe and then provide a ready-to-be-committed code to common team or raise a ticket in the common JIRA project with detailed description on what to be done.