Dojo Forum(Unofficial) FilteringTable enhancements
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 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:
...
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
--
View this message in context: http://www.nabble.com/%28Unofficial%29-FilteringTable-enhancements-tf302...
Sent from the Dojo mailing list archive at Nabble.com.
Comments
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:
--
View this message in context: http://www.nabble.com/%28Unofficial%29-FilteringTable-enhancements-tf302...
Sent from the Dojo mailing list archive at Nabble.com.
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
_Pierre_ wrote:
--
View this message in context: http://www.nabble.com/%28Unofficial%29-FilteringTable-enhancements-tf302...
Sent from the Dojo mailing list archive at Nabble.com.
_Pierre_ wrote:
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.
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 tag to match your dojo
installation.
It currently assumes dojo is installed in the same location as the html
file.
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: http://www.nabble.com/file/5683/renderusing.html
renderusing.html
(This link will not work directly. Please download it and use it against
your own dojo installation)
--
View this message in context: http://www.nabble.com/%28Unofficial%29-FilteringTable-enhancements-tf302...
Sent from the Dojo mailing list archive at Nabble.com.
Sasha,
Sasha Firsov wrote:
I'm glad you can get some use out it.
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.
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.
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.
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.
--
View this message in context: http://www.nabble.com/%28Unofficial%29-FilteringTable-enhancements-tf302...
Sent from the Dojo mailing list archive at Nabble.com.
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:
--
View this message in context: http://www.nabble.com/%28Unofficial%29-FilteringTable-enhancements-tf302...
Sent from the Dojo mailing list archive at Nabble.com.
Tom,
Tom Trenka wrote:
There was a discussion in this thread:
http://www.nabble.com/Patch-submission-tf2969750.html#a8310155 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.
--
View this message in context: http://www.nabble.com/%28Unofficial%29-FilteringTable-enhancements-tf302...
Sent from the Dojo mailing list archive at Nabble.com.
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:
--
View this message in context: http://www.nabble.com/%28Unofficial%29-FilteringTable-enhancements-tf302...
Sent from the Dojo mailing list archive at Nabble.com.
Tom Trenka wrote:
Is there a preferred forum for the 'bugging' of developers & Foundation
staff. :-)
Sounds very interesting and exciting. I can tell in your other posts that
you're
having trouble not telling folks. While we pester you about such things it
just
shows our eagerness to know & be involved.
Is there a specific thread or Wiki entry?
Thanks Tom.
Ross.
--
View this message in context: http://www.nabble.com/%28Unofficial%29-FilteringTable-enhancements-tf302...
Sent from the Dojo mailing list archive at Nabble.com.
blog.dojotoolkit.org i post two entries there about the community
site. beyond that most of the new talk has been off lists.
-Karl
On 1/29/07, Ross Thomas wrote:
--
-Karl Tiedt
Sasha Firsov wrote:
Have no fear. I have a project that relies on it that is due to be released
in a few weeks. I too will be needing the functionality. :-)
Well, Tom's post indicates that it was discussed but may be low on
the list of prioities at the moment. And may even become moot
with developments that are in the works. *shrugs* I guess we'll
see once the gag order is removed and Tom (or the Dojo team in
general) is allowed to talk about it.
Well, that wouldn't work either. The CLA represents an agreement
between two parties. My modification of it would not constitute any
sort of agreement on their part. Nice idea though. :-D
The best I could do is suggest changes and then have a back-and-forth
with their legal folks about applicability. Easier for us both if they just
produce what they are comfortable with and see if anyone signs it
or objects. There may even be issues with existing signatories and their
right to accept/refuse the changes.
The problem with introducing legal documents into a collaborative group
is that it is no longer 'collaborative', it is contractual. Now all sides
need
to be 'happy' with the agreement. Or, at least, equally unhappy about it.
:-)
In this case it wouldn't have worked. There is a widening of an internal
method's interface that cannot be catered for except by overriding a
bunch of methods and essentially duplicating 99% of their functionality.
Not an optimal solution.
That's a nice concept. I can certainly consider it for future changes.
Though, it sounds like I should hold off on new work until the Dojo
folks announce whatever it is they have up their sleeve.
Events may work, but there would be issues of handler evaluation
order and prevention of 'default' behavior(s). And the connect()
methodology is more AOP than OOP.
All that aside, it still wouldn't resolve one of the primary reasons for
providing a patch -- integration into the official code tree. As you
mentioned in the opening paragraph, you have become reliant on
someone other than Dojo for support of the functionality. While I
have every intention of providing this support, other authors of
unofficial patches may not.
Ross.
--
View this message in context: http://www.nabble.com/%28Unofficial%29-FilteringTable-enhancements-tf302...
Sent from the Dojo mailing list archive at Nabble.com.
Sasha Firsov wrote:
Those are all great ideas and I see that you have already done some work
towards
that in your other post. I will gladly help in any way I can. I just don't
know how that
jives with the CLA. Are unsigned collaborator's contributions covered? Or
does it
put you in some sort of legal jeopardy?
What I had intended to be a least-impact, smallest-footprint change to a
very useful
widget has taken on a life of its own. Just gotta love FLOSS development.
Ross.
--
View this message in context: http://www.nabble.com/%28Unofficial%29-FilteringTable-enhancements-tf302...
Sent from the Dojo mailing list archive at Nabble.com.
New patch set for the 0.4.2rc2 release. Now includes a
HOWTO demonstrator file "renderusing.html" that shows
both the renderusing & null handling in action.
Enjoy.
Ross.
http://www.nabble.com/file/7164/FilteringTable-0.4.2rc2.zip
FilteringTable-0.4.2rc2.zip
--
View this message in context: http://www.nabble.com/%28Unofficial%29-FilteringTable-enhancements-tf302...
Sent from the Dojo mailing list archive at Nabble.com.
Karl Tiedt wrote:
Thanks Karl. Is this the place to also send gentle reminders about CLA
privacy statement inclusion?
Ross.
--
View this message in context: http://www.nabble.com/%28Unofficial%29-FilteringTable-enhancements-tf302...
Sent from the Dojo mailing list archive at Nabble.com.
As promised, here's the 0.4.2 patch set. The FilteringTable in
0.4.2 did not change from 0.4.2rc2 so this is essentially the
same zip file from 0.4.2rc2 renamed and re-posted.
We'll do our best to pester. Right now this list is probably the best place
for that.
I *would* like to talk about some of the things coming but there's a lot
still up in the air about how some of these things will work, and until we
have a solid plan of action we are trying to keep mum about most of it--just
in case.
trt
Ross Thomas wrote:
--
View this message in context: http://www.nabble.com/%28Unofficial%29-FilteringTable-enhancements-tf302...
Sent from the Dojo mailing list archive at Nabble.com.
Allow me to clarify some things here, since it seems like you (Sasha) are not
understanding how we (Dojo) are trying to operate...
1. Code review, posting of code, sharing your extensions--all of these
things are *good* things and we (Dojo) are in no way discouraging or looking
to discourage this at all. Some people have certain needs and having a
vibrant community to help with that is integral to everything we do. My
apologies if the threads we've been having (here and the XSL thread) seem
contrary to that. The main reason for that is...
2. The main Dojo library code *needs* to stay limited, and what one person
needs may not be what another needs. An awful lot of the patches
proposed--including yours (again, Sasha's, just to be clear) is something I
would never add to the base FilteringTable code, simply because it will slow
the performance down a *lot*, and not everyone needs a DropdownDatePicker
widget to be embeddable in a simple tabular view of data. This doesn't mean
that your patch/extension has no utility or usage, or that we "are looking
down on it". It just means that the core library needs to solve a basic
need, in a way that lets you add these kinds of extensions.
I call these kinds of patches "selfish patches"--not because they aren't
useful but because they are usually designed with a very specific need or
purpose in mind, one that was developed because of a specific problem the
developer had. The difference here is that we (Dojo) have to make an
accurate judgment as to whether or not the concerns of said patch may have
(weight, performance, extensibility, need) are great enough to justify
forcing *everyone* who is using the library to have that patch.
It's not as easy as it seems to make that kind of judgment. In the past, we
at Dojo have been a lot more accommodating about taking in patches, and
we've paid the price of doing that with performance and bloat. In some
cases, some of the founding contributors started doing code review in an
effort to make big performance gains, and end up shaking their head at some
of the things making it into the library. Because of that, we're clamping
down a bit.
That doesn't mean you can't submit patches, or make suggestions--we want
both. All that means is that we're being strict about what makes it into
the toolkit itself, and what isn't. It's not a personal thing either; its
just us being prudent and trying to make sure that the base library is as
lean and efficient as possible.
trt
Sasha Firsov wrote:
--
View this message in context: http://www.nabble.com/%28Unofficial%29-FilteringTable-enhancements-tf302...
Sent from the Dojo mailing list archive at Nabble.com.
Sasha Firsov wrote:
Works for me! :-)
If there is a public dojo-dev list then that may be a more appropriate forum
for discussion. Or we can take it off-list.
I'll take a look and let you know.
I visited the 'test' page and one can now see why Tom was reluctant to
include support for embedded widgets. Sloooowwwww. The fact that
render() and the update methods can be called multiple times for the
same data doesn't help.
I have no idea how the contributor code integration mechanism works.
It could be as simple as a single maintainer review or as complex as
a multiple 'committee' review.
Really? I wasn't aware of making any bug fixes as such. It may have
been a side-effect of the functional enhancements but they were not
meant as bug fixes. For instance, the 'null' patch *could* be considered
a bug fix except that the original behavior is the documented behavior.
As such that patch only constitutes an enhancement. In fact, the patch
probably should've included a toggle to enable/disable the functionality.
Anyway, let's move this to your other thread and we'll consider this one
done except for any other reelases (e.g. 0.4.2) that may occur prior to
the stability of your patch.
Ross.
--
View this message in context: http://www.nabble.com/%28Unofficial%29-FilteringTable-enhancements-tf302...
Sent from the Dojo mailing list archive at Nabble.com.
Quick update regarding these patches & the Dojo 0.4.3 release.
The latest posted FilteringTable render & null patches for 0.4.2 will
work unchanged with 0.4.3.
If anybody is actually using these patches please post here. The 0.9
Grid widget will obsolete the FilteringTable (and therefore these patches)
and I would like to know whether to bother maintaining this patch-set
publicly.
Ross.
--
View this message in context: http://www.nabble.com/%28Unofficial%29-FilteringTable-enhancements-tf302...
Sent from the Dojo mailing list archive at Nabble.com.
jezza wrote:
Hmmm. I wonder if there is some sort of permissioning problem?
I don't have IE7 installed (both my employer & I are a little trepidatious).
Are you comfortable with javascript? If so, can you try putting a try/catch
around the 'setData(...)' line in the init() function and see if it
generates any
sort of exception?
What does it show if you use the original FilteringTable.js? Does it show a
table with plain (unadorned) rows? If it does, we can try the two patches
distinctly to see which one causes the problem. If it doesn't display the
table,
then it's a base widget problem. That would be something we need to address
differently.
Yeah. That is a little strange. It kinda suggests that there was a change
to the
way tables are handled between 0.4.1 and 0.4.2. But in such a way that only
IE7 is sensitive to it. And I know Tom would've been very careful about any
regressions.
Let us know what the outcome of those tests above are. I hate to put this
back
on you but I just don't have an IE7 installation to do the testing myself.
:-(
Hopefully we can solve this problem easily.
Ross.
--
View this message in context: http://www.nabble.com/%28Unofficial%29-FilteringTable-enhancements-tf302...
Sent from the Dojo mailing list archive at Nabble.com.
jezza wrote:
Heh! Yeah. Most of our clients have reverted to IE6 after various levels
of
frustration with IE7. I keep recommending FF -- some have listened. :-)
Oooo! I remember a thread about 'file' URLs a month or two ago. Same
sort of problem. Not sure if there was a resolution other than 'use a
server'.
I'll try a search and see if I can find it.
You are right about the failure occuring before we even get to loading data.
However, once we understand the problem, we may be able to provide a
solution even though neither of us is a base developer.
Cool. I think a few others on the list would also be happy for a
resolution.
NP. As usual the majority of all kudos go to Tom and the Dojo team for
providing
such a great environment to work in.
Ross.
--
View this message in context: http://www.nabble.com/%28Unofficial%29-FilteringTable-enhancements-tf302...
Sent from the Dojo mailing list archive at Nabble.com.
Sorry--been slowing abandoning looking over the Interest list in favor of the
new forums (http://dojotoolkit.org/forum)...if I remember correctly, Ross is
right: there are issues with trying to run file-based code in IE7. From the
errors you've posted, it looks to me like you aren't coming close to even
loading the FilteringTable code...I know there were some loader changes in
0.4.2 which might be the issue here.
trt
PS. That's "The New Forums Over at the Dojo Site", at
http://dojotoolkit.org/forum.
:)
Ross Thomas wrote:
--
View this message in context: http://www.nabble.com/%28Unofficial%29-FilteringTable-enhancements-tf302...
Sent from the Dojo mailing list archive at Nabble.com.
There is no big deal with file system on IE7. It does not allow XHR to
work with file system.
Shame on dojo, with all flexibility of io.bind, internal dojo.require
stuck with XHR :(
So solution will be either:
a) embed everything in dojo.js ( read docs how), which is almost
impossible for many reasons.
b) replace default fetcher with ActiveX version of XHR. Look for my
post few month back or in the end of
http://firsov.net/~suns/demos/dojo/FilteringTable_fillCell/dojo-base/doj...
Happy coding on file system!
Sasha
Ross Thomas wrote:
Be careful forcing the use of the ActiveX XMLHttpRequest object in
IE7. There are some undesirable side effects:
http://www.ashleyit.com/blogs/brentashley/2006/06/05/ie7-make-sure-you-i...
James
On 4/16/07, Sasha Firsov wrote:
Agree, on http/https or ftp, native XHR works better for many reasons.
In case of file:// protocol+IE7, there is no choice.
So it is more appropriately to ask how to make this substitution
optional and correctly.
Answer: Use for web URLs native XHR, and ActiveX for file system.
This method work well if there is no mix of protocols (file vs.
network). So far so good.
For mixed protocols:
- for dojo.require() , XHR implementation replacement need to be
done on another method - dojo.hostenv.getText(), I guess. It accepts URL
parameter and creates XHR for dojo.require().
- You still need to be aware of other narrow spots, like
FilteringTable, which uses XHR (not io.bind).
May be someone could offer wrapper with XHR interface, capable of
switching protocols ?
It will make an easier, unified patch for whole dojo.
Also, based *only* on this wrapper, extra FS could be supported, JAR
archive or offline run, for example !
If there is an interest, make a request here.
Sasha
James Burke wrote:
For anyone who is using this patch set -- the patches are still valid against
the
0.4.2.rc1 release of Dojo. The pre-patched files included in the zip file
should be
ignored and the included patch(es) applied against the file from the
release.
If anyone is intending to use the patches against the nightly buidls, let me
know
and I can generate a patch set appropriately.
Also, if you are unable to get the patch set applied against the current
release,
let me know and I'll gen up a new all-inclusive zip file.
Ross.
--
View this message in context: http://www.nabble.com/%28Unofficial%29-FilteringTable-enhancements-tf302...
Sent from the Dojo mailing list archive at Nabble.com.
Ross Thomas wrote:
Bump.
Any word on the CLA? Or is it now moot with the impending re-organization?
Ross.
--
View this message in context: http://www.nabble.com/%28Unofficial%29-FilteringTable-enhancements-tf302...
Sent from the Dojo mailing list archive at Nabble.com.