Re: PageFlowScopeProvider development request

[Michael Kurz <mi...@gmx.at>]

Hi,

I created an issue some time ago for this [1] including a description of 
the original problem and some first implementation snippets. Those 
snippets do not exactly fit the window manager api that is already part 
of Trinidad. So I really wonder if an implementation of this api is 
already floating around somewhere. As the api exists I guess that 
somebody must have an idea why it was built that why and how the 
implementation should look like. Some code would be very welcome.

regards
Michael

Am 15.08.2010 21:15, schrieb Michael Kurz:
> Hi Blake,
>
> I will look into this issue for Mark. So far, I have already looked at
> some of the code involved here. Furthermore, I created a very basic
> WindowManager implementation for playing around. As support for windows
> is already implemented in the state handler, I managed to get a simple
> version up and running (just for simple post backs).
>
> I think the first challenge here is to get a bullet-proof window
> detection (if something like this is possible). Because if the state is
> stored per window and the current window is lost we will definitly run
> into problems (back button...).
>
> Do you already have some ideas or an implementation for this? I think
> you mentioned something like this a while ago.
>
> regards
> Michael
>
> Am 06.08.2010 20:12, schrieb Blake Sullivan:
>> Mark,
>>
>> I believe that what you really need is a default WindowManager
>> implementation in Trinidad. When a WindowManager is present, Trinidad
>> will store the view state under the windows and the view state can be
>> cleaned up when the window is closed.
>>
>> -- Blake Sullivan
>>
>> On 7/27/10 9:24 PM, Mark Badorrek wrote:
>>> Developers,
>>>
>>> I have a Trinidad application that has a few independant frames that
>>> operate in a non-modal fashion (The client needs tha app to work this
>>> way). All frames extensively use 'PageFlowScope'.
>>> Now PageFlowScope works well if you have a single frame, but gives no
>>> end of grief if you have multipe frames. This can be explained:
>>>
>>> Every time a user clicks on a page, Trinidad creates another viewstate
>>> object and shoves it onto the pageflowscope map. The map is stored in
>>> the HTTP session and is not limitless. You set the size of the map in
>>> web.xml. Once you start adding viewstates to an already-full map, the
>>> map starts discarding the oldest viewstates. Ususally this is not a
>>> problem (how many times could a user be expected to click the 'Back'
>>> button?) But if you have multiple frames, the user could spend
>>> 30minutes clicking in frame 'B', whilst the current viewstate of frame
>>> 'A' becomes older and older and eventually gets pushed out of the
>>> viewstate map. The the user clicks on frame 'A', the viewstate is not
>>> found and everything falls in a smoking mess.
>>>
>>> You can get around this by specifying a huge map-size in web.xml but
>>> this results in spectacular memory wastage for no really good reason.
>>> An alternative is to implement a new pageFlowScopeProvider that keeps
>>> separate maps for each frame. Trinidad does not have one of these
>>> out-of-the-box, but I have written one for my client. The problem is
>>> that it would be better to imlement this as a general solution in
>>> Trinidad so that others may benefit (and also that my client doesn't
>>> have to maintain it).
>>>
>>> I've not been involved in the project for a while but I'd like to get
>>> a solution in place for my client. Is there a preferred method to
>>> avoid the above problem? Or should the custome PageFlowScopeProvider
>>> be pursued?
>>>
>>> If the reccomendation is to pursue a custom pageFlowScopeProvider, my
>>> client (a government client) is happy to enter into a commercial
>>> arangement with a committer here. i.e. they will pay for a solution.
>>> Either to yourself of the Apache foundation etc. My code is available
>>> if it helps.
>>>
>>> Cheers,
>>>
>>> MarkB
>>>
>>>
>>> ********************************************************
>>> The information in this e-mail is intended for the named recipient only.
>>> It may contain privileged and/or confidential information. If you are
>>> not the intended recipient, you must not disclose, copy, distribute,
>>> take any action or reliance on it. If you have received this e-mail in
>>> error, please notify the sender immediately and delete this e-mail.
>>>
>>> Warning: E-mail transmission cannot be guaranteed to be secure or
>>> error-free. The recipient should check this email and any attachments
>>> for the presence of viruses. The sender does not accept liability for
>>> any errors or omissions in the contents of this message.
>>>
>>> ********************************************************
>>>
>>>
>>

Re: PageFlowScopeProvider development request

[Blake Sullivan <bl...@oracle.com>]

  The WindowManager JIRA covers the api and why it works that way.  More 
detailed information is available in the mail archives of the api 
discussion.

-- Blake Sullivan

On 9/13/10 2:38 AM, Michael Kurz wrote:
> Hi,
>
> I created an issue some time ago for this [1] including a description 
> of the original problem and some first implementation snippets. Those 
> snippets do not exactly fit the window manager api that is already 
> part of Trinidad. So I really wonder if an implementation of this api 
> is already floating around somewhere. As the api exists I guess that 
> somebody must have an idea why it was built that why and how the 
> implementation should look like. Some code would be very welcome.
>
> regards
> Michael
>
> Am 15.08.2010 21:15, schrieb Michael Kurz:
>> Hi Blake,
>>
>> I will look into this issue for Mark. So far, I have already looked at
>> some of the code involved here. Furthermore, I created a very basic
>> WindowManager implementation for playing around. As support for windows
>> is already implemented in the state handler, I managed to get a simple
>> version up and running (just for simple post backs).
>>
>> I think the first challenge here is to get a bullet-proof window
>> detection (if something like this is possible). Because if the state is
>> stored per window and the current window is lost we will definitly run
>> into problems (back button...).
>>
>> Do you already have some ideas or an implementation for this? I think
>> you mentioned something like this a while ago.
>>
>> regards
>> Michael
>>
>> Am 06.08.2010 20:12, schrieb Blake Sullivan:
>>> Mark,
>>>
>>> I believe that what you really need is a default WindowManager
>>> implementation in Trinidad. When a WindowManager is present, Trinidad
>>> will store the view state under the windows and the view state can be
>>> cleaned up when the window is closed.
>>>
>>> -- Blake Sullivan
>>>
>>> On 7/27/10 9:24 PM, Mark Badorrek wrote:
>>>> Developers,
>>>>
>>>> I have a Trinidad application that has a few independant frames that
>>>> operate in a non-modal fashion (The client needs tha app to work this
>>>> way). All frames extensively use 'PageFlowScope'.
>>>> Now PageFlowScope works well if you have a single frame, but gives no
>>>> end of grief if you have multipe frames. This can be explained:
>>>>
>>>> Every time a user clicks on a page, Trinidad creates another viewstate
>>>> object and shoves it onto the pageflowscope map. The map is stored in
>>>> the HTTP session and is not limitless. You set the size of the map in
>>>> web.xml. Once you start adding viewstates to an already-full map, the
>>>> map starts discarding the oldest viewstates. Ususally this is not a
>>>> problem (how many times could a user be expected to click the 'Back'
>>>> button?) But if you have multiple frames, the user could spend
>>>> 30minutes clicking in frame 'B', whilst the current viewstate of frame
>>>> 'A' becomes older and older and eventually gets pushed out of the
>>>> viewstate map. The the user clicks on frame 'A', the viewstate is not
>>>> found and everything falls in a smoking mess.
>>>>
>>>> You can get around this by specifying a huge map-size in web.xml but
>>>> this results in spectacular memory wastage for no really good reason.
>>>> An alternative is to implement a new pageFlowScopeProvider that keeps
>>>> separate maps for each frame. Trinidad does not have one of these
>>>> out-of-the-box, but I have written one for my client. The problem is
>>>> that it would be better to imlement this as a general solution in
>>>> Trinidad so that others may benefit (and also that my client doesn't
>>>> have to maintain it).
>>>>
>>>> I've not been involved in the project for a while but I'd like to get
>>>> a solution in place for my client. Is there a preferred method to
>>>> avoid the above problem? Or should the custome PageFlowScopeProvider
>>>> be pursued?
>>>>
>>>> If the reccomendation is to pursue a custom pageFlowScopeProvider, my
>>>> client (a government client) is happy to enter into a commercial
>>>> arangement with a committer here. i.e. they will pay for a solution.
>>>> Either to yourself of the Apache foundation etc. My code is available
>>>> if it helps.
>>>>
>>>> Cheers,
>>>>
>>>> MarkB
>>>>
>>>>
>>>> ********************************************************
>>>> The information in this e-mail is intended for the named recipient 
>>>> only.
>>>> It may contain privileged and/or confidential information. If you are
>>>> not the intended recipient, you must not disclose, copy, distribute,
>>>> take any action or reliance on it. If you have received this e-mail in
>>>> error, please notify the sender immediately and delete this e-mail.
>>>>
>>>> Warning: E-mail transmission cannot be guaranteed to be secure or
>>>> error-free. The recipient should check this email and any attachments
>>>> for the presence of viruses. The sender does not accept liability for
>>>> any errors or omissions in the contents of this message.
>>>>
>>>> ********************************************************
>>>>
>>>>
>>>