If you asked me to use Vanilla Plone to define a custom display view through the web (TTW) for a News Item, I would normally do the following: use portal_types > News Item and register a view. Then I'd create the view (using the registered name) as a page template in portal_skins > custom.
I know this is possible in Plone 5. I also get the impression that using portal_skins is now discouraged. So what's the recommended way to pull this off on a Vanilla Plone 5 (no add-ons installed)?
I think the short answer is that it should not be done TTW anymore. The 'correct way' is probably to make browser view in your add on (or theme),
You will need
Another option could be: http://makina-corpus.com/blog/metier/2015/rapido-a-game-changer-for-plone
I'm currently looking for the simplest way to introduce a newbie (familiar with JS/HTML/CSS) to Plone. I'm fascinated with the idea of making Plone more hackable so things like collective.llistingviews, rapido, mosaic are great.
My goal is a completely through the web introduction to a common Plone 5 development scenario (custom content type, custom views and listing views) including not requiring a newbie to touch the buildout. At this point I have the following options:
How about trying collective.jbot? Mosaic makes it easy to create new layouts too. Diazo too.
I don't think we should accept that TTW work is no longer doable. We don't want to give up on large multi-site installations, because it is not scalable to require a file system Python / add-on developer for every small view change.
I think it is easier for a newbie to learn how to add a add-on like Mosaic or Rapido in the buildout and then use those powerful add-ons rather than to try to survive hacking on a vanilla Plone site.
Nevertheless I understand your point, and I think TTW is still a very valid approach in Plone 5 mainly considering what we can do using Diazo.
@tkimnguyen,
I have heard of collective.jbot, I'll keep it on my radar.
@ebrehault,
It seems my options look like one of the following:
Btw, has anyone used portal_view_customizations tool (plone.app.customerize) for ad-hoc TTW view registrations?
AFAIK, besides overriding templates, it also allows to register templates as views for any interfaces (similarly to filesystem registrations). It should work, but probably we all are too much scared by possible issues with persistent adapter registrations to really use it.
@datakurre I've never tried to add a new registration TTW that way. But I've been burned many many times by viewlet customizations that seemed to work ok but cause insufficient privilege errors because any view methods called in the customized viewlet run in restricted Python. Mysteriously, at the university we used to have many of those customized viewlets that worked fine for years then somehow would start causing errors. So mostly now I shy completely away from customizing any viewlets TTW!
Its one of the use cases for collective.listingviews. it allows you to expose the current objects content as well as one level of contents and then diazo it. The work hasn't been done to upgrade it to plone 5 yet.
It is also the use case of rapido and that is properly easier as it stores the code with the theme.
The recommended way is to not do it TTW any more. Without addons there is no good option, but for quick hacks I still use portal_view_customization and portal_skins regularly.
With addons I think Mosaic is the best way. It works great in Plone 5 and has a fair chance to land in Plone-core at some point. See the presentation at last Ploneconf: https://www.youtube.com/watch?v=ClfltAivJaQ
For a more developer-centric way (working with TAL and overriding existing templates) collective.jbot or something similar that would be tied to the resource-registry (which already allows you to override certain templates) would be my personal choice. collective.jbot has a long todo-list that will probably make it very useable in the future.
I think it would be a mistake to allow this condition to persist! TTW customization of a site should be doable, even if it requires that a Manager enable it on a per-site and maybe per-user or per-role basis.
Diazo is a good model: it lets us customize TTW, access to the theming control panel is restricted by security, and customized themes can be downloaded (and then copied to a versioned repo if so desired).
Would this work? In your Diazo theme, add a new HTML page called (for example) mynews.html, and make it look how you want. Add a rule to rules.xml to use mynews.html if-path="/news" to apply to all items in the /news folder. Add more rules inside that conditional block to replace mynews.html divs (title, summary, body) with the ones from the actual content.
Don't get me wrong I very strongly favor TTW customizing. But I think it is simply true that the current state does not allow us to recommend a way that is accessible without using a addon. Simply use Mosaic.
Its possible to use just diazo if all the info you want to display is already contained on an existing display view. Unfortunately its often not easy to do without xslt when you having repeating content like a listing. I'd like to add a subtemplate kind of idea to diazo to make it easier.
Ideally you wouldn't use path conditional as they tend to be brittle. The body tag generated by a display view is one of the nicest to use. Listingviews makes adding a new display view item easy but that ttw way of adding new display view items should also be built into plone I think.
We have to make custom views doable TTW. If not, we are abandoning our designers, front-end developers, site managers, content contributors and the like—many who do not have access to run buildout and/or have sys admins who not cooperative; yet these people are still responsible for meeting or exceeding their client's expectations, on demand.
I think for those who are used to controlling an entire Plone ecosystem, it's easy to forget how very very very very different running buildout for a local instance on a Mac is compared to running buildout on a server, and even more complicated if the test server is a production-evironment clone and includes caching, multiple zeos, authentications, redirects, etc. (oh the errors that can arise!).
Without TTW custom view capability, we're asking these "front-end people"to not only learn some sys admin skills but be able to troubleshoot like one too.
And before someone says that's it's not that hard to learn some sys admins skills, 1. maybe it is, 2. why would there be an expectation that they would have an interest in learning those skills, and 3. they're busy enough with other front-end work like theming; content strategy; analytics, marketing, and communications; user training; workflows; documentation; and creating content.
+100. And to get there that means despite the fact we, as core developers, know and love filesystem views and templates, we need to try things like rapido and other attempts to do ttw views and consider how suitable they are. How can we make it not overly complex but also very flexible? How can we avoid having know too much?
End users aren't going to give us much feedback and contribute ideas. We need to eat our own dog food and use these on our own projects.
I couldn't find a way to like this a second time, but I fully endorse this.
Some of the things I used to have to do via custom templates are now doable with Mosaic. It's not a complete answer, but it is easy to do some things TTW that were much more difficult before.
https://github.com/collective/collective.jbot also should help.
are't you asking for mosaic in core? 
I use portal_view_customizations to modify view templates; usually I want them changed permanently.
and what if a site doesn't have a theme package and is modifying Barceloneta: how are custom javascript files added to a custom view (skins folder, via Asko's blog post, the theming panel, not possible)?