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 new Display overload in DisplayDriver and fix Edit overload #16505

Closed
wants to merge 7 commits into from

Conversation

MikeAlhayek
Copy link
Member

@MikeAlhayek MikeAlhayek commented Jul 29, 2024

Adding a new virtual method to the DisplayDriver

  • Display(TModel model, TDisplayContext context)

Also, fix the recently added virtual IDisplayResult Edit(TModel model, TEditorContext context) to ensure it actually gets calls.

Here is a summary of all changes

  • The IDisplayResult Edit(TModel model, TEditorContext context) method was added.
  • The IDisplayResult Display(TModel model, TDisplayContext context) method was added.
  • The Task<IDisplayResult> DisplayAsync(TModel model, IUpdateModel updater) method was removed. Instead, you can use DisplayAsync(TModel model, TDisplayContext context).
  • The Display(TModel model, IUpdateModel updater) was removed. Instead, you can use Display(TModel model, TDisplayContext context).
  • The Task<IDisplayResult> EditAsync(TModel model, IUpdateModel updater) method was removed. Instead, you can use EditAsync(TModel model, TEditorContext context).

Here is invocation path before the PR

Edit Invocation Path

EditAsync(TModel model, TEditorContext context) >> EditAsync(TModel model, IUpdateModel updater) >> Edit(TModel model, IUpdateModel updater) >> Edit(TModel model)

Display Invocation Path

DisplayAsync(TModel model, TDisplayContext context) >> DisplayAsync(TModel model, IUpdateModel updater) >> Display(TModel model, IUpdateModel updater) >> Display(TModel model)

Here is invocation path after the PR

Edit Invocation Path

Note here we removed the EditAsync(TModel model, IUpdateModel updater)

EditAsync(TModel model, TEditorContext context) >> Edit(TModel model, TEditorContext context) >> Edit(TModel model, IUpdateModel updater) >> Edit(TModel model)

Display Invocation Path

Note here we replaced DisplayAsync(TModel model, IUpdateModel updater) and Display(TModel model, IUpdateModel updater) with Display(TModel model, TDisplayContext context). So there is one less execution step in the chain.

DisplayAsync(TModel model, TDisplayContext context) >> Display(TModel model, TDisplayContext context) >> Display(TModel model)

@MikeAlhayek MikeAlhayek requested a review from Piedone July 29, 2024 15:06
@@ -72,14 +72,19 @@ public virtual Task<bool> CanHandleModelAsync(TModel model)

public virtual Task<IDisplayResult> DisplayAsync(TModel model, TDisplayContext context)
{
return DisplayAsync(model, context.Updater);
return Task.FromResult(Display(model, context));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about this one, since this is a subtly breaking change: Previously, if you've overridden Task<IDisplayResult> DisplayAsync(TModel model, IUpdateModel updater) then you also received Task<IDisplayResult> DisplayAsync(TModel model, TDisplayContext context) calls. Now you won't. It also goes against the patterns of IDisplayResult Display(TModel model, TDisplayContext context).

Copy link
Member Author

@MikeAlhayek MikeAlhayek Jul 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Piedone you are right. I think we should replace Task<IDisplayResult> DisplayAsync(TModel model, IUpdateModel updater) with Task<IDisplayResult> DisplayAsync(TModel model, TDisplayContext context) which is another breaking change to the display driver. This isn't bad since we already had another breaking change earlier from Jasmine in the display driver. Thoguths on replacing the parameter instead?

I don't think any of the updater parameter is as useful as the context. I think removing the updater parameter is better since context also gives you updater.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm inclined to say yes, because the IUpdateModel overrides are quite strange for me too, and there's no usage of it them in OSOCE either (just one that shouldn't be as it doesn't use the updater). But I'm surely missing something. @Skrypt can you help, please?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Piedone @Skrypt I made the changes in this PR because this is the only way this PR would work. Also, I think it's less overrides we have to manage. Please review this and let me know your thoughts.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here is the call stack path

Display

DisplayAsync(TModel model, TDisplayContext context) >> Display(TModel model, TDisplayContext context) >> Display(TModel model)

Edit

EditAsync(TModel model, TEditorContext context) >> Edit(TModel model, TEditorContext context) >> Edit(TModel model, IUpdateModel updater) >> Edit(TModel model)

Update

UpdateAsync(TModel model, TUpdateContext context) >> UpdateAsync(TModel model, IUpdateModel updater) >> Edit(model, updater)

@MikeAlhayek MikeAlhayek requested review from Piedone and Skrypt July 29, 2024 17:44
MikeAlhayek and others added 2 commits July 29, 2024 11:22
Co-authored-by: Zoltán Lehóczky <zoltan.lehoczky@lombiq.com>
Co-authored-by: Zoltán Lehóczky <zoltan.lehoczky@lombiq.com>
@sebastienros
Copy link
Member

I would suggest to go even further by keeping the only necessary ones:

DisplayAsync(TModel model, TDisplayContext context)

and

EditAsync(TModel model, TEditorContext context)

and

UpdateAsync(TModel model, TUpdaterContext context)

There is no reason to provide each of the sync overloads technically. Performance and code simplification. We could provide a helper base class, or users could do that, that would have these extra methods to override.

Maybe this was the original idea...

@MikeAlhayek
Copy link
Member Author

Closing this PR in favor of #16508 as per @sebastienros suggestions to improve performance.

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

Successfully merging this pull request may close these issues.

3 participants