I migrated a Blazor FormEdit to it's equivalent in Blasorize and tbh I think the current Validations are a bit too much 'chatty' (don't know the correct word for this).
Using Blazor EditForm
<EditForm Model="Model" OnValidSubmit="@UpdateProfile">
<DataAnnotationsValidator />
<div class="form-group">
<label for="name">User name</label>
<InputText Id="name" Class="form-control" @bind-Value="Model.Name" />
<ValidationMessage For="@(() => Model.Name)" />
</div>
<div class="form-group">
<label for="email">Email</label>
<InputText Id="email" Class="form-control" @bind-Value="Model.Email" />
<ValidationMessage For="@(() => Model.Email)" />
</div>
<button type="submit" class="btn btn-primary">Update</button>
<a class="btn btn-secondary" @onclick="Reset">Reset</a>
</EditForm>
Using Blasorize
<Form>
<Validations @ref="m_validations" Mode="ValidationMode.Auto" Model="Model">
<Validation>
<Field>
<FieldLabel>User name</FieldLabel>
<FieldBody>
<TextEdit Placeholder="User name" @bind-Text="Model.Name">
<Feedback>
<ValidationError />
</Feedback>
</TextEdit>
</FieldBody>
</Field>
</Validation>
<Validation>
<Field>
<FieldLabel>Email</FieldLabel>
<FieldBody>
<TextEdit Placeholder="Email" Role="TextRole.Email" @bind-Text="Model.Email">
<Feedback>
<ValidationError />
</Feedback>
</TextEdit>
</FieldBody>
</Field>
</Validation>
</Validations>
<Button Color="Color.Primary" Type="ButtonType.Submit" Clicked="SubmitAsync">Submit</Button>
<Button Color="Color.Secondary" Type="ButtonType.Reset" Clicked="ResetAsync">Reset</Button>
</Form>
This is 15 lines of code in the old situation vs 20 lines of code in the new. And for me it makes it very hard to read the code to see what is actually the intend / happening here. It would be great if it would look something like this:
<ValidatedForm @ref="m_validations" Mode="ValidationMode.Auto" Model="Model">
<ValidatedField>
<FieldLabel>User name</FieldLabel>
<FieldBody>
<TextEdit Placeholder="User name" @bind-Text="Model.Name"/>
</FieldBody>
<FieldFeedback For="@(() => Model.Name)" />
</ValidatedField>
<ValidatedField>
<FieldLabel>Email</FieldLabel>
<FieldBody>
<TextEdit Placeholder="Email" Role="TextRole.Email" @bind-Text="Model.Email"/>
</FieldBody>
<FieldFeedback For="@(() => Model.Email)" />
</ValidatedField>
<Button Color="Color.Primary" Type="ButtonType.Submit" Clicked="SubmitAsync">Submit</Button>
<Button Color="Color.Secondary" Type="ButtonType.Reset" Clicked="ResetAsync">Reset</Button>
</ValidatedForm>
Then you can actually better read the flow of the code and it reflects what you see on screen. You will collapse Form + Validations into ValidatedForm and Validation + Field into ValidatedField
I like the proposed syntax but it's unfortunately it's not that easy to do all of it. For example Feedback is used as a placeholder so that error messages are always placed at the right markup for every supported provider. If we would introduce FieldFeedback that would be really hard or impossible to do.
ValidatedForm and ValidatedField in my opinion are valid proposals. They can be wrappers around existing Validations and Form, and Validation and Field components. I think it will make a syntax somewhat cleaner.
I will leave it on backlog for now as a proposed feature. In the meantime everyone is welcome to comment on this.
In my own project I already created ValidatedForm and ValidatedField that was indeed very simple. I will have a look if I can find the time to make a PR for this.
For the FieldFeedback indeed a bit more work is needed. Should not be impossible, because ValidationMessage from the EditForm is more or less the same. Might need to dig a bit in the Blazor codebase to see how they do it
I prefer the way it is. But it's a personal opinion. Separation of concerns, modularity and no overlapping features.
Also, it messes with attribute splatting, the workload to maintain it is increased
I agree from a SOLID design perspective on this. The problem is that also less technical ppl, like web designers want to work with this and for them the very verbose notification is hard to read. Doesn't mean we cant support both worlds. Keep the components as they are now and add a nr of helper components for those who would like to use those.
If the opinion is to keep em outside the repository that is also fine by me, maybe even create a Blasorize.Compact project for these kind of thins
I agree that a blazorise.compact would be nice.
@WillianGruber Yeah, attribute splatting can complicate things
Placing these kind of things in separate package seems like a valid option as that way the core library will stay clean. Another option is to create your own wrappers around Blazorise components. That is in my opinion the best approach as no project is the same and everyone have their own use cases.
I created my own wrappers, because I want every form to have more or less the layout and behavior. So with a nr of common components I can easily achieve this