Skip to content

Warnings during model binding #30

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

Closed
jballe opened this issue Feb 18, 2025 · 2 comments · Fixed by #31
Closed

Warnings during model binding #30

jballe opened this issue Feb 18, 2025 · 2 comments · Fixed by #31
Assignees
Labels
enhancement New feature or request

Comments

@jballe
Copy link
Contributor

jballe commented Feb 18, 2025

This line is causing a lot of console output and warnings when using the StarterKit.
I agree that it seems unexpected but should we give a warning? Or maybe it should be something that can be enabled/disabled?

https://github.com/Sitecore/ASP.NET-Core-SDK/blob/44c614011a9344e36624272b3f067017903eae3e/src/Sitecore.AspNetCore.SDK.RenderingEngine/Binding/SitecoreLayoutModelBinder.cs#L55..L60

In the NextJs SDK there are no warnings (and no strong types).

In the StarterKit there are several components that can use either a page/route field or a specific data source aka component field. That has been solved by using multiple fields and hereby the warning is triggered.

https://github.com/Sitecore/xmcloud-starter-dotnet/blob/main/headapps/aspnet-core-starter/Models/PageContent.cs

I would at least suggest that the out-of-the box configuration should not give a lot of warnings.

It might also be that it would be meaningfull with a binding that solves this fallback scenario (use component field if a data source value but fallback to route field) instead of building the logic in the head application over and over.

@robearlam
Copy link
Member

Agree, this isn't ideal, but I think the log message is still helpful when building.

What would you think about us changing this to be a Debug message instead of a warning? That way developers could see the message to help them when needed, but it wont end up polluting prod logs?

@jballe
Copy link
Contributor Author

jballe commented Mar 8, 2025

Agree, it is much better to have it as a Debug message so developers have a chance to enable and investigate if binding result is not as expected but the default behavior is not "polluted" with those (expected) log warnings.

I still think it would be simpler and more clean to have a dedicated binder/attribute to indicate that the value should be from either datasource or page - and hereby remove a lot of code and complexity in the head application. But that could be a PR for the future 😆

Let's change to a Debug message 👍

@robearlam robearlam linked a pull request Mar 11, 2025 that will close this issue
3 tasks
@sc-ivanlieckens sc-ivanlieckens added the enhancement New feature or request label Apr 7, 2025
@sc-ivanlieckens sc-ivanlieckens moved this to In review in ASP.NET Core SDK Apr 7, 2025
sc-ivanlieckens pushed a commit that referenced this issue Apr 7, 2025
This fixes issue #30 

## Description / Motivation
Changes level of log level during model binding when field is missing
from warning to debug

## Testing

- [x] The Unit & Intergration tests are passing.
- [x] I have added the necessary tests to cover my changes.

## Terms
- [X] I agree to follow this project's [Code of
Conduct](CODE_OF_CONDUCT.md).
@github-project-automation github-project-automation bot moved this from In review to Done in ASP.NET Core SDK Apr 7, 2025
jballe added a commit to jballe/Sitecore-ASP.NET-Core-SDK that referenced this issue May 22, 2025
This fixes issue Sitecore#30 

## Description / Motivation
Changes level of log level during model binding when field is missing
from warning to debug

## Testing

- [x] The Unit & Intergration tests are passing.
- [x] I have added the necessary tests to cover my changes.

## Terms
- [X] I agree to follow this project's [Code of
Conduct](CODE_OF_CONDUCT.md).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants