Skip to content
This repository has been archived by the owner on Jan 16, 2024. It is now read-only.

Enhancement: Default Default Constructor Visibility #43

Closed
dcastenholz opened this issue Dec 18, 2018 · 6 comments
Closed

Enhancement: Default Default Constructor Visibility #43

dcastenholz opened this issue Dec 18, 2018 · 6 comments
Labels
as designed As designed

Comments

@dcastenholz
Copy link
Contributor

The title is not a typo. I would like a new setting in the designer for Entity Model settings that will set the default visibility for the default constructor for all entities in the model. OData requires a public default constructor for POST operations. The second half of the feature would be in the code generation side where you could have something like:

public void WriteConstructor(ModelClass modelClass)
{
	Output("partial void Init();");
	NL();

	/***********************************************************************/
	// Default constructor
	/***********************************************************************/
			
	bool hasDefaultVisibility = GetDefaultVisibility() == null;
	bool hasRequiredParameters = GetRequiredParameters(modelClass, false).Any();
	string visibility = !hasDefaultVisibility && (hasRequiredParameters || modelClass.IsAbstract) ? "protected" :  GetDefaultVisibility();
...

Thanks for such an awesome effort and product.

@msawczyn msawczyn added the enhancement New feature request label Dec 23, 2018
@msawczyn
Copy link
Owner

Unfortunately, that's pretty much an edge condition that I don't think should be implemented in the main project. The reason the tool decides the default visibility of the default constructor the way it does is due to required properties, both scalar values and associations. It would be all too easy to allow an override that would then allow an invalid object to attempt to be saved, which would blow up at runtime.

This is a perfect case for the ability to modify the generated code by editing the T4. You clearly have a good grasp on how the template works, and I'd suggest that you just override the generation the way you need it done. That will give you the ability to use the POCO objects for ODATA while at the same time giving design safety for the masses.

@msawczyn msawczyn added as designed As designed and removed enhancement New feature request labels Dec 24, 2018
@dcastenholz
Copy link
Contributor Author

I was trying to stay in sync with your updates on the .tt's if possible. Even if it could be moved into the model without exposing it in the UI, that would help. I would just set it in the first .tt and all the others would be as-is.

@dcastenholz
Copy link
Contributor Author

If I did a pull request, would you be inclined to consider it? I might decide to branch it anyway, but that is a significant effort for the return. If not, I COMPLETELY understand. Thanks.

@msawczyn
Copy link
Owner

msawczyn commented Jan 9, 2019

Certainly! Always welcome pull requests.

@dcastenholz
Copy link
Contributor Author

I am in the middle of a big project right now, but i AM planning on doing a pull request. I will address this issue as well as another that I am going to enter shortly. Thanks for a great project.

@msawczyn
Copy link
Owner

Closing due to age. Looking forward to the PR!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
as designed As designed
Projects
None yet
Development

No branches or pull requests

2 participants