Yeah, I don't know why the dojo documentation has parseWidgets = true for everything. No one actually uses that setting for high profile web sites. Then again, I've had many heated "disagreements" with some of them so it's not surprising..(though there are equally good devs for the minor annoyances run across here and there ....mainly the same people responsible for TabContainer / Floating windows / etc...ie anything that sucks )
Right...The destroyWidget property is managed so that unnecessary destruction doesn't happen (or in situations where it can't happen) . The easiest examples are those dojo widgets already wrapped in Tapestry: http://svn.apache.org/viewvc/tapestry/tapestry4/trunk/tapestry-framework/src/java/org/apache/tapestry/dojo/ I'm not as sure about the ContentPane and other things you are running into. I wouldn't recommend using them personally as I think some simple css rules can do the same thing without all the bloat. Of course this doesn't help you in your current situation. If I were having widget issues I might create a plain vanilla html page and include dojo manually on it (ie no tapestry ) and do whatever I had to do to understand how it works there first before moving it to java managed code. On 3/15/07, Steve Shucker <[EMAIL PROTECTED]> wrote:
Can someone point me to a good primer for wrapping dojo components to be used with tapestry 4.1. Yesterday I went through a lot of grief before I realized that tapestry was setting parseWidgets=false. Eventually I concluded that: 1) Tapestry doesn't want dojo to automatically inspect the tree and turn things into widgets 2) If we shouldn't be parsing the whole page, calling that same dojo code to initialize a large fragment of the page probably isn't the recommended solution either. 3) Therefore the preferred way of doing things is to render normal divs and use initialization javascripts to widgetize them 4) Dojo's examples all assume parseWidgets=true and their documentation on doing this programmatically sucks. I was working on an accordion control with an additional parameter to set the initial pane, so I got some inspiration from the tacos sources. It seemed like this shouldn't involve nearly as much script as I saw there. The tacos 4.1 snapshot sources bothered me because ContentPane's init script had a specific check to see if it was in a tab container - that struck me as an improper interdependency. -Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]