FYI Develop your custom controls

[jpesant]

You can easily build your controls or extend control like textbox by adding properties, methods or changing the render of it. The best way to understand how to do that is by exploring my custom controls on this github project:

GitHub - wet-boew/wet-boew-dotnet-controls: Web Controls .net adapted for Web Experience Toolkit (WET) including client validation

Web Controls .net adapted for Web Experience Toolkit (WET) including client validation - wet-boew/wet-boew-dotnet-controls

github.com

If you like challenge or contribute, don't hesitate to participate on this project. It's the best way to expend your knowledge on custom controls.

 

[Skydiver]

What's with the Smurf naming convention? Isn't that what namespaces are for?

 

[jpesant]

In this case, it's a library named wetcontrols but each controls aren't name with this namespace. They are the prefix 'Wet' because it's an extension of the .net controls. WetTextbox extends Textbox but it's the same thing when you call a control TextboxExt.

 

[JohnH]

Names of Classes, Structs, and Interfaces | Microsoft Docs
Names of Namespaces | Microsoft Docs

✓ CONSIDER ending the name of derived classes with the name of the base class.

This is very readable and explains the relationship clearly. Some examples of this in code are: ArgumentOutOfRangeException, which is a kind of Exception, and SerializableAttribute, which is a kind of Attribute. However, it is important to use reasonable judgment in applying this guideline; for example, the Button class is a kind of Control event, although Control doesn’t appear in its name.

I wouldn't consider a branding or technology prefix to be reasonable in naming a class. As Skydiver said, that belongs in a namespace. What if Microsoft had put a "Net" prefix on all classes in .Net Framework?
The name should indicate functionality, there's nothing wrong in calling your flavour of TextBox just "TextBox" if there is not a special purpose that you can explain in the name.

 

[Skydiver]

On a closer look at the source code for the various WetWidgetXs in that GitHub link above, it looks like it is still using WebForms to render controls, instead of the modern Razor approach. It feels like modern .NET Core is regressing back to old fashioned WebForms. Is the primary goal of this library to help people port their old WebForms code? Or does it have a different goal? I can't seem to find the reason for being in the README.md.

 

[jpesant]

I think I will develop both approach, WebForms (not WinForms) and Razor for MVC.