# HG changeset patch # User sylvain.thenault@logilab.fr # Date 1237803985 -3600 # Node ID 43bf9a74296109a8f7e1f78eca86c9bb4ade9f8d # Parent 5548b608b7d929b6cfe88a646152c2956e7bca77# Parent 894685124c68fcefd6317f95fe3b4a4ebb7f5e5b merge diff -r c258394c0148 -r 43bf9a742961 _exceptions.py --- a/_exceptions.py Thu May 14 12:51:38 2009 +0200 +++ b/_exceptions.py Mon Mar 23 11:26:25 2009 +0100 @@ -2,7 +2,7 @@ :organization: Logilab -:copyright: 2001-2009 LOGILAB S.A. (Paris, FRANCE), all rights reserved. +:copyright: 2001-2008 LOGILAB S.A. (Paris, FRANCE), all rights reserved. :contact: http://www.logilab.fr/ -- mailto:contact@logilab.fr """ __docformat__ = "restructuredtext en" diff -r c258394c0148 -r 43bf9a742961 common/uilib.py --- a/common/uilib.py Thu May 14 12:51:38 2009 +0200 +++ b/common/uilib.py Mon Mar 23 11:26:25 2009 +0100 @@ -180,27 +180,21 @@ if add_ellipsis: return text + u'...' return text - -def text_cut(text, nbwords=30, gotoperiod=True): + +def text_cut(text, nbwords=30): """from the given plain text, return a text with at least words, trying to go to the end of the current sentence. - :param nbwords: the minimum number of words required - :param gotoperiod: specifies if the function should try to go to - the first period after the cut (i.e. finish - the sentence if possible) - Note that spaces are normalized. """ if text is None: return u'' words = text.split() text = u' '.join(words) # normalize spaces - textlength = minlength = len(' '.join(words[:nbwords])) - if gotoperiod: - textlength = text.find('.', minlength) + 1 - if textlength == 0: # no period found - textlength = minlength + minlength = len(' '.join(words[:nbwords])) + textlength = text.find('.', minlength) + 1 + if textlength == 0: # no point found + textlength = minlength return text[:textlength] def cut(text, length): diff -r c258394c0148 -r 43bf9a742961 cwconfig.py --- a/cwconfig.py Thu May 14 12:51:38 2009 +0200 +++ b/cwconfig.py Mon Mar 23 11:26:25 2009 +0100 @@ -2,7 +2,7 @@ """common configuration utilities for cubicweb :organization: Logilab -:copyright: 2001-2009 LOGILAB S.A. (Paris, FRANCE), all rights reserved. +:copyright: 2001-2008 LOGILAB S.A. (Paris, FRANCE), all rights reserved. :contact: http://www.logilab.fr/ -- mailto:contact@logilab.fr """ __docformat__ = "restructuredtext en" @@ -501,16 +501,17 @@ class CubicWebConfiguration(CubicWebNoAppConfiguration): """base class for cubicweb server and web configurations""" - INSTANCE_DATA_DIR = None if CubicWebNoAppConfiguration.mode == 'test': root = os.environ['APYCOT_ROOT'] REGISTRY_DIR = '%s/etc/cubicweb.d/' % root + INSTANCE_DATA_DIR = REGISTRY_DIR RUNTIME_DIR = '/tmp/' MIGRATION_DIR = '%s/local/share/cubicweb/migration/' % root if not exists(REGISTRY_DIR): os.makedirs(REGISTRY_DIR) elif CubicWebNoAppConfiguration.mode == 'dev': REGISTRY_DIR = expanduser('~/etc/cubicweb.d/') + INSTANCE_DATA_DIR = REGISTRY_DIR RUNTIME_DIR = '/tmp/' MIGRATION_DIR = join(CW_SOFTWARE_ROOT, 'misc', 'migration') else: #mode = 'installed' @@ -573,8 +574,7 @@ @classmethod def instance_data_dir(cls): """return the instance data directory""" - return env_path('CW_INSTANCE_DATA', - cls.INSTANCE_DATA_DIR or cls.REGISTRY_DIR, + return env_path('CW_INSTANCE_DATA', cls.INSTANCE_DATA_DIR, 'additional data') @classmethod diff -r c258394c0148 -r 43bf9a742961 devtools/devctl.py --- a/devtools/devctl.py Thu May 14 12:51:38 2009 +0200 +++ b/devtools/devctl.py Mon Mar 23 11:26:25 2009 +0100 @@ -513,22 +513,17 @@ raise BadCommandUsage("no argument expected") import re requests = {} - for lineno, line in enumerate(sys.stdin): + for line in sys.stdin: if not ' WHERE ' in line: continue #sys.stderr.write( line ) - try: - rql, time = line.split('--') - rql = re.sub("(\'\w+': \d*)", '', rql) - if '{' in rql: - rql = rql[:rql.index('{')] - req = requests.setdefault(rql, []) - time.strip() - chunks = time.split() - cputime = float(chunks[-3]) - req.append( cputime ) - except Exception, exc: - sys.stderr.write('Line %s: %s (%s)\n' % (lineno, exc, line)) + rql, time = line.split('--') + rql = re.sub("(\'\w+': \d*)", '', rql) + req = requests.setdefault(rql, []) + time.strip() + chunks = time.split() + cputime = float(chunks[-3]) + req.append( cputime ) stat = [] for rql, times in requests.items(): @@ -536,11 +531,8 @@ stat.sort() stat.reverse() - - total_time = sum(time for time, occ, rql in stat)*0.01 - print 'Percentage;Cumulative Time;Occurences;Query' for time, occ, rql in stat: - print '%.2f;%.2f;%s;%s' % (time/total_time, time, occ, rql) + print time, occ, rql register_commands((UpdateCubicWebCatalogCommand, UpdateTemplateCatalogCommand, diff -r c258394c0148 -r 43bf9a742961 doc/book/en/B0010-define-schema.en.txt --- a/doc/book/en/B0010-define-schema.en.txt Thu May 14 12:51:38 2009 +0200 +++ b/doc/book/en/B0010-define-schema.en.txt Mon Mar 23 11:26:25 2009 +0100 @@ -4,15 +4,14 @@ ================================ The schema is the core piece of a `CubicWeb` application as it defines -the data model handled. It is based on entity types that are either already -defined in the `CubicWeb` standard library; or more specific types, that -`CubicWeb` expects to find in one or more Python files under the directory -`schema`. +the data model handled. It is based on entities types already defined +in the `CubicWeb` standard library and others, more specific, we would +expect to find in one or more Python files under the `schema` directory. At this point, it is important to make clear the difference between -*relation type* and *relation definition*: a *relation type* is only a relation +relation type and relation definition: a relation type is only a relation name with potentially other additionnal properties (see XXXX), whereas a -*relation definition* is a complete triplet +relation definition is a complete triplet " ". A relation type could have been implied if none is related to a relation definition of the schema. diff -r c258394c0148 -r 43bf9a742961 doc/book/en/B0011-schema-stdlib.en.txt --- a/doc/book/en/B0011-schema-stdlib.en.txt Thu May 14 12:51:38 2009 +0200 +++ b/doc/book/en/B0011-schema-stdlib.en.txt Mon Mar 23 11:26:25 2009 +0100 @@ -3,14 +3,14 @@ Pre-defined schemas in the library ---------------------------------- -The library defines a set of entity schemas that are required by the system +The library defines a set of entities schemas that are required by the system or commonly used in `CubicWeb` applications. Of course, you can extend those schemas if necessary. System schemas `````````````` -The system entities available are: +The system entities available are : * `EUser`, system users * `EGroup`, users groups @@ -31,9 +31,6 @@ * `Bookmark`, an entity type used to allow a user to customize his links within the application -(The first 'E' in some of the names is the first letter of 'Erudi', -`CubicWeb`'s old name; it might be changed/removed some day.) - Cubes available ``````````````` diff -r c258394c0148 -r 43bf9a742961 doc/book/en/B0012-schema-definition.en.txt --- a/doc/book/en/B0012-schema-definition.en.txt Thu May 14 12:51:38 2009 +0200 +++ b/doc/book/en/B0012-schema-definition.en.txt Mon Mar 23 11:26:25 2009 +0100 @@ -3,30 +3,26 @@ Entity type definition ---------------------- -An entity type is defined by a Python class which inherits from `EntityType`. -The class definition contains the description of attributes and relations -for the defined entity type. -The class name corresponds to the entity type name. +An entity type is defined by a Python class which inherits `EntityType`. The +class name correponds to the type name. Then the content of the class contains +the description of attributes and relations for the defined entity type, +for example :: -For example :: - - class Person(EntityType): + class Personne(EntityType): """A person with the properties and the relations necessary for my application""" last_name = String(required=True, fulltextindexed=True) first_name = String(required=True, fulltextindexed=True) - title = String(vocabulary=('Mr', 'Mrs', 'Miss')) + title = String(vocabulary=('M', 'Mme', 'Mlle')) date_of_birth = Date() works_for = SubjectRelation('Company', cardinality='?*') - * the name of the Python attribute corresponds to the name of the attribute or the relation in `CubicWeb` application. -* all `CubicWeb` built-in types are available : `String`, `Int`, `Float`, - `Boolean`, `Date`, `Datetime`, `Time`, `Byte`; they are and implicitely - imported (as well as the special the function "_"). +* all built-in types are available : `String`, `Int`, `Float`, + `Boolean`, `Date`, `Datetime`, `Time`, `Byte`. * each entity type has at least the following meta-relations : @@ -38,19 +34,21 @@ - `created_by` (`EUser`) (which user created the entity) - - `owned_by` (`EUser`) (to whom the entity belongs; by default the - creator but not necessary, and it could have multiple owners) + - `owned_by` (`EUser`) (who does the entity belongs to, by default the + creator but not necessary and it could have multiple owners) - `is` (`EEType`) + +* it is also possible to define relations of type object by using `ObjectRelation` + instead of `SubjectRelation` -* relations can be defined by using `ObjectRelation` or `SubjectRelation`. - The first argument of `SubjectRelation` or `ObjectRelation` gives respectively +* the first argument of `SubjectRelation` and `ObjectRelation` gives respectively the object/subject entity type of the relation. This could be : * a string corresponding to an entity type - * a tuple of string corresponding to multiple entity types + * a tuple of string correponding to multiple entities types * special string such as follows : @@ -64,20 +62,20 @@ * optional properties for attributes and relations : - - `description` : a string describing an attribute or a relation. By default + - `description` : string describing an attribute or a relation. By default this string will be used in the editing form of the entity, which means that it is supposed to help the end-user and should be flagged by the function `_` to be properly internationalized. - - `constraints` : a list of conditions/constraints that the relation has to + - `constraints` : list of conditions/constraints that the relation needs to satisfy (c.f. `Contraints`_) - - `cardinality` : a two character string which specify the cardinality of the + - `cardinality` : two characters string which specify the cardinality of the relation. The first character defines the cardinality of the relation on - the subject, and the second on the object. When a relation can have - multiple subjects or objects, the cardinality applies to all, - not on a one-to-one basis (so it must be consistent...). The possible - values are inspired from regular expression syntax : + the subject, the second on the object of the relation. When a relation + has multiple possible subjects or objects, the cardinality applies to all + and not on a one to one basis (so it must be consistent...). The possible + values are inspired from regular expressions syntax : * `1`: 1..1 * `?`: 0..1 @@ -87,7 +85,7 @@ - `meta` : boolean indicating that the relation is a meta-relation (false by default) -* optional properties for attributes : +* optionnal properties for attributes : - `required` : boolean indicating if the attribute is required (false by default) @@ -100,11 +98,11 @@ attribute. - `default` : default value of the attribute. In case of date types, the values - which could be used correspond to the RQL keywords `TODAY` and `NOW`. + which could be used correpond to the RQL keywords `TODAY` and `NOW`. - `vocabulary` : specify static possible values of an attribute -* optional properties of type `String` : +* optionnal properties of type `String` : - `fulltextindexed` : boolean indicating if the attribute is part of the full text index (false by default) (*applicable on the type `Byte` @@ -115,17 +113,17 @@ - `maxsize` : integer providing the maximum size of the string (no limit by default) -* optional properties for relations : +* optionnal properties for relations : - `composite` : string indicating that the subject (composite == 'subject') is composed of the objects of the relations. For the opposite case (when - the object is composed of the subjects of the relation), we just set - 'object' as value. The composition implies that when the relation + the object is composed of the subjects of the relation), we just need + to set 'object' as the value. The composition implies that when the relation is deleted (so when the composite is deleted), the composed are also deleted. Contraints `````````` -By default, the available constraint types are : +By default, the available constraints types are : * `SizeConstraint` : allows to specify a minimum and/or maximum size on string (generic case of `maxsize`) @@ -137,7 +135,7 @@ * `StaticVocabularyConstraint` : identical to "vocabulary=(...)" -* `RQLConstraint` : allows to specify a RQL query that has to be satisfied +* `RQLConstraint` : allows to specify a RQL query that needs to be satisfied by the subject and/or the object of the relation. In this query the variables `S` and `O` are reserved for the entities subject and object of the relation. @@ -145,7 +143,7 @@ * `RQLVocabularyConstraint` : similar to the previous type of constraint except that it does not express a "strong" constraint, which means it is only used to restrict the values listed in the drop-down menu of editing form, but it does - not prevent another entity to be selected. + not prevent another entity to be selected Relation definition @@ -156,7 +154,7 @@ A relation is defined by a Python class heriting `RelationType`. The name of the class corresponds to the name of the type. The class then contains a description of the properties of this type of relation, and could as well -contain a string for the subject and a string for the object. This allows to create +contains a string for the subject and a string for the object. This allows to create new definition of associated relations, (so that the class can have the definition properties from the relation) for example :: @@ -176,14 +174,14 @@ table for the relation. This applies to the relation when the cardinality of subject->relation->object is 0..1 (`?`) or 1..1 (`1`) -* `symmetric` : boolean indicating that the relation is symmetrical, which +* `symetric` : boolean indication that the relation is symetrical, which means `X relation Y` implies `Y relation X` In the case of simultaneous relations definitions, `subject` and `object` can both be equal to the value of the first argument of `SubjectRelation` and `ObjectRelation`. -When a relation is not inlined and not symmetrical, and it does not require +When a relation is not inlined and not symetrical, and it does not require specific permissions, its definition (by using `SubjectRelation` and `ObjectRelation`) is all we need. @@ -377,16 +375,12 @@ Updating your application with your new schema `````````````````````````````````````````````` -If you modified your schema, the update is not automatic; this is -indeed in general not a good idea. -Instead, we call a shell on your application, which is a -an interactive python shell, with an appropriate -cubicweb environment :: +You have to get a shell on your application :: - cubicweb-ctl shell myinstance + cubicweb-ctl shell moninstance and type :: - add_entity_type('Person') + add_entity_type('Personne') And restart your application! diff -r c258394c0148 -r 43bf9a742961 doc/book/en/B0040-migration.en.txt --- a/doc/book/en/B0040-migration.en.txt Thu May 14 12:51:38 2009 +0200 +++ b/doc/book/en/B0040-migration.en.txt Mon Mar 23 11:26:25 2009 +0100 @@ -5,10 +5,10 @@ Migration ========= -One of the main concept in `CubicWeb` is to create incremental applications. -For this purpose, multiple actions are provided to facilitate the improvement -of an application, and in particular to handle the changes to be applied -to the data model, without loosing existing data. +One of the main concept in `CubicWeb` is to create incremental applications +and for this purpose multiple actions are provided to facilitate the improvement +of an application and in particular changes applied to the data model +without loosing existing data. The current version of an application model is provided in the file `__pkginfo__.py` as a tuple of 3 integers. @@ -16,8 +16,8 @@ Migration scripts management ---------------------------- -Migration scripts has to be located in the directory `migration` of your -application and named accordingly: +Migration scripts needs to be located in the directory `migration` of your +application and nammed accordingly: :: @@ -25,27 +25,26 @@ in which : -* X.Y.Z is the model version number to which the script enables to migrate. +* X.Y.Z is the model version number to which the script enable to migrate -* *mode* (between the last "_" and the extension ".py") is used for - distributed installation. It indicates to which part - of the application (RQL server, web server) the script applies. - Its value could be : +* *mode* (between the last "_" and the extension ".py") indicates which part + of the application (RQL server, web server) the script applies to in case + of distributed installation. Its value could be : * `common`, applies to the RQL server as well as the web server and updates files on the hard drive (configuration files migration for example). - * `web`, applies only to the web server and updates files on the hard drive. + * `web`, applies only to the web server and updates files on the hard drive * `repository`, applies only to the RQL server and updates files on the - hard drive. + hard drive * `Any`, applies only to the RQL server and updates data in the database - (schema and data migration for example). + (schema and data migration for example) Again in the directory `migration`, the file `depends.map` allows to indicate -that for the migration to a particular model version, you always have to first -migrate to a particular `CubicWeb` version. This file can contain comments (lines +that to migrate to a particular model version, you always have to first migrate +to a particular `CubicWeb` version. This file can contains comments (lines starting by `#`) and a dependancy is listed as follows: :: : @@ -54,31 +53,33 @@ 0.12.0: 2.26.0 0.13.0: 2.27.0 - # 0.14 works with 2.27 <= cubicweb <= 2.28 at least + # 0.14 works with 2.27 <= erudi <= 2.28 at least 0.15.0: 2.28.0 Base context ------------ -The following identifiers are pre-defined in migration scripts: +The following identifiers are pre-defined in the migration scripts: * `config`, instance configuration * `interactive_mode`, boolean indicating that the script is executed in - an interactive mode or not + an intercative mode or not * `appltemplversion`, application model version of the instance +* `applerudiversion`, cubicweb instance version + * `templversion`, installed application model version -* `cubicwebversion`, installed cubicweb version +* `erudiversion`, installed cubicweb version -* `confirm(question)`, function asking the user and returning true - if the user answers yes, false otherwise (always returns true in +* `confirm(question)`, function interrogating the user and returning true + if the user answers yes, false otherwise (always returns true when in a non-interactive mode) -* the function `_`, it is equivalent to `unicode` allowing to flag the strings - to internationalize in the migration scripts. +* `_`, function fonction equivalent to `unicode` allowing to flag the strings + to internationalize in the migration scripts In the `repository` scripts, the following identifiers are also defined: @@ -88,7 +89,7 @@ current migration) * `newschema`, installed schema on the file system (e.g. schema of - the updated model and cubicweb) + the updated model and erudi) * `sqlcursor`, SQL cursor for very rare cases where it is really necessary or beneficial to go through the sql @@ -98,7 +99,7 @@ Schema migration ---------------- -The following functions for schema migration are available in `repository` +The following functions for schema migration are available in the `repository` scripts: * `add_attribute(etype, attrname, attrtype=None, commit=True)`, adds a new @@ -108,7 +109,7 @@ * `drop_attribute(etype, attrname, commit=True)`, removes an attribute from an existing entity type. -* `rename_attribute(etype, oldname, newname, commit=True)`, renames an attribute +* `rename_attribute(etype, oldname, newname, commit=True)`, rename an attribute * `add_entity_type(etype, auto=True, commit=True)`, adds a new entity type. If `auto` is True, all the relations using this entity type and having a known @@ -148,7 +149,7 @@ or even relations definitions). * `change_relation_props(subjtype, rtype, objtype, commit=True, **kwargs)`, changes - properties of a relation definition by using the named parameters of the properties + properties of a relation definition by using the nammed parameters of the properties to change. * `set_widget(etype, rtype, widget, commit=True)`, changes the widget used for the @@ -159,19 +160,19 @@ Data migration -------------- -The following functions for data migration are available in `repository` scripts: +The following functions for data migration are available in the `repository` scripts: * `rql(rql, kwargs=None, cachekey=None, ask_confirm=True)`, executes an arbitrary RQL query, either to interrogate or update. A result set object is returned. * `add_entity(etype, *args, **kwargs)`, adds a nes entity type of the given - type. The attribute and relation values are specified using the named and + type. The attributes and relations values are specified using the nammed and positionned parameters. Workflow creation ----------------- -The following functions for workflow creation are available in `repository` +The following functions for workflow creation are available in the `repository` scripts: * `add_state(name, stateof, initial=False, commit=False, **kwargs)`, adds a new state @@ -185,10 +186,10 @@ Configuration migration ----------------------- -The following functions for configuration migration are available in all +The following functions for configuration migration are available in all the scripts: -* `option_renamed(oldname, newname)`, indicates that an option has been renamed +* `option_renamed(oldname, newname)`, indicates that an option has been renammed * `option_group_change(option, oldgroup, newgroup)`, indicates that an option does not belong anymore to the same group. @@ -202,7 +203,7 @@ -------------------------- Those functions are only used for low level operations that could not be accomplished otherwise or to repair damaged databases during interactive -session. They are available in `repository` scripts: +session. They are available in the `repository` scripts: * `sqlexec(sql, args=None, ask_confirm=True)`, executes an arbitrary SQL query * `add_entity_type_table(etype, commit=True)` diff -r c258394c0148 -r 43bf9a742961 doc/book/en/B1020-define-views.en.txt --- a/doc/book/en/B1020-define-views.en.txt Thu May 14 12:51:38 2009 +0200 +++ b/doc/book/en/B1020-define-views.en.txt Mon Mar 23 11:26:25 2009 +0100 @@ -163,7 +163,7 @@ If you want to change the way a ``BlogEntry`` is displayed, just override the method ``cell_call()`` of the view ``primary`` in ``BlogDemo/views.py`` :: - 01. from cubicweb.web.views import baseviews + 01. from ginco.web.views import baseviews 02. 03. class BlogEntryPrimaryView(baseviews.PrimaryView): 04. diff -r c258394c0148 -r 43bf9a742961 doc/book/en/B1060-templates.en.txt --- a/doc/book/en/B1060-templates.en.txt Thu May 14 12:51:38 2009 +0200 +++ b/doc/book/en/B1060-templates.en.txt Mon Mar 23 11:26:25 2009 +0100 @@ -84,7 +84,7 @@ :: - from cubicweb.web.views.basetemplates import HTMLPageHeader + from ginco.web.views.basetemplates import HTMLPageHeader class MyHTMLPageHeader(HTMLPageHeader): def main_header(self, view): """build the top menu with authentification info and the rql box""" @@ -143,7 +143,7 @@ for HTMLPageFooter and override it in your views file as in : :: - form cubicweb.web.views.basetemplates import HTMLPageFooter + form ginco.web.views.basetemplates import HTMLPageFooter class MyHTMLPageFooter(HTMLPageFooter): def call(self, **kwargs): self.w(u'