Hi all,
In addition to the rules described in the previous e-mail the following
one has been added:
* *Auxiliary input name*
o *Rule*: Now auxiliary input names must start with the
module's DBPrefix.
o *Consequence*: This rule has been enforced through database
triggers, making not possible to create or modify existent
objects if the mapping is not correct. Anyway, old modules
not following this rule will still work, but a warning will
be displayed whenever the code is compiled. These modules
will not be allowed to be packaged in obx files till they
are not fixed.
o *Action*: Rename auxiliary inputs to follow the new rule.
-------- Original Message --------
Subject: Modularity naming rules adjustments
Date: Wed, 02 Dec 2009 07:32:54 +0100
From: Asier Lostalé <[email protected]>
To: [email protected]
Hi all,
This message is VERY IMPORTANT for all of you developing and maintaining
modules. Please read it carefully to adapt your modules to the new rules.
Recently some adjustments in modularity naming rules have been performed
in order to prevent possible naming clashes between different modules.
These changes have been now applied in pi mercurial repository and they
will be released in next Openbravo ERP 2.50MP10 version. Before this, it
is recommendable to adapt modules to this adjustments.
Existent modules that do not fit the new rules will raise warning when
compiling but they will continue working, anyway it will not be possible
to package these modules as obx files till they are fixed.
Below it is listed the complete changes and what is the action to be
taken to fix modules in each case.
* *Mapping for WAD code*
o *Rule*: Mapping for WAD windows contains now the module's
mapping for tabs not in core. As this is automatically
generated and shouldn't be manually edited class and mapping
tabs in /Windows and Tabs /window has been set as non editable.
o *Consequence: *When updating to the new core version
mappings in modules will be automatically updated to the new
rule.
o *Action:* Export the module with the new automatically
generated mapping.
* *Mapping for manual code.*
o *Rule*: HTML mapping for all manual objects (forms, searchs,
reports and processes) must start now with the module's
package. For example, the mapping for a report in a module
with package (/org.myCompany.moduleTest/) could be
//org.myCompany.moduleTesr.reports/MyReport.html/.
o *Consequence*: Old modules not following this rule will
still work, but a warning will be displayed whenever the
code is compiled. These modules will not be allowed to be
packaged in obx files till they are not fixed.
o *Action:* The action to be taken to fix modules is to detect
the incorrect mappings (it will be shown as a warning when
compiling) and adapt them to the new rule.
* *Column.name value*
o *Rule:* /Name /attribute in column must follow now the same
rules as /Database name (columnname)/ had. This is, when the
column is in the same module as its table, no special rule
required; if it is in another module, it must start by /EM_
/+ the module's db_prefix.
o *Consequence*: This rule has been enforced in through
database triggers, making not possible to create or modify
existent objects if the mapping is not correct. Anyway, old
modules not following this rule will still work, but a
warning will be displayed whenever the code is compiled.
These modules will not be allowed to be packaged in obx
files till they are not fixed.
o *Action*: Locate columns not following the naming and change
it. Note that this will cause a change in the module's API,
because this value is used by DAL to generate the property
in Java. Therefore it will be necessary also to change the
Java processes accessing the column with DAL.
* *Database indexes and constraints*
o *Rule*: Indexes and constraints now must start with the
module's db_prefix if they are in the same module as their
table. If they are in a different one, the rule is the same
as it was (start by /EM_ +/ db_prefix).
o *Consequence*. Now when exporting database (if
validate.model property is set to true) a warning will be
raised if there are indexes or constraints not following the
rule. It will not be allowed to package modules in obx files
if they do not follow the rule.
o *Action*: Rename indexes and constraints to adapt them to
the new rule. Note that it is possible to define messages
for constraints, in this way it is possible to display a
customized message when the constraint is not satisfied.
These message have as /Search key /value the constraint
name, therefore it will be necessary to change them if exist.
* *Reference name*
o *Rule*: In this case a restriction has been removed. Prior
to this change, reference name was unique in the whole
database, thus it was possible two different module adding
two reference with same name and it was not possible to
install both in the same instance. Now, reference name is
unique per module, so there is no problem with several
modules defining the same name for different references.
o *Consequence*: Now name cannot be used to identify
references. Therefore constructor for /TableComboData/
shouldn't be used passing as parameter the reference name,
but its ID. This constructor has been changed and when
passing name the reference is always looked within core but
not in other modules.
o *Action*: Review module's manual code to ensure all/
TableComboData/ constructors are called using ID when the
reference is not in core.
As addition, all default messages used to be displayed when a constraint
is not satisfied have been removed from database as they are
automatically managed. This means that hundreds of messages have
disappear and it is recommended for those of you maintaining a
translation to repackage it again without all of these messages.
Sorry for all inconveniences this might carry.
Regards
Asier
------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Openbravo-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openbravo-development
