# HG changeset patch # User Sylvain Thénault # Date 1296491045 -3600 # Node ID 327443ec71203fb56c2ec56a03e35ec3c1dd2deb # Parent cb1dd14a768f5f3b99605ee167bbeea48d508b24 [doc] update photo web site tutorial: we're starting from cw 3.10/file 1.9+ diff -r cb1dd14a768f -r 327443ec7120 doc/book/en/tutorials/advanced/part01_create-cube.rst --- a/doc/book/en/tutorials/advanced/part01_create-cube.rst Fri Jan 28 23:13:47 2011 +0100 +++ b/doc/book/en/tutorials/advanced/part01_create-cube.rst Mon Jan 31 17:24:05 2011 +0100 @@ -34,8 +34,8 @@ both 'album' and a way to map file system folders. Entities are added to a given folder using the `filed_under` relation. -* `file`, containing `File` and `Image` entity types, gallery view, - and a file system import utility. +* `file`, containing `File` entity type, gallery view, and a file system import + utility. * `zone`, containing the `Zone` entity type for hierarchical geographical zones. Entities (including sub-zones) are added to a given zone using the @@ -54,8 +54,8 @@ .. sourcecode:: python - __depends__ = {'cubicweb': '>= 3.8.0', - 'cubicweb-file': '>= 1.2.0', + __depends__ = {'cubicweb': '>= 3.10.0', + 'cubicweb-file': '>= 1.9.0', 'cubicweb-folder': '>= 1.1.0', 'cubicweb-person': '>= 1.2.0', 'cubicweb-comment': '>= 1.2.0', @@ -71,14 +71,17 @@ .. sourcecode:: python - __depends__ = {'cubicweb': '>= 3.8.0'} - __depends_cubes__ = {'file': '>= 1.2.0', + __depends__ = {'cubicweb': '>= 3.10.0'} + __depends_cubes__ = {'file': '>= 1.9.0', 'folder': '>= 1.1.0', 'person': '>= 1.2.0', 'comment': '>= 1.2.0', 'tag': '>= 1.2.0', 'zone': None} +If your cube is packaged for debian, it's a good idea to update the +`debian/control` file at the same time, so you won't forget it. + Step 3: glue everything together in my cube's schema ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -89,34 +92,33 @@ class comments(RelationDefinition): subject = 'Comment' - object = ('File', 'Image') + object = 'File' cardinality = '1*' composite = 'object' class tags(RelationDefinition): subject = 'Tag' - object = ('File', 'Image') + object = 'File' class filed_under(RelationDefinition): - subject = ('File', 'Image') + subject = 'File' object = 'Folder' class situated_in(RelationDefinition): - subject = 'Image' + subject = 'File' object = 'Zone' class displayed_on(RelationDefinition): subject = 'Person' - object = 'Image' + object = 'File' This schema: -* allows to comment and tag on `File` and `Image` entity types by adding the - `comments` and `tags` relations. This should be all we've to do for this - feature since the related cubes provide 'pluggable section' which are - automatically displayed on the primary view of entity types supporting the - relation. +* allows to comment and tag on `File` entity type by adding the `comments` and + `tags` relations. This should be all we've to do for this feature since the + related cubes provide 'pluggable section' which are automatically displayed on + the primary view of entity types supporting the relation. * adds a `situated_in` relation definition so that image entities can be geolocalized. diff -r cb1dd14a768f -r 327443ec7120 doc/book/en/tutorials/advanced/part02_security.rst --- a/doc/book/en/tutorials/advanced/part02_security.rst Fri Jan 28 23:13:47 2011 +0100 +++ b/doc/book/en/tutorials/advanced/part02_security.rst Mon Jan 31 17:24:05 2011 +0100 @@ -46,10 +46,10 @@ security defined earlier, groups are not enough, we'll need some RQL expression. Here is the idea: -* add a `visibility` attribute on Folder, Image and Comment, which may be one of +* add a `visibility` attribute on Folder, File and Comment, which may be one of the value explained above -* add a `may_be_read_by` relation from Folder, Image and Comment to users, +* add a `may_be_read_by` relation from Folder, File and Comment to users, which will define who can see the entity * security propagation will be done in hook. @@ -62,7 +62,7 @@ from yams.constraints import StaticVocabularyConstraint class visibility(RelationDefinition): - subject = ('Folder', 'File', 'Image', 'Comment') + subject = ('Folder', 'File', 'Comment') object = 'String' constraints = [StaticVocabularyConstraint(('public', 'authenticated', 'restricted', 'parent'))] @@ -76,7 +76,7 @@ 'delete': ('managers',), } - subject = ('Folder', 'File', 'Image', 'Comment',) + subject = ('Folder', 'File', 'Comment',) object = 'CWUser' We can note the following points: @@ -123,7 +123,7 @@ } from cubes.folder.schema import Folder - from cubes.file.schema import File, Image + from cubes.file.schema import File from cubes.comment.schema import Comment from cubes.person.schema import Person from cubes.zone.schema import Zone @@ -131,7 +131,6 @@ Folder.__permissions__ = VISIBILITY_PERMISSIONS File.__permissions__ = VISIBILITY_PERMISSIONS - Image.__permissions__ = VISIBILITY_PERMISSIONS Comment.__permissions__ = VISIBILITY_PERMISSIONS.copy() Comment.__permissions__['add'] = ('managers', 'users',) Person.__permissions__ = AUTH_ONLY_PERMISSIONS @@ -174,7 +173,7 @@ The tricky part of the requirement is in *unless explicitly specified*, notably because when the entity is added, we don't know yet its 'parent' -entity (e.g. Folder of an Image, Image commented by a Comment). To handle such things, +entity (e.g. Folder of an File, File commented by a Comment). To handle such things, CubicWeb provides `Operation`, which allow to schedule things to do at commit time. In our case we will: @@ -200,7 +199,7 @@ class SetVisibilityHook(hook.Hook): __regid__ = 'sytweb.setvisibility' - __select__ = hook.Hook.__select__ & is_instance('Folder', 'File', 'Image', 'Comment') + __select__ = hook.Hook.__select__ & is_instance('Folder', 'File', 'Comment') events = ('after_add_entity',) def __call__(self): hook.set_operation(self._cw, 'pending_visibility', self.entity.eid, @@ -321,7 +320,7 @@ folder = req.create_entity('Folder', name=u'restricted', visibility=u'restricted') - photo1 = req.create_entity('Image', + photo1 = req.create_entity('File', data_name=u'photo1.jpg', data=Binary('xxx'), filed_under=folder) @@ -330,7 +329,7 @@ # visibility propagation self.assertEquals(photo1.visibility, 'restricted') # unless explicitly specified - photo2 = req.create_entity('Image', + photo2 = req.create_entity('File', data_name=u'photo2.jpg', data=Binary('xxx'), visibility=u'public', @@ -340,7 +339,7 @@ # test security self.login('toto') req = self.request() - self.assertEquals(len(req.execute('Image X')), 1) # only the public one + self.assertEquals(len(req.execute('File X')), 1) # only the public one self.assertEquals(len(req.execute('Folder X')), 0) # restricted... # may_be_read_by propagation self.restore_connection() @@ -351,7 +350,7 @@ # test security with permissions self.login('toto') req = self.request() - self.assertEquals(len(req.execute('Image X')), 2) # now toto has access to photo2 + self.assertEquals(len(req.execute('File X')), 2) # now toto has access to photo2 self.assertEquals(len(req.execute('Folder X')), 1) # and to restricted folder if __name__ == '__main__': diff -r cb1dd14a768f -r 327443ec7120 doc/book/en/tutorials/advanced/part03_bfss.rst --- a/doc/book/en/tutorials/advanced/part03_bfss.rst Fri Jan 28 23:13:47 2011 +0100 +++ b/doc/book/en/tutorials/advanced/part03_bfss.rst Mon Jan 31 17:24:05 2011 +0100 @@ -4,11 +4,11 @@ Step 1: configuring the BytesFileSystem storage ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -To avoid cluttering my database, and to ease file manipulation, I don't want -them to be stored in the database. I want to be able create File/Image entities -for some files on the server file system, where those file will be accessed to -get entities data. To do so I've to set a custom :class:`BytesFileSystemStorage` storage -for the File/Image 'data' attribute, which hold the actual file's content. +To avoid cluttering my database, and to ease file manipulation, I don't want them +to be stored in the database. I want to be able create File entities for some +files on the server file system, where those file will be accessed to get +entities data. To do so I've to set a custom :class:`BytesFileSystemStorage` +storage for the File 'data' attribute, which hold the actual file's content. Since the function to register a custom storage needs to have a repository instance as first argument, we've to call it in a server startup hook. So I added @@ -33,7 +33,6 @@ print 'created', bfssdir storage = storages.BytesFileSystemStorage(bfssdir) set_attribute_storage(self.repo, 'File', 'data', storage) - set_attribute_storage(self.repo, 'Image', 'data', storage) .. Note:: @@ -52,7 +51,7 @@ (or in the database before migration) will be located * be ware that by doing this, you can't anymore write queries that will try to - restrict on File and Image `data` attribute. Hopefuly we don't do that usually + restrict on File `data` attribute. Hopefuly we don't do that usually on file's content or more generally on attributes for the Bytes type Now, if you've already added some photos through the web ui, you'll have to @@ -69,8 +68,6 @@ type "exit" or Ctrl-D to quit the shell and resume operation >>> storage_changed('File', 'data') [........................] - >>> storage_changed('Image', 'data') - [........................] That's it. Now, file added through the web ui will have their content stored on diff -r cb1dd14a768f -r 327443ec7120 doc/book/en/tutorials/advanced/part04_ui-base.rst --- a/doc/book/en/tutorials/advanced/part04_ui-base.rst Fri Jan 28 23:13:47 2011 +0100 +++ b/doc/book/en/tutorials/advanced/part04_ui-base.rst Mon Jan 31 17:24:05 2011 +0100 @@ -2,94 +2,6 @@ ================================ -Step 0: updating code to CubicWeb 3.9 / cubicweb-file 1.9 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -CubicWeb 3.9 brings `several improvments`_ that we'll want to use, and the 1.9 -version of the file cube has a major change: the `Image` type has been dropped in -favor of an `IImage` adapter that makes code globally much cleaner (though we wont -see that much this here). So the first thing to do is to upgrade our cube to the -3.9 API. As CubicWeb releases are mostly backward compatible, this is not -mandatory but it's easier to follow change as they come than having a huge -upgrade to do at some point. Also, this remove deprecation warnings which are a -bit tedious... - -Also, since we've only a few lines of code yet, this is quite easy to upgrade. -Actually the main thing we've to do is to upgrade our schema, to remove occurences -of the `Image` type or replace them by the `File` type. Here is the (striped) diff: - -.. sourcecode:: diff - - class comments(RelationDefinition): - subject = 'Comment' - - object = ('File', 'Image') - + object = 'File' - cardinality = '1*' - composite = 'object' - - class tags(RelationDefinition): - subject = 'Tag' - - object = ('File', 'Image') - + object = 'File' - - class displayed_on(RelationDefinition): - subject = 'Person' - - object = 'Image' - + object = 'File' - - class situated_in(RelationDefinition): - - subject = 'Image' - + subject = 'File' - object = 'Zone' - - class filed_under(RelationDefinition): - - subject = ('File', 'Image') - + subject = 'File' - object = 'Folder' - - class visibility(RelationDefinition): - - subject = ('Folder', 'File', 'Image', 'Comment') - + subject = ('Folder', 'File', 'Comment') - object = 'String' - constraints = [StaticVocabularyConstraint(('public', 'authenticated', - 'restricted', 'parent'))] - - class may_be_readen_by(RelationDefinition): - - subject = ('Folder', 'File', 'Image', 'Comment',) - + subject = ('Folder', 'File', 'Comment',) - object = 'CWUser' - - - -from cubes.file.schema import File, Image - +from cubes.file.schema import File - - File.__permissions__ = VISIBILITY_PERMISSIONS - -Image.__permissions__ = VISIBILITY_PERMISSIONS - -Now, let's record that we depends on the versions in the __pkginfo__ file. As -`3.8`_ simplify this file, we can merge `__depends_cubes__` (as introduced if the -`first blog of this series`_) with `__depends__` to get the following result: - -.. sourcecode:: python - - __depends__ = {'cubicweb': '>= 3.9.0', - 'cubicweb-file': '>= 1.9.0', - 'cubicweb-folder': None, - 'cubicweb-person': None, - 'cubicweb-zone': None, - 'cubicweb-comment': None, - 'cubicweb-tag': None, - } - -If your cube is packaged for debian, it's a good idea to update the -`debian/control` file at the same time, so you won't forget it. - -That's it for the API update, CubicWeb, cubicweb-file will handle other stuff for -us. Easy, no? - -We can now start some more funny stuff... - - Step 1: let's improve site's usability for our visitors ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~