AJAX, but how?

[Guest]

Hello people. I'm trying to learn this concept but something just don't want to work.

I have tried some Ajax-codes like <cfgrid> or <cfinput type="datefield"...> but it did'nt work.

The calender, that should be shown is simply not there.

I've read that is no need to install some plug-in. Is that correct?

Please, what I am doing wrong.

Thank you.

Cristiano

<cfform>
     <cfinput type="datefield" name="Date" />
</cfform>

[Dan_Bracuk]

What version of coldfusion are you running?

[Guest]

I'm running the version CF 8.

And I use Dreamweaver CS4 to developp my pages.

Is there a problem with my version?

Thank for your help.

Cristiano

[BKBK]

Coldfusion needs its Javascript library to do AJAX. Your Coldfusion installation might be missing that library. On my installation, the location of the scripts is C:\ColdFusion8\wwwroot\CFIDE\scripts\. What is it on yours?

[Guest]

You're right. I don't have this on my computer installed. But waht can I do now? It's possible to install this and where can I find this library?

Thank your for the helpfull reply.

Cristiano

[BKBK]

It is an in-built library that is installed automatically when you install Coldfusion. Have you in your Coldfusion installation searched for the directory named scripts?

[Guest]

HI BKBK, thanks for your help. I found the directory in my HD. But it is in another directory.

What can I do now, that I have found this? Should I copy this into the correct directory.

I found the directory in: C:\Inetpub\wwwroot\CFIDE\scripts

No idea why that's there.

regards

[BKBK]

function(){return A.apply(null,[this].concat($A(arguments)))}

I found the directory in: C:\Inetpub\wwwroot\CFIDE\scripts

No idea why that's there.

That suggests you chose during installation to set the web server. The alternative would have been to choose Coldfusion's own in-built web server.

The directory you found is correct. It is the standard directory for running Coldfusion with IIS as web server. Since you know nothing about it, I have to assume that you mistakenly made that choice during installation. If you had chosen the in-built web server, the corresponding directory would have been C:\Coldfusion8\wwwroot\scripts.

There are two ways to go from here. Either configure Coldfusion to use its own in-built web server(JRun), or else just continue with IIS as web server.

If you are not yet comfortable with Coldfusion or IIS, then I would advise the first solution. You may uninstall Coldfusion, then re-install it, choosing the the in-built web server (There will be a screen offering you the choice). This has the advantage of being a clean beginning.

If you find that drastic, then you can simply disable IIS as web server. To do so, follow these steps (Beware: I am running on instincts here. What follows is untested, and the risk is yours):

1)  Copy (without deleting) everything from the directory  C:\Inetpub\wwwroot\ to the directory  C:\Coldfusion8\wwwroot\. That will be the new web root directory;

2) Navigate to Start=>Programs=>Adobe=>Coldfusion8 and open the Web Server Configuration Tool. (Alternatively, double-click on the file C:\Coldfusion8\runtime\lib\wsconfig.jar);

3) Remove any web servers in the list;

4) Restart Coldfusion, and you're done.

5) Test by opening http://127.0.0.1:8500/CFIDE/administrator/ in the browser.

If, instead, you decide to continue with IIS, then you should configure IIS for use with Coldfusion.

[Adam Cameron.]

Whoa there!  There's no need to deinstall, disconnect or reconfigure anything.  The IIS/Apache/etc option during the CF install is in addition to the JWS, not instead of it.

Check the jrun.xml file to see what port JWS is listening on.  It's in this section:

  <service class="jrun.servlet.http.WebService" name="WebService">

<!-- other nodes removed for clarity -->

    <attribute name="port">8300</attribute>

So my JWS install is listening on port 8300.

--

Adam

[BKBK]

> Whoa there!  There's no need to deinstall, disconnect or reconfigure anything.

> The IIS/Apache/etc option during the CF install is in addition to the JWS, not instead of it

.

The in-addition-to versus instead-of argument is irrelevant. If KaktusCris had inadvertently had IIS installed, and is uncomfortable with it or no longer wishes to use it, then he should disable it. A well-known rule of thumb in our profession is to disable modules you don't use.

> Check the jrun.xml file to see what port JWS is listening on.  It's in this section:

It comes down to the same thing. Configuring web servers by means of the Web Server Configuration Tool, as I suggested, is equivalent to modifying the appropriate system XML files. However, the XML route carries the risk that a beginner may easily make a change that disrupts the Coldfusion server.

[Adam Cameron.]

Sorry, you seemed to be suggesting that one needed to deconfigure IIS and do some additional configuration to get JWS working.  Which one does not.

Indeed that's still how your instructions read to me, even though you've clarified that you did not mean that.

   Check the jrun.xml file to see what port JWS is listening on.  It's in this section:

It comes down to the same thing. Configuring web servers by means of the Web Server Configuration Tool, as I suggested, is equivalent to modifying the appropriate system XML files. However, the XML route carries the risk that a beginner may easily make a change that disrupts the Coldfusion server.

Go on then... how does one determine the port the JWS is using via wsconfig?

--

Adam

[Adam Cameron.]

It might be an idea to use Firefox for your development browser rather than IE, as it has more functionality for developers and better error reporting.  Are you getting any JavaScript errors as well?  The broken image icon will be looking for /CFIDE/scripts/ajax/resources/cf/images/DateChooser.png.  Can you browse to that file?

In your website in IIS do you have a /CFIDE virtual dir pointing to C:\inetpub\wwwroot\CFIDE?

/localhost:8300/CFIDE/scripts/ajax/resources/cf/images/DateChooser.png

--

Adam

[BKBK]

localhost:8300

Shouldn't that be localhost:80?

[Adam Cameron.]

More to the point, it should not be in there at all.  I'm not sure how that got into my post.  Will remove.

[update: Hmmm... cannot edit posts after someone's replied ot them, it seems 😞 ]

--

Adam

Message was edited by: A Cameron

[BKBK]

> More to the point, it should not be in there at all.  I'm not sure how that got into my post.

> Will remove.

> [update: Hmmm... cannot edit posts after someone's replied ot them, it seems 😞 ]

I have been having problems submitting. The forum software appears to have hiccups, and keeps adding strings like function(){return A.apply(null,[this].concat($A(arguments)))}. However, I haven't modified the content.

[Adam Cameron.]

Oh, no, I was not suggesting you'd modified my post.  I definitely did accidentally past that URL into my post whilst I was writing it, but equally I had removed it before posting.  Or at least what was sitting in front of me on the screen had suggested I had removed it.

However this forum software is a bag of shite, and does seem to struggle with fairly rudimentary tasks like "copy" and "paste", so it doesn't surprise me it struggled to understand what I mean when I selected that text and pressed "delete".  And similarly it seems to be munging your posts as well at present: I figured it was the forums software and not you inserting that dodgy text in your posts.

Anyway, the crux of the matter is that bit you drew my attention to was never supposed to have been in my post in the first place.

--

Adam

[TLC-IT]

There are, as usual, "several ways to do it."  The first thing to do is to figure out ... from the browser's point of view ... what's going on.

Either by viewing the page-source or with FireBug (or IE's Developer Toolbar), look at what is being sent to you by the host.  Then, notice the <script> tags and, in a separate browser window or tab, see if each of them actually lead somewhere.  (FireBug will take a lot of the work for you, because if a script-tag could be followed, the script will show up in the "scripts" pulldown.)

You can also look at the headers of the HTTP reply to see, definitively, which web-server actually responded to you.

Armed with this information, and a good pencil and pad-o-paper, you can sleuth this problem pretty completely.  The user's browser obviously needs to have received a coherent HTTP response, and it needs to succeed in retrieving all of the JavaScript content referenced in all of the script-tags.

Once you can clearly see what you're actually dealing with, the resolution should be straightforward.

[Guest]

Thank you everyone that helps me.

regards

Cristiano