rapido extra view ONLY works if it is the first defined on a new Plone instance (only tested on filesystem theme)

[pigeonflight]

I wanted to map my rapido app to a custom extra view with an id of my choice. I followed this guide http://rapidoplone.readthedocs.io/en/latest/reference/display.html?highlight=view#extra-views1

This was done with the following conditions:

• A filesystem based Diazo Theme (I did not test if this is an issue with a TTW based theme)
• Plone 5.0.7
• rapido.plone 1.1.1 with plone.resource 1.2

Steps to repeat

Step 1 - Create a rapido app with the following layout:

In a site served at url http://localhost:8080/Plone/ define your rapido app in a filesystem based theme.

rapido/app/blocks/frontlinks.pt
rapdo/app/blocks/frontlinks.py
rapido/app/blocks/frontlinks.yaml

Step 2 - Define an extra view In the frontlinks.yaml file.

elements:
    links: 
        type: BASIC
view:
    id: first-defined-view
    with_theme: true

Step 3 - Visit the defined view

Visiting http://localhost:8080/Plone/@@first-defined-view works as expected

Step 4 - Change the extra view id

elements:
    links: 
        type: BASIC
view:
    id: second-defined-view
    with_theme: true

Now attempt to visit http://localhost:8080/Plone/@@second-defined-view
Instead of the view, I get a "page not found type error".

Step 5 - Create a brand new Plone site and enable the same theme

Now attempt to visit http://localhost:8080/Plone2/@@second-defined-view
It will work on both Plone sites.

Expected behaviour

Changing the view id should ALWAYS work in the context of the Plone site that you are making the change on.

My Suggestions

This appears to be more difficult than I thought. I think the following should be added to the docs
0. It should be noted that a filesystem theme is known to cause problems when there are multiple instances sharing the same Zope.

1. As a convention people should be encouraged NOT to vary the view id after deployment
2. There can be issues with view ids if you are using a filesystem based theme and that changes made to the view id will only become effective on new instances
3. People should be discouraged from depending on view ids in the scenario of a shared Zope and shared filesystem based themes
4. That works reliably TTW (still untested, so this is just a hunch)

[ebrehault]

I cannot reproduce the problem, it works fine with rapido.plone 1.1.1.

[pigeonflight]

Just did further testing.
With rapido 1.1 and 1.1.1
I tested it on Plone 5.0.7 and Plone 5.1b1

The view works for the first visit on the first instance. Changing the view configuration fails after that.
I'll note it in detail above.

[ebrehault]

@pigeonflight and when the second view fails, does the first one still working?

[pigeonflight]

@ebrehault yes the first valid configuration continues to work until the following is done:

1. changing the view id
2. spinning up a new Plone instance on the same zope
3. Visiting the new plone instance at the newly defined view id

This changes the view id in all Plone instances that share the filesystem diazo theme. This was observed with a filesystem theme and will probably not be a problem for TTW, but I haven't tested that use case.

[ebrehault]

Ok I see, that's because File-system based resources are not managed by Plone (see https://github.com/plone/plone.resource/blob/master/plone/resource/directory.py#L194 ), Plone can read directory contents, but it cannot be aware of changes, so there is no place where we can emit the PloneResourceModifiedEvent event.
As we cannot use the events here, a decent workaround wpuld be to implement a Refresh command that will ask Rapido to reload all the .yaml files on demand.

[pigeonflight]

+1 for the refresh command.
I'm still concerned that this will be an issue if sites that share views expect a certain endpoint.

In the meantime, for our customer projects, when we use filesystem views we shall work with the policy that those filesystem views should never be renamed.