headers
Adam L. Peller | 4 Nov 2008 01:20
Gravatar

Re: Dojo 1.2.1 release time?

I cut the 1.2.1 release yesterday and created a 1.2.2 milestone.
Please take a moment, particularly if you contributed a 1.2.1 patch,
and take a look at the build. Speak now if you see anything wrong.

We'll watch the 1.2.2 bug queue and see if it's necessary to cut a
release -- right now, it would probably be set around a handful of
grid bugs and the contentpane bugs, which are still in the tbd queue.

Peter, I think you said there were a couple more things in the build
that need to be done by hand?  Then maybe we could announce this
tomorrow?

-Adam

On Mon, Oct 27, 2008 at 5:04 PM, Adam L. Peller <adam <at> peller.org> wrote:
> Ooh!  A volunteer!  (Thanks, Josh :)
>
> Basically, whatever was in the 1.2.1 milestone at the time I tagged rc1,
> which hasn't changed in the last 24 hrs and I suspect aside from Bryan's
> grid patch for RC2 will be pretty much what we end up with.
>
> http://bugs.dojotoolkit.org/query?status=assigned&status=closed&status=new&status=reopened&order=priority&milestone=1.2.1&col=id&col=summary&col=status&col=type&col=priority&col=component
>
> (See the closed items)
>
> It looks like I'll bump the remainder to 1.2.2 when we cut a release, which
> sounds like it would be at the end of the week.
>
> -Adam
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Peter E Higgins | 4 Nov 2008 02:53
Favicon
Gravatar

Re: Dojo 1.2.1 release time?


> We'll watch the 1.2.2 bug queue and see if it's necessary to cut a
> release -- right now, it would probably be set around a handful of
> grid bugs and the contentpane bugs, which are still in the tbd queue.
>
>   
Yes, still in TBD but have had lots of movement, and should definitely
be part of a 1.2.2 set, as it was a pretty serious regression.  (I'm sad
we didn't get it into 1.2.1)
> Peter, I think you said there were a couple more things in the build
> that need to be done by hand?  Then maybe we could announce this
> tomorrow?
>
>   
Yes, some minor technicalities with how we do the release build versus
what we extract on the download link for static linking  ... nothing too
pressing. We (I) need to fix it to be automated. I think it involves
running two builds unfortunately. We've also got to automate the maven
version updating to happen in build_release.sh

Tomorrow seems fine. We'll have to determine soon if the contentpane
stuff will be in a 1.2.2 (if at all), and if pushing 1.2.1 or 1.2.2 to
the CDN's makes sense.

Regards,
Peter Higgins
Permalink | Reply | 0 comments |
headers
David Snopek | 4 Nov 2008 17:10
Picon
Gravatar

ContentPane bugs (was: Re: Dojo 1.2.1 release time?)

2008/11/3 Adam L. Peller <adam <at> peller.org>:
>
> We'll watch the 1.2.2 bug queue and see if it's necessary to cut a
> release -- right now, it would probably be set around a handful of
> grid bugs and the contentpane bugs, which are still in the tbd queue.

The contentpane bugs are important.  They stop many simple cases that
worked with 1.1.1 from working when you drop in 1.2.  It doesn't look
like this will make it into 1.2.1, but a quick 1.2.2 would be nice.

FYI, the "main bugs" as I see them are the following two (there are
others covering the same problems, but these have the most
information/work toward a solution):

http://trac.dojotoolkit.org/ticket/7801
http://trac.dojotoolkit.org/ticket/7784

I have a pretty good understanding of the problems, but I'm wary to
make a patch because I don't know what the dijit developers would
consider the "correct solution".  Ie. on #7801, should we be trying to
fix dijit.layout.ContentPane or dojox.layout.ContentPane?  And on
#7784, should we abandon setter.empty() like neonstalwart suggests or
should we attempt to soup it up to handle this situation?

Given some guidance on which approach to use, I could cook-up patches
for both bugs.

Thank you,
David Snopek.
(Continue reading)

Permalink | Reply | 501 comments |
headers
David Snopek | 4 Nov 2008 18:00
Picon
Gravatar

Re: ContentPane bugs (was: Re: Dojo 1.2.1 release time?)

I jumped the gun and put some patches for a few approaches on those
tickets.  If someone from the dijit team could review my patches or
advise me on which approach to use, I'd gladly rework the patches.

Thanks!
David.

2008/11/4 David Snopek <dsnopek <at> gmail.com>:
> 2008/11/3 Adam L. Peller <adam <at> peller.org>:
>>
>> We'll watch the 1.2.2 bug queue and see if it's necessary to cut a
>> release -- right now, it would probably be set around a handful of
>> grid bugs and the contentpane bugs, which are still in the tbd queue.
>
> The contentpane bugs are important.  They stop many simple cases that
> worked with 1.1.1 from working when you drop in 1.2.  It doesn't look
> like this will make it into 1.2.1, but a quick 1.2.2 would be nice.
>
> FYI, the "main bugs" as I see them are the following two (there are
> others covering the same problems, but these have the most
> information/work toward a solution):
>
> http://trac.dojotoolkit.org/ticket/7801
> http://trac.dojotoolkit.org/ticket/7784
>
> I have a pretty good understanding of the problems, but I'm wary to
> make a patch because I don't know what the dijit developers would
> consider the "correct solution".  Ie. on #7801, should we be trying to
> fix dijit.layout.ContentPane or dojox.layout.ContentPane?  And on
> #7784, should we abandon setter.empty() like neonstalwart suggests or
(Continue reading)

Permalink | Reply | 502 comments |
headers
Bill Keese | 5 Nov 2008 01:28
Favicon
Gravatar

Re: dojo.attr() - no disconnect

Nathan Toone wrote:
> If anything, I think that calling, for example dojo.attr("click",null)
> it would disconnect everything - the same as calling node.onclick=null
> would do.

Note that dojo.attr() already has code to disconnect the old handler 
when defining a new one.  dojo.attr() calls dojo.connect(), and saves 
the returned handle in _evtHdlrMap.

So I think rearranging that code a bit would make 
dojo.attr("click",null) work as you suggested.

However, the correct way to remove an attribute is dojo.removeAttr(), 
not dojo.attr(node, "click", null), so dojo.removeAttr() should work [too].
Permalink | Reply | 0 comments |
headers
Bill Keese | 5 Nov 2008 03:06
Favicon
Gravatar

Re: Subversion/Trac integration broken?

I'm getting the same problems as you (on many recent changesets) but no 
idea how to fix :-(

James Burke wrote:
> I just committed a fairly large change for this ticket:
> http://bugs.dojotoolkit.org/ticket/7913
> 
> but I do not get any feedback in the bug about the changeset, and
> going to the changeset gives an error:
> http://bugs.dojotoolkit.org/changeset/15529
> 
> Is the Subversion/Trac integration broken? Who knows how to fix it?
> 
> James
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors <at> dojotoolkit.org
> http://turtle.dojotoolkit.org/mailman/listinfo/dojo-contributors
Permalink | Reply | 0 comments |
headers
Bill Keese | 5 Nov 2008 10:25
Favicon
Gravatar

Re: ContentPane bugs (was: Re: Dojo 1.2.1 release time?)

Hi David, thanks for the patches and work on these bugs.

David Snopek wrote:
 >> http://trac.dojotoolkit.org/ticket/7784

As the ticket description states, it's debatable whether or not this is 
a bug at all, as we never explicitly said that users could directly muck 
with the content of a ContentPane, rather than using the official 
attr('content', ...) and attr('href', ...)) APIs.  However, we never 
explicitly said that they couldn't.

Anyway, your patch looks good to me.  Maybe destroyWidgets() should have 
an underscore so it's not marked as officially supported?   It's Sam's 
module though so he should comment.

>> http://trac.dojotoolkit.org/ticket/7801

I'd like dijit.layout.ContentPane fixed so it only calls 
_onUnloadHandler once.   As you said in your comment in the ticket above 
though, it should call it before erasing the original content, before 
inserting the "Loading..." message.

Actually, there's a TODO in the code:

	// TODO: this shouldn't be called when we are simply destroying a 
"Loading..." message
	this._onUnloadHandler();

Seems like whenever we set the content to "Loading..." or an error 
message we should set a flag to indicate that the content isn't "real"
(Continue reading)

Permalink | Reply | 7 comments |
headers
sam foster | 5 Nov 2008 11:13
Picon

Re: ContentPane bugs (was: Re: Dojo 1.2.1 release time?)

I'm trying... soon as trac decides finds its database.. :/

> As the ticket description states, it's debatable whether or not this is
> a bug at all, as we never explicitly said that users could directly muck
> with the content of a ContentPane, rather than using the official
> attr('content', ...) and attr('href', ...)) APIs.  However, we never
> explicitly said that they couldn't.

Whatever our intentions, its a common use case and we need to support
it. FWIW I think its reasonable, CP and its setter needs to make a
best effort, but the onus is on the developer to clean up after
themself in this case. We just need to ensure that they can

> Anyway, your patch looks good to me.  Maybe destroyWidgets() should have
> an underscore so it's not marked as officially supported?   It's Sam's
> module though so he should comment.
>
>>> http://trac.dojotoolkit.org/ticket/7801
>
> I'd like dijit.layout.ContentPane fixed so it only calls
> _onUnloadHandler once.   As you said in your comment in the ticket above
> though, it should call it before erasing the original content, before
> inserting the "Loading..." message.
>
> Actually, there's a TODO in the code:
>
>        // TODO: this shouldn't be called when we are simply destroying a
> "Loading..." message
>        this._onUnloadHandler();
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
David Snopek | 5 Nov 2008 14:08
Picon
Gravatar

Re: ContentPane bugs (was: Re: Dojo 1.2.1 release time?)

2008/11/5 sam foster <potatosculptor <at> gmail.com>:
> I'm trying... soon as trac decides finds its database.. :/

I've been having that problem too.  Usually after hitting reload once
or twice it will find it.

>> As the ticket description states, it's debatable whether or not this is
>> a bug at all, as we never explicitly said that users could directly muck
>> with the content of a ContentPane, rather than using the official
>> attr('content', ...) and attr('href', ...)) APIs.  However, we never
>> explicitly said that they couldn't.
>
> Whatever our intentions, its a common use case and we need to support
> it. FWIW I think its reasonable, CP and its setter needs to make a
> best effort, but the onus is on the developer to clean up after
> themself in this case. We just need to ensure that they can

Agreed.

>> Anyway, your patch looks good to me.  Maybe destroyWidgets() should have
>> an underscore so it's not marked as officially supported?   It's Sam's
>> module though so he should comment.

Sam, what do you think on this one?  Should this be marked as
officially unsupported or do you think this could be useful to other
potential users of dojo.html._ContentSetter?

>>>> http://trac.dojotoolkit.org/ticket/7801
>>
>> I'd like dijit.layout.ContentPane fixed so it only calls
(Continue reading)

Permalink | Reply | 3 comments |
headers
Bill Keese | 5 Nov 2008 14:15
Favicon
Gravatar

Re: ContentPane bugs

David Snopek wrote:
>>> As the ticket description states, it's debatable whether or not this is
>>> a bug at all, as we never explicitly said that users could directly muck
>>> with the content of a ContentPane, rather than using the official
>>> attr('content', ...) and attr('href', ...)) APIs.  However, we never
>>> explicitly said that they couldn't.
>> Whatever our intentions, its a common use case and we need to support
>> it. FWIW I think its reasonable, CP and its setter needs to make a
>> best effort, but the onus is on the developer to clean up after
>> themself in this case. We just need to ensure that they can
> 
> Agreed.

So then this is agreement that #7844 isn't a bug after all?   That if 
users manually insert a widget under !ContentPane's DOM node then they 
need to remove it manually before calling ContentPane.attr('content', 
...) or ContentPane.attr('href', ...)?
Permalink | Reply | 2 comments |

Gmane