show 134 results

Blog entries

  • HOWTO change the value of a variable in all-in-one.conf with a migration script

    2010/08/03

    Here is a sample migration script (see also the cubicweb documentation on that topic) which changes the variable 'sender-addr'. There is an additional twist in that the variable is only updated if the instance is configured with a known value for that variable.

    wrong_addr = 'cubicweb@loiglab.fr' # known wrong address
    fixed_addr = 'cubicweb@logilab.fr'
    configured_addr = config.get('sender-addr')
    # check that the address has not been hand fixed by a sysadmin
    if configured_addr == wrong_addr:
        config['sender-addr'] = fixed-addr
        config.save()
    

    This is very useful in cases such as:

    • automatically changing the value of a variable which used a default value set by cubicweb-ctl create
    • changing the configuration of an instance with limited intervention from the local sysadmin (because asking him to hand edit the config file is error prone): he just has to deploy the new release and run cubicweb-ctl upgrade
    • fixing issues caused by settings in the all-in-one.conf file (e.g. changing the value of max-post-length)

  • OSCON 2010 - Data freedom and the semantic web

    2010/07/29 by Sandrine Ribeau

    I presented CubicWeb at OSCON 2010. I could only stay for a day and I did not get a chance to see a lot of talks, but judging from the conference schedule it seems only a few of them were related to making data available on the web. I will focus on these talks, for they are very relevant to us who are building the semantic web.

    http://assets.en.oreilly.com/1/event/45/oscon2010_125x125.jpg

    I highly encourage you to watch this video of Stormy Peters, "Is Your Data Free?". It addresses the issue of the privacy of data that you think belongs to you but actually doesn't. This is exactly what is behind the CubicWeb design: build your own web of data in a permission based environment in order to preserve your privacy.

    http://wiki.freebase.com/skins/freebaseUpdate/freebaselogo.png

    Open source, Open data presented by the Freebase folk, makes a very interesting parallel between open source and open data raising the problematic of versioning open data and providing quality data. There are methodologies and tools for open source software to ensure well designed and reliable code. There is absolutely nothing so far that could handle properly data versioning and data quality assurance. That is the biggest concern freebase has and through this talk they asked for help from the open source community so that more people would get involved in finding solutions to serve open data.

    An attendee raised an interesting question about the format that everybody would agree to use to represent the data. I was surprised by the answer. It seems that so far they do not believe that this is a concern, not to say they don't care, but almost. For freebase, the main concern and most challenging part of the data representation is to have a unique identifier. I am not quite sure I agree on that part. Yes, this is important, even mandatory, but there is also the need to define or use a known format to represent this data, (RDF for example) so that we can source this data. To be semantic data, it needs to be both identifiable and readable. And I do not see the point of publishing data on the web if it is not ready to use.

    Just for fun, look at Rewrite or Refactor: When to Declare Technical Bankruptcy, it might sounds familiar to you...

    CubicWeb presentation went well, an interested audience which was very happy to see that we could aggregate multiple types of sources in a CubicWeb application. Of course, it would be even better if we would support an RDF source such as dbpedia: don't worry that's going to happen. Also what raised an interest is the semantic views already integrated in the framework such as SIOC, OWL, FOAF, DOAP that you can find in blog entries (sioc), schema (owl), user (foaf), project (doap).

     

    RDF Resource Description Framework Icon OWL Button - microformats JSON - RSS dublincore DOAP SIOC - FOAF

     

    By providing a platform for using data from multiple sources and publishing semantic data, CubicWeb is already a piece of the web of open data!


  • Building my photos web site with CubicWeb part IV: let's make it more user friendly

    2010/07/13 by Sylvain Thenault

    Step 0: updating code to CubicWeb 3.9 / cubicweb-file 1.9

    CubicWeb 3.9 brings several improvements 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 (although this is not directly visible 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 changes as they come than having a huge upgrade to do at some point. Also, this remove deprecation warnings which are a bit tedious...

    Since we only have very few lines of code, this step is pretty simple. Actually the main thing we have to do is to upgrade our schema, to remove occurrences of the Image type or replace them by the File type. Here is the (striped) 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 set the dependency in the __pkginfo__ file. As 3.8 simplifies this file, we can merge __depends_cubes__ (as introduced in the first blog of this series) with __depends__ to get the following result:

    __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 and cubicweb-file will handle other stuff for us. Easy, no?

    We can now start some more fun stuff...

    Step 1: let's improve site's usability for our visitors

    The first thing I've noticed is that people to whom I send links to photos with some login/password authentication get lost, because they don't grasp they have to login by clicking on the 'authenticate' link. That's probably because they only get a 404 when trying to access an unauthorized folder, and the site doesn't make clear that 1. you're not authenticated, 2. you could get more content by authenticating yourself.

    So, to improve this situation, I decided that I should:

    • make a login box appears for anonymous, so they see at a first glance a place to put the login / password information I provided
    • customize the 404 page, proposing to login to anonymous.

    Here is the code, samples from my cube's views.py file:

    from cubicweb.selectors import is_instance
    from cubicweb.web import box
    from cubicweb.web.views import basetemplates, error
    
    class FourOhFour(error.FourOhFour):
        __select__ = error.FourOhFour.__select__ & anonymous_user()
    
        def call(self):
            self.w(u"<h1>%s</h1>" % self._cw._('this resource does not exist'))
            self.w(u"<p>%s</p>" % self._cw._('have you tried to login?'))
    
    class LoginBox(box.BoxTemplate, basetemplates.LogFormView):
        """display a box containing links to all startup views"""
        __regid__ = 'sytweb.loginbox'
        __select__ = box.BoxTemplate.__select__ & anonymous_user()
    
        title = _('Authenticate yourself')
        order = 70
    
        def call(self, **kwargs):
            self.w(u'<div class="sideBoxTitle"><span>%s</span></div>' % self.title)
            self.w(u'<div class="sideBox"><div class="sideBoxBody">')
            self.login_form('loginBox')
            self.w(u'</div></div>')
    

    The first class provides a new specific implementation of the default page you get on a 404 error, to display an explicit message for anonymous users.

    Note

    Thanks to the selection mechanism, it will be selected for anonymous users, since the additional anonymous_user() selector gives it a higher score than the default, and not for authenticated since this selector will return 0 otherwise (hence the object won't be selectable).

    The second class defines a simple box, that will be displayed by default with boxes in the left column, thanks to default box.BoxTemplate'selector. The HTML is written to match default CubicWeb boxes style. To get the actual login form, we inherit from the LogFormView view which provides a login_form method (handling some stuff under the cover for us, hence the multiple inheritance), that we simply have to call to get the form's HTML.

    login box / 404 screenshot

    The login box and the custom 404 page for an anonymous visitor (translated in french)

    Step 2: providing a custom index page

    Another thing we can easily do to improve the site is... A nicer index page (e.g. the first page you get when accessing the web site)! The default one is quite intimidating (that should change in a near future). I will provide a much simpler index page that simply list available folders (e.g. photo albums in that site).

    from cubicweb.web.views import startup
    
    class IndexView(startup.IndexView):
        def call(self, **kwargs):
            self.w(u'<div>\n')
            if self._cw.cnx.anonymous_connection:
                self.w(u'<h4>%s</h4>\n' % self._cw._('Public Albums'))
            else:
                self.w(u'<h4>%s</h4>\n' % self._cw._('Albums for %s') % self._cw.user.login)
            self._cw.vreg['views'].select('tree', self._cw).render(w=self.w)
            self.w(u'</div>\n')
    
    def registration_callback(vreg):
        vreg.register_all(globals().values(), __name__, (IndexView,))
        vreg.register_and_replace(IndexView, startup.IndexView)
    

    As you can see, we override the default index view found in cubicweb.web.views.startup, getting back nothing but its identifier and selector since we override the top level view's call method.

    Note

    In that case, we want our index view to replace the existing one. We implement the registration_callback function, in which we code a registeration of everything in the module but our IndexView, then we register it instead of the former index view.

    Also, we added a title that tries to make it more evident that the visitor is authenticated, or not. Hopefully people will get it now!

    default index page screenshot

    The default index page

    new index page screenshot

    Our simpler, less intimidating, index page (still translated in french)

    Step 3: more navigation improvements

    There are still a few problems I want to solve...

    • Images in a folder are displayed in a somewhat random order. I would like to have them ordered by file's name (which will usually, inside a given folder, also result ordering photo by their date and time)
    • When clicking a photo from an album view, you've to get back to the gallery view to go to the next photo. This is pretty annoying...
    • Also, when viewing an image, there is no clue about the folder to which this image belongs to.

    I will first try to explain the ordering problem. By default, when accessing related entities by using the ORM's API, you should get them ordered according to the target's class fetch_order. If we take a look at the file cube's schema, we can see:

    class File(AnyEntity):
        """customized class for File entities"""
        __regid__ = 'File'
        fetch_attrs, fetch_order = fetch_config(['data_name', 'title'])
    

    By default, fetch_config will return a fetch_order method that will order on the first attribute in the list. We could expect to get files ordered by their name. But we don't. What's up doc ?

    The problem is that files are related to folder using the filed_under relation. And that relation is ambiguous, eg it can lead to File entities, but also to Folder entities. In such a case, since both entity types don't share the attribute on which we want to sort, we'll get linked entities sorted on a common attribute (usually modification_date).

    To fix this, we have to help the ORM. We'll do this in the method from the ITree folder's adapter, used in the folder's primary view to display the folder's content. Here's the code that I've put in our cube's entities.py file, since it's more logical stuff than view stuff:

    from cubes.folder import entities as folder
    
    class FolderITreeAdapter(folder.FolderITreeAdapter):
    
        def different_type_children(self, entities=True):
            rql = self.entity.cw_related_rql(self.tree_relation,
                                             self.parent_role, ('File',))
            rset = self._cw.execute(rql, {'x': self.entity.eid})
            if entities:
                return list(rset.entities())
            return rset
    
    def registration_callback(vreg):
        vreg.register_and_replace(FolderITreeAdapter, folder.FolderITreeAdapter)
    

    As you can see, we simply inherit from the adapter defined in the folder cube, then we override the different_type_children method to give a clue to the ORM's cw_related_rql method, that will generate the rql to get entities related to the folder by the filed_under relation (the value of the tree_relation attribute). The clue is that we only want to consider the File target entity type. By doing this, we remove the ambiguity and get back a RQL query that correctly orders files by their data_name attribute.

    Note

    • Adapters have been introduced in CubicWeb 3.9 / cubicweb-folder 1.8.
    • As seen earlier, we want to replace the folder's ITree adapter by our implementation, hence the custom registration_callback method.

    Ouf. That one was tricky...

    Now the easier parts. Let's start by adding some links on the file's primary view to see the previous / next image in the same folder. CubicWeb provides a component that do exactly that. To make it appear, it has to be adaptable to the IPrevNext interface. Here is the related code sample, extracted from our cube's views.py file:

    from cubicweb.selectors import is_instance
    from cubicweb.web.views import navigation
    
    
    class FileIPrevNextAdapter(navigation.IPrevNextAdapter):
        __select__ = is_instance('File')
    
        def previous_entity(self):
            rset = self._cw.execute('File F ORDERBY FDN DESC LIMIT 1 WHERE '
                                    'X filed_under FOLDER, F filed_under FOLDER, '
                                    'F data_name FDN, X data_name > FDN, X eid %(x)s',
                                    {'x': self.entity.eid})
            if rset:
                return rset.get_entity(0, 0)
    
        def next_entity(self):
            rset = self._cw.execute('File F ORDERBY FDN ASC LIMIT 1 WHERE '
                                    'X filed_under FOLDER, F filed_under FOLDER, '
                                    'F data_name FDN, X data_name < FDN, X eid %(x)s',
                                    {'x': self.entity.eid})
            if rset:
                return rset.get_entity(0, 0)
    

    The IPrevNext interface implemented by the adapter simply consist of the previous_entity / next_entity methods, that should respectively return the previous / next entity or None. We make an RQL query to get files in the same folder, ordered similarly (eg by their data_name attribute). We set ascendant/descendant ordering and a strict comparison with current file's name (the "X" variable representing the current file).

    Note

    • Former implements selector should be replaced by is_instance or adaptable selector with CubicWeb >= 3.9. In our case, is_instance is used to tell our adapter to get File entities.

    Notice that this query supposes we wont have two files of the same name in the same folder. Fixing this is out of the scope of this blog. And as I would like to have at some point a smarter, context sensitive previous/next entity, I'll probably never fix this query (though if I had to, I would probably choose to add a constraint in the schema so that we can't add two files of the same name in a folder).

    One more thing: by default, the component will be displayed below the content zone (the one with the white background). You can change this in the site's properties through the ui, but you can also change the default value in the code by modifying the context attribute of the component:

    navigation.NextPrevNavigationComponent.context = 'navcontentbottom'
    

    Note

    context may be one of 'navtop', 'navbottom', 'navcontenttop' or 'navcontentbottom'; the first two being outside the main content zone, the two others inside it.

    screenshot of the previous/next entity component

    The previous/next entity component, at the bottom of the main content zone.

    Now, the only remaining stuff in my todo list is to see the file's folder. I'll use the standard breadcrumb component to do so. Similarly as what we've seen before, this component is controlled by the IBreadCrumbs interface, so we'll have to provide a custom adapter for File entity, telling the a file's parent entity is its folder:

    from cubicweb.web.views import ibreadcrumbs
    
    class FileIBreadCrumbsAdapter(ibreadcrumbs.IBreadCrumbsAdapter):
        __select__ = is_instance('File')
    
        def parent_entity(self):
            if self.entity.filed_under:
                return self.entity.filed_under[0]
    

    In this case, we simply use the attribute notation provided by the ORM to get the folder in which the current file (e.g. self.entity) is located.

    Note

    The IBreadCrumbs interface is a breadcrumbs method, but the default IBreadCrumbsAdapter provides a default implementation for it that will look at the value returned by its parent_entity method. It also provides a default implementation for this method for entities adapting to the ITree interface, but as our File doesn't, we've to provide a custom adapter.

    screenshot of the breadcrumb component

    The breadcrumb component when on a file entity, now displaying parent folder.

    Step 4: preparing the release and migrating the instance

    Now that greatly enhanced our cube, it's time to release it and to upgrade production site. I'll probably detail that process later, but I currently simply transfer the new code to the server running the web site.

    However, there's some commands to get things done properly... First, as I've added some translatable string, I have to run:

    $ cubicweb-ctl i18ncube sytweb
    

    To update the cube's gettext catalogs (the '.po' files under the cube's i18n directory). Once the above command is executed, I'll then update translations.

    To see if everything is ok on my test instance, I do:

    $ cubicweb-ctl i18ninstance sytweb
    $ cubicweb-ctl start -D sytweb
    

    The first command compile i18n catalogs (e.g. generates '.mo' files) for my test instance. The second command starts it in debug mode, so I can open my browser and navigate through the web site to see if everything is ok...

    Note

    In the 'cubicweb-ctl i18ncube' command, sytweb refers to the cube, while in the two other, it refers to the instance (if you can't see the difference, reread CubicWeb's concept chapter !).

    Once I've checked it's ok, I simply have to bump the version number in the __pkginfo__ module to trigger a migration once I'll have updated the code on the production site. I can check the migration is also going fine, by first restoring a dump from the production site, then upgrading my test instance.

    To generate a dump from the production site:

    $ cubicweb-ctl db-dump sytweb
    pg_dump -Fc --username=syt --no-owner --file /home/syt/etc/cubicweb.d/sytweb/backup/tmpYIN0YI/system sytweb
    -> backup file /home/syt/etc/cubicweb.d/sytweb/backup/sytweb-2010-07-13_10-22-40.tar.gz
    

    I can now get back the dump file ('sytweb-2010-07-13_10-22-40.tar.gz') to my test machine (using scp for instance) to restore it and start migration:

    $ cubicweb-ctl db-restore sytweb sytweb-2010-07-13_10-22-40.tar.gz
    $ cubicweb-ctl upgrade sytweb
    

    You'll have to answer some questions, as we've seen in an earlier post.

    Now that everything is tested, I can transfer the new code to the production server, apt-get upgrade cubicweb 3.9 and its dependencies, and eventually upgrade the production instance.

    Conclusion

    This is a somewhat long post that starts showing you the way CubicWeb provides a highly configurable user interface, as well as powerful and reusable components. And there are a lot of others like those!

    So see you next time for part V, where we'll probably want to do more ui stuff!


  • CubicWeb 3.9 released

    2010/07/12 by Sylvain Thenault

    CubicWeb 3.9.0 went out last week. We now have tested it in production and fixed the remaining bugs, which means it is now show time!

    http://www.cubicweb.org/file/1179905?vid=download

    What's new in CubicWeb 3.9?

    The 3.9 release development was started by a one week long sprint at the beginning of May. The two goals were first to make it easier to customize the look and feel of a CubicWeb application, and second to do a big cleanup of the javascript library. This led to the following major changes.

    • We introduced property sheets, which replace former external_resources file, as well as define some constants that will be used to 'compile' cubicweb and cubes' stylesheets.
    • We started a new, clean cubicweb.css stylesheet, that tries to keep up with the rhythm. This is still a work in progress, and by default the old css is still used, unless specified otherwise in the configuration file.
    • We set the bases for web functional testing using windmill. See test cases in cubicweb/web/test/windmill/ and python wrapper in cubicweb/web/test_windmill/ if you want to use this in your own cube.
    • We set the bases for javascript unit-testing using qunit. See test cases in cubicweb/web/test/jstests/ and python wrapper in cubicweb/web/test_jscript/ if you want to use this in your own cube.
    • We cleaned the javascript code: the generic stuff moved into the cw namespace, the ajax api is now much simpler thanks to more generic and powerful functions. As usual backward compatibility was kept, which means that your existing code will still run, but you will see tons of deprecation warnings in the firebug console.
    • We implemented a simple documentation extraction system for javascript. Just put ReST in javascript comments, and get all the power of sphinx for documenting your javascript code.

    But that's not all! There are also two major changes in 3.9.

    http://www.cubicweb.org/file/1179904?vid=download

    Architectural change: adapters

    The first major change is the introduction of adapters, also found in the Zope Component Architecture and documented in the GoF book. This will allow for better application design and easier code reuse. You can see several usage in the framework, for instance the "ITree" adapter in cubicweb.entities.adapters, the "IBreadCrumbs" adapter in cubicweb.web.views.ibreadcrumbs, or still the "ICalendarable" adapter in cubicweb.web.views.calendar.

    Important full search improvement

    The second major change will benefit directly to end users: we worked with our friends from SecondWeb to expose the ranking feature found in postgres full-text search. This clearly improves the user experience when doing full-text searches. Ranking may be finely tuned by setting different weights to entity types, entity types attributes, or even be dynamically computed per entity instance. Of course, all this is done in an adapter, see "IFTIndexableAdapter" in cubicweb/entities/adapters.py.

    Minor changes

    Other minor changes include:

    • support for wildcard text search for application using postgres >= 8.4 as backend. Try searching for 'cub*' on cubicweb.org for instance.
    • inline edition of composite relation
    • nicer, clickable, schema image of the data model
    • enhanced support for the SQLserver database

    Enjoy!


  • Using RQL's HAVING clause to by-pass limitation of the WHERE clause

    2010/06/09 by Sylvain Thenault

    The HAVING clause, as in SQL, has been originally introduced to restrict a query according to value returned by an aggregat function, e.g.:

    Any X GROUPBY X WHERE X relation Y HAVING COUNT(Y) > 10
    

    It may however be used for something else...

    For instance, let's say you want to get people whose uppercased first name equals to another person uppercased first name. Since in the WHERE clause, we are limited to 3-expression (<subject> <relation> <object>), such thing can't be expressed (believe me or try it out). But this can be expressed using HAVING comparison expression:

    Person X WHERE X firstname XFN, Y firstname YFN HAVING X > Y, UPPER(XFN) = UPPER(YFN)
    

    Nice, no? This open some new possibilities. Another example:

    Person X WHERE X birthday XB HAVING YEAR(XB) = 2000
    

    Get it? That lets you use transformation functions not only in selection but for restriction as well, which was the major flaw in the RQL language.

    Notice that while we would like this to work without the HAVING clause, this can't be currently be done because it introduces an ambiguity in RQL's grammar that can't be handled by yapps, the parser's generator we're using.


  • Deactivating the 'reledit' feature

    2010/06/09 by Sylvain Thenault

    The 'reledit' feature is the one that makes attributes/relations editable in entity's primary view for authorized users (you know, the pen that appears when your mouse is over a field's value, clicking on it making a form to edit this field appears).

    This is a nice feature, but you may not want it. It can be easily deactivated everywhere it's used automatically in the site by using the code snippet below:

    from cubicweb.web.views import editforms
    
    class DeactivatedAutoClickAndEditFormView(editforms.AutoClickAndEditFormView):
        def should_edit_attribute(self, entity, rschema, form):
            return False
    
        def should_edit_relation(self, entity, rschema, role, rvid):
            return False
    
    def registration_callback(vreg):
        vreg.register_and_replace(DeactivatedAutoClickAndEditFormView,
                                  editforms.AutoClickAndEditFormView)
    

  • Django, lessons learned in the world of startup companies

    2010/06/02 by Sandrine Ribeau

    I went to the BayPIGgies meeting last thursday. The talk of this session was led by the chief software architect of RubberCan, Barnaby Bienkowski. The idea was to explain why Django turns out to be the choice a lot of startups make when building their web applications.

    Governement 2.0

    http://assets.sunlightfoundation.com/site/3.0/images/sf_logo_trans.png

    The fact that Django is recommended by Sunlight Foundation is important. This foundation is a non-partisan, non-profit organization based in Washington, DC that focuses on the digitization of government data and the creation of tools and Web sites to make that data easily accessible for all citizens. This is part of what is called Governement 2.0. It is a neologism for attempts to apply the social networking and integration advantages of Web 2.0 to the practice of government (see E-Governement).

    It looks like the Sunlight Foundation recommends Django because it comes from the publishing industry. I am not sure what is so special about this, but I wish I could get more details on it, so please add your comments below.

    Since the CubicWeb's community is still small, we are not yet recommended by such a large foundation, but we'll make more effort to talk about it and try to expand our community.

    Geo-localization

    http://geodjango.org/images/globe.png

    These days, geo-localization is a big deal in most applications. On that matter, what Django has to offer is GeoDjango, that recently became part of the Django core. It is integrated with the ORM and has pre-generated SQL queries, but it is not optimized. It uses PostGIS, which adds support for geographic objects to the PostgreSQL object-relational database. GeoDjango strives to make it as simple as possible to create geographic web applications, like location-based services. Some of the features it provides are:

    • Extensions to Django’s ORM for the querying and manipulation of spatial data
    • Editing of geometry fields inside the administration panels
    • Loosely-coupled, high-level Python interfaces for GIS geometry operations and data formats.
    http://openstreetmap.org/images/osm_logo.png?1271689861

    OpenStreetMap is used for the backend. It provides geographic data for any part of the world. This is a nice feature and we should consider it for CubicWeb. What we provide so far is an interface IGeocodable with related views gmap-view, gmap-bubble, geocoding-json and gmap-legend. We do not query this data yet, we simply render them nicely in a Google Map. You can find the details on how to use it here.

    Online stores

    Numerous web applications are not only service or data providers, they sell something. Satchmo is the Django tool to easily build online stores. It provides a shopping cart framework with checkout using different payment modules such as Authorize.net, TrustCommerce, CyberSource, PayPal, Google Checkout or Protx.

    CubicWeb does not provide a component allowing to build an online store, it's not yet a domain we worked on. But I'd like to talk a bit about the cube cubicweb-shoppingcart. This cube defines shopping item and shopping cart, and enables to add items to the shopping cart. It defines type of shopping items and only those can be added to the shopping cart. Whereas Satchmo required to define categories and add items within a category, cubicweb-shoppingcart does not oblige to define categories. Creating shopping items is the only thing you need to do. That makes this component usable not only for online store. For example, we used this cube to manage Euroscipy registration fees reusing the generic schema of a "virtual" shopping cart and its related ressources (web widgets, validation hook, ...).

    Re-usable components

    http://pinaxproject.com/site_media/img/pinax_logo.png

    Pinax has a overall good satisfaction as it supports basics components for blogging, tagging, registration, notification and so on. But one point that was raised, is the difficulty of customizing Pinax components. It seems easy to write your own version of Pinax components, but to integrate them is a pain. All the components are tightly related and by customizing one, there is a big chance it will affect the other components.

    This last point is a big disadvantage. Why? Well, as a developer there is always something that you need to adjust to fit your needs. So customizing components is something you will not avoid while developing your web application. And something I'd like to point about CubicWeb, is its simplicity of re-using existing components, which are independent from each others. This is as easy as Python inheritance. And with its VRegistry, selectors and application objects (see The VRegistry, selectors and application objects for more details), customization is well integrated into the framework.

    Assemble cubes and functionalities is very easy as well. Let's think of an example. We have those three cubes: cubicweb-book, cubicweb-tag and cubicweb-comment. Cubicweb-book defines Book entity type. Cubicweb-tag defines Tag entities and the ability to tag other entity types. Cubicweb-comment defines Comment entity type and the ability to comment other entity types. What if we want to create an application in which we could tag and comment Book. Well, this is done with the following schema definition where we explicitly define the relations between Book, Tag and Comment entity types:

    from yams.buildobjs import RelationDefinition
    class comments(RelationDefinition):
        subject = 'Comment'
        object = 'Book'
        cardinality = '1*'
        composite = 'subject'
    
    class tag(RelationDefinition):
        subject = 'Tag'
        object = 'Book'
        cardinality = '**'
    

    Forms

    Despite the fact that forms are easy in Django, there is no way to add inline entities, at least for now (see this proposition) as easily as in CubicWeb (see HTML form construction for more details). That is very neat when you create/edit related entities. Plus, since CubicWeb 3.6, forms are much easier to handle, and we still put a lot of effort into making it simplier.

    So, yes, overall Django is selected as the best compromise, but for the reason I listed, CubicWeb should be considered.

    Watch out Django, we are getting on your way ;)


  • OSCON 2010 discount!!

    2010/05/21 by Sandrine Ribeau
    http://assets.en.oreilly.com/1/event/45/oscon2010_12year.png

    Since Logilab will be presenting CubicWeb at OSCON, we get to have a discount code giving 20% rebate on OSCON registration. Please feel free to use this discount code while registering: os10fos.

    See you there!


  • Building my photos web site with CubicWeb part III: storing images on the file-system

    2010/05/20 by Sylvain Thenault

    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 BytesFileSystemStorage storage for the File/Image 'data' attribute, which holds the actual file's content.

    Since the function to register a custom storage needs to have a repository instance as a first argument, we have to call it in a server startup hook. So I added it in cubes/sytweb/hooks.py :

    from os import makedirs
    from os.path import join, exists
    
    from cubicweb.server import hook
    from cubicweb.server.sources import storage
    
    class ServerStartupHook(hook.Hook):
        __regid__ = 'sytweb.serverstartup'
        events = ('server_startup', 'server_maintenance')
    
        def __call__(self):
            bfssdir = join(self.repo.config.appdatahome, 'bfss')
            if not exists(bfssdir):
                makedirs(bfssdir)
                print 'created', bfssdir
            storage = storages.BytesFileSystemStorage(bfssdir)
            set_attribute_storage(self.repo, 'File', 'data', storage)
            set_attribute_storage(self.repo, 'Image', 'data', storage)
    

    Note

    • how we built the hook's registry identifier (_regid__): you can introduce 'namespaces' by using their python module like naming identifiers. This is especially important for hooks where you usually want a new custom hook, not overriding / specializing an existent one, but the concept may be used for any application objects
    • we catch two events here: "server_startup" and "server_maintenance". The first is called on regular repository startup (eg, as a server), the other for maintenance task such as shell or upgrade. In both cases, we need to have the storage set, else we'll be in trouble...
    • the path given to the storage is the place where a file added through the ui (or in the database before migration) will be located
    • be aware that by doing this, you can't write queries that will try to restrict on the File and the Image data attribute anymore. Thankfully we don't usually do that on a 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 migrate existing data so that the file's content will be stored on the file-system instead of the database. There is a migration command to do so, let's run it in the cubicweb shell (in actual life, you'd have to put it in a migration script as we saw last time):

    $ cubicweb-ctl shell sytweb
     entering the migration python shell
     just type migration commands or arbitrary python code and type ENTER to execute it
     type "exit" or Ctrl-D to quit the shell and resume operation
     >>> storage_changed('File', 'data')
     [........................]
     >>> storage_changed('Image', 'data')
     [........................]
    

    That's it. Now, the files added through the web ui will have their content stored on the file-system, and you'll also be able to import files from the file-system as explained in the next part.

    Step 2: importing some data into the instance

    Hey, we're starting to have some nice features, let's give this new web site a try. For instance if I have a 'photos/201005WePyrenees' containing pictures for a particular event, I can import it to my web site by typing

    $ cubicweb-ctl fsimport -F sytweb photos/201005WePyrenees/
    ** importing directory /home/syt/photos/201005WePyrenees
      importing IMG_8314.JPG
      importing IMG_8274.JPG
      importing IMG_8286.JPG
      importing IMG_8308.JPG
      importing IMG_8304.JPG
    

    Note

    The -F option tell that folders should be mapped, hence my photos will be all under a Folder entity corresponding to the file-system folder.

    Let's take a look at the web ui:

    http://www.cubicweb.org/file/972765?vid=download

    Nothing different, I can't see the new folder... But remember our security model! By default, files are only accessible to authenticated users, and I'm looking at the site as anonymous, e.g. not authenticated. If I login, I can now see:

    http://www.cubicweb.org/file/972766?vid=download

    Yeah, it's there! You can also notice that I can see some entities as well as folders and images the anonymous users can't. It just works everywhere in the ui since it's handled at the repository level, thanks to our security model.

    Now if I click on the newly inserted folder, I can see

    http://www.cubicweb.org/file/972767?vid=download

    Great! I get my pictures in the folder. I can now give a nicer name to this folder (provided I don't intend to import from it anymore, else already imported photos will be reimported), change permissions, title for some pictures, etc... Having good content is much more difficult than having a good web site ;)

    Conclusion

    We started to see here an advanced feature of our repository: the ability to store some parts of our data-model into a custom storage, outside the database. There is currently only the BytesFileSystemStorage available, but you can expect to see more coming in a near future.

    Also, we can now start to feed our web-site with some nice pictures! The site isn't perfect (far from it actually) but it's usable, and we can start using it and improve it on the way. The Incremental Cubic Way :)

    So see you next time to start tweaking the user interface!


  • CSS+JS sprint report - Day 1 and 2 (April 2010)

    2010/04/30 by Adrien Di Mascio

    These first two days essentially consisted in exploring the javascript world.

    Documenting javascript

    Sandrine and Alain worked on the javascript documentation tools and how they could be integrated into our sphinx generated documentation.

    http://www.percious.com/static/images/blog/sphinx.png

    They first studied pyjsdoc which unfortunately only generates HTML. After a somewhat successful attempt to generate sphinx ReST, we decided to use a consistent documentation format between python modules and js modules and therefore switched to a home-made, very simple javascript comment parser. Here's an example of what the parser understands:

    /**
     * .. cfunction:: myFunction(a, b, /*...*/, c, d)
     *
     *    This function is very **well** documented and does quite
     *    a lot of stuff :
     *    - task 1
     *    - task 2
     *
     *    :param a: this is the first parameter
     *    ...
     *    :return: 42
     */
    function myFunction(a, b, /*...*/, c, d) {
    }
    

    The extracted ReST snippets are then concatenated and inserted in the general documentation.

    Unit testing javascript

    Katia, Julien and Adrien looked at the different testing tools for javascript, with the two following goals in mind:

    • low-level unit testing, as cubicweb agnostic as possible
    • high-level / functional testing, we want to write navigation scenarios and replay them

    And the two winners of the exploration are:

    http://www.t0asted.com/getwindmill/wm_logo_round.png
    • QUnit for pure javascript / DOM testing. Julien and Adrien successfully managed to test a few cubicweb js functions, most notably the loadxhtml jquery plugin.
    • Windmill for higher level testing. Katia and Sylvain were able to integrate Windmill within the CubicWeb unit testing framework.

    Of course, there is still a lot of work that needs to be done. For instance, we would like to have a test runner facility to run QUnit-based tests on multiple platforms / browsers automatically.

    Parametrized stylesheets and vertical rhythm

    Sylvain worked on property sheets and managed to implement compiled CSS based on simple string interpolation. Of course, compiled CSS are still HTTP cached, automatically recompiled on debug mode, etc. On his way, he also got rid of the external_resources file. Backward compatibility will of course be guaranteed for a while.

    Nicolas worked on CSS and vertical rythm and prepared a patch that introduces a basic rhythm. The tedious work will be to get every stylesheet to dance to the beat.


  • CubicWeb sprint in Paris about js and css

    2010/04/29 by Arthur Lutz

    Logilab is once again hosting a sprint around CubicWeb - 5 days in our Paris offices.

    The general focus will be around javascript & css :

    http://www.iconarchive.com/icons/enhancedlabs/lha-objects/128/Filetype-CSS-icon.png http://codesnip.net/wp-content/uploads/javascript.png
    • easily change the style of an application
    • handling of bundles merging javascript and css
    • have a clean javascript API, documented and tested
    • have documentation about the css & javascript parts in the cubicweb book

    This sprint is taking place from thursday the 29th of April 2010 to the 5th of may 2010 (weekend is off limits - the offices will be closed). You are more than welcome to come along and help out, contribute, or just pair program with someone. Coming only for a day, or an afternoon is fine too... Network resources will be available for those bringing laptops.

    Address : 104 Boulevard Auguste-Blanqui, Paris. Ring "Logilab".

    Metro : St Jacques or Corvisart (Glacière is closest, but will be closed from monday onwards)

    Contact : http://www.logilab.fr/contact

    Dates : 29/04/2010 to 30/04/2010 and 03/05/2010 to 05/05/2010


  • CubicWeb 3.8 released

    2010/04/28 by Sylvain Thenault

    CubicWeb 3.8.0 went out last week, but now we have tested it, produced a 3.8.1, it's show time!

    What's new in CubicWeb 3.8?

    One of the most important change is http server update to move from deadend twisted.web2 to twisted.web. With this change comes the possibility to configure the maximum size of POST request in the configuration file (was hard-coded to 100Mo before).

    Other changes include:

    • CubicWeb should now be installable through pip or easy_install. This is still experimental, and we don't use it that much so please, give us some feedback! Some cubes are now also "pipable" (comment, blog...), but more will come with new releases.
    • .execute() function lost its cache key argument. This is great news since it was a pain to explain and most cubicweb users didn't know how to handle it well (and I'm thre greatest beneficer since I won't have to explain over and over again)
    • nicer schema and workflow views
    • refactored web session handling, which should now be cleaner, clearer, hence less buggy...
    • nicer skeleton generation for new cubes, cleaner __pkginfo__ (you don't have to define both __depends__ / __depends_cubes__ or __recommends__ / __recommends_cubes__ in the general case, and other cleanups)

    Enjoy!


  • Migrating cubicweb instances - benefits from a distributed architecture

    2010/04/22 by Arthur Lutz

    Aim : do the migration for N cubicweb instances hosted on a server to another with no downtime.

    Prerequisites : have an explicit definition of the database host (not default or localhost). In our case, the database is hosted on another host. You are not migrating your pyro server. You are not using multisource (more documentation on that soon).

    Steps :

    1. on new machine : install your environment (pseudocode)

      apt-get install cubicweb cubicweb-applications apache2
      
    2. on old machine : copy your cubicweb and apache configuration to the new machine

      scp /etc/cubicweb.d/ newmachine:/etc/cubicweb.d/
      scp /etc/apache2/sites-available/ newmachine:/etc/apache2/sites-available/
      
    3. on new machine : give new ids to pyro registration so the new instances can register

      cd /etc/cubicweb.d/ ; sed -i.bck 's/^pyro-instance-id=.*$/\02/' */all-in-one.conf
      
    4. on new machine : start your instances

      cubicweb start
      
    5. on new machine : enable sites and modules for apache and start it, test it using by modifying your /etc/host file.

    6. change dns entry from your oldmachine to newmachine

    7. shutdown your old machine (if it doesn't host other services or your database)

    8. That's it.

    Possible enhancements : use right from the start a pound server behind your apache, that way you can add backends and smoothily migrate by shuting down backends that pound will take into account.

    http://www.cubicweb.org/file/893561?vid=download

  • Documentation progress

    2010/04/20 by Aurelien Campeas

    As part of an effort to improve the documentation (see the cw_course version) a lot of chapters have been completed (and filled with real-world examples). Many more were updated and reorganized.

    I won't list everything but here are the most important improvements:

    picture under creative commons

    Picture under Creative Commons, courtesy of digitalnoise.

    • The publishing process
    • Templates & the architecture of views
    • Primary views customizations (including use of the uicfg module)
    • Controllers
    • Hooks & Operations
    • Proper usage of the ORM
    • Unit tests
    • Breadcrumbs
    • URL rewrite
    • Using the CW javascript library

    Last but not least, a whole new tutorial based on Sylvain's great series Building my photos Web site has been included. It covers some advanced topics such as Operations and sophisticated security settings.

    The visual style has been enhanced a bit to have better readability.

    As always, patches are welcome !

    picture under Creative Commons, courtesy of digitalnoise


  • Building my photos web site with CubicWeb part II: security, testing and migration

    2010/04/13 by Sylvain Thenault

    This post will cover various topics:

    • configuring security
    • migrating an existing instance
    • writing some unit tests

    Goal

    Here are the read permissions I want:

    • folders, files, images and comments should have one of the following visibility rules:
      • 'public', everyone can see it
      • 'authenticated', only authenticated users can see it
      • 'restricted', only a subset of authenticated users can see it
    • managers (e.g. me) can see everything
    • only authenticated users can see people
    • everyone can see classifier entities (tag and zone)

    Also, unless explicity specified, the visibility of an image should be the same as the visibility of its parent folder and the visibility of a comment should be the same as the one of the commented entity. If there is no parent entity, the default visibility is 'authenticated'.

    Regarding write permissions, that's much easier:

    • the anonymous user can't write
    • authenticated users can only add comment
    • managers will add the remaining stuff

    Now, let's implement that!

    Proper security in CubicWeb is done at the schema level, so you don't have to bother with it in the views, for the users will only see what they have access to.

    Step 1: adding permissions to the schema

    In the schema, you can grant access according to groups or RQL expressions (users get access if the expression return some results). To implements the read security defined above, groups are not enough, we'll need to use RQL expressions. Here is the idea:

    • add a visibility attribute on folder, image and comment, with a vocabulary ('public', 'authenticated', 'restricted', 'parent')
    • add a may_be_read_by relation that links folder, image or comment to users,
    • add hooks to propagate permission changes.

    So the first thing to do is to modify the schema.py of my cube to define these relations:

    from yams.constraints import StaticVocabularyConstraint
    
    class visibility(RelationDefinition):
        subject = ('Folder', 'File', 'Image', 'Comment')
        object = 'String'
        constraints = [StaticVocabularyConstraint(('public', 'authenticated',
                                                   'restricted', 'parent'))]
        default = 'parent'
        cardinality = '11' # required
    
    class may_be_read_by(RelationDefinition):
        subject = ('Folder', 'File', 'Image', 'Comment',)
        object = 'CWUser'
    

    We can note the following points:

    • we've added a new visibility attribute to folder, file, image and comment using a RelationDefinition
    • cardinality = '11' means this attribute is required. This is usually hidden under the required argument given to the String constructor, but we can rely on this here (same thing for StaticVocabularyConstraint, which is usually hidden by the vocabulary argument)
    • the 'parent' possible value will be used for visibility propagation

    Now, we should be able to define security rules in the schema, based on these new attribute and relation. Here is the code to add to schema.py:

    from cubicweb.schema import ERQLExpression
    
    VISIBILITY_PERMISSIONS = {
        'read':   ('managers',
                   ERQLExpression('X visibility "public"'),
                   ERQLExpression('X visibility "authenticated", U in_group G, G name "users"'),
                   ERQLExpression('X may_be_read_by U')),
        'add':    ('managers',),
        'update': ('managers', 'owners',),
        'delete': ('managers', 'owners'),
        }
    AUTH_ONLY_PERMISSIONS = {
            'read':   ('managers', 'users'),
            'add':    ('managers',),
            'update': ('managers', 'owners',),
            'delete': ('managers', 'owners'),
            }
    CLASSIFIERS_PERMISSIONS = {
            'read':   ('managers', 'users', 'guests'),
            'add':    ('managers',),
            'update': ('managers', 'owners',),
            'delete': ('managers', 'owners'),
            }
    
    from cubes.folder.schema import Folder
    from cubes.file.schema import File, Image
    from cubes.comment.schema import Comment
    from cubes.person.schema import Person
    from cubes.zone.schema import Zone
    from cubes.tag.schema import Tag
    
    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
    Zone.__permissions__ = CLASSIFIERS_PERMISSIONS
    Tag.__permissions__ = CLASSIFIERS_PERMISSIONS
    

    What's important in there:

    • VISIBILITY_PERMISSIONS provides read access to an entity:
      • if user is in the 'managers' group,
      • or if visibility attribute's value is 'public',
      • or if visibility attribute's value is 'authenticated' and user (designed by the 'U' variable in the expression) is in the 'users' group (all authenticated users are expected to be in this group)
      • or if user is linked to the entity (the 'X' variable) through the may_be_read_by permission
    • we modify permissions of the entity types we use by importing them and modifying their __permissions__ attribute
    • notice the .copy(): we only want to modify 'add' permission for Comment, not for all entity types using VISIBILITY_PERMISSIONS!
    • remaning parts of the security model is done using regular groups:
      • 'users' is the group to which all authenticated users will belong
      • 'guests' is the group of anonymous users

    Step 2: security propagation in hooks

    To fullfill our requirements, we have to implement:

    Also, unless explicity specified, the visibility of an image should be the same as
    the visibility of its parent folder and the visibility of a comment should be the same as the
    one of the commented entity. If there is no parent entity, the default visibility is
    'authenticated'.
    

    This kind of 'active' rule will be done using CubicWeb's hook system. Hooks are triggered on database event such as addition of new entity or relation.

    The tricky part of the requirement is in unless explicitly specified, notably because when the entity addition hook is executed, we don't know yet its 'parent' entity (eg folder of an image, image 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:

    • on entity creation, schedule an operation that will set default visibility
    • when a "parent" relation is added, propagate parent's visibility unless the child already has a visibility set

    Here is the code in cube's hooks.py:

    from cubicweb.selectors import implements
    from cubicweb.server import hook
    
    class SetVisibilityOp(hook.Operation):
        def precommit_event(self):
            for eid in self.session.transaction_data.pop('pending_visibility'):
                entity = self.session.entity_from_eid(eid)
                if entity.visibility == 'parent':
                    entity.set_attributes(visibility=u'authenticated')
    
    class SetVisibilityHook(hook.Hook):
        __regid__ = 'sytweb.setvisibility'
        __select__ = hook.Hook.__select__ & implements('Folder', 'File', 'Image', 'Comment')
        events = ('after_add_entity',)
        def __call__(self):
            hook.set_operation(self._cw, 'pending_visibility', self.entity.eid,
                               SetVisibilityOp)
    
    class SetParentVisibilityHook(hook.Hook):
        __regid__ = 'sytweb.setparentvisibility'
        __select__ = hook.Hook.__select__ & hook.match_rtype('filed_under', 'comments')
        events = ('after_add_relation',)
    
        def __call__(self):
            parent = self._cw.entity_from_eid(self.eidto)
            child = self._cw.entity_from_eid(self.eidfrom)
            if child.visibility == 'parent':
                child.set_attributes(visibility=parent.visibility)
    

    Remarks:

    • hooks are application objects, hence have selectors that should match entity or relation type to which the hook applies. To match relation type, we use the hook specific match_rtype selector.
    • usage of set_operation: instead of adding an operation for each added entity, set_operation allows to create a single one and to store the eids of the entities to be processed in the session transaction data. This is a good pratice to avoid heavy operations manipulation cost when creating a lot of entities in the same transaction.
    • the precommit_event method of the operation will be called at transaction's commit time.
    • in a hook, self._cw is the repository session, not a web request as usually in views
    • according to hook's event, you have access to different member on the hook instance. Here:
      • self.entity is the newly added entity on 'after_add_entity' events
      • self.eidfrom / self.eidto are the eid of the subject / object entity on 'after_add_relation' events (you may also get the relation type using self.rtype)

    The 'parent' visibility value is used to tell "propagate using parent security" because we want that attribute to be required, so we can't use None value else we'll get an error before we get any chance to propagate...

    Now, we also want to propagate the may_be_read_by relation. Fortunately, CubicWeb provides some base hook classes for such things, so we only have to add the following code to hooks.py:

    # relations where the "parent" entity is the subject
    S_RELS = set()
    # relations where the "parent" entity is the object
    O_RELS = set(('filed_under', 'comments',))
    
    class AddEntitySecurityPropagationHook(hook.PropagateSubjectRelationHook):
        """propagate permissions when new entity are added"""
        __regid__ = 'sytweb.addentity_security_propagation'
        __select__ = (hook.PropagateSubjectRelationHook.__select__
                      & hook.match_rtype_sets(S_RELS, O_RELS))
        main_rtype = 'may_be_read_by'
        subject_relations = S_RELS
        object_relations = O_RELS
    
    class AddPermissionSecurityPropagationHook(hook.PropagateSubjectRelationAddHook):
        __regid__ = 'sytweb.addperm_security_propagation'
        __select__ = (hook.PropagateSubjectRelationAddHook.__select__
                      & hook.match_rtype('may_be_read_by',))
        subject_relations = S_RELS
        object_relations = O_RELS
    
    class DelPermissionSecurityPropagationHook(hook.PropagateSubjectRelationDelHook):
        __regid__ = 'sytweb.delperm_security_propagation'
        __select__ = (hook.PropagateSubjectRelationDelHook.__select__
                      & hook.match_rtype('may_be_read_by',))
        subject_relations = S_RELS
        object_relations = O_RELS
    
    • the AddEntitySecurityPropagationHook will propagate the relation when filed_under or comments relations are added
      • the S_RELS and O_RELS set as well as the match_rtype_sets selector are used here so that if my cube is used by another one, it'll be able to configure security propagation by simply adding relation to one of the two sets.
    • the two others will propagate permissions changes on parent entities to children entities

    Step 3: testing our security

    Security is tricky. Writing some tests for it is a very good idea. You should even write them first, as Test Driven Development recommends!

    Here is a small test case that'll check the basis of our security model, in test/unittest_sytweb.py:

    from cubicweb.devtools.testlib import CubicWebTC
    from cubicweb import Binary
    
    class SecurityTC(CubicWebTC):
    
        def test_visibility_propagation(self):
            # create a user for later security checks
            toto = self.create_user('toto')
            # init some data using the default manager connection
            req = self.request()
            folder = req.create_entity('Folder',
                                       name=u'restricted',
                                       visibility=u'restricted')
            photo1 = req.create_entity('Image',
                                       data_name=u'photo1.jpg',
                                       data=Binary('xxx'),
                                       filed_under=folder)
            self.commit()
            photo1.clear_all_caches() # good practice, avoid request cache effects
            # visibility propagation
            self.assertEquals(photo1.visibility, 'restricted')
            # unless explicitly specified
            photo2 = req.create_entity('Image',
                                       data_name=u'photo2.jpg',
                                       data=Binary('xxx'),
                                       visibility=u'public',
                                       filed_under=folder)
            self.commit()
            self.assertEquals(photo2.visibility, 'public')
            # 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('Folder X')), 0) # restricted...
            # may_be_read_by propagation
            self.restore_connection()
            folder.set_relations(may_be_read_by=toto)
            self.commit()
            photo1.clear_all_caches()
            self.failUnless(photo1.may_be_read_by)
            # 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('Folder X')), 1) # and to restricted folder
    
    if __name__ == '__main__':
        from logilab.common.testlib import unittest_main
        unittest_main()
    

    It is not complete, but it shows most of the things you will want to do in tests: adding some content, creating users and connecting as them in the test, etc...

    To run it type:

    [syt@scorpius test]$ pytest unittest_sytweb.py
    ========================  unittest_sytweb.py  ========================
    -> creating tables [....................]
    -> inserting default user and default groups.
    -> storing the schema in the database [....................]
    -> database for instance data initialized.
    .
    ----------------------------------------------------------------------
    Ran 1 test in 22.547s
    
    OK
    

    The first execution is taking time, since it creates a sqlite database for the test instance. The second one will be much quicker:

    [syt@scorpius test]$ pytest unittest_sytweb.py
    ========================  unittest_sytweb.py  ========================
    .
    ----------------------------------------------------------------------
    Ran 1 test in 2.662s
    
    OK
    

    If you do some changes in your schema, you'll have to force regeneration of that database. You do that by removing the tmpdb* files before running the test:

    [syt@scorpius test]$ rm tmpdb*
    

    BTW, pytest is a very convenient utilities to control test execution, from the logilab-common package.

    Step 4: writing the migration script and migrating the instance

    Prior to those changes, Iv'e created an instance, fed it with some data, so I don't want to create a new one, but to migrate the existing one. Let's see how to do that.

    Migration commands should be put in the cube's migration directory, in a file named file:<X.Y.Z>_Any.py ('Any' being there mostly for historical reason).

    Here I'll create a migration/0.2.0_Any.py file containing the following instructions:

    add_relation_type('may_be_read_by')
    add_relation_type('visibility')
    sync_schema_props_perms()
    

    Then I update the version number in cube's __pkginfo__.py to 0.2.0. And that's it! Those instructions will:

    • update the instance's schema by adding our two new relations and update the underlying database tables accordingly (the two first instructions)
    • update schema's permissions definition (the later instruction)

    To migrate my instance I simply type:

    [syt@scorpius ~]$ cubicweb-ctl upgrade sytweb
    

    I will then be asked some questions to do the migration step by step. You should say YES when it asks if a backup of your database should be done, so you can get back to the initial state if anything goes wrong...

    Conclusion

    This is a somewhat long post that I bet you will have to read at least twice ;) There is a hell lot of information hidden in there... But that should start to give you an idea of CubicWeb's power...

    See you next time for part III !


  • Building my photos web site with CubicWeb (Part I)

    2010/04/01 by Sylvain Thenault

    Desired features

    • photo gallery;
    • photo stored onto the fs and displayed through a web interface dynamically;
    • navigation through folder (album), tags, geographical zone, people on the picture... using facets;
    • advanced security (eg not everyone can see everything). More on this later.

    Let's go then

    Step 1: creating a new cube for my web site

    One note about my development environment: I wanted to use packaged version of CubicWeb and cubes while keeping my cube in my user directory, let's say ~src/cubes. It can be done by setting the following environment variables:

    CW_CUBES_PATH=~/src/cubes
    CW_MODE=user
    

    The new cube, holding custom code for this web site, can now be created using:

    cubicweb-ctl newcube --directory=~/src/cubes sytweb
    

    Step 2: pick building blocks into existing cubes

    Almost everything I want to represent in my web-site is somewhat already modelized in existing cubes that I'll extend for my needs:

    • folder, containing Folder entity type, which will be used as 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 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 situated_in relation.
    • person, containing the Person entity type plus some basic views.
    • comment, providing a full commenting system allowing one to comment entity types supporting the comments relation by adding a Comment entity.
    • tag, providing a full tagging system as an easy and powerful way to classify entities supporting the tags relation by linking the to Tag entities. This will allow navigation into a large number of pictures.

    Ok, now I'll tell my cube requires all this by editing cubes/sytweb/__pkginfo__.py:

    __depends_cubes__ = {'file': '>= 1.2.0',
                         'folder': '>= 1.1.0',
                         'person': '>= 1.2.0',
                         'comment': '>= 1.2.0',
                         'tag': '>= 1.2.0',
                         'zone': None,
                         }
    __depends__ = {'cubicweb': '>= 3.5.10',
                   }
    for key,value in __depends_cubes__.items():
        __depends__['cubicweb-'+key] = value
    __use__ = tuple(__depends_cubes__)
    

    Notice that you can express minimal version of the cube that should be used, None meaning whatever version available.

    Step 3: glue everything together in my cube's schema

    from yams.buildobjs import RelationDefinition
    
    class comments(RelationDefinition):
        subject = 'Comment'
        object = ('File', 'Image')
        cardinality = '1*'
        composite = 'object'
    
    class tags(RelationDefinition):
        subject = 'Tag'
        object = ('File', 'Image')
    
    class filed_under(RelationDefinition):
        subject = ('File', 'Image')
        object = 'Folder'
    
    class situated_in(RelationDefinition):
        subject = 'Image'
        object = 'Zone'
    
    class displayed_on(RelationDefinition):
        subject = 'Person'
        object = 'Image'
    

    This schema:

    • allows to comment and tag File and Image entity types by adding the comments and tags relations. This should be all we have to do for this feature since the related cubes provide 'pluggable section' which are automatically displayed in the primary view of entity types supporting the relation.
    • adds a situated_in relation definition so that image entities can be geolocalized.
    • add a new relation displayed_on relation telling who can be seen on a picture.

    This schema will probably have to evolve as time goes (for security handling at least), but since the possibility to change and update the schema evolving is one of CubicWeb features (and goals), we won't worry and see that later when needed.

    Step 4: creating the instance

    Now that I have a schema, I want to create an instance of that new 'sytweb' cube, so I run:

    cubicweb-ctl create sytweb sytweb_instance
    

    hint: if you get an error while the database is initialized, you can avoid having to reanswer to questions by running

    cubicweb-ctl db-create sytweb_instance
    

    This will use your already configured instance and start directly from the database creation step, thus skipping questions asked by the 'create' command.

    Once the instance and database are fully initialized, run

    cubicweb-ctl start sytweb_instance
    

    to start the instance, check you can connect on it, etc...

    Next times

    We will customize the index page, see security configuration, use the Bytes FileSystem Storage... Lots of cool stuff remaining :)

    Next post : security, testing and migration


  • Fun with graphs in apycot

    2010/03/24 by Arthur Lutz

    Yesterday I had a little quick fun with apycot in the train, using the existing plots infrastructure I managed to quickly add a few graphs to the application. I only had an old dump of our apycot for mercurial (http://apycot.hg-scm.org/) so the timespan is not huge, but I like it anyway! Here are some dev screenshots while you wait for this feature your your application... The pylint grades where pretty constant so I'm not including that graph.

    http://www.cubicweb.org/file/779761?vid=download http://www.cubicweb.org/file/779768?vid=download

    Now, I have to make solid code and integrate it properly.


  • CubicWeb 3.7 released

    2010/03/19

    Hi there !

    I'm pleased to announce the 3.7 release of CubicWeb, after a much shorter development cycle than for the 3.6...

    But it still have some interesting changes:

    • NOW DEPENDS ON PYTHON 2.5
    • use the newly created logilab.database package (you'll have to install it as well as upgrade logilab.common and rql)
    • proper behaviour on the repository side of cubiweb:
      • dropped unsafe_execute, execute is now unsafe by default in hooks and operations. You can still explicitly control security using the enabled_secury context manager
      • proper transaction hooks control using the hooks_control context manager
    • started some transaction undo support (only undo of deletion supported right now)
    • various other bug fixes and improvments

    Notice the 3.6 branch will still be maintained for some time.

    Enjoy!


  • Continuous Integration platform for Mercurial with apycot

    2010/03/15 by Arthur Lutz

    Since the mercurial 1.5 sprint Pierre-Yves has been working on improving Continuous Integration for Mercurial. All developers are encouraged to run the test suites and code quality checkers but it's no always feasible to test every cases, different OS, different python versions, strange test dependencies, slow coverage run, etc. Moreover it's generally useful to keep track of the results of previous tests, especially for benchmarks.

    At http://apycot.hg-scm.org/ you will find a production setup that now runs several variants of the tests-suite for all official repo and checks code style and documentation. Notification by email or RSS is available. For more details check out the FAQ.

    apycot is open source and uses the cubicweb platform, if you want to set up one for your project, check out the step by step documentation.

    http://www.cubicweb.org/file/749160?vid=download

  • CubicWeb 3.6 is (almost) out!

    2010/02/10 by Sylvain Thenault

    And that's great news, after several months of development (things started moving in the beginning of august 2009...), it should be available on our Debian repositories and ftp site in the next few hours.

    So, we can say this release contains a (too) large set of improvements and refactorings. I'll talk about the most important ones here.

    Appobject/Entity classes namespace cleanup

    First of all, the namespace cleanup... 3.6 is a step towards cleaning the entity classes (hence more generally appobject), which are used for a lot of things, making it impossible to tell for sure what could be used or not as an attribute or relation name. We decided to declare identifiers starting with \_cw or cw\_ reserved for the core classes. A lot of methods have been deprecated to cleanup the base appobject class namespace. The remaining methods on entity classes will be removed in future version, by the introduction of an ORM for database related methods, and by the (most probable) introduction of ZCA adapters for other aspects. The most notable renaming are:

    • .req -> ._cw
    • .rset -> .cw_rset
    • .row -> .cw_row
    • .col -> .cw_col

    This is probably what you'll see first when upgrading to 3.6: a huge stack of deprecation warnings on your screen :)

    Another step towards a nice and powerful form system

    • cleaner reponsibilities separation between form, field and widget

    • fields and widgets are now responsible for handling POSTed values (the editcontroller was handling this, making things really unflexible). The editcontroller has been rewritten and now properly gets values from fields. Another benefit is that you can now easily have a widget handling multiple inputs (see the new datetime picker for instance, or the custom widget for Bookmark.path)

    • refactored automatic forms:

      • rewrite 'generic relations' as a field
      • inlined forms are now encapsulated into a field

      so you get much more control on these parts of automatic forms by using mechanism provided generally by fields

      • clearer form relations tags: removed autoform_is_inlined, more understandable autoform_field_section

    Hooks refactoring

    Hooks are now regular appobjects, with selectors (don't forget to reuse Hook.__select__, remember that !). They should simply implement __call__ with no argument (well, only self) and will get info previously passed as argument as instance attributes, according to the matching event.

    Test API cleanup

    EnvBasedTC, ControllerTC, WebTest, RepoBasedTC are all gone. Simply use CubicWebTC, with an unified API similar to what you use in cubicweb-ctl shell and in usual development.

    The Bytes File System Storage

    You can now specify a custom storage for attributes of entities stored in the system source. This mechanism is used to provide a way to store Bytes attributes (such as File.data for instance) as files on the file-system instead of BLOBs in the database. You can configure which attributes should use this storage for your instance and then everything is transparent.

    Schema definition changes (yams 0.27)

    In your schema definition file:

    • "symetric" should be correctly spelled "symmetric" :)
    • "permissions" was renamed to "__permissions__"

    Also, permissions for relations are now supported per definition, not per type, at the cost of a visible impact when writing/reading the schema.

    Note about backward compatibility

    We worked hard to keep backward compatibility, but you shouldn't upgrade to 3.6 without checking that everything is fine... Check notably:

    • forms, if you're using custom forms by overriding internal methods
    • import for date functions from cubicweb.utils (they moved to logilab.common.date)

    And also

    CubicWeb 3.6 comes with a set of 37 cubes "3.6"-ready to avoid too much warnings!

    Enjoy!


  • CubicWeb documentation mini-sprint report

    2010/02/10 by Sylvain Thenault

    We held a one day sprint last week in our Paris office, trying to improve CubicWeb's documentation.

    There is a huge work to do on this, much more than we can do on a one day sprint, even with many people. But you have to begin with something :)

    So, after a quick meeting to define priorities:

    • Stéphanie, Charles and later Sandrine (from her US home-office), began to add some documentation and screenshots to cubes. They started with the following cubes: addressbook, person, basket, tag, folder, forgotpwd, forge, tracker, vcsfile, keyword, blog and comment.
    • Julien explored sphinx abilities to build the index and extract docstrings. He applied this to improve the documentation of selectors.
    • Adrien (ach) and Celso, our friend from Mexico, tackled the task to improve the tutorial from a beginner's point of view.
    • Arthur added some pieces of documentation found in our intranet, mailing-list...
    • Pyves worked on a cubicweb-ctl command to generate schema images (png) for cubes, to include them in the cube's documentation.
    • Adrien (adim) and I helped the various teams.

    Huum, I think I did not forgot anyone...

    If there is still a lot to do (we need more doc sprints, stay tuned), this is really a nice start! This site should soon be updated to include more valuable cubes description and online documentation extracted from the contributed doc.


  • CubicWeb documentation sprint in feb. 2010

    2010/01/22 by Nicolas Chauvat
    http://farm4.static.flickr.com/3042/2871708248_950831962c_s.jpg

    On February 2nd, 2010 Logilab will host in its head offices a one-day sprint dedicated to the improvement of the CubicWeb documentation.

    Get in touch with Logilab if you want to participate in person or via the net: contact at logilab dot fr.

    Photo by Adam Hyde from the FLOSS blog


  • MS SQL Server backuping gotcha

    2010/01/19

    While working on the port of CubicWeb to the Windows platform, including supporting MS Sql Server as the database backend, I got bitten by a weird behavior of that database engine. When working with cubicweb, most administrations command are wrappped by the cubicweb-ctl utility and database backups are performed by running cubicweb-ctl db-dump <instancename>. If the instance uses PostgreSQL as the backend, this will call the pg_dump utility.

    When porting to Sql Server, I could not find such a utility, but I found that Transact SQL has a BACKUP DATABASE command, so I was able to call it using Python's pyodbc module. I tested it interactively, and was satisfied with the result:

    >>> from logilab.common.db import get_connection
    >>> cnx = get_connection(driver='sqlserver2005', database='mydb', host='localhost', extra_args='autocommit;trusted_connection')
    >>> cursor = cnx.cursor()
    >>> cursor.execute('BACKUP DATABASE ? TO DISK = ?', ('mydb', 'C:\\Data\\mydb.dump'))
    >>> cnx.close()
    

    However, testing that very same code through cubicweb-ctl produced no file in C:\\Data\\. To make a (quite) long story short, the thing is that the BACKUP DATABASE command is asynchronous (or maybe the odbc driver is) and the call to cursor.execute(...) will return immediately, before the backup actually starts. When running interactively, by the time I got to type cnx.close() the backup was finished but when running in a function, the connection was closed before the backup started (which effectively killed the backup operation).

    I worked around this by monitoring the size of the backup file in a loop and waiting until that size gets stable before closing the connection:

    import os
    import time
    from logilab.common.db import get_connection
    
    filename = 'c:\\data\\toto.dump'
    dbname = 'mydb'
    cnx = get_connection(driver='sqlserver2005',
                         host='localhost',
                         database=dbname,
                         extra_args='autocommit;trusted_connection')
    cursor = cnx.cursor()
    cursor.execute("BACKUP DATABASE ? TO DISK= ? ", (dbname, filename,))
    prev_size = -1
    err_count = 0
    same_size_count = 0
    while err_count < 10 and same_size_count < 10:
        time.sleep(1)
        try:
            size = os.path.getsize(filename)
            print 'file size', size
        except OSError, exc:
            err_count +=1
            print exc
        if size > prev_size:
            same_size_count = 0
            prev_size = size
        else:
           same_size_count += 1
    cnx.close()
    

    I hope sharing this will save some people time...

    Note: get_connection() comes from logilab.common.db which is a wrapper module which tries to simplify writing code for different database backends by handling once for all various idiosyncrasies. If you want pure pyodbc code, you can replace it with:

    from pyodbc import connect
    cnx = connect(driver='SQL Server Native Client 10.0',
                  host='locahost',
                  database=dbname,
                  trusted_connection='yes',
                  autocommit=True)
    

    The autocommit=True part is especially important, because BACKUP DATABASE will fail if run from within a transaction.


  • Distributed scalable architecture using CubicWeb

    2010/01/14 by Arthur Lutz

    Here is a small example of one the things you can do with cubicweb's scalable architecture when serving a large number of users.

    http://www.cubicweb.org/file/619085?vid=download

    Obviously you can easily add machines hosting CubicWeb to the middle bit to scale up. Adding multiple postgres servers is possible but more tricky. In a later blog I will also show a way of split CubicWeb servers onto multiple servers (separate the web engine from the data repository part). Debian is one of the possible host systems, you can use something else, it's just easier with debian...

    If you want a more detailed explanation of how we setup such an environment, please comment and we'll try to find the time to document it.

    As a systems administrator, I can then enjoy the use of the following tools :

    • clusterssh - to access all machines at once and do common task by only typing it once (a must!)
    • htop - to monitor resources in a nicer way than the simple top
    • iotop - to monitor input/output load
    • varnishist - to check varnish is properly caching some content
    • apachetop - to watch in real time what is being accessed on the apache server
    • jnettop - to watch network flows
    • apt-get (on debian) to install all this in a a few simple commands...

  • CubicWeb 3.6 sprint report

    2009/12/14 by Sylvain Thenault

    Last week we held a cubicweb sprint in our new Paris office !

    We were a nice number of people: 7 from the Logilab's crew, including Sandrine, our US representative, Celso and Carlos from Mexico, plus some others guests and colleagues working on (cubicweb based of course) customer projects.

    The objective of the sprint was to kick out the 3.6 version of cubicweb, a big refactoring release started by Adrien and I a few months ago. Unfortunatly we had been preempted by some other projects and the cubicweb development branch was simply painfully following changes done in the stable branch.

    Also, we decided to start using mq as a basis for code review. The sprint was a nice opportunity to test and see if it was actually usable for both developer and code reviewer. But more on this latter :)

    The tasks to achieve to get this release out were:

    1. resurrect the default branch after 3 months of nasty bugs introduced by simply merging from the stable branch without any time to test
    2. update main cubes to the new test / uicfg / hooks / members api
    3. finish the editcontroller (which handle post of most web forms) refactoring
    4. finish the relation permissions change, including migration
    5. update the documentation
    6. test real applications

    Of course this was ambitious :) Among those point 0. and 1. and 3. took us much more time than I expected. The editcontroller work (2.) has not been finished yet, and we didn't find any time for the documentation (4.).

    Besides this, everyone (well, me at least ;) enjoyed its time while working hard all together in our new meeting room! The 3.6 version still needs a little work before being released, but the development branch is definitly back, with a great bunch of cubes ready. Among them : comment, tag, blog, keyword, tracker, forge, card, nosylist, etc...

    So many thanks to everyone, and particularly to our Mexican friends Carlos and Celso... Tequila! ;)

    By the way the good news is that we plan to do more sprints like this now that we've some room for it!


  • Customizing search box with magicsearch

    2009/12/13 by Adrien Di Mascio

    During last cubicweb sprint, I was asked if it was possible to customize the search box CubicWeb comes with. By default, you can use it to either type RQL queries, plain text queries or standard shortcuts such as <EntityType> or <EntityType> <attrname> <value>.

    Ultimately, all queries are translated to rql since it's the only language understood on the server (data) side. To transform the user query into RQL, CubicWeb uses the so-called magicsearch component which in turn delegates to a number of query preprocessor that are responsible of interpreting the user query and generating corresponding RQL.

    The code of the main processor loop is easy to understand:

    for proc in self.processors:
        try:
            return proc.process_query(uquery, req)
        except (RQLSyntaxError, BadRQLQuery):
            pass
    

    The idea is simple: for each query processor, try to translate the query. If it fails, try with the next processor, if it succeeds, we're done and the RQL query will be executed.

    Now that the general mechanism is understood, here's an example of code that could be used in a forge-based cube to add a new search shortcut to find tickets. We'd like to use the project_name:text syntax to search for tickets of project_name containing text (e.g pylint:warning).

    Here's the corresponding preprocessor code:

    from cubicweb.web.views.magicsearch import BaseQueryProcessor
    
    class MyCustomQueryProcessor(BaseQueryProcessor):
        priority = 0 # controls order in which processors are tried
    
        def preprocess_query(self, uquery, req):
            """
            :param uqery: the query as sent by the browser
            :param req: the standard, omnipresent, cubicweb's req object
            """
            try:
                project_name, text = uquery.split(':')
            except ValueError:
                return None # the shortcut doesn't apply
            return (u'Any T WHERE T is Ticket, T concerns P, P name %(p)s, '
                    u'T has_text %(t)s', {'p': project_name, 't': text})
    

    The code is rather self-explanatory, but here's a few additional comments:

    • the class is registered with the standard vregistry mechanism and should be defined along the views
    • the priority attribute is used to sort and define the order in which processors will be tried in the main processor loop
    • the preprocess_query returns None or raise an exception if the query can't be processed

    To summarize, if you want to customize the search box, you have to:

    1. define a new query preprocessor component
    2. define its priority wrt other standard processors
    3. implement the preprocess_query method

    and CubicWeb will do the rest !


  • Using gettext on windows

    2009/12/01
    http://www.gnu.org/graphics/gnu-head-sm.jpg

    CubicWeb relies on gnu gettext for its translation management. However, the binary installers easily found for gettext (such as the one in python(x,y)) are for older versions, and compiling it is not that easy (especially in the Python world where people do not necessarily have a C compiler at hand).

    We did the job and a binary installer for gnu gettext 0.17 is available on our ftp server.


  • Browsing the Semantic Web

    2009/10/31 by Nicolas Chauvat
    http://www.cubicweb.org/file/502157?vid=download

    Now that the Web of Data has become a reality, innovative applications are springing up everywhere. Here is a selection of web apps that help you browse the semantic web.

    • Parallax is a faceted browser that is demonstrated by displaying the content of Freebase.
    • Neofonie demonstrates its faceted browser by displaying the content of DBpedia at dbpedia.neofonie.de
    • VisiNav is a search engine that allows to refine searches in a way that reminds of facets.
    • Falcons is a search engine that indexes RDF data.
    • Sindice is a search engine that indexes RDF data as well as data extracted from Microformats. It offers public Sindice API that can be used to retrieve the search results as RDF, json or Atom.
    • SameAs is a service that returns all the equivalent URIs for a search term or a given URI.
    • When you enter search terms, Sig.ma collates the data from the resources included in the results of a search on Sindice.
    • When you publish your product data according to the GoodRelations ontology, informations like the price show up in Yahoo's search results.

    More and more services will appear in the coming months that make use of these new resources. Just for tagging, you may look at CommonTag, Zemanta and OpenCalais and imagine new ways to automate and facilitate the process of publishing information on the web.


  • Comparing CubicWeb with Drupal plus CCK extension

    2009/10/29 by Nicolas Chauvat
    http://www.cubicweb.org/file/502151?vid=download

    Drupal is a CMS written in PHP that is getting more and more visibility in the Semantic Web crowd. Several researchers from DERI have been using it as a test bed for their research projects and developed extensions to showcase their ideas. It is for example used to build the Semantic Web Dog Food site that archives the semantic web conferences and publishes them as Linked Open Data. The URL for this year's ISWC is http://data.semanticweb.org/conference/iswc/2009

    This led me to read more about Drupal than I had had the incentive before. I have not had time to give it a try, but I skimmed the documentation and will try to compare it with CubicWeb from a software architecture point of view.

    Drupal defines a Node as an information item. The CCK (aka Content Construction Kit) can be used to define new types of Nodes thru a web interface. Nodes and the bits and pieces used to display them as HTML are not packed together in components. The Features extension is planning on getting this bits packaged.

    If you are a Drupal user/developer and think I am not being fair to Drupal, please comment below.

    On the other hand, CubicWeb has implemented very early the concept of reusable component. What is called a Node in Drupal is an Entity in CubicWeb. By design, CubicWeb does not have a web interface to define entities. The data model is part of the code. To efficiently maintain applications in production, changes to the data model must be tracked with changes to the code. Data model changes imply migration procedures. In CubicWeb, all of this is versionned and made part of the components. Where Drupal needs to grow extensions like CCK and Features, CubicWeb has more advanced possibilities by design, for example the ability to develop featurefull applications by assembling components.

    This was a very short comparison. I'm looking forward to getting a chance of discussing it with knowledgeable Drupal hackers.


  • Relase early, release often

    2009/10/05 by Arthur Lutz

    Looking at the releases of the CubicWeb projects for the month of September alone, I think we can conclude that we are applying the Agile Software Development principle quite closely.

    http://farm4.static.flickr.com/3025/2732378117_cdd948fd1d_m.jpg
    • 11 releases of the cubicweb framework (now in stable and unstable flavors) : 3.5.2, 3.5.1, 3.5.0, 3.4.11, , 3.4.9, 3.4.8, 3.4.7, 3.4.6, 3.4.5, 3.4.4, 3.4.3
    • 3 releases of cubicweb-vcsfile
    • 4 releases of cubicweb-forge
    • 2 releases of cubicweb-drh
    • 2 releases of cubicweb-workorder
    • 1 release of cubicweb-conference, cubicweb-tracker, cubicweb-registration, cubicweb-timesheet, cubicweb-workcase, cubicweb-task, cubicweb-expense, cubicweb-calendar, cubicweb-invoice, cubicweb-nosylist, etc.

    Hope you can keep-up or use the stable versions...

    photo by kennymatic under creative commons


  • Running CubicWeb on Windows

    2009/09/08

    This was not supported (and still isn't officially). But rumors have been circulating about a port of CubicWeb on Windows.

    http://pc-astuces.seebz.net/images/logo-windows-small.jpg

    I can confirm that there is some truth in this. A few changesets have been circulating, to be merged in the official repository any time now, enabling one to run CubicWeb on Windows. Support for running CubicWeb as a Windows service is not available yet, but should become available in the next few weeks.

    Update: check out the source of the 3.5 branch, and you will be able to create and start instances on Windows. Use cubicweb-ctl start -D for non daemon start.


  • Sparkles everywhere, CubicWeb gets fizzy

    2009/07/28 by Adrien Di Mascio
    http://www.logilab.org/file/9845/raw/sparkling.jpg

    Last week, we finally took a few days to dive into SPARQL in order to transform any CubicWeb application into a potential SPARQL endpoint.

    The first step was to get a parser. Fortunately the w3c provides a grammar definition and around 200 test cases. There was a few interesting options around there: we tried to reuse rdflib, rasqal, the sparql.g version designed for antlr3 and SimpleParse but after two days of work, we had nothing that worked well enough. We decided it was not worth it and switched to yapps since we knew yapps and rql already had a dependency on it.

    Maybe we'll consider changing the parser at some point later but the priority was to get something working as soon as we could and we finally came up with a version of fyzz passing 90% of the W3C test suite (of course, there might be some false positives).

    Fyzz parses the SPARQL query and generates something we decided to call an AST although it's still a bit rough for now. Fyzz understands simple triples, distincts, limits, offsets and other basic functionalities.

    Please note that fyzz is totally independent of cubicweb and it can be reused by any project.

    Here's an example of how to use fyzz:

    >>> from fyzz.yappsparser import parse
    >>> ast = parse("""PREFIX doap: <http://usefulinc.com/ns/doap#>
    ... SELECT ?project ?name WHERE {
    ...    ?project a doap:Project;
    ...         doap:name ?name.
    ... }
    ... ORDER BY ?name LIMIT 5 OFFSET 10
    ... """)
    >>> print ast.selected
    [SparqlVar('project'), SparqlVar('name')]
    >>> print ast.prefixes
    {'doap': 'http://usefulinc.com/ns/doap#'}
    >>> print ast.orderby
    [(SparqlVar('name'), 'asc')]
    >>> print ast.limit, ast.offset
    5 10
    >>> print ast.where
    [(SparqlVar('project'), ('', 'a'), ('http://usefulinc.com/ns/doap#', 'Project')),
     (SparqlVar('project'), ('http://usefulinc.com/ns/doap#', 'name'), SparqlVar('name'))]
    

    This AST is then processed and transformed into a RQL query which can finally be processed by CubicWeb directly.

    Here's what can be done in cubicweb-ctl shell session (of course, this can also be done in the web application) of our forge cube:

    >>> from cubicweb.spa2rql import Sparql2rqlTranslator
    >>> query = """PREFIX doap: <http://usefulinc.com/ns/doap#>
    ... SELECT ?project ?name WHERE {
    ...    ?project a doap:Project;
    ...         doap:name ?name.
    ... }
    ... ORDER BY ?name LIMIT 5 OFFSET 10
    ... """
    >>> qinfo = translator.translate(query)
    >>> rql, args = qinfo.finalize()
    >>> print rql, args
    Any PROJECT, NAME ORDERBY NAME ASC LIMIT 5 OFFSET 10 WHERE PROJECT name NAME, PROJECT is Project {}
    

    From the above example, we can notice two things. First, for cubicweb to understand the doap namespace, we have to declare the correspondance between the standard doap vocabulary and our internal schema, this is done with yams.xy:

    >>> from yams import xy
    >>> xy.register_prefix('http://usefulinc.com/ns/doap#', 'doap')
    >>> xy.add_equivalence('Project', 'doap:Project')
    >>> xy.add_equivalence('Project name', 'doap:Project doap:name')
    

    Secondly, for now, we notice that the case is not preserved during the transformation : ?project becomes PROJECT in the rql query. This is probably something that we'll need to tackle quickly.

    We've also add a few views in CubicWeb to wrap that and it will be available in the upcoming version 3.4.0 and is already available through our pulic mercurial repository.

    The door is now open, the path is still long, stay tuned !

    image under creative commons by beger (original)


  • CubicWeb at BayPiggies/OSCON in July 2009

    2009/07/14 by Nicolas Chauvat
    http://www.logilab.org/file/9631?vid=download

    I am pleased to announce that CubicWeb will be presented during a BayPIGgies meeting that will exceptionally take place in the OSCON conference building as the closing event of the Bird of Feathers on July 23rd at 8pm.

    Joins us to get to know more about CubicWeb.

    Read the report.


  • INSEE, XML and RDF

    2009/07/06 by Nicolas Chauvat
    http://insee.fr/fr/css/images/logo_insee.gif

    I discovered that the French Institute for Statistics and Economic Studies (INSEE) has published part of its data as XML and RDF:

    We will try to put that data to good use.


  • Graphing version progress

    2009/07/06 by Arthur Lutz

    As you might have noticed we've upgraded http://www.logilab.org and http://www.cubicweb.org to CubicWeb 3.3 and a bunch of cubes were upgraded too. We can now benefit from a few cool bugfixes and features on those two forges.

    One of them I like and wish to mention is the graphing of a project's progress as a Burn Down Chart, you can see an example below. We're using the some jQuery magic here, and so you can roll over the mouse to get more info on the graph... (not on the screenshot below). This type of graph is generated on all the version views... This is particularly useful on some of our extranets to see the progress of a version (and if tickets were added along the way).

    http://www.cubicweb.org/file/344424?vid=download

    For the coders out there you can check out cubicweb/web/views/plots.py and the example in the forge cube.


  • News from Europython 2009

    2009/07/02
    http://www.europython.eu/images/europython_logo.png

    Nicolas gave a talk at Europython2009 about CubicWeb. Reinout Van Rees posted his notes about the talk on his blog. Thanks Reinout. You may also read Nicolas' slides and watch his lightning talk.


  • What's new in cubicweb 3.3

    2009/06/24 by Arthur Lutz

    After the CubicWeb 3.2 blackout, the release early, release often mantra strikes back and CubicWeb 3.3 is out ! A few bugs were fixed, mainly migration scripts bug, and some new functionalities were added among which the long awaited standard plotting feature. We've added piechart support (with gchartwrapper) and standard plots with flot.

    under creative commons by jared

    Features

    • jquery has been updated to the latest 1.3.x version
    • plotting facilities using Flot and Google Chart have been added (replacing sometimes similar facilities using matplotlib)
    • the i18n command names have been changed
    • also a non-negligible amount of internal refactorings occurred, but this should be quite transparent

    Bugs fixed

    • problems with migrations using SQL has been fixed
    • bugs with the multi-source planner have been fixed
    • problems with synchronize-schema and not-null constraints

    photo licenced under CreativeCommons by jared


  • CubicWeb for DBPedia and OpenLibrary at PyConFr'09

    2009/06/05 by Nicolas Chauvat
    http://www.cubicweb.org/file/343602?vid=download

    I presented CubicWeb at the French Python Conference held in Paris last week-end. Check out the slides and the video. See also my recent post Fetching book descriptions and covers on logilab.org.

    The code used during the demo uses the brand new RangeFacet, DateRangeFacet and HasRelationFacet brought by CubicWeb 3.3 and is available in the cubes dbpedia and book. We will put the demos online in a couple weeks once we get a new server with more horsepower. Help would be welcome to set them up as Amazon EC2 or Eucalyptus instances.


  • Cubicweb 3.2 : what's new

    2009/06/03 by Aurelien Campeas
    http://farm4.static.flickr.com/3045/2585844966_05f617cd92_m.jpg

    Cubicweb has experienced a rather large shakeup. Some things needed major restructuration, and that is why you have been left with few releases in the past few weeks. All the cubes available at http://www.cubicweb.org/project have been updated accordingly.

    Version 3.2 brings us considerable improvements for:

    Form construction

    Cubicweb has had for long a nice system of forms smart enough to build themselves out of one cube's schema and some programmer-provided hints (or 'relation tags') to fine-tune things.

    It was not easy however to customize these forms nor to build new ones from scratch.

    So the new form systems draws from django-forms flexibility and style, keeping all the automatic goodness, and also make it quite easy now to build or customize forms at will.

    This is the area were backwards compatibility is mostly gone. Custom forms will have to be rewritten. Don't be angry about that, the forms overhaul was long overdue, and from now it will only move in small evolutionary, well-mannered steps.

    Relation tags

    Along with the form subsystem is the __rtags__ mechanism substantially updated and made more extensible. The __rtags__ were quite incorrectly attached to entities class at the ORM level instead of being related to views and forms. The cubicweb.web.uicfg module now provides a comprehensive catalog of relation tags instances allowing automatic forms and views customisation in a nicely declarative manner.

    Cubicweb 3.2 still remains compatible with the old __rtags__.

    View selection/filtering

    Cubiweb has also had for long a nice mechanism to filter views applicable to a given result set, the selector system. Various base classes were provided to hide selectors from the programmer and it had grown a little messy.

    Selectors now have a nicer declarative feeling and the framework does not try to hide them. Quite the opposite: writing, maintaining and using selectors is now a breeze, and the base classes are gone. More is less !

    However Cubicweb 3.2 remains backward compatible with the old selectors. Runtime warnings will help you track these and adapt as you see fit.

    Other features

    On the smaller features side, worth mentioning are:

    • new RichString attribute type in schema definitions, that simplifies format and encoding management,
    • inline relation edition is now possible (it was formerly limited to attributes) with 'reledit' view,
    • workflow definition has been simplified,
    • web/views has been somewhat cleanup up and reorganized,
    • automatic registration of app objects can now be switched to manual mode (no more hairy hard-to-debug registerer mechanism),
    • a generic SIOC view,
    • a view synthetizing permissions across a whole app.

    We hope you enjoy this release! The cubicweb development team.

    photo by jared under creative commons


  • Some new standard facets on the way

    2009/05/29 by Adrien Di Mascio

    CubicWeb has this really nice builtin facet system to define restrictions filters really as easily as possible.

    We've just added two new kind of facets in CubicWeb :

    • The RangeFacet which displays a slider using jquery to choose a lower bound and an upper bound. The RangeWidget works with either numerical values or date values
    • The HasRelationFacet which displays a simple checkbox and lets you refine your selection in order to get only entities that actually use this relation.
    http://www.cubicweb.org/file/343498?vid=download

    Here's an example of code that defines a facet to filter musical works according to their composition date:

    class CompositionDateFacet(DateRangeFacet):
        # 1. make sure this facet is displayed only on Track selection
        __select__ = DateRangeFacet.__select__ & implements('Track')
        # 2. give the facet an id (required by CubicWeb)
        id = 'compdate-facet'
        # 3. specify the attribute name that actually stores the date in the DB
        rtype = 'composition_date'
    

    And that's it, on each page displaying tracks, you'll be able to filter them according to their composition date with a jquery slider.

    All this, brought by CubicWeb (in the next 3.3 version)


show 134 results