A few issues with 1.1.1

[Jeremy Quinn]

Hi All

I am working with Dojo 1.1.1 (and mostly enjoying it :)

I am adding Dojo 1.1 to Apache Cocoon Forms framework, whereby Users'  
XML Form markup (representing model, binding and template), is  
generically transformed into a dojo-based application. The page sends  
user changes back to the server as XHR Requests, the server updates  
it's Model then sends back any changes inside XHTML 'BrowserUpdate'  
tags, which (matching on IDs) replace that content on the client.

This type of generic development brings a unique set of problems,  
specially as I am stringently avoiding any modification of the dojo  
libraries.

Here are a few issues I have found during my work :

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

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

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.

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.

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.

Many thanks for your attention.

Any suggestions for workarounds to these issues would be gratefully  
accepted.

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

[Peter E Higgins-2]

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

[Eugene Lazutkin]

Actually the documentation
(http://docs.google.com/Doc?id=d764479_11fcs7s397) describes how avatars
work, and how you can substitute your own. Please read on the Avatar
section and makeAvatar()/updateAvatar() methods in the Manager section.
You may want to generate different nodes for the avatar than for sources
to make it look pretty --- use creators for that. A creator function is
always hinted if it is asked to generate a visual representation for the
avatar (again it is documented). Let me know if you have more problems
with DnD.

Thanks,

Eugene

Jeremy Quinn wrote:

> Hi All
>
> I am working with Dojo 1.1.1 (and mostly enjoying it :)
>
> I am adding Dojo 1.1 to Apache Cocoon Forms framework, whereby Users'  
> XML Form markup (representing model, binding and template), is  
> generically transformed into a dojo-based application. The page sends  
> user changes back to the server as XHR Requests, the server updates  
> it's Model then sends back any changes inside XHTML 'BrowserUpdate'  
> tags, which (matching on IDs) replace that content on the client.
>
> This type of generic development brings a unique set of problems,  
> specially as I am stringently avoiding any modification of the dojo  
> libraries.
>
> Here are a few issues I have found during my work :
>
> 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).
>
> 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.)
>
> 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.
>
> 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.
>
> 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.
>
> Many thanks for your attention.
>
> Any suggestions for workarounds to these issues would be gratefully  
> accepted.
>
> 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
>

_______________________________________________
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

[Jeremy Quinn]

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

[Jeremy Quinn]

Hi Eugene,

Thanks for your reply.

I think I have solved the problem, please see my previous reply to  
this thread.

On 2 Jul 2008, at 18:17, Eugene Lazutkin wrote:

> Actually the documentation
> (http://docs.google.com/Doc?id=d764479_11fcs7s397) describes how  
> avatars
> work, and how you can substitute your own. Please read on the Avatar
> section and makeAvatar()/updateAvatar() methods in the Manager  
> section.

Don't worry, I would not have got this far without it :)

> You may want to generate different nodes for the avatar than for  
> sources
> to make it look pretty --- use creators for that. A creator function  
> is
> always hinted if it is asked to generate a visual representation for  
> the
> avatar (again it is documented). Let me know if you have more problems
> with DnD.

I think the difference between an Avatar and a custom creator is that  
the custom creator only gets the innerHTML of the source node, while  
the Avatar gets the actual node.

For my avatars to display properly, they needed to be made by cloning  
the source into the avatar, just setting the innerHTML resulted in a  
poor display of nested Widgets.

Conversely, I was forced to have a custom creator because I could not  
allow cloning on Drop.

So I had to work around dojo.dnd.Avatar calling the custom creator, if  
it exists.

Thanks

regards Jeremy

>
> Jeremy Quinn wrote:
>> Hi All
>>
>> I am working with Dojo 1.1.1 (and mostly enjoying it :)
>>
>> I am adding Dojo 1.1 to Apache Cocoon Forms framework, whereby Users'
>> XML Form markup (representing model, binding and template), is
>> generically transformed into a dojo-based application. The page sends
>> user changes back to the server as XHR Requests, the server updates
>> it's Model then sends back any changes inside XHTML 'BrowserUpdate'
>> tags, which (matching on IDs) replace that content on the client.
>>
>> This type of generic development brings a unique set of problems,
>> specially as I am stringently avoiding any modification of the dojo
>> libraries.
>>
>> Here are a few issues I have found during my work :
>>
>> 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).
>>
>> 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.)
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> Many thanks for your attention.
>>
>> Any suggestions for workarounds to these issues would be gratefully
>> accepted.
>>
>> 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
>>
>
> _______________________________________________
> 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

_______________________________________________
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