Hi, Johnny! > Sorry if I am being hard on you, but I think I saw this kind > of responses from you several times in the past. You know if > you don't have the answer, maybe you shouldn't reply. > > You should know by now that for every problem, there is a > solution, in our field anyway. Just because you don't know > it, it doesn't mean it doesn't exist. Did you expect Flash > to have the file upload capability? Well, it does now. There > must be some magic mechanism happening somewhere along the > way there. So what I expect is for my CFC to be able to > access my session scope or to pass it in in my CF site. I > don't think that is too much to expect.
I'm a big boy; I don't mind a little criticism. So feel free! And yes, I'm sure to be wrong plenty of times. But sometimes, when you (or anyone else) asks "how do you do x", the answer will simply be, "you can't do x". Unfortunately, it is simply not true that for every problem, there is a viable solution, especially within our field. There are a lot of things that simply can't be done within web applications. The use of an HTTP request-response model imposes lots of constraints. Very often, the "solution" is to take a different approach. For example, if you asked me how you could push data from the server to the browser, I would tell you that you can't. HTTP simply doesn't work that way. However, you could approach the problem differently, and have the client pull data from the server frequently enough to appear as if the data were being pushed to the browser. One of those constraints is that you don't have a "live", asnychronous connection between your client and the server. Every time you want data within the client, the client must issue an HTTP request, and the server must respond to it. Furthermore, the response given by the server will be text. So, within an AJAX application, the JavaScript code running in the browser can't just "see" variables that exist within memory on the server. Those variables must be transposed as text, one way or another. (Even environments where this doesn't appear to be happening, such as SOAP services that return objects, are still just passing strings of text around.) Basic knowledge of how HTTP works is crucial to understanding what you can and can't do within a web application. For example, there's no innate reason why Flash couldn't have handled file uploads in the past, because when you upload a file, it's converted to text and sent just like any other HTTP request (well, almost - it typically uses a slightly different MIME type). So, there's no magic mechanism there. Now, as for AjaxCFC, I haven't worked with it, so I don't know exactly what it does. But I do know that it's constrained to the HTTP request-response model, so I have a good idea of what it can possibly do. If it's going to expose variables that you can access from JavaScript, it's going to have to write text within an HTTP response. That text might be JavaScript statements that create variables that can be accessed from your JavaScript code, it might be XML (as Jim Davis indicated, that might provide some advantages). But in any case, if it's not already writing the variables you need, you'll have to change something so that it does. You will not be able to access ColdFusion variables directly from your client-side JavaScript code. This is a crucial thing to know, and it's why I gave you the answer that I did. > LOL. I know Dave is very knowledgeable. A lot of his > answers were right on the spots and I greatly appreciate it, > but occassionally he has one of these responses that make > beginners feel very uncomfortable to ask questions. > Fortunately I am not a CF beginner, otherwise I would be > afraid to ask questions. There are a lot of things that CF > does are way beyond my expectations. To me, CF is full of > magics. I learn new things everyday. So if I only do what I > expect CF to do, I wouldn't know much. > > On the other hand, I am an AJAX beginner and now I am afraid > to ask my Ajax questions because I really don't know what > AJAX is capable of or not capable of yet. I don't want to > feel stupid for asking crazy questions. Where I work we have > a client who complained that when she clicked on the home > icon, the door didn't open. I really don't want to be that > lady on this list and he kinda makes me feel like one. > > Again, I know Dave is an invaluable member of our list and I > really appreciate him taking the time to response, but I just > want him to be aware that he is hurting beginner people with > that kind of responses. So I hope that he won't be mad at me > for pointing it out. My intent in responding was not to make you feel uncomfortable, or to discourage you from asking questions - even crazy questions. I certainly don't want you to feel stupid, because I'm sure you're not. And no, I'm not mad at you. As an instructor, I say to my students "there's no such thing as a stupid question". I hear that from other instructors as well. Of course, that's not really true. There are plenty of stupid questions. But who cares? You're much better off asking questions as they occur to you, than trying to figure out if a question is worth asking. I just took a class last week, and asked tons of questions - some stupid, some not - and I wouldn't have learned nearly as much if I worried about the quality of my questions beforehand. If you can learn any one thing from me, the best thing to learn would be that you should just ask whatever you like, without worrying what people will think of you for asking. If you could learn one other thing from me, it would be that the idea of "magic mechanisms" is counterproductive. There really isn't any mystery about how CF works, or about how HTTP works, or AJAX, or Flash, and so on. Knowing the limitations of your environment is one of the most important things you can learn. For example, as an experienced CF developer, you probably have a pretty good idea of what is possible in AJAX and what isn't, even if you don't know it yet! The lessons you've learned about how HTTP requests and responses work, still apply to AJAX. The only salient difference is that you can separate the HTTP request-response cycle from your application interface, using JavaScript to control the interface instead of going from one document to another at every step within your application. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:234210 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
