« 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 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
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
« Return to Thread: A few issues with 1.1.1
| Free embeddable forum powered by Nabble | Forum Help |
