This isn't cache, except PerForm's internal. Or maybe mod_perl lexical closure issue?
Apparently only *some* of the values are maintained by PerForm. For example, I have a Title, Keywords, Description, and URL dialog. If I hit "submit" on the blank returned form (after it's submitted the first time), then my validators die saying that Keywords and Description are required. Title and Description are then filled in. Any cache would cache all those values. -- Ryan ----- Original Message ----- From: "Tod Harter" <[EMAIL PROTECTED]> To: "Riley James" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, October 03, 2002 6:05 AM Subject: Re: PerForm *too* sticky > On Thursday 03 October 2002 02:19 am, Riley James wrote: > > I don't trust IE (particularly) as far as I can spit in terms of its caching > strategy... I've seen it (and NS/Mozilla too for that matter) cling onto old > data for dear life in spite of everything you would think to the contrary. I > can't say EXACTLY what the conditions are which bring that about, but I feel > reasonably confident in saying that every web site developer has had the same > experience of the "page that will not update". Its frustrating. > > As for cache control directives they were really designed with proxies in > mind more than user agents. They are also all HTTP 1.1 features which are > only semi-supported in the real world (there is no 1.1 compliant browser as > of yet). I don't know ALL the gory details as things change constantly but > the last I researched this NS/IE are still in the land of "1.0 with some 1.1 > features" like pipelined requests, but that doesn't mean they ACTUALLY do > proper cache control. > > Still, with your cache flushed and disabled it shouldn't be a problem. The > next culprit would be actual proxies in the path of your request. Those could > be either forward or reverse proxies, and sometimes you may not even be aware > of them. ISPs will do stupid stuff like installing "accelerators" and > sometimes bulk hosting firms do strange things as well. Obviously the test > is to be in your own lab... > > Finally, I think resubmitting forms to themselves is just a crappy idea > personally. I know it sounds great, but this is exactly why I don't use > PerForm. It can be a useful trick, but a form package that ONLY lets you do > that is too limited for my taste... > > > Well, at first I really didn't think that was it. But I wanted to be sure, > > so I started doing some research on IE and it's caching of POST data. > > Apparently it does cache the post data if you utilize get data as well. In > > other words: > > > > <form action="/form.xsp?stuff=whatever" method="post" /> > > > > I'm not doing that, but I still wasn't comfortable. So I began utilizing > > the 'cache-control: no-cache' header, as documented via > > http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q234067&;. That > > didn't solve it, so I hit it with Netscape 7. Still no results. > > > > Netscape 7 has a nifty feature of 'View->Page Info'. In this dialog it says > > explicitly, "Source: (not cached)". > > > > So I know that it's not caching the page source. > > > > But I don't think it's caching the post data either. I've taken all the > > steps I know of to eliminate that possibility, and AFAIK browsers don't > > really cache that data, because it's obvious that you wouldn't want to > > always resubmit the same info to a form. IE explicitly asks you if you want > > to resubmit the same data. > > > > Additionally, my entries into the field would override any POST cache. > > Wouldn't it? > > > > ----- Original Message ----- > > From: "Tod Harter" <[EMAIL PROTECTED]> > > To: "Riley James" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > > Sent: Tuesday, October 01, 2002 4:55 AM > > Subject: Re: PerForm *too* sticky > > > > > On Monday 30 September 2002 11:09 pm, Riley James wrote: > > > > > > It HAS to be a browser cache problem IMHO. > > > > > > I can think of many ways it could happen, but all of them involve some > > > > sort > > > > > of misconfigured or malfunctioning software. I'd start out by testing > > > with > > > > a > > > > > client that does no caching and is running either on or very close to the > > > > box > > > > > serving the pages. That eliminates most variables. > > > > > > From there I'd test from other locations and with other client > > > > applications > > > > > and try to isolate it down to one specific element in the equation. Then > > > > you > > > > > can figure out what the fix is. > > > > > > > I must assume that either I'm doing something so stupid and obvious > > > > that > > > > no > > > > > > one can believe it, or that no one else has any answers to this. Either > > > > is > > > > > > fine, I just need to know which one... > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Riley James" <[EMAIL PROTECTED]> > > > > To: <[EMAIL PROTECTED]> > > > > Sent: Tuesday, September 24, 2002 12:36 PM > > > > Subject: Re: PerForm *too* sticky > > > > > > > > > I call /stylesheets/general.xsl which <xsl:include>'s > > > > perform_html.xsl. > > > > > > > I am using the perform_html.xsl that comes with PerForm but with > > > > slight > > > > > > > modification. I've added 2 attributes to the PerForm tags, tdlabel > > > > > and calendar. Since I couldn't wrap the perform tags in a table in > > > > > the > > > > XSP, > > > > > > and > > > > > > > > > adding the table in XSL didn't allow me to know the display name of > > > > each > > > > > > > field, I've got tdlabel. This turns: > > > > > > > > > > <f:textfield name="test" tdlabel="This is a test" /> > > > > > > > > > > into > > > > > <tr> > > > > > <th>This is a test: </th> > > > > > <td><input type="text" name="test"></td> > > > > > </tr> > > > > > > > > > > And the entire thing is always wrapped in a uniform table. This suits > > > > my > > > > > > > needs for the type of intranet site I'm building. > > > > > > > > > > The calendar attribute is applied only to textfield's and simply > > > > > tells the stylesheet to tie a javascript popup calendar to that > > > > > textfield. > > > > I've > > > > > > > attached the perform_html.xsl stylesheet. > > > > > > > > > > ----- Original Message ----- > > > > > From: "Matt Sergeant" <[EMAIL PROTECTED]> > > > > > To: "Riley James" <[EMAIL PROTECTED]> > > > > > Cc: <[EMAIL PROTECTED]> > > > > > Sent: Monday, September 23, 2002 12:36 PM > > > > > Subject: Re: PerForm *too* sticky > > > > > > > > > > > On Monday, Sep 23, 2002, at 17:06 Europe/London, Riley James wrote: > > > > > > > I've been experiencing an issue where PerForm seems to be > > > > > > > hyper-sticky, reprocessing the same form parameters over and over > > > > > > > even though they're being entered differently. > > > > > > > > > > > > > > This is happening inconsistently (it'll work long enough to make > > > > me > > > > > > > > > think it's not a problem, then I come back in a couple hours). > > > > > > > > > > > > > > For instance, I have an XSP page which is a very simple search. > > > > The > > > > > > > > > form posts to itself, and I'm using AxKit::XSP::IfParam along > > > > > > > with AxKit::XSP::AttrParam in the body to test for submission and > > > > output > > > > > > > > > the matching rows. The problem is that once I post the first > > > > > > > time, that's it. This persists when I leave the page and come > > > > > > > back, but > > > > I > > > > > > > > > haven't tested it methodically enough to determine an actual > > > > pattern. > > > > > > > > > I'm not using any session handling AxKit libraries. > > > > > > > I'm not getting any errors with AxLogLevel at 10. > > > > > > > All is from CVS, 3 days old. > > > > > > > > > > > > > > Has anyone else experienced this? > > > > > > > > > > > > > > -- Ryan > > > > > > > > > > > > > > <?xml version="1.0"?> > > > > > > > <?xml-stylesheet href="." type="application/x-xsp"?> > > > > > > > <?xml-stylesheet href="/stylesheets/general.xsl" > > > > > > > type="text/xsl"?> > > > > > > > > > > > > Are you also using the included XSLT that comes with PerForm? > > > > > > Matt. > > > > > > --------------------------------------------------------------------- > > > > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > ------------------------------------------------------------------------- > > >- > > > > - > > > > > >- ---- > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
