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.getVisit() in 4.1.
None of the approaches is perfect since Tapestry doesn't provide a
built-in end-of-request hook. Well, there is a call to
monitor.serviceEnd() that you could use without subclassing Engine.
Dobrin Ivanov wrote:
> 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 PROTECTED]> wrote:
>
>
>> 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
>> ServletRequestListener
>> {
>> public void
>> requestInitialized(ServletRequestEvent sre) {
>> // This method might not need to do
>> anything.
>> }
>>
>> public void requestDestroyed(ServletRequestEvent
>> sre)
>> {
>> // Call a static method in your
>> thread-storage class to get your
>> data.
>>
>> // The slightly messy part is getting the
>> Visit from the session.
>> HttpSession session =
>> sre.getServletRequest().getSession(false);
>> String visitKey = "state:" + appName +
>> ":visit";
>> Visit visit = (Visit)
>> session.getAttribute(visitKey);
>> }
>> }
>>
>> In your web.xml:
>>
>> <listener>
>>
>>
>>
> <listener-class>your.package.EventListener</listener-class>
>
>> </listener>
>>
>>
>> Dobrin Ivanov wrote:
>>
>>> 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 the
>>> thread and at the end of the request cycle I want
>>>
>> to
>>
>>> save it into the Visit object.
>>>
>>> --- Martin Strand <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>>
>>>> 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 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/hivedocs/config/tapestry.request.WebRequestServicerPipeline.html
>
>>>
>>>
>>>>> On 9/19/06, Dobrin Ivanov
>>>>>
>>>>>
>>>> <[EMAIL PROTECTED]> wrote:
>>>>
>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I want some advise of which is the best way to
>>>>>>
>>>>>>
>>>> catch
>>>>
>>>>
>>>>>> the end of the request cycly. I have tried it
>>>>>>
>>>>>>
>>>> using a
>>>>
>>>>
>>>>>> PageDetachListener, but the problem is that
>>>>>>
>>>>>>
>>>> sometimes
>>>>
>>>>
>>>>>> there is more than one page involved into the
>>>>>>
>>>>>>
>>>> request
>>>>
>>>>
>>>>>> cycle and then I get more than one invocation
>>>>>>
>> on
>>
>>>>>>
>>>>>>
>>>> the
>>>>
>>>>
>>>>>> pageDetached(...).
>>>>>> So I'm wondering if overriding the Engine's
>>>>>> service(...) method is the best place?
>>>>>>
>>>>>> Thanks and best regards,
>>>>>> Dobrin
>>>>>>
>>>>>>
>>>>
>>>>
> ---------------------------------------------------------------------
>
>>>
>>>
>>>> To unsubscribe, e-mail:
>>>> [EMAIL PROTECTED]
>>>> For additional commands, e-mail:
>>>> [EMAIL PROTECTED]
>>>>
>>>>
>>>>
>>>>
>>> __________________________________________________
>>> Do You Yahoo!?
>>> Tired of spam? Yahoo! Mail has the best spam
>>>
>> protection around
>>
>>> http://mail.yahoo.com
>>>
>>>
>>>
> ---------------------------------------------------------------------
>
>>> To unsubscribe, e-mail:
>>>
>> [EMAIL PROTECTED]
>>
>>> For additional commands, e-mail:
>>>
>> [EMAIL PROTECTED]
>>
>>>
>>>
>>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
