> > the only inelegant bit is this visitKey assembling
> > part may be :)
> >
> > --- James Carman <[EMAIL PROTECTED]>
> wrote:
> >
> >
> >> Sorry. Try
> >> tapestry.request.WebRequestServicerPipeline. As
> I
> >> said
request.WebRequestServicerPipeline. As I
>> said, it was
>> off the top of my head. Sorry for the typo.
>>
>> -----Original Message-----
>> From: Dobrin Ivanov
>> [mailto:[EMAIL PROTECTED]
>> Sent: Friday, September 22, 2006 1:45 PM
>> To: Tapestry
Message-
> From: Dobrin Ivanov
> [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 22, 2006 1:45 PM
> To: Tapestry users
> Subject: RE: How to listent for the Request Cycle
> End
>
> 10x
>
> Now i get the error below. Any chance that there are
> some d
AIL PROTECTED]
> Sent: Friday, September 22, 2006 1:26 PM
> To: Tapestry users
> Subject: RE: How to listent for the Request Cycle
> End
>
> And where should be located my hivemodule.xml? (I'm
> using just Tapestry, I know it lies above hivemind
> microkernel...)
&g
ED]
> Sent: Friday, September 22, 2006 1:26 PM
> To: Tapestry users
> Subject: RE: How to listent for the Request Cycle
> End
>
> And where should be located my hivemodule.xml? (I'm
> using just Tapestry, I know it lies above hivemind
> microkernel...)
>
>
>
ailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 20, 2006 1:30 PM
> To: Tapestry users
> Subject: Re: How to listent for the Request Cycle
> End
>
> I do not know about this custom Engine classes
> changes
> (frowned)...
> is there some information about this top
op of my head, but you get the idea.
> This basically acts
> like a servlet filter, but you can plug
> hivemind-managed filters in (so you
> can inject stuff into your implementation objects).
>
>
> -Original Message-
> From: Dobrin Ivanov
> [mailto:[EMAIL PROTEC
his basically
>> acts
>> like a servlet filter, but you can plug hivemind-managed filters in (so
>> you
>> can inject stuff into your implementation objects).
>>
>>
>> -----Original Message-
>> From: Dobrin Ivanov [mailto:[EMAIL PROTECTED]
>> Sent: We
nd-managed filters in (so
you
can inject stuff into your implementation objects).
-Original Message-
From: Dobrin Ivanov [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 20, 2006 1:30 PM
To: Tapestry users
Subject: Re: How to listent for the Request Cycle End
I do not know about this
stent for the Request Cycle End
I do not know about this custom Engine classes changes
(frowned)...
is there some information about this topic?
.. and also the other one with the
pipelines/WebRequestServicerPipeline/interceptors?
--- James Carman <[EMAIL PROTECTED]> wrote:
> You can
I do not know about this custom Engine classes changes
(frowned)...
is there some information about this topic?
.. and also the other one with the
pipelines/WebRequestServicerPipeline/interceptors?
--- James Carman <[EMAIL PROTECTED]> wrote:
> You can plugin to the webrequest servicer pipeli
You can plugin to the webrequest servicer pipeline.
> Ummm... you could do that too. You're correct that it would avoid the
> visit-from-session inelegant bit. It would be conceptually similar to
> the servlet filter approach. The downside would be that custom Engine
> classes are frowned upon
Ummm... you could do that too. You're correct that it would avoid the
visit-from-session inelegant bit. It would be conceptually similar to
the servlet filter approach. The downside would be that custom Engine
classes are frowned upon as Tapestry goes forward. I'm not sure there
is an Engine.ge
Hi,
Thanks Bryan, this looks like a hack:)
What do you think if I override the Engine's method:
public void service(WebRequest request, WebResponse
response) throws IOException {
super.service(request, response);
// insert code here
}
Is this a bad approach?
--- Bryan Lewis <[EMAIL PROT
It sounds like a servlet listener method could work for you. Or a
servlet filter as in the previous suggestion. Both would give you a
hook into the end-of-request, and you can get to the Visit via the
session. Here's a listener approach.
public class EventListener implements ServletRequestList
I have designed some small API in order to provide the
session persistance of the presentation layer
(Tapestry - Visit object/HttpSession) to the model
layer (in order to be able to cache some session
related stuff without being aware of how the above
layer is doing it). So the data is attached to
Exactly what do you need this for?
If you don't need any Tapestry logic, there might be other ways to do it -
like a servlet filter or a threaded service that implements Discardable.
On Tue, 19 Sep 2006 21:58:20 +0200, Jesse Kuhnert <[EMAIL PROTECTED]>
wrote:
It might not be super fun to l
It might not be super fun to learn, but I think the "tapestry" way of doing
this would be to contribute something to the WebRequestServicerPipeline so
that you know definitively when the cycle ends regardless of what
services/engines are involved..
http://tapestry.apache.org/tapestry4/tapestry/hi
18 matches
Mail list logo
