I hear ya Robert, been-there-done-that. Corporate firewalls are serious business in what I do.
That's why, by default, everything I do just runs over port 80 (or 443 for SSL), unless the customer specifically asks for something special. Being restricted to port 80 is what got me started in XML. XML Web Services, SOAP and the like are just XML payloads over HTTP, as opposed to HTML over HTTP - port 80 all the way. XML isn't the solution to everything, but it sure can solve some tough challenges :-) Scott Cadillac, Witango.org - http://witango.org 403-281-6090 - [EMAIL PROTECTED] -- Information for the Witango Developer Community --------------------- XML-Extranet - http://xml-extra.net 403-281-6090 - [EMAIL PROTECTED] -- Well-formed Development (for hire) --------------------- > -----Original Message----- > From: Robert Garcia [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 20, 2003 4:36 PM > To: [EMAIL PROTECTED] > Subject: Re: Witango-Talk: Loss of Session State Issues. > > > Must be nice. It actually isn't bad after a while. I know > exactly what > works and what doesn't right out of the box, so I stay away from > problem stuff. > > I would love to use more flash, but all of my apps are designed to > bring revenue to my clients, either through ecommerce or lead > generation tools that I have written. When one customer says they > cannot use your site because they are behind a corporate network and > they are not allowed to install any plugins, and this is a huge > customer that could mean big business. I cannot tell you how > many times > this has happened to me. > > I have done huge flash sites for customers, completely data > integrated > with witango, and slick, only to dump them for HTML because > the client > gets hammered by a few customers. > > I now make my clients sign an acknowledgement of my warning if they > want to go all flash, and they are serving the outside world. In the > end, unless they want to maintain the expense of two sites > html/flash, > it is not a good idea. > > Robert. > > > On Wednesday, August 20, 2003, at 11:34 AM, Scott Cadillac wrote: > > > My Hat is off to you Robert, > > > > Coding for general consumers is an artform, and an exercise in > > punishment at > > the same time. I have a lot of respect for your efforts. > > > > Fortunately and unfortunately (depending on your view > point), I only > > build > > business applications for Intranets. > > > > -------------------- > > My rules of thumb are nearly the exact opposite: > > > >>> Use simple javascript > > ~~ Use JScript 5.5 minimum to the fullest extent. > > ~~ Conditionally render client-side XSLT to produce HTML > from XML sent > > from > > the Server. > > > >>> Use server side solutions whenever possible. Don't use > javascript if > >>> you can do it server side. > > ~~ Use client-side solutions whenever possible. Only get > the Server to > > do > > work the browser can't do. > > ~~ Minimize the number of trips to the Server. > > ~~ Keep the work load on the Server to an absolute minimum. > > > >>> Do not have a link on the site that does not contain the > >>> <@userreferenceargument>, cookies are not as reliable as you > >>> would hope. > > ~~ Only use session-cookies. A published Intranet Use Policy. > > > >>> Do not build flash only elements. Stick with clean, tried and > >>> true HTML. > > ~~ Flash has a place in business applications, if done with > > professionals in > > mind who prefer functionality over whizziness. > > > >>> Use flash only for intros and non critical elements. > > ~~ I agree here. I find Jscript and XSLT much more reliable. > > > >>> Be careful with fancy drop down menus and such that don't work on > >>> everything. > > ~~ Not an issue. Exclusive MSIE only. > > ~~ MSIE also supports true Modal dialogs, use them where > appropriate. > > > >>> Test all your work with the lowest common denominator. > AOL on dialup. > > ~~ Test with 800x600 with minimum MS Internet Explorer 5.0 > on Windows > > 98 (no > > patches), on a 10Bt Network connection. > > > > Cheers..... > > > > > > > >> -----Original Message----- > >> From: Robert Garcia [mailto:[EMAIL PROTECTED] > >> Sent: Wednesday, August 20, 2003 11:54 AM > >> To: [EMAIL PROTECTED] > >> Subject: Re: Witango-Talk: Loss of Session State Issues. > >> > >> > >> I do some coporate sites, but most of my work is large business to > >> consumer apps, and I develop to be compatible with > >> everything. The only > >> browser I won't support now is netscape 4.x. > >> > >> Rules of thumb that I have developed over the years are: > >> > >> Use simple javascript > >> Use server side solutions whenever possible. Don't use > javascript if > >> you can do it server side. > >> Do not have a link on the site that does not contain the > >> <@userreferenceargument>, cookies are not as reliable as you > >> would hope. > >> Do not build flash only elements. Stick with clean, tried and > >> true HTML. > >> Use flash only for intros and non critical elements. > >> Be careful with fancy drop down menus and such that don't work on > >> everything. > >> Test all your work with the lowest common denominator. AOL > on dialup. > >> > >> I am sure there are more, but these are what come off the top of my > >> head. If you are doing corporate intranets, you can disregard > >> this, but > >> consumer compatibility is virtually an artform. > >> > >> Robert. > >> > >> > >> On Wednesday, August 20, 2003, at 10:23 AM, Atrix Wolfe wrote: > >> > >>> oh my gosh... > >>> > >>> do you know if netscape on mac behaves any better? we have > >> had some bad > >>> experiences with it but havent tested it as thoroughly as IE. > >>> > >>> ----- Original Message ----- > >>> From: "Web Dude" <[EMAIL PROTECTED]> > >>> To: <[EMAIL PROTECTED]> > >>> Sent: Wednesday, August 20, 2003 10:21 AM > >>> Subject: Re: Witango-Talk: Loss of Session State Issues. > >>> > >>> > >>>> I gave up on IE on the Mac too. I don't even develop for > >> it anymore. > >>>> I heard that Micro$oft is going to be pulling the product > >>>> anyway.....YIPPEE SKIPPEE! > >>>> > >>>>> Hey Robert, > >>>>> > >>>>> We too have intermitant problems with browsers, but our > >> problems come > >>> more > >>>>> in the way of javascript not always functioning (we use > >> javascript to > >>> make > >>>>> sure dates are valid etc, keep the user in bounds) and > >> browsers arent > >>> always > >>>>> passing the arguments like they should. > >>>>> > >>>>> Its very odd and disturbing and somewhat frustrating when > >> you have > >>>>> errors > >>>>> that disrupt your clients work flow that are because the > >> browser isnt > >>> doing > >>>>> what its supposed to! > >>>>> > >>>>> We have found that browsers for macs have a whole slew of > >> problems > >>>>> and > >>> that > >>>>> mac IE is a terrible product...in some versions some of the > >>>>> intermittant > >>>>> argument passing is there so you upgrade and then at the > >> next version > >>> thats > >>>>> fixed but then its something else. > >>>>> > >>>>> just wanted you to know were feelin your pain too (; > >>>>> > >>>>> ::growl:: > >>>>> > >>>>> ----- Original Message ----- > >>>>> From: "Robert Garcia" <[EMAIL PROTECTED]> > >>>>> To: <[EMAIL PROTECTED]> > >>>>> Sent: Wednesday, August 20, 2003 2:14 AM > >>>>> Subject: Re: Witango-Talk: Loss of Session State Issues. > >>>>> > >>>>> > >>>>>> The only thing I would add to that phil, is that I have > >> the problem > >>>>>> with browsers when I am sure cookies are not disabled > >> with the old > >>>>>> delete code, and it is intermittent. Mostly not > >> working, sometimes > >>>>>> working. > >>>>>> > >>>>>> I am using the default setup on the server for userkey, > >> and do no > >>>>>> altering of cookies and such. > >>>>>> > >>>>>> Thank you for the info on how the newer servers look for > >>> userreference. > >>>>>> > >>>>>> Robert. > >>>>>> > >>>>>> On Tuesday, August 19, 2003, at 11:43 PM, Phil Wade wrote: > >>>>>> > >>>>>>> I should note here that post args were not searched in T2K or > >>> Witango 5 > >>>>>>> prior to the 058 build when the server was trying to > >> locate the > >>>>>>> user > >>>>>>> reference so the T2K server would only look in the cookies and > >>>>>>> searchargs. > >>>>>>> > >>>>>>> The 5.0.1.058 server and above looks for a user > reference in the > >>>>>>> following > >>>>>>> order: > >>>>>>> > >>>>>>> 1. user reference cookie > >>>>>>> 2. user reference search arg > >>>>>>> 3. user reference post arg > >>>>>>> > >>>>>>> Once a user reference is found, the server will no > >> longer continue > >>> to > >>>>>>> search > >>>>>>> for a user reference in the remaining contexts so now > the server > >>> will > >>>>>>> use > >>>>>>> the first user reference found and not the last. > >>>>>>> > >>>>>>> Search arguments can only be up to 255 chars long so if > >> the server > >>>>>>> receives > >>>>>>> concatenated search arg data from the Browser it just > >> uses it. For > >>>>>>> this > >>>>>>> reason if you are not using user reference cookies and > >> are relying > >>> on > >>>>>>> the > >>>>>>> user reference search arg it is important to put the > >> user reference > >>> at > >>>>>>> the > >>>>>>> beginning of the search args, not at the end. > >>>>>>> > >>>>>>> These changes should not have any affect on existing > >> code, except > >>>>>>> to > >>>>>>> make > >>>>>>> the delete of the search builders work with browsers that have > >>> cookies > >>>>>>> disabled (see code below). The delete action passed the user > >>>>>>> reference via > >>>>>>> a postarg and always created a new user session in this > >> instance. > >>>>>>> This was > >>>>>>> not a big issue as the search builder did not rely on any user > >>>>>>> variables > >>>>>>> until it was extended by a user. > >>>>>>> > >>>>>>> Phil > >>>>>>> > >>>>>>> On 20/8/03 2:31 PM, "Robert Garcia" > <[EMAIL PROTECTED]> wrote: > >>>>>>> > >>>>>>>> The interesting thing about this, is I have a bunch of > >> simple web > >>>>>>>> admin > >>>>>>>> apps with the witango default code, and I haven't had > >> the problem > >>>>>>>> before. I think it started around v058 or so. > >>>>>>>> > >>>>>>>> If I use this code: > >>>>>>>> > >>>>>>>> <form method=post action="<@appfile>" name=deleteMe> > >>>>>>>> <input type=hidden name="_userreference" > >> value="<@userreference>"> > >>>>>>>> <input type=hidden name="CommonlabSchedule_uid1" > >> value="<@COLUMN > >>>>>>>> "Common.epxLessonSched.rowid">"> > >>>>>>>> <input type=hidden name="_function" value="delete"> > >>>>>>>> <INPUT TYPE=SUBMIT VALUE="Delete Record"> > >>>>>>>> </form> > >>>>>>>> > >>>>>>>> It seems to work reliably, So I will have to make a > >> lot of minor > >>>>>>>> changes. > >>>>>>>> > >>>>>>>> Robert. > >>>>>>>> > >>>>>>>> On Tuesday, August 19, 2003, at 08:50 PM, Scott > >> Cadillac wrote: > >>>>>>>> > >>>>>>>>> Hi Robert, > >>>>>>>>> > >>>>>>>>> When METHOD=GET is used in an HTML form, like in your first > >>> example, > >>>>>>>>> all the > >>>>>>>>> FORM element names and values (such as your hidden > fields) are > >>>>>>>>> automatically > >>>>>>>>> concatenated to the value of the ACTION attribute. This then > >>> appears > >>>>>>>>> in the > >>>>>>>>> address bar of your browser. > >>>>>>>>> > >>>>>>>>> BUT....if the ACTION attribute already contains other search > >>>>>>>>> arguments > >>>>>>>>> (such > >>>>>>>>> as <@USERREFERENCEARGUMENT>), then they are sometimes > >> replaced by > >>> the > >>>>>>>>> concatenated FORM elements. This is a classic > pain-in-the-*** > >>> issue. > >>>>>>>>> > >>>>>>>>> Your <@USERREFERENCEARGUMENT> is being removed which > >> can cause > >>>>>>>>> you > >>> to > >>>>>>>>> loose > >>>>>>>>> Session state. In the first FORM example, just > >> replace METHOD=GET > >>>>>>>>> with > >>>>>>>>> METHOD=POST and it should work. > >>>>>>>>> > >>>>>>>>> But of course, that doesn't explain your second or > >> third example, > >>> or > >>>>>>>>> why > >>>>>>>>> your Session-cookie didn't pickup the slack. > >>>>>>>>> > >>>>>>>>> Are Session-cookies disabled deliberately in your > >> browser? If so, > >>>>>>>>> then > >>>>>>>>> checking things like <@USERREFERENCEARGUMENT> for all > >> your links > >>> will > >>>>>>>>> be > >>>>>>>>> necessary. This includes the TAF files before your > >> actual delete > >>>>>>>>> request. > >>>>>>>>> > >>>>>>>>> Also, checking the value of your USERKEY setting in > >> witango.ini > >>> could > >>>>>>>>> be > >>>>>>>>> important too. > >>>>>>>>> > >>>>>>>>> If Session-cookies are supposed to be working, then > something > >>> strange > >>>>>>>>> is > >>>>>>>>> certainly happening. > >>>>>>>>> > >>>>>>>>> Have you tried seeing what's being passed back and > >> forth with an > >>> HTTP > >>>>>>>>> Sniffer of some kind? This will show you exactly the > >> values are > >>> being > >>>>>>>>> sent > >>>>>>>>> to the Server (both session-cookies and GET and POST > >> arguments). > >>>>>>>>> I > >>>>>>>>> recommend > >>>>>>>>> www.httpsniffer.com > >>>>>>>>> > >>>>>>>>> Hope this helps. Cheers.... > >>>>>>>>> > >>>>>>>>> Scott Cadillac, > >>>>>>>>> Witango.org - http://witango.org > >>>>>>>>> 403-281-6090 - [EMAIL PROTECTED] > >>>>>>>>> -- > >>>>>>>>> Information for the Witango Developer Community > >>>>>>>>> --------------------- > >>>>>>>>> > >>>>>>>>> XML-Extranet - http://xml-extra.net > >>>>>>>>> 403-281-6090 - [EMAIL PROTECTED] > >>>>>>>>> -- > >>>>>>>>> Well-formed Development (for hire) > >>>>>>>>> --------------------- > >>>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Robert Garcia [mailto:[EMAIL PROTECTED] > >>>>>>>>> Sent: Tuesday, August 19, 2003 9:23 PM > >>>>>>>>> To: [EMAIL PROTECTED] > >>>>>>>>> Subject: Witango-Talk: Loss of Session State Issues. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> I have been having some problems for a while with some admin > >>>>>>>>> pages > >>>>>>>>> that > >>>>>>>>> require a login, so session state is paramount. > >>>>>>>>> > >>>>>>>>> If I use the standard code Witango uses for > deleting a record, > >>> most > >>>>>>>>> of > >>>>>>>>> the > >>>>>>>>> time, state is lost: > >>>>>>>>> > >>>>>>>>> <FORM METHOD=GET > ACTION="<@APPFILE>?<@userreferenceargument>"> > >>>>>>>>> <INPUT TYPE=HIDDEN NAME="_function" VALUE="delete"> > >>>>>>>>> <INPUT TYPE=HIDDEN NAME="CommonlabSchedule_uid1" > >> VALUE="<@COLUMN > >>>>>>>>> "Common.epxLessonSched.rowid">"> > >>>>>>>>> <INPUT TYPE=SUBMIT VALUE="Delete"> > >>>>>>>>> </FORM> > >>>>>>>>> > >>>>>>>>> I have also tried these variations: > >>>>>>>>> > >>>>>>>>> <FORM METHOD=GET ACTION="<@APPFILE>"> > >>>>>>>>> <INPUT TYPE=HIDDEN NAME="_function" VALUE="delete"> > >>>>>>>>> <INPUT TYPE=HIDDEN NAME="CommonlabSchedule_uid1" > >> VALUE="<@COLUMN > >>>>>>>>> "Common.epxLessonSched.rowid">"> > >>>>>>>>> <INPUT TYPE=HIDDEN NAME="_userReference" > >>>>>>>>> VALUE="<@UserReference>"> > >>>>>>>>> <INPUT TYPE=SUBMIT VALUE="Delete"> > >>>>>>>>> </FORM> > >>>>>>>>> > >>>>>>>>> <FORM METHOD=POST ACTION="<@APPFILE>"> > >>>>>>>>> <INPUT TYPE=HIDDEN NAME="_function" VALUE="delete"> > >>>>>>>>> <INPUT TYPE=HIDDEN NAME="CommonlabSchedule_uid1" > >> VALUE="<@COLUMN > >>>>>>>>> "Common.epxLessonSched.rowid">"> > >>>>>>>>> <INPUT TYPE=HIDDEN NAME="_userReference" > >>>>>>>>> VALUE="<@UserReference>"> > >>>>>>>>> <INPUT TYPE=SUBMIT VALUE="Delete"> > >>>>>>>>> </FORM> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> However, if I use this code, I never lose state: > >>>>>>>>> > >>>>>>>>> <p><a > >>>>>>>>> > >> href="<@appfile>?_function=delete&CommonlabSchedule_uid1=<@COLUMN > >>>>>>>>> > >> "Common.epxLessonSched.rowid">&<@userreferenceargument>">Delete > >>> this > >>>>>>>>> Record</p> > >>>>>>>>> > >>>>>>>>> Anyone else having these issues, or have any ideas? > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> > >>>>>>>>> Robert Garcia > >>>>>>>>> President - BigHead Technology > >>>>>>>>> CTO - eventpix.com > >>>>>>>>> 2781 N Carlmont Pl > >>>>>>>>> Simi Valley, Ca 93065 > >>>>>>>>> ph: 805.522.8577 - cell: 805.501.1390 > >>>>>>>>> [EMAIL PROTECTED] - [EMAIL PROTECTED] > >>>>>>>>> http://bighead.net/ - http://eventpix.com/ - > >>>>>>>>> http://theradmac.com/ > >>>>>>>>> > >>>>>>>>> > >>> > >> > _____________________________________________________________________ > >>>>>>>>> __ > >>>>>>>>> _ > >>>>>>>>> TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > >>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>>>> > >>> > >> ______________________________________________________________ > >> _________ > >>>>>>> _ > >>>>>>> TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> -- > >>>>>> > >>>>>> Robert Garcia > >>>>>> President - BigHead Technology > >>>>>> CTO - eventpix.com > >>>>>> 2781 N Carlmont Pl > >>>>>> Simi Valley, Ca 93065 > >>>>>> ph: 805.522.8577 - cell: 805.501.1390 > >>>>>> [EMAIL PROTECTED] - [EMAIL PROTECTED] > >>>>>> http://bighead.net/ - http://eventpix.com/ - > > http://theradmac.com/ > >>>>> > >>>>> > >> > ______________________________________________________________ > ________ > >> _ > >> _ > >>>>> TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > >>>> > >>>> > ____________________________________________________________________ > >>>> _ > >>>> ___ > >>>> TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > >>> > >>> > >>> -- > >>> > _____________________________________________________________________ > >>> _ > >>> __ > >>> TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > >> > >> > ______________________________________________________________ > ________ > >> _ > >> _ > >> TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > >> > >> > > > > -- > > > > Robert Garcia > > President - BigHead Technology > > CTO - eventpix.com > > 2781 N Carlmont Pl > > Simi Valley, Ca 93065 > > ph: 805.522.8577 - cell: 805.501.1390 > > [EMAIL PROTECTED] - [EMAIL PROTECTED] > > http://bighead.net/ - http://eventpix.com/ - http://theradmac.com/ > > > > > ______________________________________________________________ > _________ > > _ > > TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > > > > > ______________________________________________________________ > _________ > > _ > > TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > > > > > > -- > > Robert Garcia > President - BigHead Technology > CTO - eventpix.com > 2781 N Carlmont Pl > Simi Valley, Ca 93065 > ph: 805.522.8577 - cell: 805.501.1390 > [EMAIL PROTECTED] - [EMAIL PROTECTED] > http://bighead.net/ - http://eventpix.com/ - http://theradmac.com/ > > ______________________________________________________________ > __________ > TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
