equanda-svn-commit Mailing List for equanda Java EE code generator (Page 2)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Revision: 1184
          http://equanda.svn.sourceforge.net/equanda/?rev=1184&view=rev
Author:   triathlon98
Date:     2009-12-03 22:11:25 +0000 (Thu, 03 Dec 2009)

Log Message:
-----------
spelling fixes

Modified Paths:
--------------
    trunk/src/site/wiki/dm.wiki
    trunk/src/site/wiki/templates/ejb3.wiki

Modified: trunk/src/site/wiki/dm.wiki
===================================================================

--- trunk/src/site/wiki/dm.wiki	2009-12-02 21:12:04 UTC (rev 1183)
+++ trunk/src/site/wiki/dm.wiki	2009-12-03 22:11:25 UTC (rev 1184)
@@ -95,7 +95,7 @@
 - *renderer* : indication of the renderer (and parameters) which should be used to render this fields. This overwrites the defaults.
 - *priority* : priority for setting this field. When the proxies set/update the field values, this is by default done in an order based on the priority and the order in which the fields are declared in the domain model. Priority is a value between "1" and "9", with fields at priority "1" updated first and "9" updated last.
 
-Each field can be given a _description_ and semantic annotations using _subectory_.
+Each field can be given a _description_ and semantic annotations using _subjectory_.
 
 A field can be marked as _internal_, _auto_ or _calculated_. Internal fields are not visible to the outside world. They are part of the entity beans and database representation, but have no getters or setters. Auto fields have got getters, but no setters, the values are initialized and maintained in the mediators. A calculated field also has only a getter, but it is calculated when requested, it has no database representation.
 

Modified: trunk/src/site/wiki/templates/ejb3.wiki
===================================================================
--- trunk/src/site/wiki/templates/ejb3.wiki	2009-12-02 21:12:04 UTC (rev 1183)
+++ trunk/src/site/wiki/templates/ejb3.wiki	2009-12-03 22:11:25 UTC (rev 1184)
@@ -1,7 +1,7 @@
 h1. ejb3 templates
 
 Domain model description options
-- (multiple) inheritance
+- inheritance
 - declarative constraints
 - programmed constraints
 - int, double, string, blob, clob fields
@@ -26,10 +26,10 @@
 As part of the generated classes, some powerful _data access objects_ (DAO's) are generated. These _proxies_ assure that access to the objects always behaves consistently, independent of whether access is local, remote, using a UserTransaction or not.
 The proxies have the following advantages and behaviour.
 - All multiple linked fields are lazy loaded. They are instaniated when the collection is first accessed.
-- Proxies can be saved and updated (using equandaUpdate() in place, the actual object stays the same though the data in it may change. However, linked objects which are updated because of casading update are replaced (see example velow)!
+- Proxies can be saved and updated (using equandaUpdate() in place, the actual object stays the same though the data in it may change. However, linked objects which are updated because of cascading update are replaced (see example velow)!
 - All multiple fields in the proxies are always not-null. When there are no values in it, an empty collection is returned.
 - All updates to proxies cascade. The linked records will also be updated when they are changed (though this only follows a path of changed objects, when object A links to object B which links to C and A and C are modified but B is not, then an update on A will not update C).
-- Multiple fields in proxies are intelligent. They record which elements are removed or updated and will not touch unmodified linked objects. If however, you assign a new collection to these fields, then part of the intelligence is no longer possible, making updates somewhat less efficient. Therefor it is recommend to not assign new collections.
+- Multiple fields in proxies are intelligent. They record which elements are removed or updated and will not touch unmodified linked objects. If however, you assign a new collection to these fields, then part of the intelligence is no longer possible, making updates somewhat less efficient. Therefore it is recommended not to assign new collections.
 - Proxies are only marked as _modified_ if something has actually changed. Just assigning the current value in a field will not mark that field as modified.
 - The "equandaCreate()" static method allows instantiation of a new object with all default values filled in.
 - All selectors are available through static method on the proxy class. The results are lazy collections which are instantiated and refreshed automatically.
@@ -52,11 +52,11 @@
 
 h2. How the domain model is generated
 
-A whole set of classes are being generated. To handle the inheritance, the inheritance tree is flattened and a "root-table" is created which contains all fields, actions, selectors for all the tables in the inhertance tree. When is distinction needs to be made, this is handled in the code.
+A whole set of classes are being generated. To handle the inheritance, the inheritance tree is flattened and a "root-table" is created which contains all fields, actions, selectors for all the tables in the inheritance tree. When a distinction needs to be made, this is handled in the code.
 
-The preferred way to access the data is through the proxies. These have names which equal the names of the root tables and allow remote access to the data, the selectors and actions while hiding the details of looking up beans etc. They are built to transparently instantiate fields when required.
+The preferred way to access the data is through the proxies. These have names which equal the names of the root tables and allow remote access to the data, selectors and actions while hiding the details of looking up beans etc. They are built to transparently instantiate fields when required.
 
-Alternatively, you can access the data though a set of session beans for each root table. One is the /ObjectSelectorBean/ which is stateless and allows executing the selectors which are defined. The second is the /ObjectBean/ which is a stateful session bean façade for the entity bean. To make accessing these beans slightly easier, there is a /EquandaGlobal/ class which (amongst other things) allows you to retrieve the beans.
+Alternatively, you can access the data through a set of session beans for each root table. One is the /ObjectSelectorBean/ which is stateless and allows executing the selectors which are defined. The second is the /ObjectBean/ which is a stateful session bean façade for the entity bean. To make accessing these beans slightly easier, there is a /EquandaGlobal/ class which (amongst other things) allows you to retrieve the beans.
 
 For constraint checking a smart set of intermediate classes called "mediators" are used. These are built in such a way to assure the declarative constraints can be handled and updated when the generation is re-run, but constraints added by manual coding are also maintained. For this a /MediatorRoot/ is used to start by constraining all access (nothing allowed). Then for each class there is a /MediatorBase/ which contains the declarative constraints and a /Mediator/ which is supposed to be filled in by the used and contains the programmatic constraints.
 


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.




2007	Jan	Feb	Mar	Apr	May	Jun	Jul (6)	Aug (41)	Sep (44)	Oct (31)	Nov (54)	Dec (53)
2008	Jan (71)	Feb (66)	Mar (65)	Apr (73)	May (68)	Jun (69)	Jul (28)	Aug (49)	Sep (44)	Oct (77)	Nov (64)	Dec (78)
2009	Jan (50)	Feb (28)	Mar (41)	Apr (30)	May (5)	Jun (30)	Jul (6)	Aug (2)	Sep (18)	Oct (11)	Nov (6)	Dec (10)
2010	Jan (5)	Feb (8)	Mar (4)	Apr (1)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

equanda-svn-commit Mailing List for equanda Java EE code generator (Page 2)

equanda-svn-commit — svn commits