Hi
WAApplication contains two instance side messages 1. "isDeployed" which is called during automatic deployment preparation using "WADispatcher default trimForDeployment". 2. "deploymentMode" which is called to decide wheter debugging information should be visible Currently these messages produce independent results. isDeployed calls the root WAComponent's class side message isDeployed (which may produce an error if that WAApplication has no root component) deploymentMode checks the WAApplications configuration's #deploymentMode variable In my opinion isDeployed should never fail and override deploymentMode. Hence deplyomentMode should return "true" if isDeployed returned "true" or the WAApplications configurtaion's #deploymentMode variable contains true Here are my implementations (using seaside2.6b1-pmm.76) deploymentMode self isDeployed ifTrue: [^true] ifFalse:[^self preferenceAt: #deploymentMode] isDeployed self rootComponent isNil ifTrue: [^false] ifFalse: [^self rootComponent isDeployed] I hope for suggestions and hints on the meaning of deploymentMode and isDeployed. Faithfully Dominic Letz _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
> Currently these messages produce independent results. Yes, I am the one who invented #isDeployed and it was my original intention to have the concepts independent. I suggested this idea at one of my customers where they wanted to make sure that no one would try urls like /seaside/counter in the deployed system but where /seaside/config would have the toolbar. Cheers, Michel. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
2006/10/16, Bany, Michel <[hidden email]>:
> > > Currently these messages produce independent results. > > Yes, I am the one who invented #isDeployed and it was my original > intention to have the concepts independent. I suggested this idea at > one of my customers where they wanted to make sure that no one would > try urls like /seaside/counter in the deployed system but where Why not just remove them in the build process that makes the deployment images? Philippe > /seaside/config would have the toolbar. > > Cheers, > Michel. > _______________________________________________ > Seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Philippe Marschall wrote:
> 2006/10/16, Bany, Michel <[hidden email]>: >> Yes, I am the one who invented #isDeployed and it was my original >> intention to have the concepts independent. I suggested this idea at >> one of my customers where they wanted to make sure that no one would >> try urls like /seaside/counter in the deployed system but where >> /seaside/config would have the toolbar. > > Why not just remove them in the build process that makes the deployment > images? IMHO, that just hides the underlying problem in the build process. They are independent concepts, but one of them is poorly named - probably the one that came second. Showing/hiding the toolbar is only one aspect of deployment mode. Maybe #isDeployed should have been #showToolbar. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
2006/10/16, Yanni Chiu <[hidden email]>:
> Philippe Marschall wrote: > > 2006/10/16, Bany, Michel <[hidden email]>: > >> Yes, I am the one who invented #isDeployed and it was my original > >> intention to have the concepts independent. I suggested this idea at > >> one of my customers where they wanted to make sure that no one would > >> try urls like /seaside/counter in the deployed system but where > >> /seaside/config would have the toolbar. > > > > Why not just remove them in the build process that makes the deployment > > images? > > IMHO, that just hides the underlying problem in > the build process. I still don't see the point. Why do you want a counter in you deployed application? Why do you want the dev toolbar in the config application of the . Why can't your build system take care of that? > They are independent concepts, but one of them is > poorly named - probably the one that came second. > Showing/hiding the toolbar is only one aspect of > deployment mode. Maybe #isDeployed should have been > #showToolbar. No. #deploymentMode should be named renamed to #showToolbar. The rest should be specific to your build system. Philippe _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Dominic Letz
> I still don't see the point. Why do you want a counter in you
> deployed application? Why do you want the dev toolbar in the > config application of the . Why can't your build system take > care of that? Philippe, When you want to remove a Seaside application from the image you need first to remove their entries from the dispatcher. You can use the config tool for that. Next, you should also remove the classes you do not want from the image. That may be quite complex. Removing the WACounter, the Store demo app, the Seaside tests, the WABrowser, the WAInspector, and so on. For my customers, it is considered enough to perform the first step and leave the unwanted classes in the image. As long as they are not accessible with an url, it's fine. This step is automatically achieved by implementing #isDeployed to answer true on the class side of the applications you want to deploy and to send #trimForDeployment to the dispatcher. This is done for WADispatcherEditor and WADispatcherNavigator. I also suggested my customers to register at least one application (config for instance) with authentication and #deploymentMode set to false so that the toolbar is shown. This provides a back door for accessing the class browser and the inspector. This has helped for debugging headless images. IMO, the above demonstrates that #isDeployed and #deploymentMode are truely orthogonal. And, yes, renaming #deploymentMode to #showToolbar would make a lot of sense. Cheers, Michel. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
2006/10/18, Bany, Michel <[hidden email]>:
> > I still don't see the point. Why do you want a counter in you > > deployed application? Why do you want the dev toolbar in the > > config application of the . Why can't your build system take > > care of that? > > Philippe, > > When you want to remove a Seaside application from the image > you need first to remove their entries from the dispatcher. > You can use the config tool for that. Next, you should also > remove the classes you do not want from the image. That may > be quite complex. Removing the WACounter, the Store demo app, > the Seaside tests, the WABrowser, the WAInspector, and so on. This is why you have an automated build / integration system. That takes care of all that and more like authentication decorations, error handers, paths, server urls and not seaside realated things like database settings and memory manager options. > For my customers, it is considered enough to perform the first > step and leave the unwanted classes in the image. As long as > they are not accessible with an url, it's fine. This step is > automatically achieved by implementing #isDeployed to answer > true on the class side of the applications you want to deploy > and to send #trimForDeployment to the dispatcher. This is done > for WADispatcherEditor and WADispatcherNavigator. > > I also suggested my customers to register at least one application > (config for instance) with authentication and #deploymentMode > set to false so that the toolbar is shown. This provides a back > door for accessing the class browser and the inspector. This has > helped for debugging headless images. We don't believe in headless images and this is just another reason why. If you want a browser just add one. make sure it's not accessible either via Apache or add authentication. Again an automated build system can do that. > IMO, the above demonstrates that #isDeployed and #deploymentMode > are truely orthogonal. And, yes, renaming #deploymentMode to > #showToolbar would make a lot of sense. I have still not seen a convincing example for a deployed application that needs toolbars on. Philippe _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Free forum by Nabble | Edit this page |