« Return to Thread: A few issues with 1.1.1
Re: A few issues with 1.1.1
by Jeremy Quinn
::
Rate this Message:
Hi Peter
Thanks for your useful feedback.
On 2 Jul 2008, at 13:53, Peter E Higgins wrote:
> Hi Jeremy,
>
> Couple of notes inline:
>
>> 1. API for DND Avatars
>> I am really struggling to get good avatars for making a DND Repeater
>> Widget
>> (A Repeater in Cocoon is essentially a form widget for editing
>> Collections).
>> RepeaterRows (dojoDndItems) may contain /any/ markup or widgets. We
>> have a custom 'creator' function because simply cloning dojo widgets
>> in RepeaterRows during DND copy causes problems during the subsequent
>> BrowserUpdate.
>> The specific issue I am reporting is that once my rows contain dojo
>> widgets, the avatar begins to look really bad. For instance, I get
>> button text but no button, if a row contains a dijit.ToolTip, the
>> avatar shows the naked text content of the tooltip etc. etc. I do not
>> know how to solve this and I think the problem is compounded by the
>> fact that the creator function is sent the innerHTML of the node, not
>> the node itself (less scope for a solution).
>>
>>
> You can probably just create a simple Avatar class, and overload the
> construct: method?
Sounds good
> The 1.2 Grid Container does some DnD mucking to
> clone the widget and use it as a single avatar. checkout:
> http://archive.dojotoolkit.org/nightly/dojotoolkit/dojox/layout/dnd/
Useful
> or
> http://archive.dojotoolkit.org/nightly/dojotoolkit/dojox/layout/tests/test_GridContainerBC.html
Good, I can try to work out why for instance the Calendar's Avatar in
this sample is correct, while my Avatars draw widgets incorrectly.
> Not sure why the tooltips would be rendering ...
My guess is it's the difference between using dojo.clone and injecting
innerHTML to make the Avatar.
I need a custom creator function, to make sure that a clone does /not/
happen onDrop, as the clones in the Target are about to be destroyed
by Cocoon's BrowserUpdate mechanism. If you had just cloned widgets
from another Source, that Source's cloned Widgets would also get
destroyed (but the Source does not get updated by the server, if this
was a copy not a move).
If a custom creator function exists, then it is called for both onDrop
and Avatar creation.
However, the creator function does not get the source node, it only
get's the innerHTML of the source node, meaning you cannot clone.
When my rows are cloned to make an Avatar, they display fine.
Setting the innerHTML on the Avatar results in the broken display.
I added this to the cocoon.forms.Repeater Widget :
dojo.declare("cocoon.forms.Avatar", dojo.dnd.Avatar, {
construct: function() {
var creator = this.manager.source.creator;
this.manager.source.creator = null; // temporarily hide the creator
this.inherited(arguments); // call the original
dojo.dnd.Avatar.construct
this.manager.source.creator = creator; // restore the creator,
it's needed for drop
}
});
dojo.extend(dojo.dnd.Manager, {
makeAvatar: function() {
return new cocoon.forms.Avatar(this);
}
});
This seems to solve the problem by hiding the custom creator while the
Avatar constructs, allowing it to use it's default cloning
implementation.
>> 2. TabContainer absolute height
>> TabContainer only renders on the page if you give it an absolute
>> height. This is a real nuisance for a framework-type development,
>> specially as the Tabs implementation we are replacing did not require
>> this (along with other Dojo containers like TitlePane etc. which seem
>> able to size themselves to their content automatically.)
>>
>>
> It is possible in limited fashion to do this. I worked it into the
> QuickStart guide, which turns a load of <div>'s into a StackContainer,
> which is the foundation of TabContainer.
>
> // here the subscription to selectChild will update both left and
> bottom
> navigation
> var div = dijit.byId("masterStack").domNode;
> dojo.subscribe("masterStack-selectChild",function(child){
>
> // fix "dolayout="false""
> var size = child.domNode.scrollHeight + 50;
> dojo.style(div, "height", size+"px");
>
> });
>
> from the file: http://sitepen.com/labs/guides/include/js/tab.js
> from the guide: http://sitepen.com/labs/guides/
This looks interesting ....
I setup a TabContainer with @doLayout="true" (so tabs render properly)
but with no absolute height set in CSS.
After TabContainer.layout runs, the TabContainer is not visible.
The this.selectedChildWidget.domNode.scrollHeight is positive but
this.domNode.clientHeight is zero, which was why it was not showing.
So I extended TabContainer.layout :
/* if there was no absolute height in the style, size the TabContainer
by the height of the selected Tab */
layout: function(){
this.inherited(arguments);
if (this.domNode.clientHeight == 0 && this.selectedChildWidget) {
var high = 0, border = /* eek! */2;
if (this.tabPosition == "top" || this.tabPosition == "bottom") {
high = this.selectedChildWidget.domNode.scrollHeight +
this.tablist.domNode.clientHeight;
} else { // tabs on the left or right
high = Math.max(this.selectedChildWidget.domNode.scrollHeight,
this.tablist.domNode.clientHeight);
}
if (high > 0) this.domNode.style.height = high + border + "px";
}
}
This /seems/ to work (tested in Safari, Firefox), it survives font
zooming and window resizing etc.
> This very well may be fixed in 1.2, though I am not sure officially on
> that. There is a limited doLayout test bill worked in, if I recall...
>
>> 3. TabContainer @noFormat='true' rendering problems
>> The limitation in (2) cannot be worked around by specifying
>> @noFormat='true' as the tabs are not drawn properly with formatting
>> turned off (MacOSX - Safari, Firefox). The active tab has an ugly
>> grey
>> line between it and it's content pane.
>>
>>
> I'm not seeing a noFormat attribute? What is/does/did it do?
Sorry, I meant @doLayout="false"
In 1.1.1, the test : dijit/tests/layout/
test_TabContainer_noLayout.html draws the tabs incorrectly OMM.
It seems that when you turn doLayout off in a TabContainer, lots of
necessary CSS gets left out.
>> 4. DropDownButton @id
>> This is probably just a bug, but if you add a custom id attribute
>> to a
>> DropDownButton, the id gets added to the pane while the button gets a
>> dojo-generated id. This resulted in problems destroying the
>> DropDownButton, which went away as soon as I removed the @id.
>>
>>
> hmm that would be worth seeing a test case for. Peek around
> trac.dojotoolkit.org and see if it's been found already, and file a
> new
> ticket if not. Best case scenario, submit a patch with a CLA ;) We'd
> love to work with you to identify the kinds of things you are finding.
Good, I'll do that.
>> 5. Customising InlineEditBox
>> I don't like the way that the Save/Cancel controls push the content
>> around as they pop up and down, so I made their positioning absolute.
>> We had to use fragile CSS rules, dependent on the tag hierarchy to
>> achieve this. If the widget and it's button container had CSS classes
>> that uniquely identify this widget, it would be far simpler. The
>> widget currently uses dijitReset and dijitInline, which is not
>> useful.
>>
>>
> Allowing customization is important, though the dijitInline and
> dijitReset classes are rather important to cross-browser workings of
> some widgets. Some places they are probably unnecessary, but some
> places
> their removal would allow things like table-cell paddings defined by
> the
> user to bleed through to the widget (dijitReset) ... dijitInline is
> more
> or less just a working inline-block .. Tweaking css inheritance is a
> tedious task sometimes, and is fragile by nature, imho.
Sorry, I was not suggesting taking them out :)
> Setting unique
> classes per widget instance might get to be ever more fragile.
ATM, there is no unique class to help identify this kind of widget.
Dojo has lots of Widgets that do this, which was why I suggested they
were added to InlineEditBox, I guess I got used to it ;)
> setting
> classes (or id's) on parent nodes should allow you to directly take
> precedence over the theme
Yes, wrapping the Widget with a special class was the only way I had
of identifying the Widget to apply css eg. .forms-inline-editor >
fieldset > span { /* the Button Pane */ . . . }.
Dynamically generating matching id attributes and #id css rules in
this kind of framework project adds unnecessary complexity IMHO ;)
> ... but to be honest I've not done much
> hacking on the InlineEditBox, and it sounds like you already have.
Only the minimum necessary .....
Many thanks again for your help
regards Jeremy
_______________________________________________
FAQ: http://dojotoolkit.org/support/faq
Book: http://dojotoolkit.org/docs/book
Forums: http://dojotoolkit.org/forum
Dojo-interest@...
http://turtle.dojotoolkit.org/mailman/listinfo/dojo-interest
Thanks for your useful feedback.
On 2 Jul 2008, at 13:53, Peter E Higgins wrote:
> Hi Jeremy,
>
> Couple of notes inline:
>
>> 1. API for DND Avatars
>> I am really struggling to get good avatars for making a DND Repeater
>> Widget
>> (A Repeater in Cocoon is essentially a form widget for editing
>> Collections).
>> RepeaterRows (dojoDndItems) may contain /any/ markup or widgets. We
>> have a custom 'creator' function because simply cloning dojo widgets
>> in RepeaterRows during DND copy causes problems during the subsequent
>> BrowserUpdate.
>> The specific issue I am reporting is that once my rows contain dojo
>> widgets, the avatar begins to look really bad. For instance, I get
>> button text but no button, if a row contains a dijit.ToolTip, the
>> avatar shows the naked text content of the tooltip etc. etc. I do not
>> know how to solve this and I think the problem is compounded by the
>> fact that the creator function is sent the innerHTML of the node, not
>> the node itself (less scope for a solution).
>>
>>
> You can probably just create a simple Avatar class, and overload the
> construct: method?
Sounds good
> The 1.2 Grid Container does some DnD mucking to
> clone the widget and use it as a single avatar. checkout:
> http://archive.dojotoolkit.org/nightly/dojotoolkit/dojox/layout/dnd/
Useful
> or
> http://archive.dojotoolkit.org/nightly/dojotoolkit/dojox/layout/tests/test_GridContainerBC.html
Good, I can try to work out why for instance the Calendar's Avatar in
this sample is correct, while my Avatars draw widgets incorrectly.
> Not sure why the tooltips would be rendering ...
My guess is it's the difference between using dojo.clone and injecting
innerHTML to make the Avatar.
I need a custom creator function, to make sure that a clone does /not/
happen onDrop, as the clones in the Target are about to be destroyed
by Cocoon's BrowserUpdate mechanism. If you had just cloned widgets
from another Source, that Source's cloned Widgets would also get
destroyed (but the Source does not get updated by the server, if this
was a copy not a move).
If a custom creator function exists, then it is called for both onDrop
and Avatar creation.
However, the creator function does not get the source node, it only
get's the innerHTML of the source node, meaning you cannot clone.
When my rows are cloned to make an Avatar, they display fine.
Setting the innerHTML on the Avatar results in the broken display.
I added this to the cocoon.forms.Repeater Widget :
dojo.declare("cocoon.forms.Avatar", dojo.dnd.Avatar, {
construct: function() {
var creator = this.manager.source.creator;
this.manager.source.creator = null; // temporarily hide the creator
this.inherited(arguments); // call the original
dojo.dnd.Avatar.construct
this.manager.source.creator = creator; // restore the creator,
it's needed for drop
}
});
dojo.extend(dojo.dnd.Manager, {
makeAvatar: function() {
return new cocoon.forms.Avatar(this);
}
});
This seems to solve the problem by hiding the custom creator while the
Avatar constructs, allowing it to use it's default cloning
implementation.
>> 2. TabContainer absolute height
>> TabContainer only renders on the page if you give it an absolute
>> height. This is a real nuisance for a framework-type development,
>> specially as the Tabs implementation we are replacing did not require
>> this (along with other Dojo containers like TitlePane etc. which seem
>> able to size themselves to their content automatically.)
>>
>>
> It is possible in limited fashion to do this. I worked it into the
> QuickStart guide, which turns a load of <div>'s into a StackContainer,
> which is the foundation of TabContainer.
>
> // here the subscription to selectChild will update both left and
> bottom
> navigation
> var div = dijit.byId("masterStack").domNode;
> dojo.subscribe("masterStack-selectChild",function(child){
>
> // fix "dolayout="false""
> var size = child.domNode.scrollHeight + 50;
> dojo.style(div, "height", size+"px");
>
> });
>
> from the file: http://sitepen.com/labs/guides/include/js/tab.js
> from the guide: http://sitepen.com/labs/guides/
This looks interesting ....
I setup a TabContainer with @doLayout="true" (so tabs render properly)
but with no absolute height set in CSS.
After TabContainer.layout runs, the TabContainer is not visible.
The this.selectedChildWidget.domNode.scrollHeight is positive but
this.domNode.clientHeight is zero, which was why it was not showing.
So I extended TabContainer.layout :
/* if there was no absolute height in the style, size the TabContainer
by the height of the selected Tab */
layout: function(){
this.inherited(arguments);
if (this.domNode.clientHeight == 0 && this.selectedChildWidget) {
var high = 0, border = /* eek! */2;
if (this.tabPosition == "top" || this.tabPosition == "bottom") {
high = this.selectedChildWidget.domNode.scrollHeight +
this.tablist.domNode.clientHeight;
} else { // tabs on the left or right
high = Math.max(this.selectedChildWidget.domNode.scrollHeight,
this.tablist.domNode.clientHeight);
}
if (high > 0) this.domNode.style.height = high + border + "px";
}
}
This /seems/ to work (tested in Safari, Firefox), it survives font
zooming and window resizing etc.
> This very well may be fixed in 1.2, though I am not sure officially on
> that. There is a limited doLayout test bill worked in, if I recall...
>
>> 3. TabContainer @noFormat='true' rendering problems
>> The limitation in (2) cannot be worked around by specifying
>> @noFormat='true' as the tabs are not drawn properly with formatting
>> turned off (MacOSX - Safari, Firefox). The active tab has an ugly
>> grey
>> line between it and it's content pane.
>>
>>
> I'm not seeing a noFormat attribute? What is/does/did it do?
Sorry, I meant @doLayout="false"
In 1.1.1, the test : dijit/tests/layout/
test_TabContainer_noLayout.html draws the tabs incorrectly OMM.
It seems that when you turn doLayout off in a TabContainer, lots of
necessary CSS gets left out.
>> 4. DropDownButton @id
>> This is probably just a bug, but if you add a custom id attribute
>> to a
>> DropDownButton, the id gets added to the pane while the button gets a
>> dojo-generated id. This resulted in problems destroying the
>> DropDownButton, which went away as soon as I removed the @id.
>>
>>
> hmm that would be worth seeing a test case for. Peek around
> trac.dojotoolkit.org and see if it's been found already, and file a
> new
> ticket if not. Best case scenario, submit a patch with a CLA ;) We'd
> love to work with you to identify the kinds of things you are finding.
Good, I'll do that.
>> 5. Customising InlineEditBox
>> I don't like the way that the Save/Cancel controls push the content
>> around as they pop up and down, so I made their positioning absolute.
>> We had to use fragile CSS rules, dependent on the tag hierarchy to
>> achieve this. If the widget and it's button container had CSS classes
>> that uniquely identify this widget, it would be far simpler. The
>> widget currently uses dijitReset and dijitInline, which is not
>> useful.
>>
>>
> Allowing customization is important, though the dijitInline and
> dijitReset classes are rather important to cross-browser workings of
> some widgets. Some places they are probably unnecessary, but some
> places
> their removal would allow things like table-cell paddings defined by
> the
> user to bleed through to the widget (dijitReset) ... dijitInline is
> more
> or less just a working inline-block .. Tweaking css inheritance is a
> tedious task sometimes, and is fragile by nature, imho.
Sorry, I was not suggesting taking them out :)
> Setting unique
> classes per widget instance might get to be ever more fragile.
ATM, there is no unique class to help identify this kind of widget.
Dojo has lots of Widgets that do this, which was why I suggested they
were added to InlineEditBox, I guess I got used to it ;)
> setting
> classes (or id's) on parent nodes should allow you to directly take
> precedence over the theme
Yes, wrapping the Widget with a special class was the only way I had
of identifying the Widget to apply css eg. .forms-inline-editor >
fieldset > span { /* the Button Pane */ . . . }.
Dynamically generating matching id attributes and #id css rules in
this kind of framework project adds unnecessary complexity IMHO ;)
> ... but to be honest I've not done much
> hacking on the InlineEditBox, and it sounds like you already have.
Only the minimum necessary .....
Many thanks again for your help
regards Jeremy
_______________________________________________
FAQ: http://dojotoolkit.org/support/faq
Book: http://dojotoolkit.org/docs/book
Forums: http://dojotoolkit.org/forum
Dojo-interest@...
http://turtle.dojotoolkit.org/mailman/listinfo/dojo-interest
« Return to Thread: A few issues with 1.1.1
| Free embeddable forum powered by Nabble | Forum Help |
