Starting out with angular, Ive developed an app which builds a form with directives dynamically chosen from the field type in the data from the server. All the fields are bound to data within $scope using ng-model. The data is loaded and saved to the server using $http.
Today I've looked at Angular forms, and by wrapping all this in a form element, and giving names to each input, I automatically have validation etc, which is very nice.
But now I notice there are two sets of data maintained - my bound data from my model in $scope, and the data separately maintained by the Angular form directive.
Looking at the Angular docs for eg form or input, the example also binds to $scope (ng-model="text"), but form data is separate (myForm.input.*).
Is this apparent duplication best practice? Or is there a way to unify my model with the data maintained by the Angular form, under one structure?
The form and ng-model (using ngmodelcontroller) directives provide a mechanism to support form validation and 2 way data binding on input elements.
What the form provides as data is current state of the form and its element, which beyond the standard model that you bind using ng-model. Duplication of code is bad, but here data in the form is being tracked by the form directive so it is fine.
Related
I am building a very large form with multisteps and some conditional fields and cannot find a good solution for my problem.
For example if field A is "Foo" then field B is shown via Javascript and must be validated via Symfony, otherwise the field must be empty. Is there a Way to do this?
PS:
Is https://github.com/craue/CraueFormFlowBundle a good way to go for complex multistep forms and should I use groups and entities or build it without a class? Whats the best practice?
Thanks!
My solution:
I think you should use Symfony Form Events. In events you can do such custom stuff like adding errors, check values in all form, remove and add validators/fields dynamically.
More about form events flow you can read here
Here Add error to Symfony 2 form element you have question howto add error to field from event listener(In symfony 4 it is done similarly)
My opinion about craue/CraueFormFlowBundle:
I use CraueFormFlowBundle in my projects to create complicated multistep forms. It's useful Bundle and saves a lot of time. I created a lot of forms based on CraueFormFlowBundle + Doctrine entities in combination with validation groups + symfony form events - powerful and flexible solution which I can recommend
For a openui5 component I need to bind multiple models and is investigating what the best way to do this is.
The models are both JSONModel and XMLModel.
The background is that I want provide the user choice of multiple source to use for the custom openui5-spitz-reader component https://github.com/elsewhat/openui5-spritz-reader
Each of the selection the user can make (BBC World News, Reddit /r/worldnews), has a single Model populated.
During runtime, I need to combine all the Models the user has selected and bind the combined content towards the items aggregation of the openui5-spitz-reader component.
You can use named models on aggregations see Multimodel Support - example using multiple models on an element JSBin OData Model dynamic column and data binding
I am not sure if you can bind data from 2 models on a single aggregation, you may be able to achieve it using a factory function with the aggregation or a handler on the model binding - using a generic binding to sum aggregation
I´d like to use Symfony 2 Validation Component to validate my forms without using form component as I prefer to create my own HTML forms manually. How can I do to bind the data from my manual form to an entity so that I can validate that entity in the controller?
Just go through the $request->request parameter bag and use the setters of your model to set the data. Then you can use the validator service to validate the entity:
$constraintViolationList = $this->get('validator')->validate($entity);
If $constraintViolationList is not empty, the entity is not valid.
BTW, I believe that the Symfony form component is arguably the greatest part of the framework. I suggest you reconsider your position about it.
I going to set up some large forms with up to 100 fields.
Now my question is if there is some best practise about handling such forms.
Especially:
Entity relations
Form object it self
Does somebody have experience about such tasks?
Should I put all together in one entity, one form, structured with jQuery in subforms or should I group the attributes to arrays as much as possible?
Regards,
Bodo
Whereas official documentation show many examples of forms directly linked to entities, I think this is not the best approach. In rare case it's good, when your form has exactly the same fields as your entity.
Your form must represent what you get in the browser, so only html inputs/textearea/select. I usually create a formData class, like an entity, that holds validation constraints and has the same structure as the form.
You have to initialize this formData object with your persisted datas before loading the form, and after submission, you update your entities with your formData object...
I am creating some complex forms that are built from multiple entities. I create a form class for each entity and then create a composite form class that holds the various combinations of forms I need (which is in someways similar to PéCé's suggestion).
If I don't need all of the fields, that is fine because I can control which fields are rendered in the twig template. If I need fields that aren't in the form class, I can add them to the template and process the form data as appropriate. For all of this effort I get some built in validation and flexibility to reuse forms from multiple entities and bundles.
I am using automapper to map my models to viewmodel classes to pass to my view.
My question really is where should the validation go? I was planning on using the MetaData decorations - a feature of mvc 2.
But either in the model or viewmodel? Or in both places?
Validation should be done minimum at the View Model because this is what you receive as action argument and contains the user input. You could also have validation at the model.
My answer would be ViewModel because Model can change (for example from using Linq2SQL to EF). This way when you plug another Model you still have your validation intact.
I personally have my validation 2 places using DataAnnotations. My model is not passed up to my view in full. I have separate models for my views and translate the data from the view model into the model. This way, I can put whatever I want in my view model and leave out the pieces I don't want to deal with.
My reasoning, however, is that I have a windows application and an web application using the same model. This way, the same set of validation rules govern the Model for all apps, and my view model can have slightly different rules if need be. Of course, this creates a "duplication of logic" - well, validation logic.
This way I don't have to rebuild the data that wasn't used on the page every trip back to the server or put it in hidden fields and inflate the size of my pages.
You should put validation that is specific to the UI in the ViewModel, and anything that is related to business process or database validation in the Model. These might overlap.
The model should implement the validation it needs to ensure that its state cannot become invalid; that validation most definitely belongs on the model.
for example, a book class must guarantee that its title must be between 1 and 50 characters, its id must be >= 0 etc.
business rules belong elsewhere (in your controllers if you only have the model view and controller layers). this might be something like a user cannot add more than 3 books if their email isnt verified.
validation in the view should be restricted to parsing user input for invalid data: anti xss, sql injection, out of range. etc