if
you're keeping them on a single page for your entire process and
rendering the wizard process in js, then you won't be transitioning
across pages, so you won't be burning your cache. at that point, all
that matters is that your session is kept alive. AjaxBusyIndicator
doesn't ping -- it just shows a spinner when an ajax function is
occurring ... AjaxPing (iirc) is the component you want? I'm not in
that workspace right now, so I don't have it handy ...
ms On Jul 8, 2009, at 3:37 PM, shravan kumar wrote:
Hi Mike,
Thanks
for your response Mike. I hope you are referring to "AjaxBusyIndicator"
in the Wonder/Ajax Examples for ping in the background.
As you
say, "Yes, if you bind to an action that falls out of the backtrack
cache, you'll get that error. This can happen for several reasons.", do
we have any good solution to get away from this issue and keep all my
elements/ actions in my component up-to-date?
Thank You,
Shravan Kumar. M
------------------------------------
Wednesday, July 8, 2009 7:02 PM
From:
"Mike Schrag" <email@hidden>
To:
"WO Dev Group" <email@hidden>
Yes, if you bind to an action that falls out of the backtrack cache, you'll get that error. This can happen for several reasons.
Not
sure what you mean about using component actions and direct actions
freely. Component actions are powerful but just have intrinsic
limitations. If you have a long running process on the client side that
could reasonably run longer than your session timeout, you either have
to keep the session alive with some sort of ping in the background (I
think Ajax framework has a component for this), or you need to switch
to direct actions. DA's can fully access the session, but you have the
same issue -- if your client process takes longer than your session
lifetime, you're going to lose that information. In the DA case, that
either means the same sort of ping process, or it means making your app
stateless (i.e. client side tracks and passes in the current state).
ms
On Jul 8, 2009, at 2:01 AM, shravan kumar wrote:
Thanks for your response Mike.
What is Giandiua btw? Google says it is a Chocolate from Italy!!!
The
page am referring is just one of the pages of a wizard, which has
sub-pages. The whole wizard runs through component actions.
I was actually about following situation:
When
we have long response component displayed upon initiating a request,
and we see long response until we have a response. Once after the
response let's say I just hide long response component and show the
main component, now user cannot perform any actions in this main
component and we might receive errors like: You have exceeded 30 pages
limit/ page out of cache... this is because the context bound to the
action element is older. Am I correct (Mike) ?
I understand by
your saying switching to direct actions, we can get away from this
issue if we use direct actions. But am wondering if I can use component
actions and direct actions freely. I hope I can validate whether the
direct action request is initiated by a logged-in valid user, so my
direct actions are not floating freely.
---------------
If I use component actions, can you advise me how can I have all the elements, app in the latest context?
Thank You,
Shravan Kumar. M
--------------------------------------
Monday, July 6, 2009 7:14 PM
From:
"Mike Schrag" <email@hidden>
To:
"WO Dev Group" <email@hidden>
seems
to me like you're swimming against the tide here ... i think you need
to rethink this architecture. you're basically sending the users the
entire site, which makes this more of a Sproutcore/Giandiua/etc
workflow, and mixing component actions into this style of app is going
to be very tricky. I would recommend switching to directactions. you
could keep a session alive with a ping if you really need it to be
sessionful, but trying to actually use WOForms in this thing is going
to be an endless headache imo.
On Jul 6, 2009, at 7:54 AM, shravan kumar wrote:
> Hi Group,
>
> Could you please advise me a solution to achieve below functionality:
>
> Scenario:
> -------------
>
>
I have a page which gets all the data like text content [3000 lines or
more], images info [about 500 or more] once when the user requests for
this page.
>
> Once this data from the server has arrived,
we will be displaying this whole data part by part by splitting this
data into sub-pages through _javascript_. So, user actually sees the
sub-page rather the whole page received from the server.
>
> There can be around 40 sub-pages or more.
>
>
While navigating through each of these sub-pages user may perform a
server action like edit some text and save, rotate an image and save,
... and all these actions do not refresh the whole page/ sub-page (like
we see in ajax implementations) and just update a particular field.
>
> I assume that there might be some time-gap say 10 minutes or more between each of the server actions performed by the user.
>
>
During these times as you know, we have to maintain the session of this
user in the server (this can be achieved through lets say session
timeout value), state of this page in the server, ...
>
> Problem:
> -------------
>
How can I maintain the state of this page (generally whenever we do a
submit WO app returns with a new context info, correct?), so all my
actions are valid and there are issues of Broken pipe/ page not in the
cache/ ...
>
> I thought of just pinging the server every
few seconds for some dummy data like: how are you doing? or something
like gmail does? However, I do not know how to exactly implement this
|
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
|