Bemi Faison wrote:
> Actually, there _is_ another github project called flow-js
>(https://github.com/willconant/flow-js), which shares the goal of
> ordered execution.
I hadn't seen that one. It's a very similar concept to my own,
although mine uses a declarative syntax. I have only just done a
simple proof-of-concept, and that using just jQuery's Deferred/Promise/
when implementation, but I would like it to work with any Promise/when
system.
If you're curious, all I have right now is this one simple test page:
http://scott.sauyet.com/Javascript/Test/2011-04-26b/
We have a system right now where there are four or five AJAX calls
which need to be made to different services, and they have to be
composed in different orders in different circumstances. Luckily, I
don't have to determine the composition order dynamically, but the
actual code paths were growing out of hand. I'm planning on using
this to clean that up.
The system is limited to functions that accept a single parameter and
return another of the same type or return a promise that resolves to
that type. But this is fairly generic, as it's likely to be something
of a general state object that's passed around in any case.
> I took a gamble using such a generic term - but
> otherwise abhor trendy names. Hopefully, my work will be good enough,
> so folks eying the title won't be too miffed!
I never considered whether the name might be trendy. It was simply
descriptive. It was an extension of another notion we were using of
"chain", but it was more fluid. "Flow" just seemed natural.
> [ ... ]
> I created Flow out of frustration with a complicated web project. I
> started with clean reusable objects, simple custom-events, and high-
> level controller functions. Soon, with a looming deadline and many
> business-rule changes/revelations, I simply needed to "get it done",
> and wound up inserting logic where ever necessary. The code works
> today, but I wouldn't wish it upon anyone in the future... including
> myself.
>
> [ ... W]e expect requirements to be static, even
> though they often change. Once we've translated requirements into
> functionality (e.g., objects and methods), it becomes impractical to
> update them for every changing requirement - especially when we're far
> along in the development process. My nightmare project epitomizes how
> change kills code, and that's because we never code for change.
Although my solution is much smaller in ambition, it has grown out of
the same frustration you're describing, and over the same problem.
> [ ... ]
> I hope this helps explain how Flow came about, why it exists, and what
> gaps it fills. Things are still fuzzy, but it's also my first attempt
> at explaining things publicly. I fully appreciate (all) your
> questions! On that note, to best _demonstrate_ why you should use
> Flow, I'm writing a walk-thru for the wiki. I'll notify this board
> when I'm done (tomorrow, hopefully). Many thanks for your attention
> and patience!
I look forward to seeing that.
Cheers,
-- Scott
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/[email protected]/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/[email protected]/
To unsubscribe from this group, send email to
[email protected]
