« Return to Thread: (Unofficial) FilteringTable enhancements
On patches and enhancements (was Re: (Unofficial) FilteringTable enhancements)
by Tom Trenka
::
Rate this Message:
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
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:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFtjmYVSSUoWsWyI8RAhH5AKCCJWQgMTjWXZKLMCIh6IKT8Ad5DQCeMjSA
HrVwZV7TitoW6hcXIcheOxk=
=tkXn
-----END PGP SIGNATURE-----
_______________________________________________
Dojo FAQ: http://dojo.jot.com/FAQ
Dojo Book: http://manual.dojotoolkit.org/DojoDotBook
Dojo-interest@dojotoolkit.org
http://dojotoolkit.org/mailman/listinfo/dojo-interest
« Return to Thread: (Unofficial) FilteringTable enhancements
| Free embeddable forum powered by Nabble | Forum Help |
