[Dojo-interest] Re: On patches and enhancements (was Re: (Unofficial) FilteringTable enhancements)

Tue Jan 23 11:29:45 MST 2007

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I understand and totally support heavier way to commit patches.
Still, the statement will be less useful without support for
architectural and code review process, which in fact was away from
community. At least I seen it in many cases.

Relating to runtime patches. As Aaron Evans mentioned there are cases
when so many patches need to be applied, so it is difficult to keep
hierarchy straight(dojo.extend):

http://dojo.jot.com/WikiHome/Inheritance

The only solution is dojo.mixin but they are not recommended:
http://dojo.jot.com/WikiHome/Inheritance/Multiple%20Inheritance

Anyway, runtime patch on existing widget class and/or object has reason
to exist. You can say, it is not good for many reasons, but if it has a
sense to many people, why not allow it to exist?

So far extend and mixin are elegant in some way, but heavy, when runtime
patch is simple and straight. And direct way to simulate core patches.
If I will have a choice to either use custom extension widget or patch,
the choice is obvious: runtime patch. To support multiple
features(patches) using mixing/extend bunch of code need to be written.
But for runtime patches you just need one JS per patch.

Architecturally correct way will be in supporting multiple dojoType
statements, similar to multiple styles in class attribute. But multiple
widgets on same tag (mixins?), I guess, is out of scope for now ...
So still stick to "runtime patch" as the best way to apply few features
to existing widget. Someone with me?

Sasha

Tom Trenka wrote:
> Javascript is uniquely ideal for the idea of a run-time patch, and it's a
> topic that has come up before between the Dojo committers--and is a little
> bit of a contentious topic. So I'll try to give you a rundown of how I think
> it will basically work, with the disclaimer that "my views do not
> necessarily reflect the viewpoints of the Dojo committer core".  So...
> 
> The Dojo Toolkit, like any other library with a large core of committers,
> has a problem in which many patches are submitted and (all too often)
> immediately incorporated without a real thought process as to the actual
> utility of a patch, and other over-arching concerns (such as file-size and
> complexity) that, to date, have scarcely been considered.  This has already
> led to a lot of bloat, performance issues, and in some cases duplication. 
> In a number of cases, patches were applied that dealt primarily with edge
> cases or were submitted for what I'll term "selfish" concerns.  I don't mean
> this in a bad way; but the nature of the "patch" lends itself to the
> selfish.  If you think about it, a good number of patches come from someone
> needing a bit of functionality for thier own stuff, and basically submit
> it--thinking it's a good thing.  And sometimes it is, but just as often it
> isn't.
> 
> At some point we, the core contributors to Dojo, have to stop and say to
> ourselves "this is a large library with a very large, diverse audience--and
> to date we've been *way* too permissive in terms of incorporating patches
> and enhancements".  And in fact, at the recent Dojo Developer Day
> conference, we came to that conclusion.  I believe the actual statement was
> "we have to learn how to say 'no'".
> 
> What that really means is that we are going to refocus our efforts to bring
> you a smaller, leaner, and meaner toolkit.  And a large part of that effort
> will be going through existing code, analyzing functionality, and leaning it
> out.  Unfortunately, that also means that patch review is going to get much
> more stringent.
> 
> That's the bad news for those who like to submit patches.  Now, the good
> news...
> 
> We're not oblivious to the community and it's enthusiasm at all.  In fact,
> we're all very pleasantly surprised and pleased with how much the community
> tries to help and what not.  So as part of this effort, we've got plans (I'm
> not in charge of them so I don't know what we can reveal and what we can't
> right now) to help facilitate community participation in a bit of a
> different, freer way than we've done to date.  You can expect to see this
> effort (or at least the beginnings of it) some time in the middle of
> February (hopefully!).
> 
> Now, to runtime patches.  I've a suggestion: use dojo.mixin or dojo.extend
> to override functionality for a widget based on your own situation, and
> simply use dojo.require *after* the widget is loaded to apply it.  Because
> of the way  JS works, this should be a (fairly) flawless technique (which I
> have used in the past and will undoubtedly use in the future) that does not
> require the use of overarching inheritance chains or other complex
> mechanisms.  Essentially, you'll simply overwrite the methods (or add to) of
> the object in question at run-time.  Javascript is *great* for this, and
> you, as an application developer, should take full advantage of it.
> 
> Stay tuned for other community-related things.
> 
> trt
> 
> 
> Sasha Firsov wrote:
> Ross,
> The FilteringTable enhancements are the feature which I desperately need
> and have resolved in fast, but weird ways. Your solution is elegant.
> 
> But it looks like it comes to nowhere. I have an proposal for you.
> There is few ways of improving functionalities of widgets/package.
> - custom code for each occasion(mine)
> - patch( which you are proposing )
> - inheritance/ child widget
> - run-time patch. i.e. in
> http://dojotoolkit.org/pipermail/dojo-interest/2007-January/023651.html
> 
> I do not know is term "run-time patch" exist.
> Is anything like that around?
> 
> Seems it is not standardized, but I like the idea. From one side, it
> keeps original widget and code untouched, from another gives extension
> functionality by including patch JS file to HTML.
> 
> Some patching security, versioning and future integration compatibility
> could be added on top. Like warning if new methods for some reason
> already exist in widget(i.e. been accepted in main branch), but do not
> match.
> 
> What do you think about making such "runtime" patch for your
> FilteringTable enhancements?
> I bet, it would be more thankful users than me :)
> 
> Thank you,
> Sasha
> 
> PS. Dojo guys, such model also could be an extra step before applying
> feature in core. So feature could pass full user review before integrated.
> 
> 
> Ross Thomas wrote:
>>>> While I await the new Dojo CLA text I am making the following
>>>> unofficial enhancements to the FilteringTable available.  I have seen
>>>> several cases in the list recently that would have benfited from these
>>>> capabilities.
>>>>
>>>> Attached are three patches that cover two enhancements to FilteringTable.
>>>> The two enehancements are:
>>>>
>>>> 1) Distinct rendering functionality.
>>>> ====================================
>>>> This allows for the specification of a function that provides rendering
>>>> of
>>>> the column's value in a way analogous to the 'sortUsing/sortFunction'
>>>> capability.  Thus a Number like '100.0' which currently can only be
>>>> rendered
>>>> as '100' could be rendered as '100.00' in blue text as a link and still
>>>> be
>>>> sortable by the table since it is still represented as a Number in the
>>>> data
>>>> store.
>>>>
>>>> In a similar vein, a boolean value could be represented as a CheckBox
>>>> with the 'selected' attribute set according to the current value of the
>>>> data.  Thus by updating the value in the data store, the checkbox will
>>>> change accordingly.
>>>>
>>>> The render function is called as:
>>>>    function(cell, meta, val, src)
>>>> where:
>>>>    cell is the <TD> element for the current value
>>>>    meta is the column description data (aka table.columns[index])
>>>>    val is the actual value from the data store
>>>>    src is the original JSON data (or parsed HTML data) for the row
>>>>
>>>> The presence of 'src' allows for rendering based on other values in the
>>>> row.
>>>>
>>>> The return value of the function is a string suitable for insertion as
>>>> the
>>>> 'innerHTML' value of the cell.
>>>>
>>>> To specify the render function use either the HTML tag method:
>>>>
>>>>    <TH .... renderUsing="myRenderFunc" ...>...</TH>
>>>>
>>>> or the programmatic method in the column spec:
>>>>
>>>>    var myColumn = {
>>>>       ....
>>>>       renderFunction: myRenderFunc,
>>>>       ....
>>>>    };
>>>>    table.columns.push(table.createMetaData(myColumn));
>>>>
>>>>
>>>> 2) Benign handling of 'null' data.
>>>> ==================================
>>>> This patch allows for null values to be treated as minimal values in a
>>>> sort
>>>> and also to have them displayed as empty cells by the default rendering
>>>> engine.
>>>>
>>>> Thus a Date column with a null value will not display as "01/01/70" or
>>>> "NaN/NaN/NaN".  Instead it will display as an empty cell.
>>>>
>>>> In an ascending sort all null values will be at the top of the cloumn.
>>>> Similarly, for a descending sort all null values will be at the bottom.
>>>>
>>>> Contents
>>>> ========
>>>> The attached zip file provides patches and source files for the two
>>>> functionalities distinctly and combined.  These patches and files are
>>>> relative to the 0.4.1 release.
>>>>
>>>> A patch for the nightly builds can be provided as needed/requested.
>>>>
>>>> Hope this helps others as much as it has helped me.
>>>>
>>>> Ross.
>>>>
>>>> Attachment:  http://www.nabble.com/file/5673/FilteringTable.zip
>>>> FilteringTable.zip 
>>
_______________________________________________
Dojo FAQ: http://dojo.jot.com/FAQ
Dojo Book: http://manual.dojotoolkit.org/DojoDotBook
Dojo-interest at dojotoolkit.org
http://dojotoolkit.org/mailman/listinfo/dojo-interest
>>
>>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFtlQZVSSUoWsWyI8RAnyiAJ9uju9/n8xKJ6F/VGHCLztX07hfbQCgmpQZ
XQarqzIlLJcc34uql/589Yc=
=/oDe
-----END PGP SIGNATURE-----