[thelist] RE: [ - Examples of Importing XML into Netscape or Mozilla? - ] - Jeff

Michael KImsal michael at tapinternet.com
Thu May 23 08:57:01 CDT 2002


Peter Thoenen wrote:

>
>>michael already mentioned a *very* serious issue
>>with a web application.  if
>>a visitor is printing a page that shows a purchase
>>receipt based on an
>>invoice number posted from a form on the previous
>>page, printing the page
>>will result in no invoice number being posted, no
>>purchase receipt being
>>displayed, and nothing even similar being printed.
>>
>>that's not just a visual problem.  that's an
>>application problem.
>>
>>the upside is there are ways around that in most
>>cases, but the fact remains
>>that it's a huge flaw.
>>
>
>This is an apples and oranges argument.  I don't
>*personally* see this as an issue as I dynamically
>create .pdf files on the fly for my invoices for all
>customer purchases.  I am not saying this is *correct*
>as it does have some isseus (lynx for one, requiring
>Adobe Acrobat Reader for another)... BUT I WILL ADMIT
>I can see where you are coming from.  It would be nice
>if we didnt' have to work around this..still not a
>show stopper though.  Every situation is different and
>each programs unto his own.  I could see this as an
>issue.  Now I am not an IE guy (or lynx for that
>matter..i am a big moz guy..that is first and foremost
>for me in ALL my testing) ... does (I am curious) IE
>or lynx display the proper code for a page the POST's
>to itself?  If not, this is moot as we originally
>started about Mozilla bugs.  If so, while I see BIGGER
>blocker bugs than this (for example..the
>document.lastmodifed() javascript bug)... I can see
>where ppl are coming from
>



This is not to beat a dead horse :) but yes IE does display the proper
data.  What it
does is display the actual code used to render what's on the page at the
moment
you hit 'view source'.  NS always would re'GET' the URL for just about
anything -
I mean even resizing the window would cause early NS browsers to re'GET'
the
URL in the window.  "View source" and "print" still trigger that, even
if the
page is the result of a POST.  This can easily cause people trying to print
an order page to either get wrong info or perhaps have an order
submitted twice.

Discussions on the Mozilla bug list show that it's even hard to get
people to admit
it's a problem.  There's loads of talk about storing too much history
information, etc.,
but no real work at addressing the issue.  Hell, if IE *and* Opera can
do it
(and Opera is damn fast too) why is it such a struggle to get Mozilla/NS to
do the *right* thing (perhaps not 'correct' according to some 1995 spec
sheet,
but painfully obviously 'right')?



>>
>>
>>i'm going to come back and say it depends on your
>>audience.  it also depends
>>on your budget.  the client may not have paid for
>>that level of
>>interoperability.
>>
>>see my comments about http1.1.
>>
>
>I disagree on this.  Regardless of my budget..I
>naturally code vendor neutral.  Sure certain items I
>(you) can't make perfect in all browsers (for example
>I have given up on support NS4.x visually unless
>client contract REQUIRES ... I do IE6/Moz1.0/Lynx) due
>to client restraints... but I can sure as hell make it
>workable in all (most) browsers.  Main reason I
>support Lynx is I have a job requirement to support
>(as in usable) audio browsers for visually disabled
>ppl and i personally believe ppl should quit
>discriminating against visually disabled ppl.
>

If you are *completely* vendor neutral then you are coding to 100% spec,
and every one of your visitors is getting a suboptimal experience.  The
fact
that it's suboptimal across the board may not make it seem as such, but its
suboptimal compared to what it *could* be.  This comes back to money/budget.
If the client required the *best* experience available for each browser
 you
no doubt would do it if they paid, but generally people are satisfied
with 'good
enough'.  Doesn't mean it's the best it can be though.




>
>It is unreasonable when you are doing web application
>development.
>

No it's not at all.

> Most of the code is server side and I
>don't explect it to show me my server side only source
>in the client.
>

Of course it would only show client stuff.  If you can't reliably determine
if it's closing a table cell properly, for example, because you can't
view the
source, it adds *more* time to your project, either meaning less money
in your pocket, more money out of the client's pocket, or fewer features
implemented overall.

>As for the source on a new
>request..right or wrong..i don't ever post a form to
>itself..i just post it to another page...dont' see a
>reason not to (lets not get into a security argument
>on this one...each his own and both ways are equally
>unsecure)
>

I specifically mentioned posting to itself - it happens with really any
POST
operation - as I mentioned before "view source" triggers another GET on the
URL you're at, and doesn't rePOST the data so  you won't get the same
data back reliably.

I'm sorry you find yourself creating a new serverside file to POST to
for *every single form* on your site.  That must get quite laborious.
 Having
a single or small number of processing files which handle the bulk of your
form processing can definitely cut down on development time.  Whether
it's the fusebox method of case/switch or some other methodology,
it really can help.

Cheers.

MK






More information about the thelist mailing list