Bemi Faison wrote:
> Scott Sauyet wrote:
>> This is reasonably well written. It's certainly easy to follow, and
>> the example is clean. But to me it's missing something basic. Your
>> guide still really only explains *how* to use Flow.
>
> Firstly, thanks for the compliment! I'll be updating the quality and
> content of my documentation over time.
The writing is very good, and the examples are clear. It is very nice
documentation.
>> Even after reading it and reading many of the examples on your site,
>> I'm still not clear on *why* I'd want to use it.
>
> I haven't nailed down the benefits to using Flow, but here are two:
>
> 1) Readability. Like @Dash mentioned, Flow uses a narrative,
> declarative style, for defining functions and their relationships.
> Indentation aside, this means code which is easier to follow. I find
> that readability is critical to productivity, when maintaining code.
Perhaps in a more complex scenario? I'm trying to see how your
example is more readable than a naive variation. Here is a slightly
abbreviated version of what you posted:
| var page = new Flow({
| _in: function () {
| (document.getElementById('someButton')).
| addEventListener('click', page.modal, false);
| (document.getElementById('myForm')).
| addEventListener('submit', page.modal.submit, false);
| initMyLoginWidget();
| },
| _main: function () {
| (document.getElementById('someButton')).focus();
| },
| modal: {
| _in: showMyLoginWidget,
| submit: {
| _in: hideModalMsgs,
| _main: function (e) {
| e.preventDefault();
| doAjaxThenProcessResponseWith(function (rsp) {
| if (rsp === 'ok') {
| page.modal.submit.pass();
| } else {
| page.modal.submit.fail();
| }
| })
| },
| pass: showPassMsgInModal,
| fail: showFailMsgInModal
| },
| _out: hideMyLoginWidget
| }
| });
Here is the equivalent code from my naive version:
| main = function(e) {
| e.preventDefault();
| doAjaxThenProcessResponseWith(e.target, function (rsp) {
| if (rsp.status === 'ok') {
| showPassMsgInModal(rsp);
| } else {
| showFailMsgInModal(rsp);
| }
| });
| },
| initialize = function() {
| $loginDiv = $("#loginDiv");
| $link = $("#loginLink").click(showMyLoginWidget);
| $loginForm = $("#loginForm").submit(main);
| },
(See <http://scott.sauyet.com/Javascript/Test/2011-05-03a/> for the
full page.)
So I'm simply not seeing the simplicity.
> 2) Control. Flow supports policy-based programming, and introduces the
> notion of "targeting" instead of "calling" functions. For example, the
> function "app.data.delete()" should not be immediately accessible, but
> instead go _through_ some logic that lets you deny the operation.
> Namespaces provide no control, and wrapping every "important" function
> in such logic is tedious. Flow supports policy-setting via the order
> and encapsulation of functions.
What is the advantage of `targeting` versus `calling` beyond the
tedium of coding wrappers where needed? Is it the more declarative
definition? It's nice to have functions guard their own pre- and post-
conditions rather than have the calling code have to check them, but
does that make enough difference to call for a fairly intrusive
framework to manage it?
Please note, these really are questions, not editorial statements.
I'm trying to pull out your most persuasive arguments. I don't know
if your tool would be worthwhile for me, and I'm trying to figure out
its raison d'être.
> Plus, the _map_ construct masks the
> underlying framework, letting external/existing routines remain
> ignorant of the logic behind each "call".
Are all functions encapsulated this way public? Or is there a way to
hide implementation details?
> [ ... ]
>> That internal reference to the external `page` variable is scary. The
>> object you create here can be aliased and replaced, and such a
>> reference would then point elsewhere. Can you either use `this` or
>> pass in a reference to the object?
>
> I didn't address this, in order to keep the guide simple. However,
> I've updated the guide with an alternate component function, which
> speaks to your concern. Here's a direct link to that section:
> https://github.com/bemson/Flow/wiki/Using-Flow#s4-1-2 Let me know
> what you think!
Yes, that's cleaner, IMHO. I would prefer `flow` or something more
descriptive than `that`, but it's a minor concern.
>> But my largest objection now is the same one that was brought up
>> earlier in this thread. Using the order of the definitions to
>> determine the order your functions run is a show-stopper for me. I
>
> I feel this discussion has been framed poorly. Browsers have *never*
> preserved the order of key definitions. (Yes, Chrome's integer-key
> issue is a duly-noted exception.) I've never inspected the guts of
> browser code, but will bet that the stacks used to store our key-
> definitions is the reason their order is "preserved" (i.e., the rule
> of first-in, first-out). Thus, order is not actively randomized...
> just ignored.
I'm not sure I'm following your argument here. There were two
significant threads on the Chromium and V8 Issues lists:
http://code.google.com/p/chromium/issues/detail?id=883
http://code.google.com/p/v8/issues/detail?id=164
It's clear in both of them that the default behavior preserved
insertion order in all popular engines except V8, and possibly now
IE9. It's not at all clear whether this was intentional or merely a
side-effect of the data structures they used, but until V8 the
behavior was uniform. But there are now significant environments in
which property insertion order is not necessarily reflected in
iteration order. Since the standard left this unspecified, Google was
breaking no specs in doing so, although they annoyed a lot of people.
The concern raised here is that your code seems to depend upon that
underspecified and no longer universal behavior.
> I'm fully aware that some developers prefer ordering with arrays. To
> that end, I will likely provide a parameter format which will define
> programs using arrays. I've filed a bug against myself, and you're
> welcome to contribute your ideas there.https://github.com/bemson/Flow/issues/7
It's great to hear that you're open to change.
--------------------
I'm very much enjoying learning about Flow. Please take everything
here in the spirit of constructive criticism I intend.
Thanks,
-- 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]
