Re: A few issues with 1.1.1

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