--- 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.
--- 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__':
--- 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
--- 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~