Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 7 of 7 total
Thread Removing part of the URL
Sun, Jan 4 2015 4:22 AMPermanent Link

Matthew Jones

I'm getting PayPal working on my web shop, and it's all just fine,
despite having to throw away my whole application when handing over to
PayPal. When PayPal redirects back, the application "knows" that it is
to continue the interaction by the URL, which is like this:

https://m1.banxia.com/?paypalcomplete=1

My code then changes it to:

https://m1.banxia.com/?paypalcomplete=1#login

Now, what I'd really like to do is remove the "paypalcomplete" part
from the browser address display. If I use
  Window.Location.Replace('https://' + m_szHostAddress);
then it does a complete refresh - not what I want as the application
then doesn't know anything.

Anyone know if this is even possible, and if so, what term do I need to
search for, or browser property to edit?

I can live with it as-is, but I'd rather not have the user bookmark
this address.

--

Matthew Jones
Thu, Jan 8 2015 5:24 PMPermanent Link

Rick

On 04/01/15 20:22, Matthew Jones wrote:
> I'm getting PayPal working on my web shop, and it's all just fine,
> despite having to throw away my whole application when handing over to
> PayPal. When PayPal redirects back, the application "knows" that it is
> to continue the interaction by the URL, which is like this:
>
> https://m1.banxia.com/?paypalcomplete=1
>
> My code then changes it to:
>
> https://m1.banxia.com/?paypalcomplete=1#login
>
> Now, what I'd really like to do is remove the "paypalcomplete" part
> from the browser address display. If I use
>     Window.Location.Replace('https://' + m_szHostAddress);
> then it does a complete refresh - not what I want as the application
> then doesn't know anything.
>
> Anyone know if this is even possible, and if so, what term do I need to
> search for, or browser property to edit?
>
> I can live with it as-is, but I'd rather not have the user bookmark
> this address.
>

Matthew, is it possible to work with PayPal in an iframe (TPage)? I
haven't used it but I suspect that it wants to take over the entire
document. If it does work in an iframe then that might let you avoid a
reload.

Failing that, the following links talk about altering the URL without
reloading the page.

http://stackoverflow.com/questions/824349/modify-the-url-without-reloading-the-page

http://stackoverflow.com/questions/3338642/updating-address-bar-with-new-url-without-hash-or-reloading-the-page

http://spoiledmilk.com/blog/html5-changing-the-browser-url-without-refreshing-page/


--
Rick
Fri, Jan 9 2015 4:08 AMPermanent Link

Matthew Jones

Rick wrote:

> Matthew, is it possible to work with PayPal in an iframe (TPage)? I
> haven't used it but I suspect that it wants to take over the entire
> document. If it does work in an iframe then that might let you avoid
> a reload.

Not from what I've seen, in all the purchases I've done over the years,
it is always full screen. With the Verified by Visa, I do use an
iFrame(TPage), but that is designed that way.

I will follow up the links - thank you.

Also, I just thought I could easily stick a flag in the local storage,
then refresh, then read the local storage and carry on. By doing it
immediately, the user wouldn't notice so much. I'd prefer a nicer way
though.

--

Matthew Jones
Fri, Jan 9 2015 7:28 AMPermanent Link

Uli Becker

Matthew,

how about storing the payment progress in your database and loading the maching pages?

Uli
Fri, Jan 9 2015 7:52 AMPermanent Link

Matthew Jones

Uli Becker wrote:

> how about storing the payment progress in your database and loading
> the maching pages?

The database does indeed have the status, and the EWB app picks that
up, but the browser got redirected to my app with the ?paypal
parameter. If the user then bookmarks the page, as I dream they might,
I don't want the parameter there.

Rick's URLs seem to have the answer, but I've not had time to play yet.


--

Matthew Jones
Tue, Feb 3 2015 8:46 AMPermanent Link

Matthew Jones

Rick wrote:

> Failing that, the following links talk about altering the URL without
> reloading the page.
>
>
http://stackoverflow.com/questions/824349/modify-the-url-without-reloading-the-page
>
>
http://stackoverflow.com/questions/3338642/updating-address-bar-with-new-url-without-hash-or-reloading-the-page
>
>
http://spoiledmilk.com/blog/html5-changing-the-browser-url-without-refreshing-page/

FWIW, I got around to trying this, and the EWB framework doesn't have
window.history.pushState so I quickly gave up. Will try again in EWB2
sometime.

--

Matthew Jones
Thu, Feb 5 2015 8:11 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Matthew,

<< FWIW, I got around to trying this, and the EWB framework doesn't have
window.history.pushState so I quickly gave up. Will try again in EWB2
sometime. >>

The issue isn't really adding pushState/replaceState methods and the state
property - that's easy:

WebDOM unit:

  external THistory = class
     public
        { Properties }
        property length: Integer read;
        property state: TObject read;
        { Methods }
        procedure back;
        procedure forward;
        procedure go(relative_position: Integer);
        procedure go(const target_string: String);
        procedure pushState(stateObj: TObject; const title: String;
                            const URL: String='');
        procedure replaceState(stateObj: TObject; const title: String;
                               const URL: String='');
     end;

The issue is what the TObject contains, especially after it is read from the
browser cache during a browser restart.  If you stick to just data-only
objects, then you'll be fine.  It's when you try to save complex EWB objects
that are supposed to be part of a given application class hierarchy that may
have completely changed or been renamed (think identifier compression).
IOW, the design of persisting object instances is not good in terms of EWB.
I'll have to double-check this, but if the state objects were handled as
just straight Strings in the EWB code, then it may be do-able without
worrying about any weird object instance side-effects.  In such a case, you
would just change all of the above TObject references to String:

  external THistory = class
     public
        { Properties }
        property length: Integer read;
        property state: String read;
        { Methods }
        procedure back;
        procedure forward;
        procedure go(relative_position: Integer);
        procedure go(const target_string: String);
        procedure pushState(stateObj: String; const title: String;
                            const URL: String='');
        procedure replaceState(stateObj: String; const title: String;
                               const URL: String='');
     end;

That would eliminate any chance of a method being called that didn't exist,
etc.

Tim Young
Elevate Software
www.elevatesoft.com


Image