Yes. Form posts would as default be treated as "return to the same page as you had" instead of "go to this new page that happens to be the same as the one we where just on". At least, that should be it. I haven't been able to test it perfectly yet, I'll have better information tomorrow.
On Oct 8, 9:33 pm, The Editor <[email protected]> wrote: > Are you talking about changing this in the forms markup function? > Would we gain functionality we don't already have? > > Cheers, > Dan > > On Thu, Oct 8, 2009 at 1:38 PM, DrunkenMonk <[email protected]> wrote: > > > If "action=<the current page>" is replaced by: > > > <form action='".$_SERVER['php_self']."' method='post'> > > > Everything should work with post and update, always and forever. There > > may be problems with it remembering the '&action=' in the url, so one > > does not automatically return from action pages, but I think we can > > get around this. > > > So, replace $scriptURL$pageLink with $_SERVER['php_self'] and we get > > "post and update" functionality automatically, without influencing > > [nextpage]. > > > I do hope everyone can see what a bonus this would be, but I'm > > prepared to explain it better when I have more time. > > > On Oct 6, 8:57 pm, The Editor <[email protected]> wrote: > >> You'll have to do the research on this DM. I really don't know how to > >> do what you want. If I can make a simple, secure change to the core, > >> I'm happy to. So far we have done absolutely nothing with frames. > >> Haven't had a need, but I think what you are suggesting may be > >> possible. But here are some problems: > > >> 1) If your main skin has a frame calling two BoltWire pages, both > >> those will have frames in them unless somehow they are given different > >> skins. Perhaps a php trigger which loads the main skin the first time, > >> and a real skin/invisible skin the second time. It might be easier to > >> setup an iframe that is small and virtually invisible... > > >> 2) You can change the action parameter in the form to target the > >> invisible frame perhaps but I don't think that's how html works. I > >> think the form submission would insert the output of the action into > >> the current frame. Giving you two invisible frames. > > >> Anyway, good luck! > > >> Cheers, > >> Dan > > >> On Tue, Oct 6, 2009 at 12:40 PM,DrunkenMonk<[email protected]> wrote: > > >> >> Is there no way to automate > >> >> the page creation process using some kind of template that gives > >> >> anchors? > > >> > No. I've got a list of items that have been marked as "active". For > >> > each item, there is a box for "number of items that have been carried > >> > from storage to the pub" and a box for "number of boxes of item that > >> > have been carried from storage to the pub". You enter as many items as > >> > you wish, now and again saving to protect yourself from time-outs. So > >> > multiple items are updated on each post, and the position of the page > >> > is random. > > >> >> I don't think we can solve this one DM. > > >> > I can think of one way: > >> > Stage one: > >> > Use the post request to generate a page that is ignored (javascript > >> > has void or something for this, doesnt it? HTML has a frame of zero > >> > size). You post a request, but your browser does not move. > >> > This can be done with links, so why shouldnt it be doable with forms? > >> > Stage two: > >> > use javascript or something to make a "reload page" call. > > >> > I just don't know how to do this. Or, rather, I think I can make a > >> > button perform an "on activate, reload page" thing. I don't know how > >> > to make BoltWire retarget the post request to a zero-width frame. > > >> > On Oct 6, 4:31 pm, The Editor <[email protected]> wrote: > >> >> This will not work because of a security feature in BoltWire. > >> >> Basically, all session inputs have to be generated by a fresh page > >> >> load. Which saves the session value of course. To reload a page will > >> >> regenerate the same html, but not the session values which must be > >> >> stored on the server. It is also not really possible to reset those > >> >> session values, because the back button never notifies the server the > >> >> page has been reloaded. > > >> >> I don't think we can solve this one DM. Is there no way to automate > >> >> the page creation process using some kind of template that gives > >> >> anchors? > > >> >> Cheers, > >> >> Dan > > >> >> On Tue, Oct 6, 2009 at 10:22 AM,DrunkenMonk<[email protected]> wrote: > > >> >> > A while ago I requested a way to ensure browsers returned to the same > >> >> > page. It turned out that much of the problem was that Firefox 3.0-3,1 > >> >> > had a bug regarding positioning on pages, and I just about managed to > >> >> > solve the issue with a "back" javascript function. > > >> >> > I now have a similar problem, in that I want to hit "submit" and not > >> >> > be placed at the top of the same page. > >> >> > This is doable with a simple "back" statement, but this invalidates > >> >> > form input. > > >> >> > I submit a form and return to the same page from which i sent it. > > >> >> > if I simply leave out nextpage, I am left at the top of the page with > >> >> > functioning form input. > >> >> > I can "save an continue" without problems, but I am moved to the top > >> >> > of the page. > > >> >> > if I add a "back" function, I am left where I was, but further form > >> >> > input is invalidated since the form is not reloaded. > > >> >> > I guess what I want to do is post information, ignore the page update > >> >> > and then reset form inputs. possibly reload the page. > > >> >> > Anyone know how? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "BoltWire" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/boltwire?hl=en -~----------~----~----~----~------~----~------~--~---
