Give the store panel its own view components and base class - #774
Merged
KrzysztofPajak merged 2 commits intoAug 10, 2026
Merged
Conversation
Two of the eleven view components in Grand.Web.Store were unfinished copies of their vendor counterparts. StorePageViewComponent declared namespace Grand.Web.Vendor.Components while living in the store project, and both it and StoreWidgetViewComponent derived from BaseVendorViewComponent. The other nine use Grand.Web.Store.Components and BaseAdminViewComponent. No behaviour changes. The [Area] attribute those base classes carry is inert for a view component - MVC resolves a component's view from the area of the request being served, not from an attribute on the component class - which is why the mismatch went unnoticed. What it cost was readability: two files claimed to belong to a panel they are not part of, in the area of the codebase where Admin, Store and Vendor are already hard to tell apart. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Grand.Web.Store had no base of its own, so its eleven view components
inherited BaseAdminViewComponent - and two of them BaseVendorViewComponent.
BaseStoreViewComponent joins its two siblings in Grand.Web.Common, where
the store project already looks for them, and all eleven now use it.
Still no behaviour change, and the existing code is what proves it: the
nine components that carried [Area("Admin")] render views that exist only
under Areas/Store/Views/Shared/Components - Grand.Web.Admin has no view
for any of them. A view component resolves its view from the area of the
request being served, so the attribute never took part. Moving it from
"Admin" to "Store" therefore cannot move where these views are found; it
only stops the class from claiming the wrong panel.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
KrzysztofPajak
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Type: bugfix
Issue
Two of the eleven view components in
Grand.Web.Storeare unfinished copies of their vendor counterparts:Components/StorePage.csdeclaresnamespace Grand.Web.Vendor.Componentswhile living in the store project, and derives fromBaseVendorViewComponent.Components/StoreWidget.cshas the right namespace but also derives fromBaseVendorViewComponent.The other nine use
Grand.Web.Store.ComponentsandBaseAdminViewComponent.Reproduce:
grep -h "class .*ViewComponent" src/Web/Grand.Web.Store/Components/*.cs— nineBaseAdminViewComponent, twoBaseVendorViewComponent.Solution
Both moved to the namespace and base class the other nine already use.
This changes no behaviour, and the reason is worth stating so the next reader does not go looking for one. The
[Area]attribute those base classes carry is inert for a view component: MVC resolves a component's view from the area of the request being served, not from an attribute on the component class. All three base classes are therefore interchangeable at runtime, which is exactly why the mismatch survived. What it cost was readability — two files claiming to belong to a panel they are not part of, in the corner of the codebase where Admin, Store and Vendor are already hard to tell apart.Not done here, worth a decision separately:
Grand.Web.Storehas noBaseStoreViewComponent, so its components inherit the admin one. Adding it would be more honest than the status quo, but it touches all eleven files and buys nothing at runtime.Breaking changes
None.
StorePageViewComponentandStoreWidgetViewComponentare resolved by component name (vc:store-page, and the widget zone invocations), not by namespace, and neither type is referenced by name anywhere outside its own file.Testing
dotnet build ./GrandNode.sln— succeeds, no new warnings.dotnet test src/Tests/Grand.Web.Store.Tests— 17 pass.vc:store-page system-name="StorePortalInfo") renders, and widget zones on store panel pages still render their widgets.Step 3 needs a store manager account and was not exercised on my side — see the note below.
🤖 Generated with Claude Code