(Unofficial) FilteringTable enhancements

[Ross Thomas]

Tom Trenka wrote:

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)

Is there a preferred forum for the 'bugging' of developers & Foundation staff. :-)

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

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.

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

Is there a specific thread or Wiki entry?

Thanks Tom.

Ross.

[Karl Tiedt]

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 <dojo@...> wrote:

>
>
> Tom Trenka wrote:
> >
> > 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)
> >
>
> Is there a preferred forum for the 'bugging' of developers & Foundation
> staff. :-)
>
>
>
> > ... 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.
> >
>
> 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.
>
>
>
> > (see Karl's discussions about a community site.)
> >
>
> Is there a specific thread or Wiki entry?
>
> Thanks Tom.
>
> Ross.
> --
> View this message in context:
> http://www.nabble.com/%28Unofficial%29-FilteringTable-enhancements-tf3023551.html#a8702318
> Sent from the Dojo mailing list archive at Nabble.com.
>
> _______________________________________________
> Dojo FAQ: http://dojo.jot.com/FAQ
> Dojo Book: http://manual.dojotoolkit.org/DojoDotBook
> Dojo-interest@...
> http://dojotoolkit.org/mailman/listinfo/dojo-interest
>

--
-Karl Tiedt
_______________________________________________
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 Firsov wrote:

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

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

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.

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.

Anyway, nothing prevent them to accept CLA with additional privacy
statement from you.

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

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.

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.

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.

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.

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.

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.

[Sasha Firsov]

There is my vision:
Extensibility core patch( FilteringTable.js ):
    parseMetadata: pass all cell function attributes to metadata object regardless of name.
    fillCell: check if metadata has same name function(fillCell) and call instead of default processing.
HTML :
    define fillCell in columns which want to be customized. Either by setting cell.innerHTML to text or making custom ContentPane withing the cell.

Details inline...

Ross Thomas wrote:

Sasha Firsov wrote:
  

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

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

Cool!

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. 
    

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 was my concern as well. And I see no other alternative except of embedding future extensions hooks withing *core* code.
And those hook shall be more general. You are better prepared for such kind of things: so far I have not done even one extension.

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.
    

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.
  

As I understand, there is no conceptual changes in regards of extensibility expected. We still on our own here.

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. 
    

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.
  

I can see nothing bad about aspects, this framework is asking to be AOP. Besides of advantages, no harm I could see.
( Only if zillions of features appeared will be treated as a good sign :)

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.
  

The basics you have in patch are asking to became a part of extensibility patch.

Just few notes if you like to make separate core extension changes:
- RenderCell assumes to give back HTML text, which is OK, unless you want to perform some other activities like add event handlers to cell or embed another widget.
So instead of giving HTML back, why do not perform assigning *inside* of RenderCell?
From another hand, fillCell is more appropriate place for "runtime patch". And it allow to perform any kind of custom rendering, so fillCell is not required at all.

Custom rendering could be applied when someone want to proceed the other way, like copy DOM from template or render content similar/or using ContentPane...

Question is how to use metadata attributes/functions in more general way.
My assumption for functions like fillCell,  is to check metadata for existing attribute/function with same name( fillCell in that case ) and call it instead of default processing.

- Other hooks are also need to be in place: DND, resize, lifetime(init,hide,destroy),etc.
Question to All: what hooks in addition to fillCell/RenderCell will be useful?

- In order to support future metadata attributes, all attributes passed as functions shall be assigned to metadata object. So instead of treating "renderusing" attribute as particular case, it shall be processing of any attribute in parseMetadata.

Ross, If it will be helpful, I could do this general changes to avoid CLA problem, but I need your deep code review, due to lack of dojo knowledge.
(help from dojo guys are appreciated as well :)

Ross.
  

Sasha


_______________________________________________
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 Firsov wrote:

There is my vision:
Extensibility core patch( FilteringTable.js ):
    parseMetadata: pass all cell function attributes to metadata object
regardless of name.
    fillCell: check if metadata has same name function(fillCell) and
call instead of default processing.
HTML :
    define fillCell in columns which want to be customized. Either by
setting cell.innerHTML to text or making custom ContentPane withing the
cell.

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.

[Ross Thomas]

Karl Tiedt wrote:

blog.dojotoolkit.org i post two entries there about the community
site. beyond that most of the new talk has been off lists.

Thanks Karl.  Is this the place to also send gentle reminders about CLA
privacy statement inclusion?

Ross.

[Tom Trenka]

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:

Karl Tiedt wrote:

blog.dojotoolkit.org i post two entries there about the community
site. beyond that most of the new talk has been off lists.

Thanks Karl.  Is this the place to also send gentle reminders about CLA
privacy statement inclusion?

Ross.

[Sasha Firsov]

Ross Thomas wrote:

Sasha Firsov wrote:
  

There is my vision: 
Extensibility core patch( FilteringTable.js ): 
    parseMetadata: pass all cell function attributes to
metadata object
regardless of name. 
    fillCell: check if metadata has same name
function(fillCell) and
call instead of default processing. 
HTML : 
    define fillCell in columns which want to be customized.
Either by
setting cell.innerHTML to text or making custom ContentPane withing the
cell. 

    

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.
  

Ross,
I have tried to  make an abstraction layer spoken before and development has been done independently. In basic principles you gave, but they are dictated by original code, so CLA is not violated. I guess.

I am not core contributor and my knowledge in dojo and JS OO programming is limited. That is why review need to be done.
The code review is a good practice anyway. And since project source is public anyway, there is no way to avoid discussions about  sources.
The bad thing, it is not popular here. Can we / do we want  to change it?
If you was fine with CLA, I will be trying to convince you to modify your patch a bit. Since, there are still problems, I am proposing to do the same with my patch. Comments are deeply appreciated. I wish they will pass next to dojo core team as well.

By the way, in your code there is some bug fixes, which worth to be filed in bug tracker and most likely shall have separate patch.

Sasha
_______________________________________________
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]

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:

Ross Thomas wrote:

 
Sasha Firsov wrote:
 
 
    There is my vision:
Extensibility core patch( FilteringTable.js ):
&nbsp;&nbsp;&nbsp; parseMetadata: pass all cell function attributes to
metadata object
regardless of name.
&nbsp;&nbsp;&nbsp; fillCell: check if metadata has same name
function(fillCell) and
call instead of default processing.
HTML :
&nbsp;&nbsp;&nbsp; define fillCell in columns which want to be customized.
Either by
setting cell.innerHTML to text or making custom ContentPane withing the
cell.

   
 
 
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.
 

Ross,
I have tried to  make an abstraction layer spoken before and
development has been done independently. In basic principles you gave,
but they are dictated by original code, so CLA is not violated. I guess.

I am not core contributor and my knowledge in dojo and JS OO
programming is limited. That is why review need to be done.
The code review is a good practice anyway. And since project source is
public anyway, there is no way to avoid discussions about  sources.
The bad thing, it is not popular here. Can we / do we want  to change
it?
If you was fine with CLA, I will be trying to convince you to modify
your patch a bit. Since, there are still problems, I am proposing to do
the same with my patch. Comments are deeply appreciated. I wish they
will pass next to dojo core team as well.

By the way, in your code there is some bug fixes, which worth to be
filed in bug tracker and most likely shall have separate patch.

Sasha




_______________________________________________
Dojo FAQ: http://dojo.jot.com/FAQ
Dojo Book: http://manual.dojotoolkit.org/DojoDotBook
[e-mail]
http://dojotoolkit.org/mailman/listinfo/dojo-interest

[Ross Thomas]

Sasha Firsov wrote:

I have tried to  make an abstraction layer spoken before and
development has been done independently. In basic principles you gave,
but they are dictated by original code, so CLA is not violated. I guess.

Works for me!  :-)

I am not core contributor and my knowledge in dojo and JS OO
programming is limited. That is why review need to be done.
The code review is a good practice anyway. And since project source is
public anyway, there is no way to avoid discussions about sources.
The bad thing, it is not popular here. Can we / do we want to change
it?

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.

If you was fine with CLA, I will be trying to convince you to modify
your patch a bit. Since, there are still problems, I am proposing to do
the same with my patch. Comments are deeply appreciated.

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 wish they will pass next to dojo core team as well.

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.

By the way, in your code there is some bug fixes, which worth to be
filed in bug tracker and most likely shall have separate patch.

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.

[Sasha Firsov]

Further patch discussion moved to "FilteringTable extensibility patch 4 review" thread.
inline...

Ross Thomas wrote:

Sasha Firsov wrote:
  

I have tried to  make an abstraction layer spoken before and
development has been done independently. In basic principles you gave,
but they are dictated by original code, so CLA is not violated. I guess. 
    

Works for me!  :-)

  

I am not core contributor and my knowledge in dojo and JS OO
programming is limited. That is why review need to be done. 
The code review is a good practice anyway. And since project source is
public anyway, there is no way to avoid discussions about sources. 
The bad thing, it is not popular here. Can we / do we want to change
it?

    

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.
  

Agree, such questions are more appropriate in dojo-dev. There is mail list and nntp:
dojo dev. dojo-contributors@...
news://news.gmane.org  gmane.comp.web.dojo.devel

But as I understand we are not belong to core and not welcome there (separate permission was requested and rejected). Still this discussion will be quite helpful for newbie contributors, so it has a reason to have it public.
Current gmane.comp.web.dojo.user looks OK to me.

If you was fine with CLA, I will be trying to convince you to modify
your patch a bit. Since, there are still problems, I am proposing to do
the same with my patch. Comments are deeply appreciated.

    

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.
  

We can take it as starting point in patch thread.

I wish they will pass next to dojo core team as well. 
    

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.
  

As soon as any reasons given, it will be collected, discussed  and I will try to summarize common opinion in my regard :)

By the way, in your code there is some bug fixes, which worth to be
filed in bug tracker and most likely shall have separate patch. 
    

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.
  

_______________________________________________
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]

Tom,
We(Ross,you, me) all experienced enough to see importance of aspects
like performance or core reliability.
That is why instead of fighting against existing policy, we are trying
to find the way which will serve all. I am still confident that such way
exist.
inline...

Tom Trenka wrote:

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

Regardless of patches are not welcome reasons, why code review is a tabu?
I see only one, which is sorry to waist the time. But without such
discussion even best deals will be lost. What is criteria to judge,  the
patch or design pattern a reason has a reason to became a part of core?
Without code review it shall not even raised the merging question. All
potential bugs and narrow spots shall be exposed *before*  trying to put
on core`s team vote. Most likely you messed the order of events. In SDLC
I would name it research stage. The development could follow later
according to results or just dropped off due mismatch with requirements.
So support for code review is not bad thing. If there is no time, that
is OK, but why to find excuses?

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

Here I would love to debate your words. If patch is not accepted, it
really has no use. Author do not need the patch per-ce, he own the code.
Patch has a sense if able to be used. So it is either question of is
there ANY reasons to try the patch if it be not even discussed :(
One way through I see, but still there is no interest, not to mention
support for it: runtime patches.

> 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.
>  
I see here subject for discussion. Why the patch is safe, generic and do
not impact performance, maintenance, etc.
I will try to explain in patch thread.

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

Well, all we(contributors) need - both ways discussion with visible
affect in code. All is in your hands.
Our side is to convince, your - reasons for rejecting, so we can debate
and be able to prove the best.

Thanks,
Sasha

_______________________________________________
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]

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.

[Ross Thomas]

Ross Thomas wrote:

Tom Trenka wrote:

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)

Is there a preferred forum for the 'bugging' of developers & Foundation staff. :-)

Bump.

Any word on the CLA?  Or is it now moot with the impending re-organization?

Ross.

[Ross Thomas]

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.

FilteringTable-0.4.2rc2.zip

[Ross Thomas]

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.

From that post:

 Now includes a
HOWTO demonstrator file "renderusing.html" that shows
both the renderusing & null handling in action.

Ross.

Attachment: FilteringTable-0.4.2.zip

[jezza]

Ross,

This is great work.  Unfortuantely it doesn't appear to work under IE7.  Using your example, it won't populate the table at all.  I have the exact same example working well under FF 2.0.0.3, IE6 and Opera 9.10.

I also have used your previous version under 0.4.1 and it works well under all 4 of these browsers, including IE7.

Thanks for all your work so far.
Jeremy

Ross Thomas wrote:

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.

From that post:

 Now includes a
HOWTO demonstrator file "renderusing.html" that shows
both the renderusing & null handling in action.

Ross.

Attachment: FilteringTable-0.4.2.zip

[Ross Thomas]

jezza wrote:

Unfortuantely it doesn't appear to work under IE7.  Using your example, it won't populate the table at all.  I have the exact same example working well under FF 2.0.0.3, IE6 and Opera 9.10.

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.

I also have used your previous version under 0.4.1 and it works well under all 4 of these browsers, including IE7.

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.

[jezza]

I agree with you entirely with regards to IE7.  I have had nothing but trouble since it was released.

I think you are right about it being a permission thing.  The behaviour seems to be the same regardless of whether I am using the patched version or the original version.  To make matters more confusing, it now appears to be working when I place the test file inside apache or tomcat and view it using http:// ... renderusing.html but is not working when I try to open it as a stand alone file ( e.g. c:\... renderusing.html in the address bar).

This strikes me as rather odd, b/c running it inside a web application at work today is where I first noticed the problem.  Unfortunately, I won't be in again until Monday, so I won't be able to run the same tests until then.

Putting a try / catch block in the init function seemed to make no difference, as I think it might be failing before it even gets to it.  Getting IE to break on error gives the following error message:
Error Line: 97
Char: 1
Error: Could not load 'dojo.widget.FilteringTable';last tried '__package__.js
Code: 0
URL: file:///c:/temp/renderusing.html

In light of that, it looks to me that dojo is not loading at all.  If that is the case, I assume is a permission thing IE somewhere that needs to be enabled.  Either way, there is not much you can do about it.

I will have another look on Monday at on the server where I first noticed the issue.  If I come up with anything new, I will let you know.

Thanks for pointing me in the right direction, and thanks again for providing such a useful function.

[Ross Thomas]

jezza wrote:

I agree with you entirely with regards to IE7.  I have had nothing but trouble since it was released.

Heh!  Yeah.  Most of our clients have reverted to IE6 after various levels of
frustration with IE7.  I keep recommending FF -- some have listened. :-)

I think you are right about it being a permission thing.  The behaviour seems to be the same regardless of whether I am using the patched version or the original version.  To make matters more confusing, it now appears to be working when I place the test file inside apache or tomcat and view it using http:// ... renderusing.html but is not working when I try to open it as a stand alone file ( e.g. c:\... renderusing.html in the address bar).

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.

This strikes me as rather odd, b/c running it inside a web application at work today is where I first noticed the problem.  Unfortunately, I won't be in again until Monday, so I won't be able to run the same tests until then.

Putting a try / catch block in the init function seemed to make no difference, as I think it might be failing before it even gets to it.  Getting IE to break on error gives the following error message:
Error Line: 97
Char: 1
Error: Could not load 'dojo.widget.FilteringTable';last tried '__package__.js
Code: 0
URL: file:///c:/temp/renderusing.html

In light of that, it looks to me that dojo is not loading at all.  If that is the case, I assume is a permission thing IE somewhere that needs to be enabled.  Either way, there is not much you can do about 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.

I will have another look on Monday at on the server where I first noticed the issue.  If I come up with anything new, I will let you know.

Cool.  I think a few others on the list would also be happy for a resolution.

Thanks for pointing me in the right direction, and thanks again for providing such a useful function.

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.