Apphooks and Sub-pages

[Martin Koistinen]

Hi all, I'd like for us to discuss how, if at all, we'll support the existence of CMS pages under a page which has an app-hook.

If we plan to support this, it seems we have to make a choice:

1) Prioritize CMS sub-pages over application URLs during URL resolution

2) Prioritize application URLs over CMS sub-pages during URL resolution

Each one presents the possibility of shadowing that will lead to confusion and possibly 500 errors.

Thoughts?

[Martin Koistinen]

I propose we a method to the base CMSApp implementation for path inspection by the CMS. Default implementation returns an empty list for backwards compatibility with existing functionality. However, the developer is encouraged to implement this to return a list of "used"  slugs. We could then update the CMS's own URL resolution to consider these when creating new page slugs to avoid the creation of CMS pages with the same slug path. Any developer who implements this new method, should also inspect the CMS's own slugs when creating new application objects.

This will avoid shadowing for creation of new pages or application objects, however, collisions could still happen when dragging existing pages into existing apphook'ed nodes. This would again result in shadowing of either pages or objects. I presume this could be addressed by either automatic re-slugification of the pages being added that collide with existing application objects, or, we veto the drop operation and present a dialog explaining why.

Anyone see any issues with this approach?

[Iacopo Spalletti]

On 23/12/2015 16:54, Martin Koistinen wrote:
> I propose we a method to the base CMSApp implementation for path
> inspection by the CMS. Default implementation returns an empty list for
> backwards compatibility with existing functionality. However, the
> developer is encouraged to implement this to return a list of "used"
> slugs. We could then update the CMS's own URL resolution to consider
> these when creating new page slugs to avoid the creation of CMS pages
> with the same slug path. Any developer who implements this new method,
> should also inspect the CMS's own slugs when creating new application
> objects.
>
> This will avoid shadowing for creation of new pages or application
> objects, however, collisions could still happen when dragging existing
> pages into existing apphook'ed nodes. This would again result in
> shadowing of either pages or objects. I presume this could be addressed
> by either automatic re-slugification of the pages being added that
> collide with existing application objects, or, we veto the drop
> operation and present a dialog explaining why.
>
> Anyone see any issues with this approach?
>

How about having a soft 404 in handle_no_page which allows to fallback
to apphook urls?

As for available slugs, we can just reuse the menu system which does
exactly that and it does not require any special hook. For CMS we can
simply extend the relevant functions that checks available slugs, and we
can provide an API / sample code for external projects


--
Iacopo Spalletti

Nephila s.a.s. - Firenze
Telefono: +39 055 5357189
Assistenza Tecnica: +39 055 3985730
http://nephila.it