I am CTO at Six Feet Up. Doing Plone since 2003. Lineage was one of my first contributions.

Lineage is an add-on for Plone. Enabled by the pieces that are built into Plone, like INavigationRoot, IPossibleSite, together as IChildSite. So we are using the ZCA (Zope Component Architecture).

With Lineage you create one site and lots of sub sites for departments. Advantages compared to having lots of Plone sites:

• You only need to upgrade Plone once.
• You can share content among the sites. You can link to it in the TinyMCE editor.
• Performance is better: you get a smaller footprint for all sites combined.

Disadvantages:

• Want to split them up into different Plone sites? That is a bit more difficult.
• Add-ons and configuration are global, not per sub site, so your sites need to be really alike.

There are various add-ons/extensions that build on Lineage, for example lineage.themeselection for giving sub sites a different theme.

Add collective.lineage to the eggs in your buildout. Activate it in the add-ons control panel. Go to a folder, to the actions drop down and enable this folder as a sub site. Within this folder, the home will be this folder. You can add sub sites within sub sites if you want. You can exclude a sub site from navigation if you want to.

I want to show you some cool tricks you can do.

You can use custom site types. As long as they are IFolderish types, you can enable a sub site on it. At Penn State we used that to ease creating a new course.

Some add-ons:

• lineage.registry, for storing some config per site
• lineage.index: adds a separate index to the catalog per site.
• Resonate is new and does moving and syndicating to sub sites.

With Resonate it is possible to move content between sub sites, via the workflow, giving control to the content managers of the sub sites.

With Resonate you can syndicate content to various sub sites, still using standard Plone workflow machinery. A teaser of a news item can then be shown on the other sub sites, where they point to the original item, so that one remains the canonical one, which is good for SEO. The editor can see which sub sites accepted and rejected the share.

How does it perform? I set up two Zope instances, one with 100 Plone Sites, one with 1 Plone Site and 100 sub sites. Advantage of Lineage, with blank sites: about 9 MB against about 130 MB. Startup memory did not differ much, slightly better for Lineage. (Audience: may be influenced by the ZODB cache size too.)

Lineage is actually Plone 5 compatible. Version 2.0 released last night.

Code: https://pypi.python.org/pypi/collective.lineage

Example usage: http://www.la.psu.edu

For migration from the old separate sites to sub sites we used transmogrifier.

Watch the video of this talk.

This is about Plone's new front-end library. Mockup is a framework for adding Javascript functionality from other libraries to Plone. Will be part of Plone 5.

For example the 'moment' pattern:

some date

That will output a nicer date using the client browser language.

Currently, on Plone 4.3, we are still developing js as if it were 2004. 41 Javascripts registered in a default site. The resource registries have a packer functionality, with last commit from 2009. Maybe not so good anymore. No tests.

History of mockup. Based on Patternslib, created by Cornelis Kolbach and Wichert Akkerman and others in 2011. Forked by Rok Garbas in 2012, split up in Mockup and Mockup core in December 2013. plone.widgets and plone.app.widgets by Nathan van Gheem in November 2011, an attempt to bring more modern UI to Plone.

Build environment:

• Yo: used to generate base skeleton
• Grunt: comparable to buildout for js
• NPM: node package manager
• Front end: RequireJS.
• Testing: Karma, Mocha, ExpectJS/CHAI

[Showing some code.]

We made a generator for mockup:

npm install -g generator-plonemockup
yo plonemockup

Then you answer a few questions and you get a base pattern.

Now do some coding and call make and it will minify, create a bundle, etc.

There is a training that you can follow online:

http://mockup-training.readthedocs.org

Alternatives:

• Patternslib is still being developed and is of course similar to Mockup due to the shared history.
• Web components, w3c draft. Some experimental projects, Google Polymer, Mozilla X-Tags. Limited browser compatibility. Status: html templates is completed, shadow dom and html imports are in draft.
• AngularJS directives are similar to Mockup. Angular is full stack framework. It will switch to Web Components once it is ready. Hard to migrate Mockup to using AngularJS of course.

Our opinion about Mockup: great framework, big improvement to current situation, nice workflow, but uncertainty about future, maybe Angular could be better. Open space tomorrow at 11:00.

Audience: mockup (or patternslib) is an abstraction layer, Angular is something really different. Don't use Angular as base for the Plone JS. We have to get the whole community into thinking 'Javascriptish', really push it into the head of more developers. It is actually pretty easy to change a Mockup pattern into a Patternslib pattern or the other way around. Changing a date picker pattern into a different one? Not so difficult either. Not enough people are currently feeling secure developing with Mockup, but that will come.

Watch the video of this talk.

In some cases there are many sites that are almost the same, for example universities using Plone EDU. Different look and feel, different content, same base.

At Simples Consultoria we have been successful in dealing with this market.

Marketing Plone is very hard. It can do so much, is so flexible, how are you going to market that to a specific audience.

Marketing a solution is easier. If a client wants an intranet, I am not going to tell him that we made a portal for the Brazilian government.

Customizing Plone should not be hard. Distributions should be first class citizens. Offer a download specifically for educations or for an intranet on plone.org. The code we use to make the standard installers, VMs, packages, should be there for distributions too.

We need documentation, tests. We would love to have help with Jenkins and stuff.

Talk the customer's language, know their needs. For example PloneGov and local initiatives.

Something like the Plone Intranet Consortium is the very best thing that happened to Plone in a long time. We need to work like this. Companies should act together. Plone and Intranet are a perfect match. Bring new people to Plone. Companies will save Plone. We love Plone, but Plone needs customers and companies.

Watch the video of this talk.

Why should you want to create or run a Plone product on Substance D? Because it is fun. It might be a good experience for the future of Plone.

Substance D has all the good things from Pyramid. Plus stores data in a ZODB. It is a CMS.

Rapido is the next Plomino version. Plomino started in 2006, still based on Archetypes, stores data into CMF objects. Uses extensively ZCatalog and PythonScript.

I turned it into Rapido. Plone 5. Based on dexterity.

• rapido.core, totally independent of Plone.
• Storage service: rapido.souper provides a storage service based on Souper. Souper works on Plone and Pyramid, so I chose it.
• rapido.plone, standard dexterity content types, adapts them using rapido.core, ideally uses nothing but plone.api.
• rapido.substanced, standard substanced.content classes, uses nothing but Substance D api.

[Demo of Plone part and Substance D part.]

So how is this done?

• TTW scripting is what Rapido is about. I could not use PythonScript, but I used zope.untrustedpython.
• Catalog: repozo.catalog is just fine, working on both systems.
• Content persistence: souper, created by Blue Dynamics, designed to work on both pyramid and Plone.
• settings persistence: using annotations. Very basic, but just works. Both contents can be IAttributeAnnotatable.
• Forms and widgets. Substance D has Deform, but it is not rich enough. Porting z3c.form to Substance D... maybe not. So: client side rendering with Angular Schema Form.
• Access control. Both systems have a granular ACL service. Probably possible to support them both transparently, but for now I created a custom security implementation.

My experience with Substance D. Pros:

• Fun.
• Happy to find all the good ingredients.
• Fast testing.

Cons:

• Not 100 percent ZCA ready, need to call config.hook_zca(), it works fine, no problem, I am just not comfortable with the 'hook' term here. Also, we would probably need a local registry.

Conclusions for me about Plone future:

• ZCA plus buildout plus ZODB make our identity, and we must preserve it. It sets us apart, it is something strong.
• We can find clever approaches to avoid a full rewrite. For example do more in plone.api instead of relying on what Zope does for us.
• Can we easily migrate to Substance D? No.
• Should we migrate to something else? No.

Watch the video and slides of this talk.

This talk is about the ENCODE portal, an encyclopedia of DNA elements.

I want to talk here about a pattern, not really about the specific technologies involved.

I work at the data coordination center, generating and organizing data. We get metadata submissions, store it in a metadata database. It is really a knowledge management system. It could have been built in Plone, but it would not be a great fit. I started from scratch based on Pyramid and ReactJS. Nowadays services more and more have a Javascript UI, where Javascript talks to the backend.

Embrace Javascript. There has been progressive enhancement. Single page web apps really need it. For building a portal, I have been looking at isomorphic web applications. Originally from the Render framework. It is important that pages are loading quickly. The exit rate for visitors goes just as quickly up with the loading time.

Json is the lowest common denominator for data. xml is more flexible, but more complex. In Python it is much easier to use json.

JSON-LD: json link data. Adopted recently by the w3c. It is partly about semantic data, but we are not using that yet.

At first we needed to duplicate the routing information on the server and the client side. JSON-LD allows us to express type information, which avoids the duplication.

You can have JSON-LD like this [in "pseudo json" here, just for the idea, Maurits]:

{
  @context: context/jsonld
  @id: ...
  @type: [biosample, item]
  @submitted_by: {
    @id: /users/lrowe
    @type: [user, item]
    name: Laurence Rowe
    }
}

Defined using JSON Schema, which is an IETF draft. Schema version, field definitions, types, validators. It is an extensible format.

All our normalized data is stored in Postgres as json. JSON-LD has the concept of framing, which objects should be embedded (mapping to a view in Plone terms), possibly doing some elasticsearch. Above it is server rendering (with NodeJs) that is creating html, and sends it to the browser. After the first page load, the browser uses Javascript to talk the the JSON-LD backend directly, instead of via the NodeJS server, letting the ReactJS Javascript do its own rendering.

The browser opens a page. Gets html back. Then it does a query for json data and gets that back and shows it on the page.

Indexing linked data. Updating one item may need a reindex of other items that link to it. We have written code for that. Using elasticsearch as a cache.

Come work with us, we are hiring.

See code at https://github.com/ENCODE-DCC

Watch the video and slides of this talk.