Working on a B-tree form.

[nixnerd]

Ok,
I’m working on a form right now that I hope will be pretty versatile and helpful. I’m calling it the B-tree form because logically, that’s exactly what it it is. I’m trying to remake it in a more OO way. So, I don’t have much done:

http://codepen.io/Joe_Temp/pen/BkejG

The ‘trunk’ of the tree is the information that is common to all. Regardless of what other information the form collects, it has to collect a name, an email and a phone number.

Once the rules for those are satisfied, the next button will become active and allow the user to select what it is they would like to do.

Right now, I’m trying to put the rules in an object… and it’s not going so well. I’ll keep working but post with any suggestions you might have. Thanks!

[nixnerd]

Ok, so if you check the pen now, I’ve got an object that I’m storing some rules (methods) in. Then I’ve got an outside function that calls each method when there’s any input… but I’d like to cleanly call only the method (rule) that is relevant to that particular input field.

Thoughts?

[__]

I haven’t thought this through in too much detail, but I’d start by modelling the tree itself, and add the individual rules later.

Each “node” of your b-tree could be a fieldset, and you’d start with all but the root fieldset hidden.

What does your tree need to accommodate? I get that it’s not linear. It is a true “tree” (only forks; no branches rejoin others)?

How does branching need to be handled? Does the user explicitly choose what to do next? is it dependent on their prior input? In the latter case, each node would need a “done” function to determine which fieldset to show next. In the former, you could use a simple map.

I’d like to cleanly call only the method (rule) that is relevant to that particular input field.

Listening to change would cause less work than input. Since there is usually no real need to validate input until the user is actually done composing it, this probably wouldn’t cause problems.

You could limit which methods you call by building a map of method(s) needed for each input. You could also put this info on the input itself (e.g., <input data-validate="name">).

not tested, or even seriously proofread

var rules = {
    name: function( value ){ /* ... */ },
    phone: function( value ){ /* ... */ },
    email: function( value ){ /* ... */ },
    //  ...
};

//  ...

var validationHandler = function( event ){
    var i,
        input = event.target,
        tests = event.target.getAttribute('data-validate');
    if( tests ){
        tests = tests.split(',');
        for( i=0; i<tests.length; i++ ){
            if( rules[tests[i]] && ! rules[tests[i]]( input.value ) ){ 
                return false; 
            }
        }
    }
    return true;
}

[nixnerd]

To answer a few questions… no branches ever come back together. See, the trunk or the root, whatever you want to call it, is the info that all the branches share. The user EXPLICITLY chooses what they want to do. This is actually for a real estate website, so options would be something like “Find a home” or “Pre-qualify for a loan.”

But see, this form could work on any site that has the potential for multiple interested parties. Let’s say you had a site where you could contact customer service, the marketing department, the IT department, etc. You fill in your basic info, then make a selection from there.

It should be easily mod-able, so there’s no level to how deep or “far out” branches can grow or how many times they can fork. Obviously at some point, it becomes ridiculous and convoluted… but that’s the dev’s job to organize the information.

You could even throw a survey right in the form. Basically, the sky is the limit.

So, you’re telling me I should wire-frame the whole thing out with all my branches first and then worry about the validation rules later?

[__]

So, you’re telling me I should wire-frame the whole thing out with all my branches first and then worry about the validation rules later?

I always start with wireframing. It’s all about the model.
As for validation, I think I like my data-validate attribute idea. That would keep it flexible.

Aaaaaaaaaanywho, I’m going to bed. I’ll check back tomorrow.

[nixnerd]

I haven’t even wire-framed yet so no worries. I’m going to get that built and then work on the most OO way to validate. Will post when there’s an update.

[nixnerd]

Codepen is updated. I’ve wire-framed the entire thing, so you can get a feel for the basic functionality:

http://codepen.io/Joe_Temp/pen/BkejG

Here’s what I want to work on right now: OOP. I’ve got a bunch of shit in objects… but that doesn’t make it object oriented. Also, this thing is INSANELY simple and it’s like 100 SLOC. That’s kind of ridiculous. Please give me some pointers on how I can clean this up. Thanks!

BTW: I’ll work on validation later. For now, I want to get a solid foundation to build on.

[nixnerd]

On another note… I think I’m going to go purely functional on this. There’s not a real reason to use all these objects and there is a performance hit. Plus… doesn’t look as clean.

Beyond that, post whatever input you have.

[__]

Ideas:

• make each of the “branches” just a map of attributes: whether it shows the next/prev/submit buttons, and a reference to the DOM Element (the fieldset) itself. (later, we will also add a .validation method.)
• abstract the process of switching between states so we can use a single event listener for all switches. This requires an event handler (stateHandler), currentState and history vars, and a function to actually handle classes, etc. (switchTo).

pen

(BTW translate needs to be prefixed outside of FireFox)

[nixnerd]

Thanks man. Your JS looks quite a bit different, so I’m going to dive in and try to wrap my head around what’s going on. I’ll post back with any questions.

(BTW translate needs to be prefixed outside of FireFox)

I know but I didn’t feel the need to prefix it for dev because it won’t actually be centered on the live site. It’s just so I can have it look pretty during dev. I suppose I could prefix it for the people helping me though :)

[nixnerd]

Are we just using history so that previous will go to whatever it was just at? So, we don’t have to explicitly handle each state with those complicated if/else statements?

[__]

Yes. Managing that stupid history state is the part the took an hour (but AKAICT it’s working perfect now).

I originally wanted to do something similar with the [next] button, and have the state handler actually check where “next” was in relation to the current branch, but since it only ever goes to one place I just fudged and made it always go to the “fork.” I don’t think it would be too difficult to make this change in the future, if we wanted to make a general-purpose form tree.

I know but I didn’t feel the need to prefix it for dev …

I prefer doing JS dev in chrome and for a while I thought I had screwed something up because the form kept pushing itself off the screen : )

[nixnerd]

Yes. Managing that stupid history state is the part the took an hour

Well, thanks for putting in the effort. It’s much better that it’s abstracted in such a way. I was going to try and devise a way to manage the state better… but was unsure of the cleanest way to do it. But, in retrospect… anything would have been better than that stupid iterator. That seems SUPER dirty to me and very prone to breakage, should there be additional levels added at any time.

for a while I thought I had screwed something up because the form kept pushing itself off the screen : )

My bad. I guess I was just being lazy. All I have to do is add the Compass mixin. Ha ha.

[nixnerd]

Oh and by the way… the reason the form is so wide when you edit it is because I wanted to make it look nice when pasted into the thread. Also the window I’m developing in is pretty narrow because I run the browser console right beside it.

Don’t want you guys to think I’m into super wide forms. I’m not some uncivilized animal :)

[__]

Looks just fine, I thought.

BTW, a lot of the differences in (code) appearance is because I didn’t use jQuery. If you want to put jQuery back in you totally could. If you needed compatibility with IE < 9, for example.

[Author]

Posts