You can click on the Google or Yahoo buttons to sign-in with these identity providers,
or you just type your identity uri and click on the little login button.
interesting automations done to suggest alignments when initial data is uploaded to an opendata website
some opendata platforms have built-in APIs to get files, one example is Socrata : http://dev.socrata.com/
some work is being done to scale processing of linked data in the cloud (did you know you could access ready available datasets in the Amazon cloud ? DBPedia for example )
the data stored in wikipedia can be a good source of vocabulary on certain machine learning tasks (and in the future, wikidata project)
WebSmatch uses morphological operators (erosion / dilation) to identify grids and zones in Excel Spreadsheets and then aligns column data on known reference values (e.g. country lists).
CubicWeb got rewarded yesterday at the award ceremony of the Dataconnexions 2013 contest.
Dataconnexions is a contest organized by Etalab, the organization part of the French State that is in charge of data.gouv.fr, that catalogs the open data published by the french administration.
Congratulations to all the developers and users of CubicWeb and welcome to the people who will join the CW community thanks to the media coverage we are now experiencing.
The Logilab team now holds a roadmap meeting every two months to plan its CubicWeb development effort. Here are the decisions that were taken on Feb 1st, 2013.
This version should be published before the end of March and will finish all the things
that are work in progress. It will include:
the refactoring necessary to introduce persistant sessions,
the shrinking of web/views: everything that does not deserve its own cube (like sioc, embed,
geocoding, etc) will go into a cube named legacyui (this will open the door to squareui),
stop serving pages with "content-type: application/xhtml",
handling postgresql schemas (will require a new version of logilab.database),
Once the cube legacyui extracted (in version 3.17), it will be possible to move forward
swiftly with squareui. Due to its other duties, one can not expect the core CW team to develop squareui.
People interested will be in charge and ideally the squareui cube could be released when cubicweb 3.17
will be published.
possibility to add new base types (Array, HStore,
Geometry, TSVector, etc.) that would use extensions from the
SQL backend
FROM clause in rql queries
websockets
defining attribute on relations and defining "virtual" relations or rules:
classContribution(EntityType):author=SubjectRelation('Person',cardinality='1*',inlined=True)book=SubjectRelation('Book',cardinality='1*',inlined=True)role=SubjectRelation('Role',cardinality='1*',inlined=True)preface_writer=VirtualRelation('C is Contribution, C author S, C book O, ''C role R, R name "preface writer"')
And:
Any P WHERE B is Book, P preface_writer B
Will we need a materialized view in the database, a standard relation maintained by hooks,
rewrite the RQL on-the-fly ? Time will tell.
cards with logic (mustache js templates for example)
coffeescript ? brython ? javascript ? prototype something with CubicDB + WebService that
outputs json + user interface in full javascript
package separately Cubic(Web)DB et CubicWeb ?
think about the overall architecture (using WSGI, persistent sessions, etc.), and find
solutions that fit a distributed architecture (look at paste.deploy, circus, etc.)
clean up the javascript en web/data/*.js
configurable metadata, managing the size of the entities table
more SPARQL
namespaces for the data models of the cubes
As already said on the mailing list, other developers and contributors are more than welcome to share their own goals in order to define a roadmap that best fits everyone's needs.
Logilab's next roadmap meeting will be held at the beginning of April 2013.
Add a new dataimport store (SQLGenObjectStore). This store enables a fast
import of data (entity creation, link creation) in CubicWeb, by directly
flushing information in SQL. This may only be used with PostgreSQL, as it
requires the 'COPY FROM' command.
Orm: set_attributes and set_relations are unified (and
deprecated) in favor of cw_set that works in all cases.
db-api/configuration: all the external repository connection information is
now in an URL (see #2521848),
allowing to drop specific options of pyro nameserver host, group, etc and fix
broken ZMQ source. Configuration related changes:
Dropped 'pyro-ns-host', 'pyro-instance-id', 'pyro-ns-group' from the client side
configuration, in favor of 'repository-uri'. NO MIGRATION IS DONE,
supposing there is no web-only configuration in the wild.
Stop discovering the connection method through repo_method class attribute
of the configuration, varying according to the configuration class. This is
a first step on the way to a simpler configuration handling.
DB-API related changes:
Stop indicating the connection method using ConnectionProperties.
Drop _cnxtype attribute from Connection and cnxtype from
Session. The former is replaced by a is_repo_in_memory property
and the later is totaly useless.
Turn repo_connect into _repo_connect to mark it as a private function.
Deprecate in_memory_cnx which becomes useless, use _repo_connect instead
if necessary.
the "tcp://" uri scheme used for ZMQ
communications (in a way reminiscent of Pyro) is now named
"zmqpickle-tcp://", so as to make room for future zmq-based lightweight
communications (without python objects pickling).
Request.base_url gets a secure=True optional parameter that yields
an https url if possible, allowing hook-generated content to send
secure urls (e.g. when sending mail notifications)
Dataimport ucsvreader gets a new boolean ignore_errors
parameter.
The RQL search bar has now some auto-completion support. It means
relation types or entity types can be suggested while typing. It is
an awesome improvement over the current behaviour !
The action box associated with table views (from tableview.py)
has been transformed into a nice-looking series of small tabs; it
means that the possible actions are immediately visible and need not
be discovered by clicking on an almost invisible icon on the upper
right.
The uicfg module has moved to web/views/ and ui configuration
objects are now selectable. This will reduce the amount of
subclassing and whole methods replacement usually needed to
customize the ui behaviour in many cases.
Remove changelog view, as neither cubicweb nor known cubes/applications
were properly feeding related files.
'pyrorql' sources will be automatically updated to use an URL to locate the source
rather than configuration option. 'zmqrql' sources were broken before this change,
so no upgrade is needed...
Debugging filters for Hooks and Operations have been added.
Some cubicweb-ctl commands used to show the output of msgcat and
msgfmt; they don't anymore.
For two days, on dec 13th/14th 2012, ten hackers gathered at Logilab to improve the user interface of CubicWeb. This hackathon was initiated by
Crealibre. About a year ago, they started the Orbui project, a new user interface for CubicWeb based on the Bootstrap HTML/CSS framework.
Several projects at Logilab and Crealibre proved that Orbui was heading in the right direction, but that it had to fight with the default user interface of Cubicweb. Orbui makes different design/ergonomic choices and needs different HTML/CSS structure and Javascript components.
Sylvain published a roadmap back in may with a section titled "on the road to Bootstrap". After more than half a day of heated debate on the firts day, it was decided to follow the direction he pointed to. We started extracting from CubicWeb the default user interface and turning it into a set of cubes:
cubicweb-legacyui: css, views and templates extracted from CubicWeb 3.16, so as to provide full backward compatibility
cubicweb-bootstrap: empty cube with only bootstrap version 2.2.2 in data/
cubicweb-squareui: bootstrapified version of legacyui (slightly altered to benefit from the bootstrap css without breaking backward compatibility too hard)
At the end of the sprint, one could add_cube('squareui') on an existing application and keep it usable... and get "some kind of responsiveness" for free, thus proving that we were on the right track.
A lot of work is still ahead of us, but we have moved a few step forward towards the goal of making it easier to implement different UIs on top of CubicWeb 3.17.
For the curious, here is what the skeleton of legacyui.views.maintemplate (aka cw.web.views.maintemplate) looks like:
Décrivez le (ou les) problème(s) que votre projet tente de résoudre, ainsi que
son (leur) importance : taille du marché, fréquence d’utilisation potentielle,
population concernée, bénéfices éventuels de service public, etc. (maximum 1000
signes).
L'avènement du web sémantique et de l'Open Data nécessite de disposer d'outils
adaptés pour développer des applications centrées sur les données.
Ces outils doivent permettre d'importer des données facilement, de les mettre en
relation lorsqu'elles proviennent de sources disjointes, de les republier et de
faciliter leur interrogation et leur visualisation.
Idéalement, ces outils doivent utiliser et respecter les standards ouverts
d'internet afin de simplifier les communications et les échanges, mais aussi
faciliter le développement pour les terminaux multiples (ordinateur, tablette,
smartphone).
Décrivez votre produit, service ou visualisation, dans sa forme actuelle et le
cas échéant après les développements futurs éventuels que vous envisagez.
Précisez le ou les jeux de données publiques que vous utilisez à cet effet
(maximum 1000 signes).
CubicWeb est une plate-forme libre de développement pour le web sémantique.
CubicWeb permet aux développeurs de se concentrer sur les spécificités de leur
application plutôt que d'avoir à réinventer les briques essentielles de
l'import, la fusion, la publication, l'interrogation et la visualisation de
données.
CubicWeb est un logiciel libre développé ouvertement sur internet par une
communauté réduite mais déjà internationale. CubicWeb est disponible sous
licence LGPL, respecte les standards du W3C (RDF, SPARQL, HTML5, CSS3,
Responsive Design) et sait gérer nativement plusieurs modèles de données
faisant office de standards de fait (FOAF, SIOC, DOAP, etc).
Décrivez le modèle d’affaire de votre projet, c’est-à-dire les conditions de sa
pérennité et de son développement : plan d’affaires et projections commerciales
dans le cas d’un projet entrepreneurial ; objectifs, donneurs clés, partie
prenantes dans le cas d’un projet d’ordre civique (maximum 1000 signes).
Plusieurs sociétés commerciales s'appuient aujourd'hui sur CubicWeb pour vendre
des services informatiques. L'objectif de cette communauté est de croître pour
bénéficier d'une audience plus large et d'une mutualisation plus importante des
coûts de maintenance et de développement de la plate-forme CubicWeb.
Parmi les utilisateurs de CubicWeb, on compte à ce jour la Bibliothèque
nationale de France, EDF, GDF-Suez, le Commissariat à l'Energie Atomique, le
Centre National d'Etudes Spatiales, l'Institut Radioprotection et Sûreté
Nucléaire, l'INRIA, des laboratoires de recherche médicale et des entreprises
du domaine informatique.
Décrivez les étapes que vous avez franchies, les ressources mobilisées, les
indicateurs et métriques déjà établies, etc. (maximum 1000 signes).
Le projet CubicWeb est issu d'un effort de R&D commencé en 2001 par la société
Logilab, qui avait comme objectif de se doter d'un outil permettant le
développement d'applications centrées sur les données et respectant les
standards du web sémantique en cours d'élaboration au W3C.
Depuis 2008, CubicWeb est un logiciel libre dont le développement est mené
ouvertement sur internet.
Décrivez l’équipe qui vous accompagne dans votre projet (le cas échéant), vos
compétences, expériences et réalisations, ainsi que les partenaires éventuels
qui vous soutiennent (maximum 1000 signes).
Détaillez toutes les précisions additionnelles que vous souhaiteriez apporter
au sujet de votre projet, et expliquez en quoi DataConnexions peut contribuer à
pérenniser son développement (maximum 1000 signes).
Plusieurs sociétés commerciales s'appuient aujourd'hui sur CubicWeb pour vendre
des services informatiques. Les utilisations industrielles de CubicWeb sont
variées et concernent des applications importantes, voire critiques.
CubicWeb est un outil peu (re)connu et sa communauté est aujourd'hui réduite,
malgré ses solides références et le récent engouement pour l'Open Data.
DataConnexions pourrait être une tribune et une vitrine permettant à CubicWeb de
trouver de nouveaux développeurs d'applications préférant bénéficier de
l'expérience capitalisée dans cet outil libre plutôt que de rédécouvrir et
déjouer un par un les pièges rencontrés au cours des dix ans qui ont été
nécessaires à sa réalisation.
L'objectif de cette candidature est donc de faire croître la communauté des
utilisateurs et contributeurs de CubicWeb.
Lien permettant de télécharger une vidéo décrivant le Projet et ses
fonctionnalités, d’une durée maximale de 3 minutes
Ce n’est pas la qualité de la vidéo qui est jugée, mais le projet lui-même. La
vidéo doit permettre de rendre compte des fonctionnalités du projet. Les
candidats sont encouragés à réaliser une capture d’écran ou un « screencast »
(par exemple avec des outils tels que CamStudio, Jing ou Screenr).
Démonstration de l'utilisation de CubicWeb pour importer et visualiser la liste
des gares françaises téléchargée depuis data.gouv.fr. Sélection des gares par le
filtre à facettes et affichage sur fond de carte openstreetmap, puis export en
RDF, JSON et CSV.
CubicWeb est une plate-forme libre de développement pour le web sémantique, qui
permet aux développeurs de se concentrer sur les spécificités de leur
application plutôt que d'avoir à réinventer les briques essentielles de
l'import, la fusion, la publication, l'interrogation et la visualisation de
données.
Lien permettant d’accéder au Projet, ou au code informatique compilé et
interprétable du Projet
Par exemple : URL permettant de consulter, ou, le cas échéant, de télécharger
l’application, accompagnée, si nécessaire, d’instructions à cet
effet. L’application devra être facile à installer et aisément démontrable sur
sa plateforme de destination.
Décrivez le Projet dans des termes compatibles avec une diffusion au grand
public : non confidentiels, compréhensibles par le plus grand nombre, et mettant
en avant l’intérêt du projet (maximum 1000 signes).
Lien vers un élément visuel décrivant et mettant en valeur le projet et ses
fonctionnalités (capture d’écran, page d’accueil, schéma de description).
A few people from Logilab attended the dotjs conference in Paris last week. The conference wasn't exactly what we expected, we were hoping for more technical talks. Nevertheless, some of the things we saw were quite interesting. Some of them could be relevant to CubicWeb.
Here is a raw roundup of links collected last friday :
This sprint will take place in decembre 2012 from thursday the 13th to friday the 14th. You are more than welcome to come along, help out and contribute. An introduction is planned for newcomers.
Network resources will be available for those bringing laptops.
Address : 104 Boulevard Auguste-Blanqui, Paris. Ring "Logilab" (googlemap)
In cubicweb, you often have to build url's that redirect the current view to
a specific entity view or allow the execution of a given action. Moreover, you
often want also to fallback to the previous view once the specific action or
edition is done, or redirect also to another entity's specific view.
To do so, cubicweb provides you with a set of powerful tools, however as
there is often more than one way to do it, this blog entry is here to help
you in choosing the preferred way.
build_url is accessible in any context, so for instance in the rendering of a
given entity view you can call self._cw.build_url to build you URLs easily,
which is the most common case. In class methods (for instance, when declaring the
rendering methods of an EntityTableView), you can access it through the context
of instantiated appobject which are usually given as argument,
e.g. entity._cw.build_url. For test purposes you can also call
session.build_url in cubicweb shells.
build_url basically take a first optional, the path, relative to the base
url of the site, and arbitrary named arguments that will be encoded as url
parameters. Unless you wish to direct to a custom controller, or to match
an URL rewrite url, you don't have to specify the path.
Extra parameters given to build_url will vary according to your needs, however
most common arguments understood by default cubicweb views are the followings:
vid: the built view __regid__;
rql: the RQL query used to retreive data on which the view should be
applied;
eid: the identifier of an entity, which you should use instead of rql
when the view apply to a single entity (most often);
__message: an information message to display inside the view;
__linkto: in case of an entity creation url, will allow to set some
specific relations between both entities;
__redirectpath: the URL of the entity of the redirection;
__redirectvid: the view id of the redirection.
__redirectvid and __redirectpath are used to control redirection after
posting a form and are more detailed in the cubicweb documentation, chapter
related to the edition control
(http://docs.cubicweb.org/devweb/edition/editcontroller.html).
Generally, an entity has two important methods that retrieve its absolute or
relative urls:
entity.rest_path() will return something like <type>/<eid> where
<type> corresponds to the entity type and <eid> the entity eid;
entity.absolute_url() will return the full url of the entity
http://<baseurl>/<type>/<eid>. In case you want to access a specific view
of the entity, just pass the vid='myviewid' argument. You can give
arbitrary arguments to this method that will be encoded as url parameters.
Passing the rql to the build_url method requires to have a proper RQL
expression. To do so, there is a convenience method, printable_rql(), that is
accessible in rset resulting from RQL queries. This allows to apply a view to the
same result set as the one currently process, simply using rql =
self.cw_rset.printable_rql().
There are several ways to get URL of the current view, the canonical one being to
use self._cw.relative_path(includeparams=True) which will return the path of
the current view relative to the base url of the site (otherwise use
self._cw.url(), including parameters or not according to value given as
includeparams).
You can also retrieve values given to individual parameters using self._cw.form, eg:
self._cw.form.get('vid', '') will return only the view id;
self._cw.form.get('rql', '') will return only the RQL;
self._cw.form.get('__redirectvid', '') will return the redirection
view if defined;
self._cw.form.get('__redirectpath', '') will return the redirection
path if defined.
This case often appears when you want to create a link to a startup view or a
controller. It the first case, you simply build you URL like this:
self._cw.build_url('view', vid='my_view_id')
The latter case appears when you want to call a controller directly without
having to define a form in your view. This can happen for instance when you
want to create a URL that will set a relation between 2 objects and do not need
any confirmation for that. The URL construction is done like this:
Any extra arguments passed to the build_url method will be available in the
controller as key, values pairs of the self._cw.forms dictionary. This is
especially useful when you want to define some kind of hidden attributes
but there is not form to put them into.
And, last but not least, a convenient way to get the root URL of the instance:
There are other ways to create a link to registered actions than using
build_url, mostly by accessing them via the registry vreg.
For instance, the action registry holds effectively all possible actions in a
given context: a specific action can be selected using the select_or_none()
method, or even using the possible_action() method which will return a list of
categorized actions. The url of the action is then available as
action.url(). For contextual components (e.g. boxes), you can even directly
get a link to the selected action(s) using the self.action_link(this_action)
method.
If the action corresponds to the creation of a new entity, there is an even
faster and elegant way to do it, using the schema of your cube:
defpublish(self,rset):value1,value2=self._cw.form['arg1'],self._cw.form['arg2']# do some stuff with value1 and value2 here...raiseRedirect(self._cw.build_url(rql=self._cw.form['rql'],vid=self._cw.form['__redirectvid'],__message=_('you message')))
Create a link to add a given entity and relate this entity to the current one
with a relation 'child_of', then go back to the current entity's view:
Sometimes you need to associate to a given view your own specific form
and the associated controller. We will see in this blog entry how it
can be done in cubicweb on a concrete case.
Let's suppose you're working on a social network project where you have
to develop friend-of-a-frient (foaf) relationships between persons.
For that purpose, we use the cubicweb-person cube and create in our
scheme relations between persons like X in_contact_with Y:
We will also assume that a given Person corresponds to a unique CWUser through
the relation is_user.
Although it is not evident, we would like that any connected person can chose
to disconnect himself from another person at any time. For that, we will
create a table view that will display the list of connected users, with a
custom column giving the ability to "disconnect" with the person.
Before disconnecting with this particular person, we would like also to have
a confirmation form.
To display the list of connected persons to the current person, but also to add
custom columns that do not refer specifically to attributes of a given entity,
the best choice is to use EntityTableView (see here for more information):
classContactView(EntityTableView):__regid__='contacts_tableview'__select__=is_instance('Person')columns=['person','firstname','surname','email','phone','remove']layout_args={'display_filter':'top','add_view_actions':None}defcell_remove(w,entity):"""link to the suppression of the relation between both contacts"""icon_url=entity._cw.data_url('img/user_delete.png')action_url=entity._cw.build_url(eid=entity.eid,vid='suppress_contact_view',__redirectpath=entity._cw.relative_path(),__redirectvid=entity._cw.form.get('__redirectvid',''))w(u'<a href="%(actionurl)s" title="%(title)s">'u'<img alt="%(title)s" src="%(url)s" /></a>'%{'actionurl':xml_escape(action_url),'title':_('remove from contacts'),'url':icon_url})column_renderers={'person':MainEntityColRenderer(),'email':RelatedEntityColRenderer(getrelated=lambdax:x.primary_emailandx.primary_email[0] \
orNone),'phone':RelatedEntityColRenderer(getrelated=lambdax:x.phoneandx.phone[0]orNone),'remove':EntityTableColRenderer(renderfunc=cell_remove,header=''),}
A few explanations about the above view:
By default, the column attribute contains a list of displayable attributes
of the entity. If one element of the list does not correspond to an attribute,
which is the case for 'remove' here, it has to have rendering function
defined in the dictionnary column_renderers.
However, when the column header refers to a related entity attribute, we can
easily use the rendering function RelatedEntityColRenderer, as it is the
case for the email and phone display.
As for concerns the 'remove' column, we render a clickable image in the
cell_remove method. Here we have chosen an icon from famfamsilk that
is putted in our data/ directory, but feel free to chose a predefined
icon in the cubicweb shared data directory.
The redirection URL associated to each image has to be a link to a specific
action allowing the user to remove the selected person from its contacts.
It is built using the self._cw.build_url() convenience function. The
redirection view, 'suppress_contact_view', will be defined later on. The
eid argument passed refers to the id of the contact person the user wants
to remove.
The above view has to be called with a given rset which corresponds to the
list of known contacts for the connected user. In our case, we have defined
a StartupView for the contact management, in which in the call function we
have added the following piece of code:
person=self._cw.user.related('is_user','object').get_entity(0,0)rset=self._cw.execute('Any X WHERE X is Person, X in_contact_with Y, ''Y eid %(eid)s',{'eid':person.eid})self.w(u'<h3>'+_('Number of contacts in my network:'))self.w(unicode(len(rset))+u'</h3>')iflen(rset)!=0:self.wview('contacts_tableview',rset)
The Person corresponding to the connected user is retrieved thanks to the
use of the related method and the is_user relation. The contact table
view is displayed inside the parent StartupView.
The corresponding view is a simple View class instance, that will display
a confirmation message and the related buttons. It could be defined as follows:
classSuppressContactView(View):__regid__='suppress_contact_view'defcell_call(self,row,col):entity=self.cw_rset.get_entity(row,col)msg=self._cw._('Are you sure you want to remove %(name)s from your contacts?')self.w(u'<p>'+msg%{'name':entity.dc_long_title()}+u'</p>')form=self._cw.vreg['forms'].select('suppress_contact_form',self._cw,rset=self.cw_rset)form.add_hidden(u'eidto',entity.eid)form.add_hidden(u'eidfrom',self._cw.user.related('is_user','object').get_entity(0,0).eid)form.render(w=self.w)
Inside the cell_call() method of this view, we will have to render a form
which aims at displaying both buttons (confirm deletion or cancel deletion).
This form will be described later on.
The Person contact to remove is retrieved easily thanks to cw_rset. The
Person corresponding to the connected user is here also retrieved thanks to the
is_user relation. To make both of them available in the form, we add them at
the instanciation of the form using the convenience function
add_hidden(key,val).
The deletion form as mentioned previously is only here to hold both buttons for
the deletion confirmation or the cancelling. Both buttons are declared thanks
to the form_buttons attribute of the form, which is instanciated from
forms.FieldsForm:
Specifying a given domid will ensure that your form will have a specific DOM identifier,the controller defined in the
action method will be called without any ambiguity. The form_renderer_id is
precised here so as to avoid additional display of informations which don't make sense here.
The custom controller is instanciated from the Controller class in
cubicweb.web.controller. The declaration of the controller should have the
same domid than the calling form, as mentioned previously. The related
actions are described in the publish() method of the controller:
classSuppressContactController(Controller):__regid__='suppress_contact_controller'domid='delete_contact_form'defpublish(self,rset=None):if'__action_cancel'inself._cw.form.keys():msg=self._cw._('Deletion canceled')raiseRedirect(self._cw.build_url(vid='contact_management_view',__message=msg))elif'__action_delete'inself._cw.form.keys():xid=self._cw.form['eidfrom']dead_contact=self._cw.entity_from_eid(xid)yid=self._cw.form['eidto']self._cw.execute('DELETE X in_contact_with Y'' WHERE X eid %(xid)s, Y eid %(yid)s',{'xid':xid,'yid':yid})msg=self._cw._('%s removed from your contacts')%\
dead_contact.dc_long_title()raiseRedirect(self._cw.build_url(vid='contact_management_view',__message=msg))
Retrieving of the user action is performed by testing if the
'__action_<action>', where <action> refers to the cwaction in the
button declaration, is present in the form keys. In the case of a cancelling,
we simply redirect to the contact management view with a message specifying
that the deletion has been cancelled. In the case of a deletion confirmation,
both Person id's for the connected user and for the contact to remove are
retrieved from the form hidden arguments.
The deletion is performed using an RQL request on the relation
in_contact_with. We also redirect the view to the contact management view,
this time with another message confirming the deletion of the contact link.
We have been playing along with political data for a while, using CubicWeb
to store and query various sets of open data
(e.g. NosDeputes, data.gouv.fr),
and testing different visualization tools.
In particular, we have extended our prototype of News Analysis (see the
presentation we made last year at Euroscipy),
in order to use these political datasets as reference for the named
entities extraction part.
Last week's conference "The Law Factory" at Sciences Po was a really nice opportunity to meet people with similar interests in
opendata for political sciences, and to find out which questions we should be asking our data !
Check out the talk of our presentation and a few screencasts (no sound) :
Among the different things that we have seen, we want to emphasize on:
Law is Code (http://gitorious.org/law-is-code/) - This project by the team of Regards Citoyens, aims at analysing the laws and amendments, by extracting information from the French National Assembly website, and by pushing the contributions of the members of parlement to a given law in a git repository. If we can find the time, we'll turn that into a mercurial repository and integrate it into our above application using cubicweb-vcsfile.
Both national websites (Assemblée Nationale, Sénat), do not allow (yet...) to get data any other way than parsing the sites. However, it seems that the people involved are aware of the issues of opendata, and this may changed in the next months. In particular, the Senat use two databases (Basile and Ameli), and opening them to the public could be really interesting
Different projects about African parlements can be found on the following website : http://www.parliaments.info
Check out, ITCparliement which gives tools to analyse and share data from many different parliments.
Saturday, at La Cantine Numérique, the discussions focused on the
possibilities to share tools, and the possible collaborations. I think that this is the crucial point: How people can share tools and use them in a efficient way, without being an IT expert ?
In this way, we have are thinking about some evolutions of CubicWeb that can fullfill (part) of these requirements:
easier installation, especially on Windows, and easier Postgresql configuration. This could perhaps be made by allowing some graphical interface for creating/managing the instances and the databases.
a graphical tool for schema construction. Even if the construction of a data model in CubicWeb is quite simple, and rely on the straightforward Python syntax, it could be interesting to expose a graphical tool for adding/removing/modifying entities from the schema, as well as some attributes or relations.
easier ways to import data. This point is not trivial, and we don't want to develop a specific language for defining import rules, that could be used for 80% of the cases, but will be painful to extend to the 20% exotic cases. We would rather develop some helpers to ease the building of some import scripts in Python, and to upload some CubicWeb instances already filled with open databases.
This demo site allows you to deeply explore the data, with different visualisations, and complex queries. Again, comments are welcome, especially if you want to retrieve some information but you don't know how to! This demo site will probably evolve in the next weeks, and we will use it to test different cubes that we have been building.
PS: We are sorry we cannot open the propotype of news aggregator for now, as there are still
licensing issues concerning the reusability of the different news sources that we get articles from.
Add ZMQ server, based on the cutting edge ZMQ socket
library. This allows to access distant instances, in a similar way as Pyro.
Publish/subscribe mechanism using ZMQ for communication among cubicweb
instances. The new zmq-address-sub and zmq-address-pub configuration variables
define where this communication occurs. As of this release this mechanism is
used for entity cache invalidation.
Improved WSGI support. While there are still some caveats, most of the code
which was twisted only is now generic and allows related functionalities to work
with a WSGI front-end.
Full undo/transaction support: undo of modifications has finally been
implemented, and the configuration simplified (basically you activate it or not
on an instance basis).
Controlling HTTP status code returns is now much easier:
WebRequest now has a status_out attribute to control the response status ;
most web-side exceptions take an optional status argument.
The base registry implementation has been moved to a new
logilab.common.registry module (see #1916014). This includes code from :
cubicweb.vreg (everything that was in there)
cw.appobject (base selectors and all).
In the process, some renaming was done:
the top level registry is now RegistryStore (was VRegistry), but that
should not impact CubicWeb client code;
former selectors functions are now known as "predicate", though you still use
predicates to build an object'selector;
for consistency, the objectify_selector decorator has hence been renamed to
objectify_predicate;
on the CubicWeb side, the selectors module has been renamed to
predicates.
Debugging refactoring dropped the need for the lltrace decorator. There
should be full backward compat with proper deprecation warnings. Notice the
yes predicate and objectify_predicate decorator, as well as the
traced_selection function should now be imported from the
logilab.common.registry module.
All login forms are now submitted to <app_root>/login. Redirection to requested
page is now handled by the login controller (it was previously handled by the
session manager).
Publisher.publish has been renamed to Publisher.handle_request. This
method now contains a generic version of the logic previously handled by
Twisted. Controller.publish is not affected.
New 'ldapfeed' source type, designed to replace 'ldapuser' source with
data-feed (i.e. copy based) source ideas.
New 'zmqrql' source type, similar to 'pyrorql' but using ømq instead of Pyro.
A new registry called 'services' has appeared, where you can register
server-side cubicweb.server.Service child classes. Their call method can be
invoked from a web-side AppObject instance using the new self._cw.call_service
method or a server-side one using self.session.call_service. This is a new
way to call server-side methods, much cleaner than monkey patching the
Repository class, which becomes a deprecated way to perform similar tasks.
a new ajaxfunction registry now hosts all remote functions (i.e. functions
callable through the asyncRemoteExec JS api). A convenience ajaxfunc
decorator will let you expose your python functions easily without all the
appobject standard boilerplate. Backwards compatibility is preserved.
the 'json' controller is now deprecated in favor of the 'ajax' one.
WebRequest.build_url can now take a __secure__ argument. When True, cubicweb
tries to generate an https url.
This is a fairly technical post talking about the structural changes I would like to see in CubicWeb's near future. Let's call that CubicWeb 4.0! It also drafts ideas on how to go from here to there. Draft, really. But that will eventually turn into a nice roadmap hopefully.
Some parts of cubicweb are sometimes too hairy for different reasons (some good,
most bad). This participates in the difficulty to get started quickly. The goal of CubicWeb 4.0 should be to make things simpler :
Fix some bad old design.
Stop reinventing the wheel and use widely used libraries in the Python Web
World. This extends to benefitting from state of the art libraries to build nice
and flexible UI such as Bootstrap, on top of the JQuery foundations (which could
become as prominent as the Python standard library in CubicWeb, the development team should get
ready for it).
If there is a best way to do something, just do it and refrain from providing configurability and options.
First, a few simple things could be done to simplify the UI code:
drop xhtml support: always return text/html content type, stop bothering
with this stillborn stuff and use html5
move away everything that should not be in the framework: calendar?, embedding,
igeocodable, isioc, massmailing, owl?, rdf?, timeline, timetable?, treeview?,
vcard, wdoc?, xbel, xmlrss?
Then we should probably move the default UI into some cubes (i.e. the content of
cw.web.views and cw.web.data). Besides making the move to Bootstrap easier, this
should also have the benefit of making clearer that this is the default way to
build an (automatic) UI in CubicWeb, but one may use other, more usual,
strategies (such as using a template language).
At a first glance, we should start with the following core cubes:
corelayout, the default interface layout and generic components. Modules to
backport there: application (not an appobject yet), basetemplates, error,
boxes, basecomponents, facets, ibreadcrumbs, navigation, undohistory.
coreviews, the default generic views and forms. Modules to backport there:
actions, ajaxedit, baseviews, autoform, dotgraphview, editcontroller,
editforms, editviews, forms, formrenderers, primary, json, pyviews, tableview,
reledit, tabs.
corebackoffice, the concrete views for the default back-office that let you
handle users, sources, debugging, etc. through the web. Modules to backport
here: cwuser, debug, bookmark, cwproperties, cwsources, emailaddress,
management, schema, startup, workflow.
coreservices, the various services, not directly related to display of
something. Modules to backport here: ajaxcontroller, apacherewrite,
authentication, basecontrollers, csvexport, idownloadable, magicsearch,
sessions, sparql, sessions, staticcontrollers, urlpublishing, urlrewrite.
This is a first draft that will need some adjustements. Some of the listed
modules should be split (e.g. actions, boxes,) and their content moved to
different core cubes. Also some modules in cubicweb.web packages may be moved
to the relevant cube.
Each cube should provide an interface so that one could replace it with another
one. For instance, move from the default coreviews and corelayout cube to
bootstrap based ones. This should allow a nice migration path from the current UI
to a Bootstrap based UI. Bootstrap should probably be introduced bottom-up: start
using it for tables, lists, etc. then go up until the layout defined in the main
template. The Orbui experience should greatly help us by pointing at hot spots
that will have to be tackled, as well as by providing a nice code base from which
we should start.
Regarding current implementation, we should take care that Contextual components
are a powerful way to build "pluggable" UI, but we should probably add an
intermediate layer that would make more obvious / explicit:
what the available components are
what the available slots are
which component should go in which slot when possible
Also at some point, we should take care to separate view's logic from HTML
generation: our experience with client works shows that a common need is to use
the logic but produce a different HTML. Though we should wait for more use of
Bootstrap and related HTML simplification to see if the CSS power doesn't
somewhat fulfill that need.
The Werkzeug framework sounds like a good candidate to use as a library that
would replace/simplify the request, httpcache, session, authentication (maybe
more) modules as well as the wsgi package. It sounds like the right candidate for
the following reasons:
it's a non-intrusive WSGI library, not a web framework,
it's used by fairly popular frameworks (openerp, flask),
I'm +1 on A. Ronacher idea of a common request implementation for python web
frameworks, let's experiment and promote this idea.
Investigate URL routing modules as a replacement for urlpublishing, urlrewrite and
apacherewrite.
Candidates are :
werkzeug.routing, which has noticable pros: celebrated by A. Martelli,
provided by an already-in-wishlist library, URL routing AND generation.
routes (http://routes.readthedocs.org/en/latest/), pros: used by pylons,
features conditional matching based on domain, cookies, HTTP method... and
sub-domain support.
I've to say I'm somewhat impatient to find some time to give a try to
werkzeug.routing. IMO, used well, that may introduce a structural change that
would make things much easier to understand and configure properly.
The current looping task / repo thread mecanism is used for various sort of
things and has several problems:
tasks don't behave similarly in a multi-instances configuration (some should
be executed in a single instance, some in a subset); the tasks system has been
originally written in a single instance context; as of today this is (sometimes)
handled using configuration options (that will have to be properly set in each
instance configuration file);
tasks is a repository only api but we also need web-side tasks;
there is probably some abuse of the system that may lead to unnecessary
resources usage.
Analyzing a sample http://www.logilab.org/ instance, below are the running looping
task by categories. Tasks that have to run on each web instance:
clean_sessions, automatically closes unused repository sessions. Notice
cw.etwist.server also records a twisted task to clean web sessions. Some
changes are imminent on this, they will be addressed in the upcoming refactoring session (that will
become more and more necessary to move on several points listed here).
regular_preview_dir_cleanup (preview cube), cleanup files in the
preview filesystem directory. Could be executed by a (some of the) web
instance(s) provided that the preview directory is shared.
Tasks that should run on a single instance:
update_feeds, update copy based sources (e.g. datafeed, ldapfeed). Controlled
by 'synchronize' source configuration (persistent source attribute that may be
overridden by instance using CWSourceHostConfig entities)
expire_dataimports, delete CWDataImport entities older than an amount of
time specified in the 'logs-lifetime' configuration option. Not controlled
yet.
cleanup_auth_cookies (rememberme cube), delete CWAuthCookie entities
whose life-time is exhausted. Not controlled yet.
cleaning_revocation_key (forgotpwd cube), delete Fpasswd entities with
past revocation_date. Not controlled yet.
cleanup_plans (narval cube), delete Plan entities instance older than an
amount of time specified in the configuration. If 'plan-cleanup-delay' is set
to an empty value, the task isn't started.
refresh_local_repo_caches (vcsfile cube), pull or clone vcs repositories
cache if the Repository entity ask to import_revision_content (hence web
instance should have up to date cache to display files content) or if
'repository-import' configuration option is set to 'yes'; import vcs repository
content as entities if 'repository-import' configuration option and it is
coming from the system source.
Some deeper thinking is needed here so we can improve things. That includes
thinking about:
the inter-instances messages bus based on zmq and introduced in 3.15,
the Celery project (http://celeryproject.org/), an asynchronous task queue,
widely used and written in Python,
Remember the more cw independent the tasks are, the better it is. Though we still want an
'all-integrated' approach, e.g. not relying on external configuration of Unix
specific tools such as CRON. Also we should see if a hard-dependency on Celery or
a similar tool could be avoided, and if not if it should be considered as a
problem (for devops).
First, we should drop the different behaviour according to presence of a '.hg' in
cubicweb's directory. It currently changes the location where cubicweb external
resources (js, css, images, gettext catalogs) are searched for. Speaking of
implementation:
shared_dir returns the cubicweb.web package path instead of the path to the
shared cube,
i18n_lib_dir returns the cubicweb/i18n directory path instead of the path to the
shared/i18n cube,
migration_scripts_dir returns the cubicweb/misc/migration directory path
instead of share/cubicweb/migration.
Moving web related objects as proposed in the Bootstrap section would resolve the
problem for the content web/data and most of i18n (though some messages
will remain and additional efforts will be needed here). By going further this
way, we may also clean up some schema code by moving cubicweb/schemas and
cubicweb/misc/migration to a cube (though only a small benefit is to be expected
here).
We should also have fewer environment variables... Let's see what we have today:
CW_INSTANCES_DIR, where to look for instances configuration
CW_INSTANCES_DATA_DIR, where to look for instances persistent data files
CW_RUNTIME_DIR, where to look for instances run-time data files
CW_MODE, set to 'system' or 'user' will predefine above environment variables differently
CW_CUBES_PATH, additional directories where to look for cubes
CW_CUBES_DIR, location of the system 'cubes' directory
CW_INSTALL_PREFIX, installation prefix, from which we can compute path to 'etc', 'var', 'share', etc.
I would propose the following changes:
CW_INSTANCES_DIR is turned into CW_INSTANCES_PATH, and defaults to
~/etc/cubicweb.d if it exists and /etc/cubicweb.d (on Unix platforms) otherwise;
CW_INSTANCES_DATA_DIR and CW_RUNTIME_DIR are replaced by configuration file
options, with smart values generated at instance creation time;
the above change should make CW_MODE useless;
CW_CUBES_DIR is to be dropped, CW_CUBES_PATH should be enough;
regarding CW_INSTALL_PREFIX, I'm lacking experience with non-hg-or-debian
installations and don't know if this can be avoided or not.
Last but not least (for the moment), the 'web' / 'repo' / 'all-in-one'
configurations, and the fact that the associated configuration file changes
stinks. Ideas to stop doing this:
one configuration file per instance, with all options provided by installed
parts of the framework used by the application.
activate 'services' (or not): web server, repository, zmq server, pyro
server. Default services to be started are stored in the configuration file.
There is probably more that can be done here (less configuration options?), but
that would already be a great step forward.
Remember the following goals: migration of legacy code should go smoothly. In a perfect world every application should be able to run with CubicWeb 4.0 until the backwards compatibility code is removed (and CubicWeb 4.0 will probably be released as 4.0 at that time).
Please provide feedbacks:
do you think choices proposed above are good/bad choices? Why?
do you know some additional libraries that should be investigated?
do you have other changes in mind that could/should be done in cw 4.0?
I attented the conference organised by IRI in a series of conferences about "Muséologie, muséographie et nouvelles formes d’adresse au public" (hashtag #museoweb). This particular occurence was about "Le Web devient audiovisuel" (the web is also audio and video content). Here are a few notes and links we gathered. The event was organised by Alexandre Monnin @aamonnz.
Following his presentation, the question was asked if using Wikipedia content on an institutional web site would be possible in France, I pointed to the use of Wikipedia on http://data.bnf.fr , for example at the bottom of the Victor Hugo page.
Raphaël Troncy @rtroncy made a presentation about "Media Fragments" which will enable sharing parts of a video on the web. Two major features : the sharing of specific extracts and the optimization of bandwith use when streaming the extract (usefull for mobile devices for example). It is a W3C working draft : http://www.w3.org/TR/media-frags-reqs/. Here are a few links of demos and players :
The technologies seen during this conference are often related to semantic web technologies or at least web standards. Some of the visualizations are quite impressive and could mean new uses of the Web and an inspiration for CubicWeb projects.
A few of the people present at the conference will be attending or presenting talks at SemWeb.Pro which will take place in Paris on the 2nd and 3rd of may 2012.
Many desktop applications offer the possibility for the user to
undo the recent changes : a similar undo feature has now been
integrated into the CubicWeb framework.
Because a semantic web application and a common desktop
application are not the same thing at all, especially as far as
undoing is concerned, we will first introduce what is the undo
feature for now.
A CubicWeb application acts upon an Entity-Relationship model,
described by a schema. This ensures some data integrity
properties. It also implies that changes are made by group called transaction : so as to insure the data integrity the transaction is completely applied or none of it is applied.
What may appear as a simple atomic action to a user can actually consist in several actions for the framework. The end-user has no need to know the details of all actions in those transactions. Only the so-called public actions will appear in the description of the an undoable transaction.
Lets take a simple example: posting a "comment" for a blog entry will create the entity itself and the link to the blog entry.
For now there are two ways to access the undo feature when
it has been activated in the instance configuration file with
the option undo-support=yes. Immediately after having done something the undo** link appears in the "creation" message.
Otherwise, one can access at any time the undo-history view
accessible from the start-up page.
This view shows the transactions, and each provides its own
undo link. Only the transactions the user has permissions to
see and undo will be shown.
If the user attempts to undo a transaction which can't be undone or whose undoing fails, then a message will explain the situation and
no partial undoing will be left behind.
The undo feature is functional but the interface and configuration
options are quite limited. One major, planned, improvement would be enable the user to filter which transactions or actions
he sees in the undo-history view. Another critical
improvement would be to selectively enable the undo feature on part of the entity-relationship schema to avoid storing too much
data and reduce the underlying overhead.
Feedback on this undo feature for specific CubicWeb applications is welcome.
More detailed information regarding the undo feature will be published in the CubicWeb book when the patches make it through the review process.
There has been a growing interest in ZMQ in the past months, due to its ability to efficiently deal with message passing, while being light and robust.
We have worked on introducing ZMQ in the CubicWeb framework for various uses :
As a replacement/alternative to the Pyro source, that is used to connect to distant instances. ZMQ may be used as a lighter and more efficient alternative to Pyro. The main idea here is to use the send_pyobj/recv_pyobj API of PyZMQ (python wrapper of ZMQ) to execute methods on the distant Repository in a totally transparent way for CubicWeb.
As a JSONServer. Indeed, ZMQ could be used to share data between a server and any requests done through ZMQ. The request is just a string of RQL, and the response is the result set formatted in Json.
As the building block for a simple notification (publish/subscribe) system between CubicWeb instances. A component can register its interest in a particular topic, and receive a callback whenever a corresponding message is received. At this point, this mechanism is used in CubicWeb to notify other instances that they should invalidate their caches when an entity is deleted.
Cubicweb has had WSGI support for several years, but this support was incomplete.
The WSGI team was in charge of turning WSGI support into a full featured backend that could replace Twisted in real production scenarii.
Because we only had first class support for Twisted, some of the CubicWeb logic related to HTTP handling was implemented on the twisted side with twisted concepts. Our first task was to move this logic in CubicWeb itself. The handling of HTTP status in our response was improved in the process.
Our second task was to focus on the "non-HTTP" part of CubicWeb (because the repository also manages background tasks). The developement mode for WSGI is now able to handle and run such tasks. For this purpose we have begun a process that aims to remove server related code from the repository object.
We also Tested several WSGI middleware. One of the most promising is Firepython, integrating python logging and debugging feature with Firebug. werkzeug debugger seems neat too.
All these improvements open the road to a simple and efficient multi-process architecture in CubicWeb.
