mithril-components
mithril-components copied to clipboard
eddyystop
Forms and form controls
I started a new issue so we keep the occlussion table separate from the forms.
Sunday, being a bright, sunny Sunday, I didn't do much. However, I am a little stuck with forms because there is a need to have information shared in between the form and its controls and I don't have that with the current version.
For example, in a horizontal form you need to tell it how much will the labels take out of the whole width. If you look at the code, it shows the LABEL elements having a col-sm-2 class, which is a grid system measurement. That measure is common to all the form. As bsform stands right now, there is no sharing of information in between the form and its controls. That is not good.
Likewise, in your bsform2 example, where you are sending the form, gathering the data to be sent is a PITA and even prone to errors (firstName has its parenthesis in place, the others don't)
I think it would be better if the form had a reference to a property containing an object and the input controls stored their values in properties within that object.
I'm still trying to figure out an elegant way to pass that info down into the hierarchy.
I mean to add validation to the forms and automatically apply the styles provided by Bootstrap to that effect. I planned on using your validation component, though I haven't looked into it yet so I don't know if it is possible, otherwise I will use the same validation library as you.
We had a beautiful Sunday here too, so not much was done on the readme's.
As a general comment, I like the idea of targeting components to popular CSS frameworks. It produces what most devs want as a final result; it reduces the number of tags for devs to code; it reduces the number of selector/classname params; it lowers the knowledge barrier; it makes the code easier to understand.
I would not be surprised if all the rudimentary components in the repo are absorbed within such targeted components.
There are multiple wins but they will come at an inevitable loss of some flexibility compared to hand-coding. (more soon)
You were are to do some notable things like re-rendering only one component, like rendering on the server and sending the cacheNode to the client at least partially because Mithril is plain, simple Javascript. It doesn't insist on much and is therefore flexible.
Perhaps you're thinking too monolithic about bsform, wanting everything to be in one config object, and losing the flexibility you need.
Maybe bsform should create just the required tags with just the mandatory classes/decoration, and let the dev inject additional classes and attributes. The dev would indicate that col-sm-2 is required, which basically means the dev is injecting some logic structure which bsform doesn't have to explicitly understand.
Maybe bsform should also allow Mithril sub-components are well as known structures like input fields. For example occlusionList can produce this with this.
When I first saw bsform, I realized I could profitably use it to render just one or two fields here, and then use it again to render a few more there. I did not see using it only to build what I needed in just one call.
Perhaps you should code two components simultaneously: bsform and bslayout. bslayout take care of things like containers, jumbotrons, inline and horizontal form specs, wells, etc. You could pass it m() sub-components as params such as those produced by bsform.
The dev would have the flexibility to create anything sophisticated without bslayout, bsform having to implement any specialized options. Alternatively the dev can create a basic form using just bsform.
One todo for FormMixin is adding something like jQuery's serializeArray. It would create an object containing the fields associated with a < form>. That would be the body of the POST.
I'm not sure bsform should handle computing the POST's body. Perhaps that's too monolithic, inflexible.
Another todo is eliminate the need for the example's postStatus().
I'm not sure you can use ValidationMixin. Perhaps you can modify it. Perhaps that would be more trouble than its worth. Using one (any) validation library seems sensible though.
On 30/06/14 14:45, Eddyystop wrote:
Perhaps you're thinking too monolithic about bsform, wanting everything to be in one config object, and losing the flexibility you need. You are right. I am trying to provide an API for all the options Bootstrap forms provide, and that might not be be the best idea.
I'd still like to have some global options for the table, like a single model for all the fields.
I have to provide both interfaces, with and without an enclosing forms. A full form or just loose fields.
You can have 'packaged' or 'default' options for, say, a table. The dev can override some or all of them.
When I looked at bsform, it already looked like I could generate either loose fields or one's within a < form>.
On 30/06/14 15:04, Eddyystop wrote:
You can have 'packaged' or 'default' options for, say, a table. The dev can override some or all of them.
When I looked at bsform, it already looked like I could generate either loose fields or one's within a < form>.
It did and it does now again.
I'm expanding tabs to produce BS like pills, and I'm starting to see a zoo of BS configuration options. You likely have faced the same.
It might be a good idea for me to see what you're doing at present for bsform, so I can choose a similar approach to handling config info. I don't need anything working, seeing the code would do.
This is how I'm handling the zoo of options ATM. The tabs control can render the following by specifying a flavor
- Bootstrap tabs
- Bootstrap horizontal and vertical pills
- Foundation horizontal and vertical tabs.
Flavor names are inspired by the CSS framework e.g. bs/nav-pills.nav-stacked. The differences are only in class names. The dev can define new flavors. Detailed customization by element remains.
The tabs readme explains this when you search for flavor multiple times.
I've added dropdowns to Tabs. I'll now start Navbar as much of it is Tabs.
As of 10:15 pm, (not my usual hours) I think I got the issue about validation cracked. It was turning quite a headache, but now I think I'm on the good track. I'll apply the same to the rest of the controls and I think that will be it. Finally.
I assume you've read about some new components. I assume I should look into making a github website.
What are your plans? You have mentioned date pickers in some postings.
I saw them. At this point I'm back to some basic design of the whole Forms thing because I'm patching too many things with the current design and it doesn't make sense. Thus, it is not my main concern right now. However, it doesn't escape me that being a bootstrap component, it would make sense to list it along other Bootstrap components. However, being already half the size the full mistril-components distributable, I don't think it should be distributed in the same file.
Basically, I think I have a bad design, which is causing me too much trouble, just as simple as that.
Anyway, time to watch the second half of the World Cup.
Cheers
I understand you about redesigns. I would be sorry to see repos start to fragment. Build systems extract what they need from a repo, so size is not critical.
I plan to soon default all the present components to a Bootstrap flavor, so everything will be that. Now I need to do yet another web site using Github Pages
Hope your team wins.
Hi. I went into a big-think on components after seeing mithril-bootstrap, and have been rewriting mine.
I just want to make sure you'll contribute to deciding on components standards . I posted most of my recent thinking.