GPMSWiki/DeveloperDocumentation/MigrationHelp/APIChanges: Difference between revisions

From BRF-Software
Jump to navigation Jump to search
imported>MichaelDondrup
No edit summary
 
m (4 revisions)
 
(3 intermediate revisions by one other user not shown)
Line 8: Line 8:
== Changes ==
== Changes ==


* Method '''project''' is now use: '''init_project''' and '''release_project'''. Use init to connect to a project and release to disconnect prior to changing to another project. You '''must''' release before you can init a second time, otherwise risking malfuncton. Be careful: method ''project'' still exists but does something different /!\ Don't use it /!\
* Dokumentation is improved, all packages contain POD documentation.
* Method '''project''' is now: '''init_project''' and '''release_project'''. Use init to connect to a project and release to disconnect prior to changing to another project. You '''must''' release before you can init a second time, otherwise risking malfuncton. Be careful: method ''project'' still exists but does something different /!\ Don't use it /!\  
* All attribute accessor methods use consistent spelling: lowercase
* All attributes returning arrays are consistenly plural syntax, all scalar values singular
* All Classnames are consistently named in singular: '''Rights''' --> '''Right'''
* Own Application_Frame is now mandatory: Now you '''must''' have your own subclass of GPMS::Application_Frame. Put this module into the share/perl/GPMS/ folder within '''your''' application path.
Don't put it into the GPMS module. Naming covention should follow GPMS::Application_Frame::<[[ProjectClass]]>
 
A minimal Application_Frame should look like this:
 
 
<pre><nowiki>
 
Example: The Minimal Application_Frame
 
        package GPMS::Application_Frame::Minimal;
 
        use strict;
 
        use base('GPMS::Application_Frame');
 
        1;
 
        sub master_class {
 
            return 'Minimal::DB';
 
        }
 
        sub db_type {
 
            return 'MinimalDB';
 
        }
 
 
</nowiki></pre>
 
 
To demonstrate a full-blown Application_Frame with the use of callbacks, have a look at ''share/perl/GPMS/Application_Frame/Sample.pm'' (GPMS::Application_Frame::Sample) in the cvs repository.

Latest revision as of 07:17, 26 October 2011

List of Changes in the GPMS API

This list is non exhaustive and Perl only although we try.....

More or less sorted by frequency of occurance in our code:

Changes

  • Dokumentation is improved, all packages contain POD documentation.
  • Method project is now: init_project and release_project. Use init to connect to a project and release to disconnect prior to changing to another project. You must release before you can init a second time, otherwise risking malfuncton. Be careful: method project still exists but does something different /!\ Don't use it /!\
  • All attribute accessor methods use consistent spelling: lowercase
  • All attributes returning arrays are consistenly plural syntax, all scalar values singular
  • All Classnames are consistently named in singular: Rights --> Right
  • Own Application_Frame is now mandatory: Now you must have your own subclass of GPMS::Application_Frame. Put this module into the share/perl/GPMS/ folder within your application path.

Don't put it into the GPMS module. Naming covention should follow GPMS::Application_Frame::<ProjectClass>

A minimal Application_Frame should look like this:



 Example: The Minimal Application_Frame

         package GPMS::Application_Frame::Minimal;

         use strict;

         use base('GPMS::Application_Frame');

         1;

         sub master_class {

             return 'Minimal::DB';

         }

         sub db_type {

             return 'MinimalDB';

         }



To demonstrate a full-blown Application_Frame with the use of callbacks, have a look at share/perl/GPMS/Application_Frame/Sample.pm (GPMS::Application_Frame::Sample) in the cvs repository.