I posted this on Stackoverflow (http://stackoverflow.com/questions/13075919/correctly-removing-development-toolbar-in-seaside), but as there were no answers, i repost it here. I think it may be a bug?
In order to disable the Development Toolbar at the bottom of my Seaside applications i did execute, as the Seaside Book says: WAAdmin applicationDefaults removeParent: WADevelopmentConfiguration instance Which does what it says - BUT only about half of the registered applications take notice that their parent is gone. The other half shows still the Toolbar and the Configuration site for these applications still shows: Root Decoration Classes: WAToolDecoration [inherited] and only after i click one time at Configure (Root Decoration Classes), the next screen shows Available: WAToolDecoration, Current: (empty) and so i click nothing else but OK, and the Toolbar is finally gone. |
Helene Bilbo <thereluctantprogrammer <at> fastmail.fm> writes:
How interesting - I get by via the application configuration link, or via code as in WAGlobalConfiguration setDeploymentMode or WAGlobalConfiguration setDevelopmentMode. You have noticed that the development toolbar is implemented as a decoration. You many inherit from the parent decoration. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
I use Seaside 3.0.7 on Pharo 1.3 and Pharo 1.4 and there is no WAGlobalConfiguration at all. From what i read, this may have been the way to do it in prior versions? I used the technique from the seaside book: http://book.seaside.st/book/advanced/deployment/deployment-preparing |
In reply to this post by Helene Bilbo
On 10/27/2012 02:20 AM, Helene Bilbo wrote:
> I posted this on Stackoverflow > (http://stackoverflow.com/questions/13075919/correctly-removing-development-toolbar-in-seaside), > but as there were no answers, i repost it here. I think it may be a bug? > > In order to disable the Development Toolbar at the bottom of my Seaside > applications i did execute, as the Seaside Book says: > > WAAdmin applicationDefaults > removeParent: WADevelopmentConfiguration instance > > Which does what it says - BUT only about half of the registered applications > take notice that their parent is gone. > > The other half shows still the Toolbar and the Configuration site for these > applications still shows: > > Root Decoration Classes: WAToolDecoration [inherited] > > and only after i click one time at Configure (Root Decoration Classes), the > next screen shows > > Available: WAToolDecoration, Current: (empty) > > and so i click nothing else but OK, and the Toolbar is finally gone. > > > > -- > View this message in context: http://forum.world.st/I-have-a-problem-with-removing-the-Development-Toolbar-tp4653109.html > Sent from the Seaside General mailing list archive at Nabble.com. > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > That should remove them. It sounds like a bug related to this issue: http://code.google.com/p/seaside/issues/detail?id=608 Are the applications that retain the developer toolbar the default applications or applications you've (or some other package) has created? _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
It occures on both kinds of applications. You can reproduce it with a current One-Click-Image for Seaside 3.0.7 on Pharo from seaside.st with just the standard applications that come preloaded with this image. The issue you point to seems promising, though :) I already experimented with WAAdmin clearConfigurationCaches, but that does not do the job. I am not yet familiar with the internals of Seaside. I will start looking at it over the weekend.. Thank you for the hints! Helene. |
On 02/11/12 8:14 AM, Helene Bilbo wrote:
> > The issue you point to seems promising, though :) I already experimented > with WAAdmin clearConfigurationCaches, but that does not do the job. I've recently updated the Seaside packages I use in my build, and noticed the problem with the Dev Toolbar staying around. However, I build two images, one for deployment and one for development. My deployment image does not have the toolbar, whereas my development image has the toolbar and it resists all attempts, so far, to remove it, except by the method you described. It does seem to be caching problem, since my deployment image never starts up with the toolbar, so doesn't have the problem with its unwanted appearance. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Helene Bilbo
On 11/02/2012 05:14 AM, Helene Bilbo wrote:
> Paul DeBruicker wrote >> That should remove them. It sounds like a bug related to this issue: >> >> http://code.google.com/p/seaside/issues/detail?id=608 >> >> Are the applications that retain the developer toolbar the default >> applications or applications you've (or some other package) has created? > > It occures on both kinds of applications. You can reproduce it with a > current One-Click-Image for Seaside 3.0.7 on Pharo from seaside.st with just > the standard applications that come preloaded with this image. > > The issue you point to seems promising, though :) I already experimented > with WAAdmin clearConfigurationCaches, but that does not do the job. > > I am not yet familiar with the internals of Seaside. I will start looking at > it over the weekend.. > > Thank you for the hints! > > Helene. > > > > -- > View this message in context: http://forum.world.st/I-have-a-problem-with-removing-the-Development-Toolbar-tp4653109p4653582.html > Sent from the Seaside General mailing list archive at Nabble.com. > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > If you don't care about accessing the other applications you can run this: WADispatcher default handlers do: [ :each | WADispatcher default unregister: each ]. which removes all of the applications that are installed in the image and then you can re-initialize your own applications so you only have the apps you're interested in to fix. It will be good to learn how to remove the toolbar without unregistering everything, but this may help in the short term. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
On 02/11/12 11:05 AM, Paul DeBruicker wrote:
> > WADispatcher default handlers do: [ :each | WADispatcher default > unregister: each ]. > > > which removes all of the applications that are installed in the image > and then you can re-initialize your own applications so you only have > the apps you're interested in to fix. My build script was using: WADispatcher default withDescendantsDo: [...] to remove unwanted entries. Just yesterday, I fixed it to accumulate the entries to be removed, and then remove them after the traversal. I finally figured out that removing entries while doing the #withDescendantsDo: traversal would cause some entries to be missed. (I.e. don't remove collection entries, while traversing that same collection). It used to work in Seaside 3.0 though. I think the approach of removing everything, then adding back the entries you need, is what I'll do in future. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Paul DeBruicker
I did not check the details, but tried the version before (3.0.3 - everything works as it should) and after (3.0.4 - my problem occures) this cache was integrated and this confirms that the problem might in fact be related to the cache. I opened an issue in the bugtracker: http://code.google.com/p/seaside/issues/detail?id=746 |
Free forum by Nabble | Edit this page |