On Thursday 18 of October 2007 14:45:21 Ate Douma wrote: > Matej Knopp wrote: > > Hi, > > > > isn't there a better way to detect if applicaiton is being run inside > > a portlat than checking for classes from portlet-api on classpath? > > At filter or servlet init time? Not that I know... > The only sure way of knowing this is either specifying this through init > parameters or delaying the portlet specific initialization until the first > portlet request coming through. > > "Hard configuring" to use/initialize for a portlet context through init > parameters seems logical, but it makes dual usage of a wicket app war for > both portlet and servlet environment without having to change the web.xml > impossible (e.g. like for wicket-examples). So I'd rather not go that > route. The automatic detection of portlet environment may be good for some examples and presentations, but for real-life applications it is important to be in an absolute control of this behavior.
I suggest a three state init parameter (non-portlet / portlet / autodetect) and 'autodetect' could be the default option. What do you think? Regards, Bendis > > Delayed initialization until the first portlet request can easily be done > of course, but I'm not sure of the consequences/side-effects of changing > the rendering strategy that late in the game, after which *servlet* based > requests even may already have been served... > > Do you have an opinion on this? > > If we need to change this (and I agree the current implementation is a bit > too crude), my preference would be the delayed initialization. > > Ate > > > If someone puts portlet-api by accident to classpath, wicket thinks it's > > running in portlet environment, which have certain consequences, e.g. > > the rendering strategy is REDIRECT_TO_RENDER, which is not really > > preferred for non-portlet applications. > > > > -Matej
signature.asc
Description: This is a digitally signed message part.
