Prev: Runtime Instance Name without using eval()
Next: Authentic Designer Handbags EVOGUER.COM 15% OFF DISCOUNT!!!!
From: David Mark on 28 Nov 2009 04:08
On Nov 28, 3:20 am, "Richard Maher" <maher...(a)hotspamnotmail.com>
wrote:
> Hi Jorge,

Please address the group.

>
> > there is no reason for any app to foul
> > up navigation
>
> And no navigation will be "fouled", just de-emphasised and de-optimized.

I wasn't saying there was. I was referring to one side of your drawn
lines, not your Java idea.

>
> > that hash changes don't
> > necessarily trigger an event.
>
> Reason ii) It really trashes the normal lifecycle of Applets

Java or no, it's a bad thing to do. We've been over that endlessly.

>
> So to all xenophobic, nervous-Nellies, clinging to the perceived security of
> yesteryear, I say "Burn your bridges, your boats and anything else that
> detracts from the now!" or maybe "This is the web-page; there are no other
> pages!" :-)
>

Is Jorge catching? :)
From: Jorge on 28 Nov 2009 04:58
On Nov 28, 10:08 am, David Mark <dmark.cins...(a)gmail.com> wrote:
> On Nov 28, 3:20 am, "Richard Maher" <maher...(a)hotspamnotmail.com>
> (...)
> > So to all xenophobic, nervous-Nellies, clinging to the perceived security of
> > yesteryear, I say "Burn your bridges, your boats and anything else that
> > detracts from the now!" or maybe "This is the web-page; there are no other
> > pages!" :-)
>
> Is Jorge catching?  :)

I'm not sure. Ideally the app's state should be reflected in the url,
because a single-page web-app is single-page from the point of view of
the browser, but inside the app there might be many different views.
It's not easy to do it nowadays because touching the search part of
the url would trigger a reload, and touching the hash part may pass
unnoticed to the app (people are using timers to track it). M$ IIRC
has already implemented onHashChange in IE8, and others are following
(or is it the other way around ?). That will be of great help... in
the future :-(

Or, are you saying that there should be no link between the url and
the app's state ?
--
Jorge.
From: David Mark on 28 Nov 2009 06:19
On Nov 28, 4:58 am, Jorge <jo...(a)jorgechamorro.com> wrote:
> On Nov 28, 10:08 am, David Mark <dmark.cins...(a)gmail.com> wrote:
>
> > On Nov 28, 3:20 am, "Richard Maher" <maher...(a)hotspamnotmail.com>
> >  (...)
> > > So to all xenophobic, nervous-Nellies, clinging to the perceived security of
> > > yesteryear, I say "Burn your bridges, your boats and anything else that
> > > detracts from the now!" or maybe "This is the web-page; there are no other
> > > pages!" :-)
>
> > Is Jorge catching?  :)
>
> I'm not sure.
> Ideally the app's state should be reflected in the url,
> because a single-page web-app is single-page from the point of view of
> the browser, but inside the app there might be many different views.

That makes zero sense (and I know about the views). ;)

> It's not easy to do it nowadays because touching the search part of
> the url would trigger a reload, and touching the hash part may pass
> unnoticed to the app (people are using timers to track it).

Web developers do all sorts of ill-advised things. :)

> M$ IIRC
> has already implemented onHashChange in IE8, and others are following
> (or is it the other way around ?).

As do browser developers.

> That will be of great help... in
> the future :-(

No it won't.

>
> Or, are you saying that there should be no link between the url and
> the app's state ?

Search the archive, Jorge. We've been over this a million times.
From: Jorge on 28 Nov 2009 09:55
On Nov 28, 12:19 pm, David Mark <dmark.cins...(a)gmail.com> wrote:
>
> Search the archive, Jorge.  We've been over this a million times.

IIRC, last time I saw a thread about this Peter Michaux said ~ what
I'm saying now, and you instead thought that state should be saved in
cookies, not-at-all in the url#hash, right ?

ISTM that cookies (and/or client-side persistent storage, when/if
available) are there -of course- to save state. But, it also STM that
that's not all that there's to it, because neither cookies nor client-
side persistent storage can be passed along in a url, and that's part
of the story. Say your app does bells and whistles, how would you -
with cookies- pass someone else a link to the bells panel ?

So I don't get why using #hash to save -some- state is ill-advidsed
(?). Just because the (missing) events ?
--
Jorge.
First  |  Prev  | 
Pages: 1 2
Prev: Runtime Instance Name without using eval()
Next: Authentic Designer Handbags EVOGUER.COM 15% OFF DISCOUNT!!!!