This is an answer that I posted on another topic, but I think that is
exactly the same in this case: (consider .php files  = your .do files)

I will try to explain this as simple as I can.

First, the content generated by php files is dynamic content. php
files contain only basic html code and rest is generated based on
parameters sent to server, content of the session, or any other
"variables" in the system.
Examples:
Calling my_nice_php_file.php or my_nice_php_file.php?show=lastMonth or
my_nice_php_file.php?show=welcome_screen could be ENTIRELY different
pages

One method to get those files offline is to cache in manifest ALL
possible parameters combination and set IgnoreQuery
 to false. This means that your manifest should contain a record for
each possible query combination for each file. In our example, willl
be 3 entries for my_nice_php_file.php file.
This could be a tedious work and result into a huge manifest (imagine
a page were a daily report is generated based on the day passed as a
get parameter and the report is available from last 15 years).

This method solves only partial you problem. If there are files that
need POST parameters to generate the content or use things stored in
session, then this method will not work. To have this functionality
offline, you have to reproduce it in java script code. Depends of the
complexity of the web application this is ranged from very simple to
real complex js programming.

On Mar 31, 5:17 pm, "[email protected]" <[email protected]> wrote:
> I was able to get it to capture the inbox and some javascript and css
> files as well.  What else needs to be done to get the dynamic content
> to display?  Is there documentation somewhere you can point me to?
>
> On Mar 31, 1:41 am, Eduard Martini <[email protected]> wrote:
>
> > I you want us to help, give more details.
> > If you call in console:
> > store.enabled
> > store.lastErrorMessage
> > store.canServeLocally("/emailsystem/inbox.do")  (btw your manifest
> > file should contain "/emailsystem/inbox.do").
>
> > Also, if inbox.do is a dynamic generated page based on the session
> > variables (user that is logged in, customised view, etc) you may need
> > to do a bit more work, but capture should work anyway.
>
> > On Mar 30, 5:25 pm, "[email protected]" <[email protected]> wrote:
>
> > > That didn't work either.  Anybody have any other ideas?

Reply via email to