form action and 'this' not working 4

[1DMF]

Hi,

Can someone tell me why the following dosen't work...

<form action="javascript:check_form(this);" id="penform">

shouldn't 'this' pass in the form object?

it works fine if I do it like this...

<form action="javascript:check_form(document.getElementById('penform'));" id="penform">

cheers,
1DMF

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Google Rank Extractor -> Perl beta with FusionCharts

 

[vacunita]

Why would your form action be a javascript call?

Once you check it, then nothing else happens to the information, unless you are actually processing it in your JS.

With that said: like with links the javascript: protocol runs outside the scope of the object. Which means "this", refers not to the form, but to the browser instead.

If you want to be able to use "This" you need to run your Js from one of the object's JS events. Such as onSubmit.



----------------------------------
Phil AKA Vacunita
----------------------------------
Ignorance is not necessarily Bliss, case in point:
Unknown has caused an Unknown Error on Unknown and must be shutdown to prevent damage to Unknown.

 

[1DMF]

Why would your form action be a javascript call?

Because I like writing my web apps utilising AJAX. I don't want anything submitted to the server side unless the data has been veted, validated, cleaned and sent via AJAX. Coding in such a manner dramtically speeds up application development, puts the strain on the client machine NOT the server and just makes it easier to make interactive applications rather than the usual, click , page refresh, click, page refresh method.


Anyways, thanks Phil, not sure I fully undertand what scope the JS protocol does fall under.

or if you mean only 'events' allow the pseudo variable 'this' to be used.

If you had an onclick="myFunc(this)" it would pass the element as an object to the called function.

But I understand that that onclick is an event.

I guess your saying is if you used

<a href="javascript:myFunc(this);">

that wouldn't pass the anchor object either.


"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Google Rank Extractor -> Perl beta with FusionCharts

 

[jmeckley]

Because I like writing my web apps utilising AJAX. I don't want anything submitted to the server side unless the data has been veted, validated, cleaned and sent via AJAX. Coding in such a manner dramtically speeds up application development, puts the strain on the client machine NOT the server and just makes it easier to make interactive applications rather than the usual, click , page refresh, click, page refresh method.

you should still be doing this on the sever because it extremely easy to bypass the client script.
also, the "strain" doesn't come from validation or cleansing. "strain" is typically a result of the number of remote calls (other servers, IO, database) and poor query execution plans. And there are even ways to push this work offline so the website itself is very responsive.

however what you are trying to accomplish is common, with a different approach.
setup the form as you would typical form, without ajax. then apply an OnSubmit handler. in this handler you can scrub the data and send an ajax request and return false. this will prevent the form from submitting the standard way.

jquery has an ajaxForm plugin which makes this dead simple.

Jason Meckley
Programmer
Specialty Bakers, Inc.

faq855-7190
faq732-7259

 

[1DMF]

you should still be doing this on the sever because it extremely easy to bypass the client script.

Extremely easy for whom??? not our members that's for sure.

Don't let in-house, bespoke extranet applications get mixed up with public facing websites ;-)

I know you can use

onsubmit="return myscript(this);"

I just decided I'd use the action instead, it's neither here nor there really.

I'm not having difficulty with the app, I was curious why 'this' didn't pass the form object, that was all.

The thing I have learnt from all this is (correct me if i'm wrong), only 'events' allow javascript to interact with the DOM and pass objects via the 'this' pseudo variable.





"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Google Rank Extractor -> Perl beta with FusionCharts

 

[jmeckley]

Extremely easy for whom??? not our members that's for sure.

while I can sympathize with that statement I wouldn't use this as a driving force of the UI design.

Speaking from experience I have found that designing an ajaxy site upfront usually causes more problems than results. If I design the site as a typical webpage and then apply ajax I find the development process much easier.

Jason Meckley
Programmer
Specialty Bakers, Inc.

faq855-7190
faq732-7259

 

[1DMF]

Hey maybe next time I'll have a go at doing it another way.

Also it's only a very small addition to a massive application. I like to try new things while developing additional stuff.

As I'm the IT department, I can choose to build things what ever way I want, keeps the bordem at bay ;-)

Though I admit I do heavily rely on JS for client side validation, but that's just because it's an inhouse app where I can force JS to be enabled, I have control over the environment and only authenticated users can execute server side code.

I apprecaiate JS should only be used to enhance a webpage, but that's if it's public facing and required to meet accesibility standards.

Anyway's why do you find AJAX causes you problems? I love it, I've written an entire application based on AJAX alone, it works great, looks great, and hasn't caused users any problems whatsoever (well, touch wood), it's still under testing by a small number of users, so I won't blow my own trumpet quite yet ;-)



"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Google Rank Extractor -> Perl beta with FusionCharts

 

[jmeckley]

ajax itself doesn't cause the problem. it's how ajax can influence the flow of the UI that can be a problem for me (no the end user).

here is an example from a recent project. using jquery tabs I took 5 work flows and loaded them into one screen. In effect each tab was an atomic context to anything else on the page. each tab required a unique set of scripts for prettiness and/or functionality.

since the content was loaded using ajax I couldn't fire the "page loaded" scripts based on document.ready because the content was loaded via ajax. I didn't want all the scripts loaded when the page was first loaded, because not all of the scripts were needed.

so the solution I came up with was to put the scripts directly in the html content. Not my first choice but it worked, and the previous decision about the tabs made it necessary (at least with my skill set).

The mistake I made was using tabs for a context which didn't lend itself to the tabs in the first place. Had I designed each page with the ajax loading I would have realized this wasn't a good choice.

from the user's perspective everything works and works nicely. but from a developer's perspective I have scripts thrown all over the place and it's tedious to evaluate what's happening because of this. I can also rule out any form of automated tests for my scripts.

To sum up this rather long post... the problem premature ajax usage causes me is the ongoing cost of UI maintenance. Ajax in itself isn't the problem, but how I used (abused) it to solve a problem.

Jason Meckley
Programmer
Specialty Bakers, Inc.

faq855-7190
faq732-7259

 

[1DMF]

so the solution I came up with was to put the scripts directly in the html content.

Why?


Did you know you can change the source of a script tag and it loads the required JS file for you, it also doesn't remove previously loaded JS from memory.

That way you only load the JS files as required.

The other way is to use AJAX to get the JS and then parse the returned HTML (script code) using

eval(myHTML)

But I know what you mean, when I first found AJAX, I thought wow, went steaming off making things AJAXified thinking how cool am I, and learned the hard way about the downside and things that need to be done differently when using the AJAX method.

Even the state of forms can be a pain where you need to have something remembering what radio/checkbox elements were ticked and then setting them correctly.

I also found out that bit about how to dynamically load scripts because I hit a similar problem to you.

But I guess it's no different than going from procedural programming to object orientated, it's a different mindset, but once you get your head round it, the development just comes natuaraly and you don't even think about some things you just do them kind of on auto pilot.







"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Google Rank Extractor -> Perl beta with FusionCharts

 

[jmeckley]

because it's all I knew at the time.

I didn't realized you can change the source of scripts. this might be worth investigating.

I know about eval(), but I have read that is should be avoided because it opens up the possibility of scripting attacks.

Jason Meckley
Programmer
Specialty Bakers, Inc.

faq855-7190
faq732-7259

 

[vacunita]

Seems like I missed a very interesting Ajax debate.

Just to explain a bit more about the scope:

The javascript: protocol in a form action or a link href runs outside the object's scope because its a browser action not an element action. It tells the browser what to do, not the element its in.

Its pretty much the same as just typing it in the address bar, and hitting enter.

Since its scope is the browser, "this" now points to the browser window instead of the form.

Its like slapping an address label outside a box. You aren't immediately able to use the contents of the box.
You just know what to do with it.



----------------------------------
Phil AKA Vacunita
----------------------------------
Ignorance is not necessarily Bliss, case in point:
Unknown has caused an Unknown Error on Unknown and must be shutdown to prevent damage to Unknown.

 

[1DMF]

Ahh, nice one Phil.

Thanks for explaining, makes sense now.

It always helps when you know what 'this' is referring to!

Plus knowing what 'javascript:' actually means, I never realised it was a protocol reference as just like 'http:' wow, you learn something new everyday here at TT.

Still the best Techie form on the planet!

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Google Rank Extractor -> Perl beta with FusionCharts

 

[1DMF]

*Still the best Techie forum on the planet!

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Google Rank Extractor -> Perl beta with FusionCharts