Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for deep links #468

Open
alexander-schranz opened this issue Apr 28, 2020 · 3 comments
Open

Add support for deep links #468

alexander-schranz opened this issue Apr 28, 2020 · 3 comments

Comments

@alexander-schranz
Copy link
Member

Currently every type has its own detail view:

$this->viewBuilderFactory->createFormViewBuilder(self::ADD_FORM_VIEW_DETAILS . '_' . $typeKey, '/details')

This currently this make it impossible to use the sulu deep link feature. #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
Copy link
Contributor

niklasnatter commented Apr 29, 2020

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
Copy link
Contributor

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
Copy link
Contributor

niklasnatter commented May 22, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants