If you read my blog regularly, the MVVM topic will be nothing new to you.
But please take your time and fill out my new survey, thanks for that, of course, even if you visit my blog for the first time. I would love it if you can also be part of this survey.
If you are a first-time-reader... Welcome to my blog. Please read the other posts about my #D.MVVM implementation. As you can see, this subject is not new to me and my knowledge has, of course, improved over the years. (I hope, I'm right with this statement)
- Workflow and multi - binding with #D.MVVM - The Delphi MVVM Framework!
- #D.MVVM - At what point is a framework ready for release?
- Live Youtube, Chat, FDK & MVVM...
- MVVM is just a concept.
- How long does it take to develop a "complete" MVVM framework for Delphi?
- MVVM for legacy Apps?
- MVVM PropertyChanged is not Component related!
- MVVM and Mobil app development.
- MVVM Survey results and feedback!
- Is there a sharp border between MVVM and MVC/MVP?
If you do not make it down to the end:
Here is the link to my new survey!
But perhaps you want to know why I've created a new one? ;-)
Let's collect - one more time - my goals:
- The framework must be as fast as possible. (My goal is - it is supposed to be the fastest MVVM framework available for Delphi.)
- The development time should not be significantly longer than using the RAD-Approach. At best, the development time should be shorter, comparing to a non MVVM, but not "everything in the Form unit" - development.
- Everything that could be done in a background thread should be done in a background thread.
- Support for FMX and VCL. Including the "special needs" for the FMX UI.
- It must definitely run on ALL platforms.
- 100% Unit-Test-able of your Application. (Switch for disabling the background thread to do a better Unit-Testing).
- Mockup's for View-Components to test the Binding of your App.
- A nice Wizard should be installed into the IDE to create a new VCL or FMX-MVVM Application. This Wizard should be changeable over an Ini-File to make a User-Configuration without recompiling the Wizard-DLL.
- One central binding point (Composition.Root)
- If you are an FDK-User (My Firemonkey-Development-Kit) the framework should work streamless as a plugin, with all the benefits of my ORM-Lite, threading, or Client-Server units.
- No need for special components. (Components must work without an extension)
- Open to User-Implementation for non-standard components.
- The View (Form) should not have a single line of code. Or should not need any code-behind...
- Visual Livebindings must not be used.
- A developer who has NEVER dealt with MVVM has to get along with my framework IMMEDIATELY.
- A good developer who has already used MVVM should find his way around immediately. (Except for some things that I have implemented differently than MS).
- We are Delphi-Developer - If we are doing MVVM differently than our C# friends - that's fine!
- Views must be able to be composed of any number of sub-Views (frames) without writing a single line of code for them. (Sub-Views must be interchangeable for special requirements)
- It must also be possible for a sub-View to be a ViewPort3D (FMX-Only). Full support of 3D objects from the ViewModel will be another thing for further investigation. This could be very interesting for Game-Development, but that is completely another topic.
- User-Level and flagged Menu-System with auto Action-Binding.
- Multiple View for a ViewModel, also with sub-View/ViewModel Binding.
- Conventions over definitions.
- This is especially true for automatic binding by naming convention. Example: Name: TEdit should auto bind to the fName: TProperty<String> or to a normal property Name: String. The Binding is connected to the Text-Property of the TEdit Component and the OnChange and OnChangeTracking (FMX Only) event should update the ViewModel.
- User-defined naming convention... Bind Name:TEdit to fEdNameField : TProperty<String>
- Global naming rules and also naming rules by TypeInfo.
- Overwrite any predefined rule with an attribute.
- Multi-Binding to different properties.
- Example: Save: TButton.OnClick -> Procedure DoSave
- Save :TButton.Enabled -> fCanSave : TProperty<boolean> or Property CanSave : boolean
- Fone : TCombobox.Items -> fFoneItems : TListProperty<String>.
- Also user-defined naming: "Can"+Save;"Do"+Save could be changed to: e.G.: -> "CheckFor"+Save;"Execute"+Save.
- Optimal performance on ".Strings";".Items";".Lines" - never ever send the complete list on a single change. A virtual created adapter must take care of the updates. (e.G. for a single changed line in a Memo of 10.000 lines it is a nogo to update the Text-Property of the Memo.)
- Data-Verification on Property-Level to check the fields inside the ViewModel.
- Listview and Listbox special treatment for FMX.
- A data model for VCL Grids - The FMX Grid already has a data model.
- A not so easy implementation of an MVVM-Treeview. (Perhaps not in the Beta)
- Complete logging of all internal functions should be possible. (Only for the Plugin Version)
- Error messages that are normally written in English must be able to be translated by an external language file.
- Only if the Framework supports the transfer of all the collected data from the ViewModel to the Model, my goal of: "As fast as RAD Development" is possible.
- The Framework must have a Datacontext that can make the transfer from the ViewModel to the Model, and back.
- The Datacontext should be able to convert, combine and separate fields as they are transferred back and forth.
- The Model should directly work as an ORM or REST-full Web interface.
- As an FDK-Plugin it should also work with my Client-Server-REST-Units.
A comment in advance from René Höger:
"Is a lot of information! Those who have dealt with this, I think will be hot on it! I don't know what your feedback is so far, but I think this could be a milestone. When I think of all my old applications! But maybe I am biased because I have already received an introduction into your framework!"
Perhaps I need to write some kind of NDA contract (never done before). One thing I want to avoid, after all these hours, is to find my Source-Code as a zip on a hacker site.
Before I could start the Alpha-Phase, I have to:
- Open up a ticket system or some kind of bulletin board?
- Perhaps a discord server?
- Perhaps a slack group?
- Think about how to collect User-contributions...
- Think about contribution benefits?
- Late or discount payment for Alpha & Beta users?