« Return to Thread: A few issues with 1.1.1
Re: A few issues with 1.1.1
by Peter E Higgins-2
::
Rate this Message:
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? 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/
or
http://archive.dojotoolkit.org/nightly/dojotoolkit/dojox/layout/tests/test_GridContainerBC.html
Not sure why the tooltips would be rendering ...
> 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 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?
> 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.
> 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. Setting unique
classes per widget instance might get to be ever more fragile. setting
classes (or id's) on parent nodes should allow you to directly take
precedence over the theme ... but to be honest I've not done much
hacking on the InlineEditBox, and it sounds like you already have.
Regards,
Peter Higgins
_______________________________________________
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
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).
>
>
construct: method? 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/
or
http://archive.dojotoolkit.org/nightly/dojotoolkit/dojox/layout/tests/test_GridContainerBC.html
Not sure why the tooltips would be rendering ...
> 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 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?
> 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.
> 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. Setting unique
classes per widget instance might get to be ever more fragile. setting
classes (or id's) on parent nodes should allow you to directly take
precedence over the theme ... but to be honest I've not done much
hacking on the InlineEditBox, and it sounds like you already have.
Regards,
Peter Higgins
_______________________________________________
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 |
