Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > If you think you must modify the hash, think again

Reply
Thread Tools

If you think you must modify the hash, think again

 
 
David Mark
Guest
Posts: n/a
 
      03-21-2010
As I've said before, if you find yourself leaning towards a design that
modifies the location hash because you think that an app can't be
"modern" or "robust" or "fast" without such hack-ery, think again.
There's always a better design (and often it involves leveraging what
the browser does best, which is _browsing_).

I ran across this recently:-

http://stackoverflow.com/questions/1...-in-javascript

It is a microcosm for everything that has gone wrong with "Web 2.0"
(quotes indicate that term is used to describe so many things it is
meaningless). These ridiculous "history managers" and "back button
fixers" (see Dojo and YUI) are self-imposed doom and gloom. Doesn't
work in IE < 8 (or IE8 compatibility views of course), also fails in
less-than-ancient Opera versions. Standardizing this nonsense with a
hash change event must have felt like validation for a clearly backwards
approach to Web application authoring, but it's just more folly. You
can't force users to upgrade their browsers to accommodate incompetent
designs (and some couldn't do it if they wanted to).
 
Reply With Quote
 
 
 
 
Peter Michaux
Guest
Posts: n/a
 
      03-21-2010
On Mar 21, 3:22*pm, David Mark <(E-Mail Removed)> wrote:
> As I've said before, if you find yourself leaning towards a design that
> modifies the location hash because you think that an app can't be
> "modern" or "robust" or "fast" without such hack-ery, think again.
> There's always a better design (and often it involves leveraging what
> the browser does best, which is _browsing_).


Browsers are not just used to navigate around a collection of linked
documents anymore. Browsers are used as an application platform. Use
as an application platform is increasing, not decreasing.

Setting location.hash is a fine idea and I appreciate applications
like Gmail and Yahoo! Maps that use the technique. I hope to see more
web applications doing it and steadily improving browser support for
it.

- - -

You are also neglecting issues related to working in a difficult
development environment/team. Some folks might be willing to implement
your alternative design but others won't be. At that point the client-
side programmer may use hash setting as a compromise.

Peter
 
Reply With Quote
 
 
 
 
David Mark
Guest
Posts: n/a
 
      03-21-2010
Peter Michaux wrote:
> On Mar 21, 3:22 pm, David Mark <(E-Mail Removed)> wrote:
>> As I've said before, if you find yourself leaning towards a design that
>> modifies the location hash because you think that an app can't be
>> "modern" or "robust" or "fast" without such hack-ery, think again.
>> There's always a better design (and often it involves leveraging what
>> the browser does best, which is _browsing_).

>
> Browsers are not just used to navigate around a collection of linked
> documents anymore.


I know that. We've had this discussion already. The issue is _how_
it is done (and the prevailing trend has been to throw away all of the
advantages of _browsing_, which is not required to write robust
applications).

> Browsers are used as an application platform.


Sure they are! I write applications for them every day. What I don't
do is program for failure by designing applications that must rely on a
heart-stopping number of hacks to shoehorn everything into one document
(and then barely work in a handful of observed environments and doing
God knows what in unknown environments).

> Use
> as an application platform is increasing, not decreasing.


Yes, until something more appropriate replaces Web browsing as the
application platform of choice (the Apple iPhone apps are a step in that
direction, which is why Apple doesn't even bother with a MobileMe
website).

>
> Setting location.hash is a fine idea and I appreciate applications
> like Gmail and Yahoo! Maps that use the technique.


We've been over this. It is not a fine idea. It is a completely
backwards Wile E. Coyote type idea. The writing on the wall is clear.
Look at all of the ridiculous hoops you must jump through just to create
a half-ass cross-browser application. It doesn't make a whit of sense.
I defy anyone to read that StackOverflow interchange and not feel the
need to wonder just how crazy and misguided those people are.

> I hope to see more
> web applications doing it and steadily improving browser support for
> it.


Why would you hope that? I hope people get a clue and realize they are
programming for failure. Why do you think the authors of Dojo and YUI
keep blaming old browsers for their incompetence (and calling for them
to be banned?) It would be laughable if it weren't so freaking irritating.

>
> - - -
>
> You are also neglecting issues related to working in a difficult
> development environment/team.


I'm not neglecting anything. You seem to be assuming you can read my
mind (I get a lot of that).

> Some folks might be willing to implement
> your alternative design but others won't be.


That's as maybe. Some people think jQuery is an elegant design. It's a
crazy world.

> At that point the client-
> side programmer may use hash setting as a compromise.
>


They might. I'd sure as hell try to talk them out of it though.
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      03-21-2010
David Mark wrote:
> Peter Michaux wrote:
>> On Mar 21, 3:22 pm, David Mark <(E-Mail Removed)> wrote:
>>> As I've said before, if you find yourself leaning towards a design that
>>> modifies the location hash because you think that an app can't be
>>> "modern" or "robust" or "fast" without such hack-ery, think again.
>>> There's always a better design (and often it involves leveraging what
>>> the browser does best, which is _browsing_).

>> Browsers are not just used to navigate around a collection of linked
>> documents anymore.

>
> I know that. We've had this discussion already. The issue is _how_
> it is done (and the prevailing trend has been to throw away all of the
> advantages of _browsing_, which is not required to write robust
> applications).
>
>> Browsers are used as an application platform.

>
> Sure they are! I write applications for them every day. What I don't
> do is program for failure by designing applications that must rely on a
> heart-stopping number of hacks to shoehorn everything into one document
> (and then barely work in a handful of observed environments and doing
> God knows what in unknown environments).
>
>> Use
>> as an application platform is increasing, not decreasing.

>
> Yes, until something more appropriate replaces Web browsing as the
> application platform of choice (the Apple iPhone apps are a step in that
> direction, which is why Apple doesn't even bother with a MobileMe
> website).
>
>> Setting location.hash is a fine idea and I appreciate applications
>> like Gmail and Yahoo! Maps that use the technique.

>
> We've been over this. It is not a fine idea. It is a completely
> backwards Wile E. Coyote type idea. The writing on the wall is clear.
> Look at all of the ridiculous hoops you must jump through just to create
> a half-ass cross-browser application. It doesn't make a whit of sense.
> I defy anyone to read that StackOverflow interchange and not feel the
> need to wonder just how crazy and misguided those people are.
>
>> I hope to see more
>> web applications doing it and steadily improving browser support for
>> it.

>
> Why would you hope that? I hope people get a clue and realize they are
> programming for failure. Why do you think the authors of Dojo and YUI
> keep blaming old browsers for their incompetence (and calling for them
> to be banned?) It would be laughable if it weren't so freaking irritating.
>


And it's worth noting that it is the exact same situation with the
horribly ill-advised technique of downloading scripts via XHR and
evaluating them on the client side. I asked some of the Dojo guys why
they thought _that_ was a good idea (despite the fact that, as
implemented, it required either synchronous XHR or some horribly
convoluted workaround that completely changed their application at
deployment time). They said something along the lines of "because the
Web has applications now" and wondered aloud how I could have missed
that. Well, LOL; the Web (public and private) has had applications for
over a decade and I, for one, never encountered the need to resort to
such obviously flawed designs. YMMV.

 
Reply With Quote
 
Peter Michaux
Guest
Posts: n/a
 
      03-21-2010
On Mar 21, 4:09 pm, David Mark <(E-Mail Removed)> wrote:
> Peter Michaux wrote:
> > On Mar 21, 3:22 pm, David Mark <(E-Mail Removed)> wrote:


> Sure they are! I write applications for them every day. What I don't
> do is program for failure by designing applications that must rely on a
> heart-stopping number of hacks to shoehorn everything into one document
> (and then barely work in a handful of observed environments and doing
> God knows what in unknown environments).


Putting a whole company's worth of tools into a single page certainly
doesn't work. Having GMail, Adsense, and Maps all in the same page
would be lunacy. GMail all in one page is not lunacy. It is great for
the user with sufficient horsepower and bandwidth. For others they do
provide a stripped down client.


> > Use
> > as an application platform is increasing, not decreasing.

>
> Yes, until something more appropriate replaces Web browsing as the
> application platform of choice (the Apple iPhone apps are a step in that
> direction, which is why Apple doesn't even bother with a MobileMe
> website).


I would take Web apps in Safari over iPhone apps any day both from a
user and developer perspective.


> > Setting location.hash is a fine idea and I appreciate applications
> > like Gmail and Yahoo! Maps that use the technique.

>
> We've been over this. It is not a fine idea. It is a completely
> backwards Wile E. Coyote type idea.


Acme JavaScript Library.


> Look at all of the ridiculous hoops you must jump through just to create
> a half-ass cross-browser application.


Not really. These days, just set the location hash and poll it. For
users of new browsers the back button will work to navigate though the
DHTML page changes. For users of old browsers, the experience will be
different. Hitting the back button might mean going back a genuine
page. So what? That' is not the end of the world. This way the
application is not dependent on location hash setting but most users
can benefit from it.

Peter
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      03-21-2010
Peter Michaux wrote:
> On Mar 21, 4:09 pm, David Mark <(E-Mail Removed)> wrote:
>> Peter Michaux wrote:
>>> On Mar 21, 3:22 pm, David Mark <(E-Mail Removed)> wrote:

>
>> Sure they are! I write applications for them every day. What I don't
>> do is program for failure by designing applications that must rely on a
>> heart-stopping number of hacks to shoehorn everything into one document
>> (and then barely work in a handful of observed environments and doing
>> God knows what in unknown environments).

>
> Putting a whole company's worth of tools into a single page certainly
> doesn't work. Having GMail, Adsense, and Maps all in the same page
> would be lunacy.


Yes. That would be taking the strategy to an obscene extreme (which is
the polar opposite of what I advocate).

> GMail all in one page is not lunacy.


I didn't say it was. But you have to stop and think: what is a page?

> It is great for
> the user with sufficient horsepower and bandwidth.


I don't really see why you would need any extreme horsepower or
bandwidth to read and write email from a Web document (or documents).
But then, if Google wrote it... Why does everyone want to use
Google as an example. It's such a self-defeating proposition.

> For others they do
> provide a stripped down client.


Of course they do. They couldn't write a non-behemoth, so they ended up
writing a whole extra application. And, as is well-documented, they
have enough trouble maintaining one.

>
>
>>> Use
>>> as an application platform is increasing, not decreasing.

>> Yes, until something more appropriate replaces Web browsing as the
>> application platform of choice (the Apple iPhone apps are a step in that
>> direction, which is why Apple doesn't even bother with a MobileMe
>> website).

>
> I would take Web apps in Safari over iPhone apps any day both from a
> user and developer perspective.


I don't follow. Are you comparing desktop Safari to mobile Webkit?
That's apples and grapes.

>
>
>>> Setting location.hash is a fine idea and I appreciate applications
>>> like Gmail and Yahoo! Maps that use the technique.

>> We've been over this. It is not a fine idea. It is a completely
>> backwards Wile E. Coyote type idea.

>
> Acme JavaScript Library.


Yep. It's what I call the Cult Of Programming by Observation and not
Understanding a Thing (COPOUT).

http://vids.myspace.com/index.cfm?fu...ideoID=7622124

>
>
>> Look at all of the ridiculous hoops you must jump through just to create
>> a half-ass cross-browser application.

>
> Not really. These days, just set the location hash and poll it.


That doesn't work in IE < 8 (or IE8's various compatibility modes),
which is a real downer as the Dojo folks (for example) often find
themselves recommending the forcing of compatibility mode (via a META)
to make applications built with older Dojo's (predating IE8 observation
marathons and re-workings) to "work".

http://n3.nabble.com/What-is-the-lat...25p463125.html

And don't click that link in the latest Opera unless you enjoy needless
aggravation.

Speaking of that bunch, get a load of this all-in-one-page wonder:-

http://www.dojofoundation.org/

This is what I'm talking about. All of those eyes (and hands) and where
are the brains?

> For
> users of new browsers the back button will work to navigate though the
> DHTML page changes.


You said it. New browsers? Many users don't know what a browser is,
let alone that there are new ones. You can't force the general public
to update browsers and that fact should be considered from the start of
any design slated for the Web.

> For users of old browsers, the experience will be
> different.


Ain't that the truth? Broken would better describe the experience in
many common cases (and I'm talking about major browsers in heavy use today).

> Hitting the back button might mean going back a genuine
> page.


Having dealt with a project that did this recently, I can tell you it
may do all sorts of bizarre things. Going back to a "genuine page" is
the least of the worries. The fact is, the history gets all out of
sync, which breaks many useful browser features (e.g. the bookmarking
that seems to be the biggest concern of such designs). And the
inescapable truth is that there is virtually always a better way
(meaning one that does not break browsers for no good reason).

> So what? That' is not the end of the world.


What is? Some say we will find out in a couple of years, but they are
likely just as nutty as those who think Web applications are the wave of
the future for anyone but hobbyists and scientists.

> This way the
> application is not dependent on location hash setting but most users
> can benefit from it.
>


Nice thought, but it doesn't match up with reality.
 
Reply With Quote
 
Peter Michaux
Guest
Posts: n/a
 
      03-22-2010
On Mar 21, 5:05 pm, David Mark <(E-Mail Removed)> wrote:
> Peter Michaux wrote:
> > On Mar 21, 4:09 pm, David Mark <(E-Mail Removed)> wrote:
> >> Peter Michaux wrote:
> >>> On Mar 21, 3:22 pm, David Mark <(E-Mail Removed)> wrote:


> I don't really see why you would need any extreme horsepower or
> bandwidth to read and write email from a Web document (or documents).
> But then, if Google wrote it... Why does everyone want to use
> Google as an example. It's such a self-defeating proposition.


People like using Google's apps as examples because people like using
Google's apps. I like using fully featured GMail more than a static
1997 webmail client.


> > For others they do
> > provide a stripped down client.

>
> Of course they do. They couldn't write a non-behemoth, so they ended up
> writing a whole extra application. And, as is well-documented, they
> have enough trouble maintaining one.


A lot of people do not have any trouble using GMail. I never have a
problem.

Apparently "There are several hundred thousands lines of javascript in
Gmail". I always think "several" means at least 4. That boggles my
mind. GCC is written in C and has a bit over a million lines of code.
To think that the GMail client, written in such a high-level language
like JavaScript, is getting even close to the size of GCC makes me
think something is wrong. Still, I like using GMail so I don't worry
too much.


> >>> Use
> >>> as an application platform is increasing, not decreasing.
> >> Yes, until something more appropriate replaces Web browsing as the
> >> application platform of choice (the Apple iPhone apps are a step in that
> >> direction, which is why Apple doesn't even bother with a MobileMe
> >> website).

>
> > I would take Web apps in Safari over iPhone apps any day both from a
> > user and developer perspective.

>
> I don't follow. Are you comparing desktop Safari to mobile Webkit?
> That's apples and grapes.


I like using web apps with Safari on my iPhone than using iPhone apps
on my iPhone and not just by a little bit. I like the web apps a lot
more.


> > Not really. These days, just set the location hash and poll it.

>
> That doesn't work in IE < 8 (or IE8's various compatibility modes),


I haven't be experiencing any problems with IE < 8.


> Speaking of that bunch, get a load of this all-in-one-page wonder:-
>
> http://www.dojofoundation.org/
>
> This is what I'm talking about. All of those eyes (and hands) and where
> are the brains?


I agree that an information-based site like that, which would be
desirable to have indexed well by search engines, should not be done
with hash navigation. That is a really bad idea.

I think what they were going for was to show off dojo through their
own site.


> You said it. New browsers? Many users don't know what a browser is,
> let alone that there are new ones.


In some cases it doesn't matter much if users with new browsers and
users with old browsers have the same experience. The important part
is they all have a good experience.


> You can't force the general public
> to update browsers and that fact should be considered from the start of
> any design slated for the Web.


For the general web. A lot of applications are behind login and
benefit more by using fancy features than being accessible to all.
That is a business call.


> > Hitting the back button might mean going back a genuine
> > page.

>
> Having dealt with a project that did this recently, I can tell you it
> may do all sorts of bizarre things. Going back to a "genuine page" is
> the least of the worries. The fact is, the history gets all out of
> sync,


Under what circumstances? I'm not experiencing any problems in my
tests.

Peter

 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      03-23-2010
Peter Michaux wrote:
> On Mar 21, 5:05 pm, David Mark <(E-Mail Removed)> wrote:
>> Peter Michaux wrote:
>>> On Mar 21, 4:09 pm, David Mark <(E-Mail Removed)> wrote:
>>>> Peter Michaux wrote:
>>>>> On Mar 21, 3:22 pm, David Mark <(E-Mail Removed)> wrote:

>
>> I don't really see why you would need any extreme horsepower or
>> bandwidth to read and write email from a Web document (or documents).
>> But then, if Google wrote it... Why does everyone want to use
>> Google as an example. It's such a self-defeating proposition.

>
> People like using Google's apps as examples because people like using
> Google's apps. I like using fully featured GMail more than a static
> 1997 webmail client.
>
>
>>> For others they do
>>> provide a stripped down client.

>> Of course they do. They couldn't write a non-behemoth, so they ended up
>> writing a whole extra application. And, as is well-documented, they
>> have enough trouble maintaining one.

>
> A lot of people do not have any trouble using GMail. I never have a
> problem.
>
> Apparently "There are several hundred thousands lines of javascript in
> Gmail". I always think "several" means at least 4. That boggles my
> mind. GCC is written in C and has a bit over a million lines of code.
> To think that the GMail client, written in such a high-level language
> like JavaScript, is getting even close to the size of GCC makes me
> think something is wrong. Still, I like using GMail so I don't worry
> too much.
>
>
>>>>> Use
>>>>> as an application platform is increasing, not decreasing.
>>>> Yes, until something more appropriate replaces Web browsing as the
>>>> application platform of choice (the Apple iPhone apps are a step in that
>>>> direction, which is why Apple doesn't even bother with a MobileMe
>>>> website).
>>> I would take Web apps in Safari over iPhone apps any day both from a
>>> user and developer perspective.

>> I don't follow. Are you comparing desktop Safari to mobile Webkit?
>> That's apples and grapes.


Actually, I intended "iPhone apps" rather than "mobile Webkit".

>
> I like using web apps with Safari on my iPhone than using iPhone apps
> on my iPhone and not just by a little bit. I like the web apps a lot
> more.


The iPhone apps are actually far more capable than Web apps (just on a
much smaller screen). Now imagine such a solution for the desktop,
without all of the browser scripting baggage to hold it back. That's
the future...

>
>
>>> Not really. These days, just set the location hash and poll it.

>> That doesn't work in IE < 8 (or IE8's various compatibility modes),

>
> I haven't be experiencing any problems with IE < 8.


Then I assume you have used the ill-advised IFrame injection hack.
IE6/7 (and IE8 in IE7 compatibility mode) don't add the hash changes to
history. In fact, setting the hash and then attempting to read it back
(from either location.hash or location.href) often failed in my testing.
Older versions of Opera (e.g. some of 9.x) have similar problems. It's
a major can of worms that I never attempted to open (the abstraction
described on the label indicated a bad idea) until presented with a
project that was doing it.

>
>
>> Speaking of that bunch, get a load of this all-in-one-page wonder:-
>>
>> http://www.dojofoundation.org/
>>
>> This is what I'm talking about. All of those eyes (and hands) and where
>> are the brains?

>
> I agree that an information-based site like that, which would be
> desirable to have indexed well by search engines, should not be done
> with hash navigation. That is a really bad idea.


Yes, that site gives new meaning to the word failure. That's the sort
of overzealous "Ajax at all costs" design that is ruining the Web.

>
> I think what they were going for was to show off dojo through their
> own site.


LOL. That tells you something about Dojo's cracked foundation (in terms
of code and contributor mindset). Try it with your browser slightly
smaller than whatever (high) resolution the author tested in.

>
>
>> You said it. New browsers? Many users don't know what a browser is,
>> let alone that there are new ones.

>
> In some cases it doesn't matter much if users with new browsers and
> users with old browsers have the same experience. The important part
> is they all have a good experience.


I agree 100%. My point is that users of old browsers will often have a
dreadful experience with this technique. I went through it all about a
week ago and my suspicions were confirmed in spades.

>
>
>> You can't force the general public
>> to update browsers and that fact should be considered from the start of
>> any design slated for the Web.

>
> For the general web. A lot of applications are behind login and
> benefit more by using fancy features than being accessible to all.
> That is a business call.


But as there is virtually always a better design available, an informed
businessperson should not feel the urge to make that call.

>
>
>>> Hitting the back button might mean going back a genuine
>>> page.

>> Having dealt with a project that did this recently, I can tell you it
>> may do all sorts of bizarre things. Going back to a "genuine page" is
>> the least of the worries. The fact is, the history gets all out of
>> sync,

>
> Under what circumstances? I'm not experiencing any problems in my
> tests.
>


Just the simple act of setting the hash and reading it back is extremely
problematic. Some of the issues were described (and bizarre workarounds
proposed) in the cited StackOverflow exchange. All of those people
complaining that the end result didn't seem to work in IE6/7 were not
just whistling Dixie. I can confirm that there are major issues in
those browsers with relation to setting the hash with script. If you
set the hash and then can't read it back reliably (which I can
definitely confirm), it pretty much sinks the whole endeavor. I sure as
hell wouldn't inject an IFrame (as seen in ill-advised junk like YUI and
Dojo) or mess with Opera's navigation mode (also in YUI IIRC) to try to
make such an obvious non-starter start.
 
Reply With Quote
 
Jorge
Guest
Posts: n/a
 
      03-23-2010
On Mar 23, 9:55*am, David Mark <(E-Mail Removed)> wrote:
> (...)
> Just the simple act of setting the hash and reading it back is extremely
> problematic. *Some of the issues were described (and bizarre workarounds
> proposed) in the cited StackOverflow exchange. *All of those people
> complaining that the end result didn't seem to work in IE6/7 were not
> just whistling Dixie. *I can confirm that there are major issues in
> those browsers with relation to setting the hash with script. *If you
> set the hash and then can't read it back reliably (which I can
> definitely confirm), it pretty much sinks the whole endeavor. *I sure as
> hell wouldn't inject an IFrame (as seen in ill-advised junk like YUI and
> Dojo) or mess with Opera's navigation mode (also in YUI IIRC) to try to
> make such an obvious non-starter start. *


I think that none of the many long-standing bugs in IEs are merely
accidents due to incompetence. Rather the opposite, I firmly believe
that most of them are bricks on the road clever and intentionally left
there -service pack after service pack- by M$ in order to handicap the
web and its potential, which M$ has always seen as a threat for their
OS business.

There's no need to be a genius in order to see that if the web ever
succeeded as an application delivery channel it would have been the
end for the proprietary Windows®™ API lock-in. That's why it's been
into M$ plans for the last so many years to lock and f*ck the browsers
API as much as possible in as obscure -and not too evident- as
possible ways.

You, Cornford, and so many others not only in this group but in the
whole web panorama are good living examples of M$'s intended effect,
whenever you advocate ditching a clever idea due to a certain IE
(in)compatibility.

This is exactly the same reason why there's no <canvas> in IEs: they
don't want the browsers API to provide such an essential
functionality. Think about it: there's no way but the <canvas> to draw
arbitrary pixels on-screen.

So in order to get out of this trap in which we've been for so long, I
think that the way forward for the web should not care the slightest
about working around any of the many of IE's misbehaviours. Instead,
think about killing IE forever. It deserves it.
--
Jorge.
 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      03-23-2010
On Mar 23, 10:05 am, Jorge wrote:
<snip>
> So in order to get out of this trap in which we've been for so
> long, I think that the way forward for the web should not care
> the slightest about working around any of the many of IE's
> misbehaviours. Instead, think about killing IE forever. It
> deserves it.


Dreaming of killing IE is futile. That action is not within your
power, or that of any web developers (individually or collectively).
The world will change (probably in unpredictable ways) but a
responsible web developer will learn to cope with the way things are
now rather then how they wish things to be.

For years there were people maintaining that only IE mattered; that it
was the de facto standard, the only really capable browser and that
there was no point in the extra work necessary to accommodate the
statistically insignificant number of user's of alternative browsers.
Those people were wrong when they said that, and proved wrong by the
passage of time. But arguing today that nobody should bother to
support IE is just repeating that mistake with a different subject. It
is arrogant to take such a position, and even more arrogant to think
that it might change anything.

Richard.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Why must and must not be "final" ? NeoGeoSNK Java 25 11-24-2006 02:02 AM
So you want free Trade with the Janks, just think again. Jack Hammond NZ Computing 2 09-17-2006 06:38 AM
if 'ejecting' a cd is how you remove it, then when you put it in, you must be injecting a cd. Doc Martian Computer Information 4 06-09-2006 11:04 PM
Think your Wireless Network is Secure? Think Again. Careers Computer Security 7 01-31-2004 07:04 AM
Think Off Brand Inks Are Just as Good in your Inkjet Printer - Think Again! John Horner Digital Photography 5 11-09-2003 09:38 PM



Advertisments