That is indeed what i mean. This request of mine does not touch the
wicket request cycle. And yes i could check for all individual classes
of the errorpages used internally by wicket (2 or 3 classes). So its
not a big problem but it certainly would be easier and i am sure
sooner or later someone else could really use this too.
Maurice
2005/11/30, Johan Compagner <[EMAIL PROTECTED]>:
> What maurice i think means is that inside its security it wants to check if
> the page was an error page yes or no.
> It doesn't have anything to do with the strategies or requesttargets.
>
> But for now maurice can do it themself by using there own internalerrorpage
> and check for that one. (that one specific or what it implements)
> But then he also needs to check for our 2 exception pages.
>
>
>
> On 11/30/05, Eelco Hillenius <[EMAIL PROTECTED] > wrote:
> > I really don't think all this is needed anymore. Could you please take
> > a look at those request cycle refactorings?
> >
> > In IRequestCycleProcessor there is a special respond method:
> >
> > /**
> > * Whenever a unhandled exception is encountered during the
> processing of a
> > * request cycle, this method is called to respond to the request
> in a
> > * proper way.
> > *
> > * @param e
> > * any unhandled exception
> > * @param requestCycle
> > * the current request cycle
> > */
> > void respond(Exception e, RequestCycle requestCycle);
> >
> > and if you are going to use CompoundRequestProcessor (which probably
> > is a good idea since that let's you plug in just the parts you want),
> > there is interface:
> >
> > /**
> > * Strategy interface for implementing
> > * [EMAIL PROTECTED]
> wicket.request.compound.AbstractCompoundRequestCycleProcessor#respond(Exception,
> > RequestCycle)}.
> > *
> > * @author Eelco Hillenius
> > */
> > public interface IExceptionResponseStrategy
> > {
> > /**
> > * Whenever a unhandled exception is encountered during the
> processing of a
> > * request cycle, this method is called to respond to the request
> in a
> > * proper way.
> > *
> > * @param requestCycle
> > * the current request cycle
> > * @param e
> > * an uncaught exception
> > */
> > void respond(RequestCycle requestCycle, Exception e);
> > }
> >
> >
> > You can literally do anything you want in this strategy.
> >
> > Eelco
> >
> >
> > On 11/30/05, Maurice Marrink <[EMAIL PROTECTED]> wrote:
> > > One usage is like i said in IAuthorizationStrategy. Most of the time
> > > you want errorpages to always be able to be constructed. Ofcourse if
> > > you are using jaas you can also put them in your policy, but having a
> > > tagging interface for different types of pages (in this case
> > > errorpages) is always a good idea.
> > > And if we use a tagging interface we can indeed remove the isErrorPage
> method.
> > > just my thoughts.
> > >
> > > Maurice
> > >
> > > 2005/11/29, Johan Compagner < [EMAIL PROTECTED]>:
> > > > i see we only do it the Class check way we already had and that is
> fine by
> > > > me
> > > > (so currentResponsePage != internal or exceptionpage then respond else
> send
> > > > servlet error)
> > > >
> > > >
> > > > Now the question remains where do you need info that it is a error
> page.
> > > > Because it is just wickets own pages or the one the developer itself
> says it
> > > > is (InternalError page)
> > > >
> > > > johan
> > > >
> > > >
> > > >
> > > > On 11/29/05, Johan Compagner < [EMAIL PROTECTED]> wrote:
> > > > > Page.isErrorPage () isn't called anymore no
> > > > > But how do we catch it now when a page that was the error page is
> > > > failing??
> > > > >
> > > > >
> > > > > johan
> > > > >
> > > > >
> > > > >
> > > > > On 11/29/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > > > > > dont know, havent had the time to go through all the changes yet.
> > > > > > -Igor
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 11/29/05, Eelco Hillenius < [EMAIL PROTECTED]> wrote:
> > > > > > > Actually, I don't think we need such a method nor a tagging
> interface
> > > > > > > at all after the refactorings?
> > > > > > >
> > > > > > > Eelco
> > > > > > >
> > > > > > >
> > > > > > > On 11/29/05, Johan Compagner <[EMAIL PROTECTED] > wrote:
> > > > > > > > i agree and i also find that a much better approache
> > > > > > > > especially because you can check the class instead of an
> instance of
> > > > it.
> > > > > > > >
> > > > > > > > johan
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On 11/29/05, Igor Vaynberg < [EMAIL PROTECTED] > wrote:
> > > > > > > > > if we create a tagging interface there is no longer a need
> for
> > > > > > > > iserrorpage()
> > > > > > > > >
> > > > > > > > > -Igor
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 11/29/05, Maurice Marrink < [EMAIL PROTECTED]> wrote:
> > > > > > > > > > I know Page has an isErrorPage method to identify
> errorpages
> > > > from
> > > > > > > > > > normal pages, but if you only have the classname of the
> page
> > > > (for
> > > > > > > > > > example in
> > > > > > > >
> IAuthorizationStrategy.allowCreateComponent(Class
> > > > clz))
> > > > > > > > > > that is not enough.
> > > > > > > > > > Therefore i would like to suggest a tagging interface (say
> > > > ErrorPage)
> > > > > > > > > > that all pages the return true for isErrorPage should
> implement.
> > > > So we
> > > > > > > > > > can easilly distinct between the different pagetypes.
> > > > > > > > > >
> > > > > > > > > > Maurice
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > >
> -------------------------------------------------------
> > > > > > > > > > This SF.net email is sponsored by: Splunk Inc. Do you grep
> > > > through log
> > > > > > > > files
> > > > > > > > > > for problems? Stop! Download the new AJAX search engine
> that
> > > > makes
> > > > > > > > > > searching your log files as easy as surfing the web.
> DOWNLOAD
> > > > SPLUNK!
> > > > > > > > > >
> > > > http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
> > > > > > > > > >
> _______________________________________________
> > > > > > > > > > Wicket-develop mailing list
> > > > > > > > > > [email protected]
> > > > > > > > > >
> > > > > > > >
> > > >
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > >
> -------------------------------------------------------
> > > > > > > This SF.net email is sponsored by: Splunk Inc. Do you grep
> through log
> > > > files
> > > > > > > for problems? Stop! Download the new AJAX search engine that
> makes
> > > > > > > searching your log files as easy as surfing the web. DOWNLOAD
> > > > SPLUNK!
> > > > > > >
> http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
> > > > > > > _______________________________________________
> > > > > > > Wicket-develop mailing list
> > > > > > > [email protected]
> > > > > > >
> > > >
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> > > for problems? Stop! Download the new AJAX search engine that makes
> > > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> > > http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
> > > _______________________________________________
> > > Wicket-develop mailing list
> > > [email protected]
> > >
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> > >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> > for problems? Stop! Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> > http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
> > _______________________________________________
> > Wicket-develop mailing list
> > [email protected]
> >
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> >
>
>
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
