(Unofficial) FilteringTable enhancements

[Ross Thomas]

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: FilteringTable.zip

[_Pierre_]

Can you post a full example ?
Cause when I replace my filteringtable.js with the patched one the NaN values are still visible.
And an Example HowTo for distinct rendering functionality would be handy also.
I have a Currency Field that I want to have ex: 1000 € instead of 1000 Is this possible with the distinct rendering functionality ?
Will these Patches go into Upstream ?

Thanks for your work !

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: FilteringTable.zip

[Tom Trenka]

Numeric formatting is a current ticket filed against me; I was waiting for some of the i8ln code to land so that I can take advantage of things like that for currency formatting purposes.

trt


Can you post a full example ?
Cause when I replace my filteringtable.js with the patched one the NaN values are still visible.
And an Example HowTo for distinct rendering functionality would be handy also.
I have a Currency Field that I want to have ex: 1000 € instead of 1000 Is this possible with the distinct rendering functionality ?
Will these Patches go into Upstream ?

Thanks for your work !

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: FilteringTable.zip

[Ross Thomas]

_Pierre_ wrote:

Cause when I replace my filteringtable.js with the patched one the NaN values are still visible.

Are you using the HTML tag method or the program method?  I assume from the
next section that you are also using a Number dataType column?

If you have a sample of the failing document could you post it too?  I use the
programmatic interface mostly so this could be a 'parsed HTML table data' issue
that I haven't catered for.

And an Example HowTo for distinct rendering functionality would be handy also.
I have a Currency Field that I want to have ex: 1000 € instead of 1000 Is this possible with the distinct rendering functionality ?

I have attached a sample html file that uses the renderUsing functionality.  If
and/or when I upload a new version of the patches I will include that example
file in the zip.

You may need to alter the first <SCRIPT> tag to match your dojo installation.
It currently assumes dojo is installed in the same location as the html file.

Will these Patches go into Upstream ?

That is entirely up to the Dojo folks.  I am waiting for a modified
CLA (Contributor's License Agreement) before I sign it.  And the
Dojo folks (quite rightly) will not accept changes from unsigned
contributors.  Catch-22.  This is why the enhancements are tagged
as 'Unofficial'.

If nothing else I will make patches available for future releases of Dojo.
And for the nighty builds if requested.

Ross.

Attachment:  renderusing.html
(This link will not work directly.  Please download it and use it against your own dojo installation)

[Sasha Firsov]

-----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@...
http://dojotoolkit.org/mailman/listinfo/dojo-interest

[Tom Trenka]

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:

-----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
[e-mail]
http://dojotoolkit.org/mailman/listinfo/dojo-interest

[aaronmevans]

Hi Tom,

I agree with what you are saying here.

My one comment is that often times, the reason why one might want to
get their patch incorporated into the source tree is so that it is
part of the next official release.

If not, then what ends up happening is that every time one upgrades,
one has to go through all of their patches and re-engineer how to
properly implement them.

This becomes a very painful process because:

1. Dojo releases come out so frequently.

2. There are so *many* changes in each release, especially with
widgets, where in my experience, I have had to do so many patches.

Sticking with an older, official release is also very problematic
because it is very hard to get community support when you encounter a
strange problem.  The answer is always "get the latest from SVN".
Unfortunately for production systems with a lot of customizations and
dojo patches, this is just not feasible.

Now, as for #1, I am sure that as dojo matures, releases will become
less frequent.

Also, wrt #2, I am sure that a lot of the changes with each release
are in fact due to the problem you've identified here! (ie. being to
permissible with the community wrt patches).

But, I just thought I would put in my 2 cents from the perspective of
a dojo user.

-aaron
_______________________________________________
Dojo FAQ: http://dojo.jot.com/FAQ
Dojo Book: http://manual.dojotoolkit.org/DojoDotBook
Dojo-interest@...
http://dojotoolkit.org/mailman/listinfo/dojo-interest

[Jayaram Krishnaswamy]

By the way what is the latest release?

----- Original Message -----
From: "Aaron Evans" <aaronmevans@...>
To: <dojo-interest@...>
Sent: Tuesday, January 23, 2007 12:27 PM
Subject: Re: [Dojo-interest] On patches and enhancements (was Re:
(Unofficial)FilteringTable enhancements)

> Hi Tom,
>
> I agree with what you are saying here.
>
> My one comment is that often times, the reason why one might want to
> get their patch incorporated into the source tree is so that it is
> part of the next official release.
>
> If not, then what ends up happening is that every time one upgrades,
> one has to go through all of their patches and re-engineer how to
> properly implement them.
>
> This becomes a very painful process because:
>
> 1. Dojo releases come out so frequently.
>
> 2. There are so *many* changes in each release, especially with
> widgets, where in my experience, I have had to do so many patches.
>
> Sticking with an older, official release is also very problematic
> because it is very hard to get community support when you encounter a
> strange problem.  The answer is always "get the latest from SVN".
> Unfortunately for production systems with a lot of customizations and
> dojo patches, this is just not feasible.
>
> Now, as for #1, I am sure that as dojo matures, releases will become
> less frequent.
>
> Also, wrt #2, I am sure that a lot of the changes with each release
> are in fact due to the problem you've identified here! (ie. being to
> permissible with the community wrt patches).
>
> But, I just thought I would put in my 2 cents from the perspective of
> a dojo user.
>
> -aaron
> _______________________________________________
> Dojo FAQ: http://dojo.jot.com/FAQ
> Dojo Book: http://manual.dojotoolkit.org/DojoDotBook
> Dojo-interest@...
> http://dojotoolkit.org/mailman/listinfo/dojo-interest
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.410 / Virus Database: 268.17.8/648 - Release Date: 1/23/2007
>
>

_______________________________________________
Dojo FAQ: http://dojo.jot.com/FAQ
Dojo Book: http://manual.dojotoolkit.org/DojoDotBook
Dojo-interest@...
http://dojotoolkit.org/mailman/listinfo/dojo-interest

[aaronmevans]

0.4.1 I believe...

On 1/23/07, Jayaram <jkrishnaswamy@...> wrote:

> By the way what is the latest release?
>
> ----- Original Message -----
> From: "Aaron Evans" <aaronmevans@...>
> To: <dojo-interest@...>
> Sent: Tuesday, January 23, 2007 12:27 PM
> Subject: Re: [Dojo-interest] On patches and enhancements (was Re:
> (Unofficial)FilteringTable enhancements)
>
>
> > Hi Tom,
> >
> > I agree with what you are saying here.
> >
> > My one comment is that often times, the reason why one might want to
> > get their patch incorporated into the source tree is so that it is
> > part of the next official release.
> >
> > If not, then what ends up happening is that every time one upgrades,
> > one has to go through all of their patches and re-engineer how to
> > properly implement them.
> >
> > This becomes a very painful process because:
> >
> > 1. Dojo releases come out so frequently.
> >
> > 2. There are so *many* changes in each release, especially with
> > widgets, where in my experience, I have had to do so many patches.
> >
> > Sticking with an older, official release is also very problematic
> > because it is very hard to get community support when you encounter a
> > strange problem.  The answer is always "get the latest from SVN".
> > Unfortunately for production systems with a lot of customizations and
> > dojo patches, this is just not feasible.
> >
> > Now, as for #1, I am sure that as dojo matures, releases will become
> > less frequent.
> >
> > Also, wrt #2, I am sure that a lot of the changes with each release
> > are in fact due to the problem you've identified here! (ie. being to
> > permissible with the community wrt patches).
> >
> > But, I just thought I would put in my 2 cents from the perspective of
> > a dojo user.
> >
> > -aaron
> > _______________________________________________
> > Dojo FAQ: http://dojo.jot.com/FAQ
> > Dojo Book: http://manual.dojotoolkit.org/DojoDotBook
> > Dojo-interest@...
> > http://dojotoolkit.org/mailman/listinfo/dojo-interest
> >
> >
> > --
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.1.410 / Virus Database: 268.17.8/648 - Release Date: 1/23/2007
> >
> >
>
> _______________________________________________
> Dojo FAQ: http://dojo.jot.com/FAQ
> Dojo Book: http://manual.dojotoolkit.org/DojoDotBook
> Dojo-interest@...
> http://dojotoolkit.org/mailman/listinfo/dojo-interest
>

_______________________________________________
Dojo FAQ: http://dojo.jot.com/FAQ
Dojo Book: http://manual.dojotoolkit.org/DojoDotBook
Dojo-interest@...
http://dojotoolkit.org/mailman/listinfo/dojo-interest

[Sasha Firsov]

-----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@...
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-----

_______________________________________________
Dojo FAQ: http://dojo.jot.com/FAQ
Dojo Book: http://manual.dojotoolkit.org/DojoDotBook
Dojo-interest@...
http://dojotoolkit.org/mailman/listinfo/dojo-interest

[Tom Trenka]

Aaron Evans-2 wrote:

Hi Tom,

I agree with what you are saying here.

My one comment is that often times, the reason why one might want to
get their patch incorporated into the source tree is so that it is
part of the next official release.

If not, then what ends up happening is that every time one upgrades,
one has to go through all of their patches and re-engineer how to
properly implement them.

This becomes a very painful process because:

1. Dojo releases come out so frequently.

2. There are so *many* changes in each release, especially with
widgets, where in my experience, I have had to do so many patches.

Sticking with an older, official release is also very problematic
because it is very hard to get community support when you encounter a
strange problem.  The answer is always "get the latest from SVN".
Unfortunately for production systems with a lot of customizations and
dojo patches, this is just not feasible.

We know this both from the community and from our own experiences, and we're working on it as well.  Once again, I don't think I'm in a position to "let the cat out of the bag" as it were but you can expect some very, very BIG changes in the near future, with an aim at both future stability as well as getting to a real 1.0 release.

One thing to consider (for those who need the consideration), both IBM and Sun are incorporating Dojo into major products of thier own, and because of that we *have* to create long term stability in the near future.

If it helps at all (and you're using SVN), one thing that we have found that helps tremendously is the use of the svn:externals command to either lock down your code to a specific Dojo revision, or to work off the HEAD automatically.

Aaron Evans-2 wrote:

Now, as for #1, I am sure that as dojo matures, releases will become
less frequent.

Actually, I think the Dojo committer core is of two minds with that.  There is a very large portion of core contributors that thoroughly subscribe to the "release early and release often" ideal, and while we've been inching closer to a full on 1.0 release, that particular philosophy (early and often) has (to date) had a large influence on releases.

Aaron Evans-2 wrote:

Also, wrt #2, I am sure that a lot of the changes with each release
are in fact due to the problem you've identified here! (ie. being to
permissible with the community wrt patches).

It's a good part of it, yes.   But the plethora of bug reports and fixes made (Bill Keese is kind of a monster in that regard, he's a machine) have more to do with it.

trt

[Tom Trenka]

Sasha Firsov wrote:

-----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.

No offense, but patch review will always be away from the community and reserved for the core contributors and modules.  We've already had a few instances where even contributors have "gone cowboy" on the codebase and caused major issues with parts of the library that were hardly considered beforehand.

Sasha Firsov wrote:

...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?

It depends on the patch, what it does, how heavy it is in terms of performance, whether or not the patch steps on another part of the code in a major way, and whether or not it's truly useful to the community as a whole.  All patches are considered (as long as there's a verifiable CLA attached to it).  All I'm saying is that to date we've been very permissive about accepting and incorporating patches--and going forward, we are going to be a lot more strict about what gets into the actual core.

Sasha Firsov wrote:

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.

You can always include a single JS file as well.  Really, it depends on what your own preference is; if you want to have a single patch file, feel free.  I suggested extend and mixin because both work well for what is done.  You can also always use the traditional JS method:

someConstructorToApply.call(objectToApplyItTo);

...which is not nearly as heavy as you might think.  Of course, that comes with it's own quirks...

Sasha Firsov wrote:

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?

You are now talking specifically about the widget system and not about Dojo itself, and I can say for sure that there are major changes coming here as well.  As far as supporting multiple dojoType attributes (or multiple values within a dojoType attribute), its a neat idea but one thing we (core Dojo committers) are learning is that the majority of performance problems--as well as the high learning curve--of Dojo is in good portion due to the way we tend to support multiple, highly complex ways of doing things.  This is also something we are going to change--knowing full well that there are people like you out there who can, if they really want it, roll their own solution and (hopefully) share it with the community at large.

Remember--we (Dojo) have to support the community at large, and because of that we have to be a lot more careful about what gets into the actual library and what doesn't.  But (as I hinted at in the last email), good things are coming soon :)

trt

[Sasha Firsov]

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

Looks I expressed myself not clear. Under "runtime patch" I meant
separate JS file which add or substitute some of existing package
functionality. It never meant to be a part of deployment, rather
temporary solution until accepted as official patch to be integrated in
core. Those "runtime patches" could be applied one by one or
simultaneously allowing to include/exclude some features from
package/widget.

While "runtime patch" lives as independent entity, there is no
correlation with core. It is similar to custom widgets, except of you
can apply multiple features to same object/widget. (I am not sure is it
possible to merge several (widget) extensions in easy way or at all).

The current patch process gives only choice of custom dojo build.
The "runtime patch" does not require build assembly every time you want
some feature added/removed.

So it is safe for core to support such "runtime patch" js files. And not
include them unless decision is made.
It would be nice for users to let them beside what feature set need to
be included.

The patch acceptance procedure also could be easier, since custom
features will become pluggable, while core stays build-in.



Tom Trenka wrote:

> Sasha Firsov wrote:
>> ...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?
>>
>
> It depends on the patch, what it does, how heavy it is in terms of
> performance, whether or not the patch steps on another part of the code in a
> major way, and whether or not it's truly useful to the community as a whole.
> All patches are considered (as long as there's a verifiable CLA attached to
> it).  All I'm saying is that to date we've been very permissive about
> accepting and incorporating patches--and going forward, we are going to be a
> lot more strict about what gets into the actual core.

Well, I like your awareness. But it automatically prohibit the use of
patch for people who want to use them. They still can go though custom
patching and build, which is painful comparing to "runtime patches".
Why do not keep patches in "runtime" form, separately of core?
In the end this is just a form of storing the patch: instead of diff,
some JS files.

> Sasha Firsov wrote:
>> 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.
>>
>
> You can always include a single JS file as well.  Really, it depends on what
> your own preference is; if you want to have a single patch file, feel free.
> I suggested extend and mixin because both work well for what is done.  You
> can also always use the traditional JS method:
>
> someConstructorToApply.call(objectToApplyItTo);
>
> ....which is not nearly as heavy as you might think.  Of course, that comes
> with it's own quirks...

May me the "heavy" is not proper word. It is more "complicated to use",
at least for me.
I already gave the sample how it can be done in "weird" way.
Question is what method could be used and what is better?
There is no such discussion I seen before, so It would be nice to get
those "how to" on "runtime patch" cleared and possibly publish on WiKi
pages.
And the ideal case, review for all given proposals. As freshman in
object JS, it is difficult for me to judge their different aspects.

It seems to me that "runtime patch" functionality has a sense in dojo.
Like dojo.lang.runtimepatch
and it`s precious ability to enable/disable features on fly from debug
console :)

> Sasha Firsov wrote:
>> 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?
>>
>
> You are now talking specifically about the widget system and not about Dojo
> itself, and I can say for sure that there are major changes coming here as
> well.  As far as supporting multiple dojoType attributes (or multiple values
> within a dojoType attribute), its a neat idea but one thing we (core Dojo
> committers) are learning is that the majority of performance problems--as
> well as the high learning curve--of Dojo is in good portion due to the way
> we tend to support multiple, highly complex ways of doing things.  This is

OK. "runtime patch" actually could help with splitting such complexity
apart. Small limited core gives robustness. "runtime patch" will bring
feature flexibility.

> also something we are going to change--knowing full well that there are
> people like you out there who can, if they really want it, roll their own
> solution and (hopefully) share it with the community at large.
Seems too late: sourceforge already has bunch of dojo-derived code, not
to mention personal sites.
dojo registry for custom code definitely will be useful.
I also would love 2 ratings: from all and from you, dojo contributors.

> Remember--we (Dojo) have to support the community at large, and because of
> that we have to be a lot more careful about what gets into the actual
> library and what doesn't.  But (as I hinted at in the last email), good
> things are coming soon :)
> trt
Rumor goes for long time. We have only choice: to be patient ;)
Thanks,
Sasha
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFto7VVSSUoWsWyI8RAseHAKDxoy4z+772L8QOrb11qjo0s39eIwCgt1Hp
UMGYC+zzn5ZascCQ0kXKzSc=
=CnTG
-----END PGP SIGNATURE-----

_______________________________________________
Dojo FAQ: http://dojo.jot.com/FAQ
Dojo Book: http://manual.dojotoolkit.org/DojoDotBook
Dojo-interest@...
http://dojotoolkit.org/mailman/listinfo/dojo-interest

[Ross Thomas]

Sasha,

Sasha Firsov wrote:

The FilteringTable enhancements are the feature which I desperately need
and have resolved in fast, but weird ways. Your solution is elegant.

I'm glad you can get some use out it.

But it looks like it comes to nowhere.

Meaning it won't work for you?  Or that the Dojo CLA is still not in a state
that I can sign?

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.

The main (closely related) reasons for providing a patch were: 1) to get the
functionality into the main source tree; and 2) remove the need for continued
maintenance on my part.  By providing the patch the functionality is 'just there'
from release to release.  No-one has to wait for new versions of a 3rd-party
class/patch to become available.  In addition, the functionality would be preserved
during the inter-release periods when the nightlies are the latest avaialble.

Both a derived widget & a run-time patch would require long-term maintenance
and some major copying of existing functionality out of the base class into the
class/patch.  Both methods would be highly susceptible to internal changes in the
base class.

The only other way to achieve this would still require wholesale copying of 'default'
functionality into new 'default' functions that get applied to the table as part of
the initialization.

Is anything like that around?

Nope.  The reletively minor changes required to augment Tom's fine work made it
a perfect candidate for a patch.  As mentioned above, the effort involved in making
this available in another form is several orders of magnitude more involved than the
patch already supplied.

What do you think about making such "runtime" patch for your
FilteringTable enhancements?
I bet, it would be more thankful users than me :)

If the Dojo folks get the CLA updated in a timely fashion the point is moot.  However,
if nothing comes to pass before the next release......*shrug*  I guess I'll have to have
a re-think about the whole issue.

Ross.

[Tom Trenka]

I don't see that the CLA is going to change any time soon.  What was your issue with it?

trt

(btw there are a lot of other considerations going on right now WRT applying submitted patches to widgets; don't take a refusal the wrong way, it's just that times are a changin'.)

Ross Thomas wrote:

Sasha,

Sasha Firsov wrote:

The FilteringTable enhancements are the feature which I desperately need
and have resolved in fast, but weird ways. Your solution is elegant.

I'm glad you can get some use out it.

But it looks like it comes to nowhere.

Meaning it won't work for you?  Or that the Dojo CLA is still not in a state
that I can sign?

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.

The main (closely related) reasons for providing a patch were: 1) to get the
functionality into the main source tree; and 2) remove the need for continued
maintenance on my part.  By providing the patch the functionality is 'just there'
from release to release.  No-one has to wait for new versions of a 3rd-party
class/patch to become available.  In addition, the functionality would be preserved
during the inter-release periods when the nightlies are the latest avaialble.

Both a derived widget & a run-time patch would require long-term maintenance
and some major copying of existing functionality out of the base class into the
class/patch.  Both methods would be highly susceptible to internal changes in the
base class.

The only other way to achieve this would still require wholesale copying of 'default'
functionality into new 'default' functions that get applied to the table as part of
the initialization.

Is anything like that around?

Nope.  The reletively minor changes required to augment Tom's fine work made it
a perfect candidate for a patch.  As mentioned above, the effort involved in making
this available in another form is several orders of magnitude more involved than the
patch already supplied.

What do you think about making such "runtime" patch for your
FilteringTable enhancements?
I bet, it would be more thankful users than me :)

If the Dojo folks get the CLA updated in a timely fashion the point is moot.  However,
if nothing comes to pass before the next release......*shrug*  I guess I'll have to have
a re-think about the whole issue.

Ross.

[Ross Thomas]

Tom,

Tom Trenka wrote:

I don't see that the CLA is going to change any time soon.  What was your issue with it?

There was a discussion in this thread:  Patch submission
about the lack of a privacy or personal data security statement.

(btw there are a lot of other considerations going on right now WRT applying submitted patches to widgets; don't take a refusal the wrong way, it's just that times are a changin'.)

It never got that far.  Eugene pointed to the CLA and I didn't want to sign it without
some sort of statement about privacy in there.  Karl seemed to indicate that the issue
would be addressed, or at least looked at.  This is why I released the changes as an
unofficial patch.  I had seen a few people on the list with similar issues and wanted them
to at least have the option of using it.

I review the CLA on a regular basis in the hope it will change soon.

Ross.

[Tom Trenka]

I see.  Eugene did bring up a privacy clause and Alex seemed open to the idea but that's as far as it got.  I suppose at some point we'll come back to it (please keep bugging about it) but we've got a *lot* of things on our plate right--including some way of letting you submit things like patches and widgets without having to sign a CLA.

(see Karl's discussions about a community site.)

trt

Ross Thomas wrote:

Tom,

Tom Trenka wrote:

I don't see that the CLA is going to change any time soon.  What was your issue with it?

There was a discussion in this thread:  Patch submission
about the lack of a privacy or personal data security statement.

(btw there are a lot of other considerations going on right now WRT applying submitted patches to widgets; don't take a refusal the wrong way, it's just that times are a changin'.)

It never got that far.  Eugene pointed to the CLA and I didn't want to sign it without
some sort of statement about privacy in there.  Karl seemed to indicate that the issue
would be addressed, or at least looked at.  This is why I released the changes as an
unofficial patch.  I had seen a few people on the list with similar issues and wanted them
to at least have the option of using it.

I review the CLA on a regular basis in the hope it will change soon.

Ross.

[Sasha Firsov]

Ross,
Thanks again for your patch, I took the risk of accepting your changes and using in the code. Now I rely on your promise to have patch for next release :).

I totally agree with your privacy concerns in CLA, even if I have it signed some time back. I wish dojo guys will make that privacy statement inserted for all. Anyway, nothing prevent them to accept CLA with additional privacy statement from you.

Regarding "runtime patch" and sophistication of support. The patch which modifies the core is hard to support, unless code itself is build in easy to modify way. Some empty stub methods in core patch will do the trick. Later, enhancement could override/append those stubs with own code.

So your patch could be divided into 2 parts:
1)  patch to core with safe enhancements stubs
2) actual enhancement features which rely on stubs.
It will make stub acceptance easy, since no harm for core code is done.
The support will be easier as well: non-related features will not correlate with yours and with stubs.
As one of relatively safe approach for stubs could be event mechanics: it has all necessary queue control features like  substitution, override, etc.
Sasha

Ross Thomas wrote:

Sasha,


Sasha Firsov wrote:
  

The FilteringTable enhancements are the feature which I desperately need
and have resolved in fast, but weird ways. Your solution is elegant.

    

I'm glad you can get some use out it.



  

But it looks like it comes to nowhere.

    

Meaning it won't work for you?  Or that the Dojo CLA is still not in a state
that I can sign?


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.

    

The main (closely related) reasons for providing a patch were: 1) to get the
functionality into the main source tree; and 2) remove the need for
continued
maintenance on my part.  By providing the patch the functionality is 'just
there'
from release to release.  No-one has to wait for new versions of a 3rd-party
class/patch to become available.  In addition, the functionality would be
preserved
during the inter-release periods when the nightlies are the latest
avaialble.

Both a derived widget & a run-time patch would require long-term maintenance
and some major copying of existing functionality out of the base class into
the
class/patch.  Both methods would be highly susceptible to internal changes
in the
base class.

The only other way to achieve this would still require wholesale copying of
'default'
functionality into new 'default' functions that get applied to the table as
part of
the initialization.



  

Is anything like that around?

    

Nope.  The reletively minor changes required to augment Tom's fine work made
it
a perfect candidate for a patch.  As mentioned above, the effort involved in
making
this available in another form is several orders of magnitude more involved
than the
patch already supplied.



  

What do you think about making such "runtime" patch for your
FilteringTable enhancements?
I bet, it would be more thankful users than me :)

    

If the Dojo folks get the CLA updated in a timely fashion the point is moot. 
However,
if nothing comes to pass before the next release......*shrug*  I guess I'll
have to have
a re-think about the whole issue.

Ross.
  

_______________________________________________
Dojo FAQ: http://dojo.jot.com/FAQ
Dojo Book: http://manual.dojotoolkit.org/DojoDotBook
Dojo-interest@...
http://dojotoolkit.org/mailman/listinfo/dojo-interest

[Giovanni Porcari]

Sasha

you could submit the patch for stubs and as you signed the CLA it should be ok.

Then Ross could send a mixin method that use these stubs in current and future versions.

:)

G.

Il giorno 29/gen/07, alle ore 18:13, Sasha Firsov ha scritto:

Ross,
Thanks again for your patch, I took the risk of accepting your changes and using in the code. Now I rely on your promise to have patch for next release :).

I totally agree with your privacy concerns in CLA, even if I have it signed some time back. I wish dojo guys will make that privacy statement inserted for all. Anyway, nothing prevent them to accept CLA with additional privacy statement from you.

Regarding "runtime patch" and sophistication of support. The patch which modifies the core is hard to support, unless code itself is build in easy to modify way. Some empty stub methods in core patch will do the trick. Later, enhancement could override/append those stubs with own code.

So your patch could be divided into 2 parts:
1)  patch to core with safe enhancements stubs
2) actual enhancement features which rely on stubs.
It will make stub acceptance easy, since no harm for core code is done.
The support will be easier as well: non-related features will not correlate with yours and with stubs.
As one of relatively safe approach for stubs could be event mechanics: it has all necessary queue control features like  substitution, override, etc.
Sasha

Ross Thomas wrote:

Sasha,


Sasha Firsov wrote:
  

The FilteringTable enhancements are the feature which I desperately need
and have resolved in fast, but weird ways. Your solution is elegant.

    

I'm glad you can get some use out it.



  

But it looks like it comes to nowhere.

    

Meaning it won't work for you?  Or that the Dojo CLA is still not in a state
that I can sign?


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.

    

The main (closely related) reasons for providing a patch were: 1) to get the
functionality into the main source tree; and 2) remove the need for
continued
maintenance on my part.  By providing the patch the functionality is 'just
there'
from release to release.  No-one has to wait for new versions of a 3rd-party
class/patch to become available.  In addition, the functionality would be
preserved
during the inter-release periods when the nightlies are the latest
avaialble.

Both a derived widget & a run-time patch would require long-term maintenance
and some major copying of existing functionality out of the base class into
the
class/patch.  Both methods would be highly susceptible to internal changes
in the
base class.

The only other way to achieve this would still require wholesale copying of
'default'
functionality into new 'default' functions that get applied to the table as
part of
the initialization.



  

Is anything like that around?

    

Nope.  The reletively minor changes required to augment Tom's fine work made
it
a perfect candidate for a patch.  As mentioned above, the effort involved in
making
this available in another form is several orders of magnitude more involved
than the
patch already supplied.



  

What do you think about making such "runtime" patch for your
FilteringTable enhancements?
I bet, it would be more thankful users than me :)

    

If the Dojo folks get the CLA updated in a timely fashion the point is moot. 
However,
if nothing comes to pass before the next release......*shrug*  I guess I'll
have to have
a re-think about the whole issue.

Ross.
  

_______________________________________________

Dojo FAQ: http://dojo.jot.com/FAQ

Dojo Book: http://manual.dojotoolkit.org/DojoDotBook

Dojo-interest@...

http://dojotoolkit.org/mailman/listinfo/dojo-interest

_______________________________________________
Dojo FAQ: http://dojo.jot.com/FAQ
Dojo Book: http://manual.dojotoolkit.org/DojoDotBook
Dojo-interest@...
http://dojotoolkit.org/mailman/listinfo/dojo-interest

[Sasha Firsov]

Probably, I am not the right person for committing FilteringTable changes.
Besides rendering, there are bunch of others extensions are in line for this widget.
As I could recall, the row resizing(drag on caption and programmaticaly), row visibility and other enhancements are in line.
If any changes at this stage will be accepted (which I doubt), they shall be more general to allow side extensions.
Event handling will be a good way, I guess, for a cell, header and a table as whole:
- onInit
- onCalcSize
- onResize
- onRender
- DnD
- onTimer
- name others
All parameters up to the object field name and HTML element shall be passed appropriately.
Enhancements will be able to hook on event chain and perform own functionality.

But it is just my own newbie vision, FilteringTable owners have a better view.
They track feature requests and, I guess, making design with those extensions in mind.
Cheers,
Sasha

Giovanni Porcari wrote:

Sasha

you could submit the patch for stubs and as you signed the CLA it should be ok.

Then Ross could send a mixin method that use these stubs in current and future versions.

:)

G.

Il giorno 29/gen/07, alle ore 18:13, Sasha Firsov ha scritto:

Ross,
Thanks again for your patch, I took the risk of accepting your changes and using in the code. Now I rely on your promise to have patch for next release :).

I totally agree with your privacy concerns in CLA, even if I have it signed some time back. I wish dojo guys will make that privacy statement inserted for all. Anyway, nothing prevent them to accept CLA with additional privacy statement from you.

Regarding "runtime patch" and sophistication of support. The patch which modifies the core is hard to support, unless code itself is build in easy to modify way. Some empty stub methods in core patch will do the trick. Later, enhancement could override/append those stubs with own code.

So your patch could be divided into 2 parts:
1)  patch to core with safe enhancements stubs
2) actual enhancement features which rely on stubs.
It will make stub acceptance easy, since no harm for core code is done.
The support will be easier as well: non-related features will not correlate with yours and with stubs.
As one of relatively safe approach for stubs could be event mechanics: it has all necessary queue control features like  substitution, override, etc.
Sasha

Ross Thomas wrote:

Sasha,


Sasha Firsov wrote:
  

The FilteringTable enhancements are the feature which I desperately need
and have resolved in fast, but weird ways. Your solution is elegant.

    

I'm glad you can get some use out it.



  

But it looks like it comes to nowhere.

    

Meaning it won't work for you?  Or that the Dojo CLA is still not in a state
that I can sign?


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.

    

The main (closely related) reasons for providing a patch were: 1) to get the
functionality into the main source tree; and 2) remove the need for
continued
maintenance on my part.  By providing the patch the functionality is 'just
there'
from release to release.  No-one has to wait for new versions of a 3rd-party
class/patch to become available.  In addition, the functionality would be
preserved
during the inter-release periods when the nightlies are the latest
avaialble.

Both a derived widget & a run-time patch would require long-term maintenance
and some major copying of existing functionality out of the base class into
the
class/patch.  Both methods would be highly susceptible to internal changes
in the
base class.

The only other way to achieve this would still require wholesale copying of
'default'
functionality into new 'default' functions that get applied to the table as
part of
the initialization.



  

Is anything like that around?

    

Nope.  The reletively minor changes required to augment Tom's fine work made
it
a perfect candidate for a patch.  As mentioned above, the effort involved in
making
this available in another form is several orders of magnitude more involved
than the
patch already supplied.



  

What do you think about making such "runtime" patch for your
FilteringTable enhancements?
I bet, it would be more thankful users than me :)

    

If the Dojo folks get the CLA updated in a timely fashion the point is moot. 
However,
if nothing comes to pass before the next release......*shrug*  I guess I'll
have to have
a re-think about the whole issue.

Ross.
  

_______________________________________________

Dojo FAQ: http://dojo.jot.com/FAQ

Dojo Book: http://manual.dojotoolkit.org/DojoDotBook

Dojo-interest@...

http://dojotoolkit.org/mailman/listinfo/dojo-interest

_______________________________________________
Dojo FAQ: http://dojo.jot.com/FAQ
Dojo Book: http://manual.dojotoolkit.org/DojoDotBook
Dojo-interest@...
http://dojotoolkit.org/mailman/listinfo/dojo-interest
  

_______________________________________________
Dojo FAQ: http://dojo.jot.com/FAQ
Dojo Book: http://manual.dojotoolkit.org/DojoDotBook
Dojo-interest@...
http://dojotoolkit.org/mailman/listinfo/dojo-interest