search

sulu / SuluArticleBundle

Bundle for managing localized content-rich entities like blog-posts in the Sulu content management system
MIT License
52 stars 77 forks source link

Add support for deep links #468

Open alexander-schranz opened 4 years ago

alexander-schranz commented 4 years ago

Currently every type has its own detail view:

https://github.com/sulu/SuluArticleBundle/blob/146bc852228d3c06020353f9eb292b10cb9796b6/Admin/ArticleAdmin.php#L241

This currently this make it impossible to use the sulu deep link feature. https://github.com/sulu/SuluArticleBundle/pull/467. From DX this is also annoying because the ArticleAdmin::EDIT_FORM_VIEW constant does link to a view which does not exist.

We need to find a way to get ride of the type specific routes or a way to support deep links to this routes.

So I'm questioning here is do we really need a detail view per type or can we merge them into 1 detail view which is used by every tab?

niklasnatter commented 4 years ago

After a quick look at the code, i think it could be possible to use a single view with a type attribute in the path and use addRouterAttributesToFormMetadata instead of addMetadataRequestParameters.

I guess the handling of the new type attribute could be implemented somehow similar to the handling of the webspace attribute in the PageAdmin.

niklasnatter commented 4 years ago

The fact that we use a seperate edit view for each article type also prevents to include articles in the admin search results. See #480

niklasnatter commented 4 years ago

I had a look at the proposed solution of using a single view with a type attribute today. Unfortunately, things are more complicated than I anticipated them. When implementing such a solution, we need to solve the following problems:

  1. The bundle allows to set permissions per article type. At the moment, we can check these permissions in the ArticleAdmin service and enable/add the respective toolbar actions. When implementing the edit form with a single view, we need to resolve and apply these permissions in the frontend. It should be possible to solve this similar to the solution for pages (include a _permissions object in the article API response).

  2. When implementing the edit form with a single view, we cannot set a type specific back view. This means that the user will always be sent to the first tab when he clicks the back button. This is not a problem for pages because webspaces are selected via a dropdown instead of tabs. Unfortunately, I cannot think about an easy solution for this at the moment. I fear that we are not able to solve this without adjusting the sulu/sulu core.