I really like Python. I always miss its elegancy when I write Javascript. But Javascript is a reality. It runs on all browsers. If you are a web developer, you need to know Javascript and its frameworks. Things are moving fast.

Plone development happens slow in comparison. Also we have Plone 5, but some universities are still at Plone 3. [My site is Plone 2.5, Maurits.]

plone.restapi is our bridge between Plone and the Javascript framework world. It is not opinionated: you can use Angular or React or tomorrow's framework.

You can login using the REST api and get a token back that you can use in subsequent requests. You can create/get/edit/delete content information, navigation, breadcrumbs, get or set registry settings, handle users. A unified search api will be tricky: making it usable for both default catalog, solr and elasticsearch is basically impossible.

plone.rest is stable. plone.restapi is still in the alpha phase, but a lot of companies are already using it. We are really open to contributions.

• https://pypi.python.org/pypi/plone.restapi
• https://pypi.python.org/pypi/plone.rest

Questions? Doesn't the front-end need access to some configuration information that we currently consider private? Yes, that is a problem we run into and are thinking about.

plone.server is just a project, it is not approved by the framework team, this is not in Plone core yet.

Philip Bauer in Brazil Plone conference 2013 was pushing people to think about the future of Plone. Where are we going. Plone has a really good component architecture, thanks to Martin Aspeli and others. After lots of discussions about the future in Bristol Plone conference 2014 Timo Stollenwerk started working on the Plone REST api. Asko Soukka worked on Mosaic. Nathan Vangheem worked on elasticsearch. Eric Brehault worked on front end with Angular 2. We took lots of these people and gathered them in Barcelona earlier this year. Fifteen developers on back-end, api and front-end. Experiment: could we do it? Yes, we had really great results. We have reached an experimental version of the whole stack. We will present this today in three talks.

In this talk: the back-end.

We split the various parts of Plone in three: front-end, basic core (dexterity, zodb), extra Plone stuff (link integrity, discussion). The division between the parts is bridged with a REST api and the framework api (plone.api).

Possible future is that plone.restapi will be included in Plone 6, and separate front-end is possible in a later version.

For plone.server we used as base ZODB 5, ZEO asyncio, and the ZTK (Zope ToolKit). It is an asynchronous app server that offers a traversable REST api with a ZODB.

It is a headless CMS: it does not include the view/presentation part.

Content type: there is no CMF, it is based on zope.container and dexterity. One content type: an item that is a container. Content types are specified declaratively, defined in Python code and zcml, not stored in the database, no option to create content types through the web at this point. A simple base.

plone.jsonserializer. Used on plone.app.mosaic. We need to merge this with plone.restapi. We did fixes yesterday night.

plone.registry is the main or really the only configuration place. All persistent info is in one place. For example portal actions should be in the registry.

API definition. Traversal is hard to define in an api, we used json. We use the websocket api. All is built on plone.restapi.

Mount databases or sites using json configuration. /DB/SITE/FOLDER/OBJECT.

In traversal we do a lot:

• Get the resource
• abstract the user
• language negotiation
• check access permission
• etc

Read calls (mostly GET) by definition do not write anything to the database. Any changes are rolled back.

On the request we make available several things like the site components, the main object, configuration registry, etc. Some helper methods. Upload/download is done with external blobstorage with async.

There is no ZCatalog, but there are ways to hook up what you want yourself. No GenericSetup, no acquisition, no z3c.form, no attribute traversal. No Zope roles, only Plone roles or permissions. The base Plone server does not need many packages outside of the ZTK.

It is Gunicorn compatible (WSGI). It is only for Python 3.5 and higher.

Extra packages: pserver.oauth, pserver.elasticsearch, pserver.gcouldstorage, pserver.cms.

You can try a demo with the repository at https://github.com/pyrenees/pserver.demo

We are a community! We can have fun! We should be proud!

Plone is fifteen years old this year. What does the future hold?

Plone 5.0 has been really positively received. Plone 5.1 is where we apologize for what we did in 5.0. Some stuff:

• Meta bundles generation, so you don't get so many javascript and css files.
• Getting rid of the quick installer, so you don't have two competing ways of installing stuff. We have an @@installer view now that only uses GenericSetup. We will warn when there is no uninstall profile. The default profile is now really the default profile, instead of the quick installer taking the first one alphabetically.
• Configure portal actions through the Plone UI.
• Retina image scaling. Set scaling ratios for higher resolution images. Pretty seamless.

That is definitely going in. Probably several or all of the following as well:

• Conditionally import registry records.
• Merge Products.RedirectionTool into the core, with new control panel.
• Add/edit/delete registry records in the UI.
• Get rid of old resource registries (portal_css, portal_javascript)
• Merge collective.emailconfirmationregistration into core.
• Merge collective.indexing into core, giving queued indexing, which gives performance improvement.
• Some javascript improvements.
• Mosaic, not yet 'plipped' (proposed) for 5.1. This is content layout using tiles, giving you a lot of flexibility over how a page looks. We started similar projects years ago when browsers were not ready for it yet. Let's see a demo. The layout is saved as simple html that you can manually edit if needed.

With Mosaic and Rapido you have very powerful through-the-web development. We were pushing people away from this, to safe them from themselves. But with these two, you can export it to the file system, which makes it much more viable and safe.

For Google Summer of Code:

• Vikas Parashar created several themes.
• Prakhar Joshi worked on collective.easyform, which is dexterity form creation. It now has an upgrade path from PloneFormGen.

Plone 2020 discussion: where do we want to go as community and as software project?

• APIs to hide complexity. plone.api. plone.restapi.
• Improve TTW customisation.
• Improve training and documentation. You can follow a training at http://training.plone.org or use this to give a training yourself. It gives you a jump start to development.
• Cleaner codebase: simplify structure, remove unused functionality and code.
• Update dependencies to latest versions, ztk, Zope 2/4, ZODB3. Most are already Python 3 compatible. That is the step needed for Plone before we can focus on Python 3 ourselves.

CMS traditionally has three layers: content storage, management and presentation. Headless CMS removes the presentation layer. If you have that, you can write your own fronts for it: traditional UI, phone app, other front-end framework. What we are currently building with plone.rest and plone.restapi is more a decoupled CMS, because the original front-end is still always there. In a sprint in Barcelona we worked on several parts of this:

• REST api
• front-end: working with plone.server or plone 5 + restapi, server side rendering via Angular Universal
• back-end: plone.server, aiohttp-based server.

There will be several talks about these today.

So we have two parallel paths to the future:

• server/client with rest api
• back-end Zope and other dependency cleanup

What have we ripped out in the past? Kupu, Archetypes, classic theme, portal_interfaces, plonetestcase, xdv, portal_Css, DTML, NuPlone, etc. The Hello Kitty Theme. And Plone still works. So we can do this.

See the PyGrunn website for more info about this one-day Python conference in Groningen, The Netherlands.

I am from the CWI, Center for Mathematics and Informatics, at Amsterdam, where Python was born, and where I worked on ABC, the basis for Python. I wrote parts of gcc. I ended up chairing the w3c html working group.

I will talk about Moore's switch and the future of programming.

We were developing ABC in the beginning of the eighties, when computers were really slow. However, we knew about Moore's law, that computers would become faster.

In the fifties, computers were really expensive. You could hire an hour of computer time for the amount of money you pay a developer in a year. What I call Moore's switch: this has gone the other way around. Earlier programming languages were geared towards making it the computer easier, not the programmer.

Moore's law: computing power doubles every 18 months. In 1977 was the first time I heard say that Moore's law was soon over. In 1988 my laptop had a power of 500, now it has doubled fifteen times.

By the 1970's, computers had become cheaper, but programmers not: software crisis. Ninety percent of the cost was in debugging. Fred Brookes wrote about this in The Mythical Man Month. The larger the program, the more expensive it becomes.

An order of magnitude improvement would help a lot. What takes one week, would take a morning instead.

A declarative approach is much shorter, and therefor faster to write. Can this help? What does declarative programming mean? I wrote a declarative clock program in the beginning of the 1990s of twelve lines, instead of 1000 for a procedural clock program.

Declarative: you specify what needs to be and remain true. This also means there can be no while loops.

Look at XForms for a declarative language. A certain company went from five years and thirty people to finish a project to one year and ten people, by using XForms. It shows that declarative programming is feasible, usable, for real world projects.

I believe that eventually everyone will switch to declarative programming.

Questions.

"Some programmers move from Python to lower level languages to get more performance out of computers." They may not have done the numbers. Programmers need to learn a new technique, which may make them not want to do this. Countries have held back the use of the Arab numerals that we now all use.

In ABC we saw that people were mostly busy with sorting and searching. So we made this very fast.

"Do big companies use this?" Yes, various, like Yahoo, IBM. Usually in small groups, not company wide.

"What will then happen with Python?" What happened to Pascal?

"Where should I start?" Look at Xforms. That is the only standardised version that I know of that does this stuff.

Strictly speaking, spreadsheets are declarative.

"What books do you recommend?" There are no books on XForms yet.

"Do you consider Prolog a declarative language?" Not really, though I see what you mean.

[For more information, see the XForms article on wikipedia, Maurits.]

Twitter: @stevenpemberton

Python and web developer since 1998. I did Zope, and for a little while it was as popular as Python itself.

What is this about? Implementation details, concepts, creativity, software development.

Morepath is a web microframework. The planet Zope exploded and Morepath came out. It has a unique approach to routing and link generation with Traject. Easy and powerful generic code with Reg. Extensible and overridable with Dectate.

In the early nineties you had simple file system traversal to publish a file on the web. Zope 2, in 1998, had traversal through an object tree, conceptually similar to filesystem traversal. Drawback: all objects need to have code to support web-stuff. Creativity: filesystem traversal is translated to an object tree. Similar: javascript client frameworks that mimick what used to be done on the server.

Zope 3 got traversal with components: adapt an object to an interface that knows how to publish to html, or to json. So the base object can be web agnostic again.

Pyramid simplified traversal, with __getitem__. So the object needs to be web aware again. Might not be an issue.

Routing: map a route to a view function. As developer you need to handle a 404 yourself, instead of letting the framework do this.

You can fight about this as frameworks. But morepath has it all. It is a synthesis.

I experimented with a nicer developer API than Zope was offering to get a view for traversal. So I created experimental packages like iface and crom. I threw them together in Reg. It was just a rewrite of the Zope Component Architecture with a simpler API.

Class dispatch: foo.bar() has self as first argument. Reg uses functools.singledispatch and builds multiple dispatch. But then I generalised it even more to predicate dispatch, as Pyramid had.

Don't be afraid to break stuff when you refactor things.

Dectate is a meta framework for code configuration. Old history involving Zope, Grok, martian, venusian, but now Dectate. With this you can extend or override configuration in your app, for example when you need to change something for one website.

Detours are good for learning.

Splitting things off into a library helps for focus, testing, documentation.

Morepath uses all these superpowers to form a micro framework.

Twitter: @faassen