WAApplication isDeployed vs. deploymentMode

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

WAApplication isDeployed vs. deploymentMode

Dominic Letz
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
Reply | Threaded
Open this post in threaded view
|

RE: WAApplication isDeployed vs. deploymentMode

Bany, Michel

> 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
Reply | Threaded
Open this post in threaded view
|

Re: WAApplication isDeployed vs. deploymentMode

Philippe Marschall
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
Reply | Threaded
Open this post in threaded view
|

Re: WAApplication isDeployed vs. deploymentMode

Yanni Chiu
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
Reply | Threaded
Open this post in threaded view
|

Re: Re: WAApplication isDeployed vs. deploymentMode

Philippe Marschall
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
Reply | Threaded
Open this post in threaded view
|

RE: Re: WAApplication isDeployed vs. deploymentMode

Bany, Michel
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
Reply | Threaded
Open this post in threaded view
|

Re: Re: WAApplication isDeployed vs. deploymentMode

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