Wizard for the Reverse Engineer Feature to improve developer UX #2626
Comments
|
Amazing - are you really willing to take on this huge task? This will be a great UX improvement. So we can basically add a new menu item: "Reverse Engineer Wizard (experimental)" and not break the exiting experience until we feel confident with the wizard. Some additional thoughts/concerns:
|
|
Yes, already started; you created a very valuable tool that my team will be relying on; glad to help. I’ll implement all of your suggestions. What do you think about an additional wizard page (post processing) for navigation properties? The page could have treeview with all selected / processed tables, containing node for navigation props. I was thinking a context menu for “rename” while keeping the F2 as well. This removes complexity of navigation properties while providing consistent interface for subsequent updates.
Get Outlook for iOS
From: Erik Ejlskov Jensen ***@***.***>Sent: Sunday, November 17, 2024 3:56 AMTo: ErikEJ/EFCorePowerTools ***@***.***>Cc: Bill Kratochvil ***@***.***>; Author ***@***.***>Subject: Re: [ErikEJ/EFCorePowerTools] Wizard for the Reverse Engineer Featureto improve developer UX (Issue #2626)
Amazing - are you really willing to take on this huge task?
This will be a great UX improvement.
So we can basically add a new menu item: "Reverse Engineer Wizard (experimental)" and not break the exiting experience until we feel confident with the wizard.
Some additional thoughts/concerns:
There is also the call to the additional "Schema selection" and "Advanced settings" dialogs, I think we can keep both as is today?
Maybe we could replace the VS statusbar feedback during dialog transitions with a dialog step giving detailed progress?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
Get Outlook for iOS
|
I say let's stick to the basics for now .. and I do not know of any current feature for navigation renaming other than T4. |
|
More thoughts:
|
|
FYI, my plan is to focus first on functionality; once all dialogs are refactored into the wizard (and working) I will circle back and comply with all logic/UI request. So please don’t take upcoming updates as ignoring request. Another objective will be to change “as little” code as possible, while moving the code forward with its new wizard. |
|
@BillKrat sounds good, let's start simple! |
|
@ErikEJ I created a project to manage the wizard work and assigned you as admin EFCorePowerTools Reverse Engineer Wizard; please feel free to update backlog as needed. Note: I created tasked, estimated, and provided a projected roadmap for work. |
|
@BillKrat I added some updates to the project |
|
@ErikEJ reference video of wizard at work. There are two remaining development tasks in the project .
For this phase of development the goal was to touch as little code as possible. In the future should you want to upgrade the EfCorePowerTools and are interested we can revisit a pattern more suitable for wizard support (using actual BLL and DAL). I'll be adding testing tasks. This part will slow me down as I'll have to ramp up to application outside of the reverse engineer feature, e.g., untouched dialogs which should work. Since I touched very little code in the handler the scope of testing should be minimal. If you do a code compare between the current and new handlers you'll see the only changes that impact actual code (short of menu updates). I worked hard to ensure backwards compatibility.
|
|
@ErikEJ |
|
@BillKrat Awsome! Potential summary wizard page: A page with a read only text box labelled "Summary" - contains the output from the Extensions output window, possibly with warning: and error: replaced with icons / emojis
Where will they be moved to?
|
On this link it was suggested they be moved to the new summary page. I'll be starting the new summary page early this week. I'll go with the guidance you provided [and any new ideas that you may have]. |
Ah! Thinking more about it and viewing your video, I think the help button / link should remain on the advanced options page, and the Rate link/button could be moved to the summary page. |
|
@BillKrat Just checking in if you are blocked waiting for any input from me? |
This issue aims to improve the developer UX by implementing a wizard for the Reverse Engineer feature.
The POC is available at this fork / branch
Reverse Engineering Wizard
The following video demonstrates the wizard at work. Don't be distracted by its current design as XAML can be easily configured to look as required. At this point, it is a POC to demonstrate that a wizard can be used within the existing EFCorePowerTools project. The code for the wizard comes from the Microsoft WPF-Samples project [Windows/Wizard folder] which was slightly refactored for our purposes.
Where the patterns and design are subject to discussion and approval, the proposed path would be to use the Model-View-Presenter, View-Model [MPV-VM] pattern which is described below. However, unlike true MVP-VM, the view's code-behind logic may remain intact to minimize the refactor effort; with MVP-VM the view does not contain business logic.
mvpvm-demo.mp4
The sequence diagram below is a high level view of the wizard's primary classes. Note that the location of each
class within the solution is located below each timeline box (in gray), e.g., RegEngWizardhandler.cs is located
under the solution's Shared / Handlers / Wizard folder.
Figure 1
MVP-VM
The pattern suggested for the proposed work is the Model-View-Presenter, View-Model pattern. The current design lends
itself to this because it isn't a true MVVM pattern; unlike MVVM, the existing handler performs much of the business logic
invoking business logic within each of the view's code-behind classes, thus effectively overcoming some MVVM limitations. Traditional MVVM is more a "widget" pattern that mirrors the MVC pattern (adapted for WPF). With MVVM, the view and view model contain all of the logic and as such cannot be easily reused because of the tight coupling between the view, view model, and its logic layers.
Note: MVC evolved to the Model-View-Presenter pattern to overcome such limitations. MVP-VM (like MVP) is more of a framework pattern which will required for our use case.
Presenter (RevEngWizardHandler)
The presenter has primary responsibility for communicating with the business logic layer to populate the view model(s).
This pattern allows the views and view models to remain decoupled (lending to easier reuse and unit testing); Views
and view models do not access the business and/or data layers directly.
Model
Business and data access layers compose the model (in the MVC days it might have been referred to as application model). The presenter will use the business logic layer to populate the view models as required. Under MVP-VM, the business logic layer is the only component that communicate with the data access layer.
Views / View Models
The view reflects the data that is on its view model. Outside of the UI behavior logic, there is generally no business
logic within the view code-behind using MVP-VM. Under MVP-VM it is easy to reuse views and view-models because of this decoupling.
Note: for more indepth information on MVP-VM you can read my MSDN 2011 article MVP-VM Design Pattern for WPF
Proposed design
The below use case diagram reflects the relationships between the existing, and new, components.
Figure 2High level UML for current design
These diagrams are not all inclusive, but will provide a high level view of applicable classes and primary processes invoked.
Page 1 - Choose Your Data Connection
Figure 3Page 2 - Choose Your Database Objects
Figure 4Page 3 - Choose Your Settings For Project
Figure 5The text was updated successfully, but these errors were encountered: