Recently, when I use React&material-ui to make a form, I find that many components do not have 'name' property, such as 'SelectField'. So I must get the value through a method. Is material-ui suitable for implementing a form? If the answer is yes, can you give me a intact example which uses some components such as 'TextField', 'SelectField', and how do I submit it?
I could recommend connectin material-ui with redux-form:
http://redux-form.com/6.8.0/examples/material-ui/
Works fine as long as you pass component representing material-ui form into the Field from react redux
import { Field } from 'redux-form/immutable';
import TextField from 'material-ui/TextField';
<Field
name="username"
id="username"
type="text"
placeholder="Username"
label="Username"
required
iconName="person"
component={TextField}
/>
And then you would have form values existing in redux state.
This actually is not a material-ui specific issue i believe. You'll be in the same boat if you use simple <input> elements.
Basically what you want to do is get/set the value of a text box / checkbox when a user does some action or clicks submit. Material-ui just lets you do pretty, reusable and designed components so that you wont have to write them yourself.
To work easily with forms you would have do some additional coding from your side. I also suggest the great library redux-form but it would require you to also implement redux in your app (A great thing by itself but i dont know what are your requirements).
If you want another option then you can use https://github.com/christianalfoni/formsy-react which is another great and popular library for managing forms and doesnt require redux
If you want to do things yourself then you can use recommendations from https://facebook.github.io/react/docs/forms.html which in general tell you to have controlled components.
One final thing. Dont be afraid to use additional libraries and modules. The whole point in having hundreds thousands of modules is for people to use them =]
Related
I'm about to take on my first shopify project where I will need to modify certain theme markup (for WCAG accessibility purposes).
Having never worked on Shopify before, I'm reading their documentation and theme editing using liquid seems fairly straightforward. However, someone warned me that modifying theme markup can sometimes break core functionality like the checkout process or something similar if/when shopify requires a certain specific markup to be present.
This would force me to opt for DOM manipulation with Javascript, instead of modifying template files - which is not a great way to go about it in my opinion.
Out-of-the box, do shopify functions depend on the markup in any way? I suppose anything's that written in Ruby should not be affected. Perhaps there would be JS that expects a specific DOM interaction. If anyone has run into similar issues, or can make any constructive suggestions, I would really appreciate it.
You can't break any Back-end functionality of Shopify if you modify the markup.
The purpose of the liquid is only to output some content, it can't modify the back-end in any way or form.
You can say that it's a glorified HTML markup with a few bells and whistles. ( but it loads before the DOM is ready )
In addition you don't have access to the checkout template if you are not on a Shopify Plus account, so it's really hard to even try to break something there.
That said you can break some base front-end functionality if you delete some items.
For example the product form needs to have an form element with an name="id" and value of the variant.id. If you remove that the product will not submit to the cart and you won't be able to use the checkout since you will never be able to add the product to the cart.
So yes you can break front-end functionality but you can't NEVER break the back-end logic with Liquid only.
I'm looking for a WP plugin which can allow me to create different forms and embed them on pages and following are the requirements:
Only a single textbox required in each of those forms
The submit button will only be shown if a custom entry/answer is inputted into the textbox. (basically a client-side validation)
The submitted answer should be stored in the back-end with the usermeta (or just the username of the user logged in) so that I can export the entries in a format like csv, etc.
Any thoughts?
P.S. I have found one but not sure if the PRO version of this allows me to have a validation for a custom text. This is the plugin: http://wordpress.org/extend/plugins/visual-form-builder/
Gravity Forms is the most robust form builder plugin for WordPress. You can, with the right knowledge and skills, make it do pretty much anything you'd like. You can find it here: Gravity Forms.
Very well, I've found this. There are actually good plugins however, you will have to purchase it. I'm looking for a free one. http://www.webdesignboom.com/2013/formcraft-wordpress-form-builder/
I am almost at the end of my rope trying to style my Zend form using decorators. Previously to avoid these issues I would create a form script extending zend_form, add whatever validators, labels, etc I needed then retrieved the element from my view script using $form->getElement('my_form_element');
that way I could wrap whatever css tags I wanted around the element. I thought I should learn how to use the built in decorators, but I'm starting to feel like it's a waste of my time. My old way seems easier, is there some reason I am not seeing that makes using custom decorators better?
In general decorators are used to dynamically add functionality without having to touch the code's core functionality and for a better re-usage of code. In Zend_Form however, I think that the decorator system (as well as Zend_Form in general) is unintuitive and heavily over-engineered and so it does exactly the opposite of what it should do: Help the developer to create better and more intuitive code faster.
In my opinion the usage of Zend_Form_Decorator makes only sense in the case where you have some extended logic that you plan to reuse throughout your project on multiple and different types of elements.
Let me give you two examples:
You want to add a tooltip icon next to an arbitrary form element with a nice icon and a fancy JavaScript hover box.
An element should be validated directly upon entering data by posting an AJAX request and adding either a green check mark on success or a red cross icon on failure next to the element.
With the decorator you can now separate the logic of the added functionality from that of the underlying element and so you can use the same code to add the tooltip and/or the live validation feature to a textbox element as well as any other element simply by adding all the decorators you want to the element.
There is also a great article from Matthew Weier O'Phinney, the lead developer of Zend Framwork, that gives some background insight on the motivations for using decorators along with a lot of examples: Decorators with Zend_Form
Decorators can come in handy if you have a specific repeatable markup for your forms, for example if you want to use Bootstrap. Other than that, especially if you have a good html/css person, I would avoid them.
When I build a form I need to use a dots in path variable. When html is generated inputs has dots in ids. There is a problem with third party jquery plugins like validators. They doesn't work well with dots. Is there a way to change all dots into eg. "_".
One solution would be not to use automatic form binding, so instead of using <spring:form/> you might still use plain HTML tag <form> and handle it regular way. It all depends if you want to benefit from Spring's mechanisms like automatic form field binding and error handling. But if you are handling form validation with JavaScript and you plan to do it across the whole project, you might want to make that effort. What I usually do is to handle client side and server side validation with JavaScript (plain and AJAX), so I'm not using <spring:form/> at all.
I often face a problem when I need to encapsulate some far apart fields in one form, and the fields in between them in other forms. Or encapsulating first two rows of a table in form and other two in other forms and so on. But of-course this is not allowed in standard practice. My question is why such tags like form (and other non displaying tags) have to be treated as "displaying" tags, and they also are restricted to be used at some places. Is there any genuine reason.
PS: what I was thinking about form in particular, that I define as many forms as I want at a single place, and give their references (eg ids or names) to the corresponding fields. That way form tag does not have to interfere somehow with the location of fields?
Asking "why" questions of HTML behaviour is not normally a useful activity. Very often the answer is "because one of the browsers originally did it that way and we're stuck with it for backward-compatibility reasons".
Note also what #DanMan says about the displayability of <form>.
However, your description of declaring forms in one place and then having the controls associate with the forms by id, is very similar to what has been done with the HTML5 form attribute. The only difference is that the controls reference the forms, rather than the forms referencing the controls. All we need to do now is wait for implementations in the browsers.
How is a <form> a non-displaying element? You can apply all kinds of CSS on it, and they will show up. It's just that they usually have no default browser styles. It's a rookie mistake to wrap elements in <div>s and styling those, when the only thing inside them is a single element.
<div class="myform"><form>...</form></div>
<form><div class="myform">...</div></form>
Both equally superfluous. Just style the original element directly.
<form class="myform">...</form>
Now, before you jump on my back: I'm not saying you're doing that. Just a general advice.
About restricted usage: that's probably to make it easier for implementors (browser creators) and for backwards compatibility.