[jQuery] Re: Dealing with incremental page rendering and ready events
Hi. I can't give much super targeted help with the info you provide. I have a couple thoughts that may or may not be helpful. Although there are exceptions, usually javascript that fails because the page is not loaded will still fail even if your network connection is very fast (in other words network speed is unlikely to outrun client side javascript execution speed under most circumstances). Basically he shows that you can apply certain scripts much faster by simply putting the necessary code after the elements the scripts work with. I've used this trick and it should work fine, provided the inline JS code really really does come after (in the DOM) everything it is trying to touch. Well, it works in FF without any problems, but IE completely refuses to load the page at all This is very common when you refer to a DOM element that doesn't exist yet. FF will recover as gracefully as it can (although if you have firebug or error reporting turned on you may get a report) and IE will just stop trying to run inline JS for the rest of the page. My attempts to delay rendering of parts of a page using PHP's sleep() or usleep() functions doesn't help at all, I simply don't get any output at all until all calls to sleep finish Try this for more control over php output buffer: http://us3.php.net/outcontrol Sometimes an ISP will wrap php so that it doesn't all work the way php thinks it's going to but if you have control over your server environment you should be to simulate delayed delivery of page components. Nathan .:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:. Nathan Young Cisco.com-Interface Development A: ncy1717 E: [EMAIL PROTECTED] -Original Message- From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Jörn Zaefferer Sent: Monday, April 02, 2007 2:44 PM To: jquery-en@googlegroups.com Subject: [jQuery] Dealing with incremental page rendering and ready events Hi folks, I'm trying to solve a severe performance issue I'm experiencing in an enviroment that heavily uses incremental page rendering. I have several parts on one page that are basically independent, but to apply any JavaScript to one of those parts (actually jsr168 portlets on a websphere portal) I currently rely on jQuery's DOM ready event, which is simply too late, causing ugly rendering issues. Now I stumbled about this blog entry by Ben Nadel: http://www.bennadel.com/index.cfm?dax=blog:583.view Basically he shows that you can apply certain scripts much faster by simply putting the necessary code after the elements the scripts work with. That is a viable solution that could be quite helpful for my issue, but unfortuantely I can't get it to work: Well, it works in FF without any problems, but IE completely refuses to load the page at all, instead alerting me about something like can't display this page, so quite impossible to debug. Now I tried to seperate testing of the workaround from the actual enviroment and failed to properly simulate incremental page rendering. My attempts to delay rendering of parts of a page using PHP's sleep() or usleep() functions doesn't help at all, I simply don't get any output at all until all calls to sleep finish. And under that circumstance the put-script-behind-element works perfectly. So, any hint on how to get one of those issues solved is highly welcome, be it executing scripts before DOM ready in IE or simulating incremental page rendering. -- Jörn Zaefferer http://bassistance.de
[jQuery] Re: Web 2.0 is vulnerable to attack
Hi. I know you asked for code but what you're getting is more talk. Sorry. You can't produce the secret in pure client side JS, you need the server to round trip the secret to itself with the cooperation of the JS. Also note that as stated before, creating mashups and securing your service in this way are in simplest form directly opposing priorities. In other words the simplest way to secure your service from people using it in ways that you don't want them to is not to let them use it at all. The simplest thing to check for is the referrer. If the browser requesting your service reports your own page as a referrer, then you can send them the response. An attacker can fake the referrer in their own browser, but they don't have a session to ride. There's no way they can embed a request to your service in their page in such a way that it fakes the referrer in the browser of someone who visits their page. The way you'd use a secret token is a little more complex, and it involves the cooperation of client side code. An ajax application could increase security by using a secret token in the following way: Assuming the user is logged in and has a session cookie: 1. When the server sends a page to the browser, it embeds the secret token in the page. On the server side, the token is associated with the session ID of the visitor 2. When the client side code in the page does a request (ajax) to the server, it includes the token as a parameter (and the session as a cookie automatically) There are two kinds of leverage the server has at this point that it would not have had without the secret. First, it can check what kinds of actions are valid for that token/session combination. For example, the token sent out with an edit account details page might allow for changing the first name of the person, but not manipulating their orders. Second, the server can revoke the token under a variety of conditions. If the referrer is wrong, if too much time has gone by, if a new page has been requested, if a request not allowed by that token is attempted, etc. -Nathan .:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.: ||:. Nathan Young Cisco.com-Interface Development A: ncy1717 E: [EMAIL PROTECTED] -Original Message- From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin Sterling Sent: Tuesday, April 03, 2007 12:10 PM To: jquery-en@googlegroups.com Subject: [jQuery] Re: Web 2.0 is vulnerable to attack How about posting some example code that shows an example of how secret one time tokens can be created and used within jQuery. I second that. It would go a long way in educating me on the proper way of doing things. -- Benjamin Sterling http://www.KenzoMedia.com http://www.KenzoHosting.com
[jQuery] Re: Test for a function being defined
if (typeof(modify)==function){}
.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:
||:.
Nathan Young
Cisco.com-Interface Development
A: ncy1717
E: [EMAIL PROTECTED]
-Original Message-
From: jquery-en@googlegroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of Shelane Enos
Sent: Tuesday, April 03, 2007 4:41 PM
To: jquery-en@googlegroups.com
Subject: [jQuery] Test for a function being defined
Is there a test to know if a function has been defined or declared?
function modify(){
...my code
}
if(function('modify'))
or something like that?
[jQuery] Re: Moving to Google Groups (Finally)
Bullets and numbering!!! Front Page 97!!! For my serious vote: top post with the whole thread quoted. N The worst thing ever?? Come on. Have you tried Microsoft Bob? On 4/4/07, Chris W. Parker [EMAIL PROTECTED] wrote: On Wednesday, April 04, 2007 2:48 PM Glen Lipka said: Top posting, bottom posting. (Age old dillema - or at least 10 years old) Is it acceptable to erase the message and just post? Like this? That's the worst thing ever! It makes it almost impossible to get context unless you've already been following along with the entire thread. Or should I have said that here? On a serious note, I think it totally depends on the mail reader. For example, I use Gmail. I tag everything from the group with a label and archive it. (Using a filter). Gmail happens to be really good at keeping the thread together and I never delete anything. I literally have the entire thread on the screen. Its almost like a forum with no pagination (pagination-yuck). However, on a different client (like Outlook or Outlook Express) you get a totally different view. Those clients are not designer to keep everything. There context is much more important. I would venture to say that this is a touchy issue. Everyone has a view on it, usually based on the view of their mail client. ;) So is there an ettiquette rule to follow here on 1. What to delete when replying (if any) and 2. Where to post? (top or bottom) G
[jQuery] Re: Body Browser Classes
Hi.
I love this idea, it's inventive and the need is there.
The only feedback I have is that CSS that depends on JS will absolutely
not fly where I work and play.
Nathan
Feedback desired:
Lately, I have been developing CSS and HTML for a deep Web
2.0 complex app. Usually, I avoid CSS hacks like the plague.
But recently, I have had to resort to the Holly Hack or the
StarHTML Hack. But then it occured to me that jQuery
provides a better way.
A simple plugin could be written (has this already been
written?) that tags the BODY (or other node) with a browser
class resulting in:
body class=FF or body class=IE6 or body class=Saf
or whatever. Then your CSS would be:
body.ie6 div.troublesome {height: 100%} rather than
* html div.troublesome etc
This makes your CSS avoid bizarre invalid hacks and use
normal conditional classes that are self-documenting.
Everyone knows that body.IE6 means you are adjusting for
browser differences. And jQuery is much better at detection
than crazy hacks.
I wish all my CSS could do it right and find the common
ground that all the browsers love. But this seems like a better way.
What is your opinion?
Anyone want to write a plugin that allows for $(body).browserTag()?
Personally, I think this would be a cool thing in the
basecode, but I wont push it.
Glen
[jQuery] Re: JavaScript Hijacking - Jquery among the vulnerable ones
Hi. In reality, I have yet to see any evidence that this problem actually exists in the wild. I'd caution against dismissing this possibility out of hand. A potential hacker would need to find a site that delivers private data in this very specific fashion, build a page to exploit that, then have you visit his page AFTER you have already logged in and established a session on the other site. It's really the second point that seems to make this unlikely but please consider that some very high profile sites have exposed XSS vulnerabilities. The myspace worm for example got millions of hits: http://namb.la/popular/ Don't think that hasn't happened on that scale elsewhere (it has) or won't happen again on another equally high profile, high traffic site (it will). The key is that any site that has a XSS vulnerability can be used by an attacker to do session riding on everyone who visits. A potential hacker would need to find a site that delivers private data in this very specific fashion This is still true, so if you care, don't publish your data this way. --Nathan -Original Message- From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Matt Kruse Sent: Monday, April 16, 2007 8:01 AM To: jQuery (English) Subject: [jQuery] Re: JavaScript Hijacking - Jquery among the vulnerable ones On Apr 16, 9:11 am, Scottus [EMAIL PROTECTED] wrote: The single take away (true point) they don't point out is that if you use any javascript hosted on a remote server (google adwords for example) fully compromises any page that host these scripts. I don't think that has anything to do with the article. So for any site that needs security Don't host third party scripts/content problem solved. Not at all. That has nothing to do with it. I think your conclusions are based on a misunderstanding of the article. The true take away of the article is something that has been known for a long time, and rarely actually exists in reality: Don't deliver a JSON response containing private information that consists of an Array literal as the base object, in response to a GET request that uses only session authentication. In reality, I have yet to see any evidence that this problem actually exists in the wild. It's a theoretical security concern (not even a flaw) that is interesting but has very little practical application. A potential hacker would need to find a site that delivers private data in this very specific fashion, build a page to exploit that, then have you visit his page AFTER you have already logged in and established a session on the other site. In other words, that's not going to happen. IMO. Matt Kruse
[jQuery] Re: Library showdowns
Hi.
Can you describe a problem whose solution becomes much easier by using
currying?
-Nathan
From: jquery-en@googlegroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of Sean Catchpole
Sent: Monday, April 16, 2007 8:17 PM
To: jquery-en@googlegroups.com
Subject: [jQuery] Re: Library showdowns
Jeffrey and Glen,
Allow me to explain currying. Imagine if you will the following
function (written in javascript)
add = function (a,b) { return a+b }
I can now call add(3,7) and it will return 10.
A language that allows currying would allow me to pass only one
variable and it would return a new function that takes a single
variable. ex: add(3) would return a function that adds three to the
input. Here is an example way of implementing it in javascript:
add = function (a) { return function (b) { return a+b } }
Now I can call add(3) and it will return function (b) { return
3+b }
In the same sense as the first example we can now call add(3)(7)
and it will return 10.
This allows for lots of cleverness in use of functions and
ultimately make functions far more reusable. I consider it a great
advantage of functional programming. So as you can see, the same effect
can be created, but it's tedious. I'm trying to come up with a trickier
way so that it's not so painful to create a curried function in
javascript.
~Sean
[jQuery] Re: Library showdowns
Thanks for the reply!
If I understand your problem statement this is something I'd currently
solve using closures, is there a way that using currying is
fundamentally different or is it a different way of thinking about the
same problem?
---Nathan
From: jquery-en@googlegroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of Rhapidophyllum
Sent: Tuesday, April 17, 2007 6:36 PM
To: jquery-en@googlegroups.com
Subject: [jQuery] Re: Library showdowns
There are some situations when you can only pass a variable
referring to a function; with a curry function you can pass a variable
that refers to a function + arguments.
A problem, though, is that some curry functions seem to go a
little beyond this basic functionality, behaving differently with
different numbers of arguments. (I'm thinking of the dojo curry
function, which is based on one from a certain language.) I don't
follow it exactly when it does this, but it makes me leery of using it.
On Apr 17, 2007, at 6:38 PM, Nathan Young -X ((natyoung -
Artizen at Cisco)) wrote:
Hi.
Can you describe a problem whose solution becomes much
easier by using currying?
-Nathan
From: jquery-en@googlegroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of Sean Catchpole
Sent: Monday, April 16, 2007 8:17 PM
To: jquery-en@googlegroups.com
Subject: [jQuery] Re: Library showdowns
Jeffrey and Glen,
Allow me to explain currying. Imagine if you
will the following function (written in javascript)
add = function (a,b) { return a+b }
I can now call add(3,7) and it will return 10.
A language that allows currying would allow me
to pass only one variable and it would return a new function that takes
a single variable. ex: add(3) would return a function that adds three to
the input. Here is an example way of implementing it in javascript:
add = function (a) { return function (b) {
return a+b } }
Now I can call add(3) and it will return
function (b) { return 3+b }
In the same sense as the first example we can
now call add(3)(7) and it will return 10.
This allows for lots of cleverness in use of
functions and ultimately make functions far more reusable. I consider it
a great advantage of functional programming. So as you can see, the same
effect can be created, but it's tedious. I'm trying to come up with a
trickier way so that it's not so painful to create a curried function in
javascript.
~Sean
[jQuery] Re: Best way to determine if a user has Javascript enabled?
Hi. There is another surefire solution to getting a site that works with JS and non-js usage, and that is to bifurcate the experience quite early on and send the two sets of users down very different paths. In that case, JS users see one set of pages and non-js users see another. ---Nathan -Original Message- From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] idea pages shouoglegroups.com] On Behalf Of Rey Bango Sent: Friday, April 20, 2007 7:35 AM To: jquery-en@googlegroups.com Subject: [jQuery] Re: Best way to determine if a user has Javascript enabled? Hi Rick, Let me summarize what everyone is saying before this turns into a long thread. Basically, there's no easy and surefire way of determining if JS is enabled on the browser. You need to code your forms and pages in the traditional way that you would any non-JS application. Once you have those pages working correctly with proper server-side validation and handling, then you can look at progressive enhancement to extend the functionality of your pages by leveraging JS, DOM-manipulation and Ajax. I realize that you're trying to find a way of doing this from a server-side perspective but you're going to end up building a hodge-podge solution that will not be effective. You have some really sharp people giving you the right advice and since I want you to be successful, I highly recommend that you follow their suggestions. This is the *only* surefire way of ensuring that browsers that have JS disabled will work properly on your site. Otherwise, its a shot in the dark. Rey... Rick Faircloth wrote: That's what's motivating the question. I'm trying to take Progressive Enhancement, as I see it, one step further by integrating the enhancement into the server-side process, where possible and applicable. This part concerns return validation result messages back to the form page, or rather back to the page itself, since I'm currently posting the form back to the page its own. If JS is disabled, then I would simply have to refresh the page. If JS is enabled, then I could use taconite to place messages on the page without refresh...if I'm understanding everything correctly. Rick
[jQuery] Re: Best way to determine if a user has Javascript enabled?
Hi. Another way to think of it is: 1. Develop a site that works without JS 2. Work out ways to enhance each page using JS 3. step 2 may result in JS users not seeing whole classes of pages, but you have a fall back at any point. This discipline may result in a better application design and may result in a faster site and may give better options for performance enhancement. Or not. It's almost certain to be more accessible and to provide a better no-js experience. Nathan -Original Message- From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Rick Faircloth Sent: Tuesday, April 24, 2007 8:18 PM To: jquery-en@googlegroups.com Subject: [jQuery] Re: Best way to determine if a user has Javascript enabled? As much as I dislike the idea of having to develop two different sites or, sometimes, just different pages, it seems like that is the only way to accommodate both JS and non-JS users. I know jQuery can be used unobtrusively, but in some cases that just doesn't seem to be a workable approach. For instance, one use I plan for jQuery is with calendars I develop. These are calendars which have one row with columns for date, time, event, and location. Usually, I put a details link on the row for the page to refresh and reveal the details beneath the main row. That works well, but would be much better with a slide and show jQuery effect. However, if JS isn't working, the details for every row in the calendar will be showing and that's a no go. Perhaps there is a way to cause the calendar to default back to its original functionality with a page refresh. Or the alternative is to develop two pages and send the user with JS to the JS page and the non-JS user to the non-JS page. Thoughts? Rick -Original Message- From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Nathan Young -X (natyoung - Artizen at Cisco) Sent: Tuesday, April 24, 2007 3:48 PM To: jquery-en@googlegroups.com Subject: [jQuery] Re: Best way to determine if a user has Javascript enabled? Hi. There is another surefire solution to getting a site that works with JS and non-js usage, and that is to bifurcate the experience quite early on and send the two sets of users down very different paths. In that case, JS users see one set of pages and non-js users see another. ---Nathan -Original Message- From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] idea pages shouoglegroups.com] On Behalf Of Rey Bango Sent: Friday, April 20, 2007 7:35 AM To: jquery-en@googlegroups.com Subject: [jQuery] Re: Best way to determine if a user has Javascript enabled? Hi Rick, Let me summarize what everyone is saying before this turns into a long thread. Basically, there's no easy and surefire way of determining if JS is enabled on the browser. You need to code your forms and pages in the traditional way that you would any non-JS application. Once you have those pages working correctly with proper server-side validation and handling, then you can look at progressive enhancement to extend the functionality of your pages by leveraging JS, DOM-manipulation and Ajax. I realize that you're trying to find a way of doing this from a server-side perspective but you're going to end up building a hodge-podge solution that will not be effective. You have some really sharp people giving you the right advice and since I want you to be successful, I highly recommend that you follow their suggestions. This is the *only* surefire way of ensuring that browsers that have JS disabled will work properly on your site. Otherwise, its a shot in the dark. Rey... Rick Faircloth wrote: That's what's motivating the question. I'm trying to take Progressive Enhancement, as I see it, one step further by integrating the enhancement into the server-side process, where possible and applicable. This part concerns return validation result messages back to the form page, or rather back to the page itself, since I'm currently posting the form back to the page its own. If JS is disabled, then I would simply have to refresh the page. If JS is enabled, then I could use taconite to place messages on the page without refresh...if I'm understanding everything correctly. Rick
[jQuery] Ajax application history
Hi. We've learned over time to build in backbutton functionality and bookmarkability to our DHTML widgets or at least try to ascertain what our clients will want ahead of time... Just because although people usually don't think to ask up front, often when they use the application a bit and they can't bookmark, paste URLs, or use their browser back button they come back asking for some or all of those. This library takes a simple approach to creating at least a model that could be used to address all of those in a coherent way: http://codinginparadise.org/projects/dhtml_history/README.html Is there similar thinking in the jQuery world? I've seen: http://www.stilbuero.de/jquery/history/ And http://www.mikage.to/jquery/jquery_history.html Which I _think_ are more specific and partial solutions, unless maybe I've missed some documentation for those. Nathan
[jQuery] Re: Ajax application history
Hi. The original link I sent: http://codinginparadise.org/projects/dhtml_history/README.html Had callbacks as well. In other words, your application would log history waypoints where each waypoint represented a state change in the application. These waypoints would consist of a name for the waypoint as well as a set of data that could be used by the callback to re-construct the critical aspects of that state of the application. When a user clicked the back button, the callback would get triggered and passed the data appropriate to reconstruct the state of the application. I can envision many scenarios where re-constructing state would be hideously complex. For tabs or something similarly simple, it would be totally doable. Desktop applications for the most part don't have much application state (anyone else an Opera fan?) but they pretty regularly have control z for edit rollbacks. Nathan -Original Message- From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Sean Catchpole Sent: Thursday, April 26, 2007 9:33 PM To: jquery-en@googlegroups.com Subject: [jQuery] Re: Ajax application history Nathan, A long time ago I made a simple proof of concept script on this: http://www.sunsean.com/Jistory/ ~Sean
