| We need official AJAX library from CI team ! |
[eluser]Randy Casburn[/eluser]
@Nick, Yes I too handle my complex AJAX based applications on the server side with dedicated controllers/libraries to deal with the security issues that manifest themselves in regard to AJAX vulnerabilities. As far as the client side, I'm also curious to see where they go with the dumping of the JS library into the framework. I'm not sure they will actually implement any JS as part of the core, but we'll have to wait and see. I'm currently actively developing with ExtJS and the Dojo Toolkit. I'm worried about the meaning of jQuery in m favorite framework because of this, but I'll get over it. @Mossab - It is not my intent to offend you. I realize that you believe the least-common-denominator, fewest-lines-of-code, smallest-sized-JavaScript-file solution to your problem is the best answer. I'm willing to accept that is your opinion. What I'm asking you to do right now is accept my opinion too. Here it is as the bottom line: It is better to have the jQuery development team work on the client-side (browser) interoperability capabilities and issues related to all the client-side AJAX problems than it is to burden the CodeIgniter development team with a non-PHP development issue. The result of that means that, yes, we all will have to load up the jQuery.js file to run the jQuery implementation of the XMLHttpRequest() method. You don't have to agree. Randy
[eluser]Xeoncross[/eluser]
CI should NOT tie it's self to any JS libary! Sometimes I need jQuery and sometimes I need Mootools... Also, why would a bunch of talented PHP programmers try to create their own from scratch? That is just a waste of time - let the JS programmers keep building their libraries (which there are way to many of already) and the CI Team can keep making CI great! Also, if you just want a small library for ONLY AJAX just use Mootools - it plugs in great and you can build your own version of it if you don't like the huge 63kb filesize. Use the mootools CORE builder to only download the AJAX part. http://mootools.net/core Take a look at my site if you want an example.
[eluser]oddman[/eluser]
Seems to me that this thread is more about "this isn't how i want it done" rather than "this is how i think it should be done". I've voted no. For me, CI is great because it DOESN'T try and do everything. This is why frameworks like Zend and Cake are so damn heavy - they really try to do everything a dev may want to do. This in itself isn't bad, those frameworks have their place (especially when dev time is important), but when you want performance, they're not such a wise choice. Really, if you want to do AJAX properly, you should be obfuscating your JS completely, and only relying on a lib for the requests (which imo, is rather easy to do yourself). This way, your JS is completely separated from your HTML and makes it very easy to manage, it also keeps your views and controllers nice and clean. I really see this as a non-issue. It is so easy to write server-side AJAX request handlers it's ridiculous. And what's even better is that it will be tailored to your product/service, which means fewer lines to code, and a cleaner application. I've done exactly that for my web-based game. In short, we don't need it.
[eluser]oddman[/eluser]
Adding to my post above, I would be very displeased if CI tied themselves to a particular library - that was half the problem of rails and cake. If you didn't like it, you either had to install a 3rd party plugin, or write your own - which meant even more code being parsed in each request.
[eluser]usmc[/eluser]
Nothing is as good as XAJAX. I see no reason to duplicate what has already been done.
[eluser]oddman[/eluser]
[quote author="usmc" date="1229342063"]Nothing is as good as XAJAX. I see no reason to duplicate what has already been done.[/quote] I disagree. I felt that XAJAX had quite a large footprint for something fairly straightforward.
[eluser]xwero[/eluser]
Javascript should have no ties with a server side programming language. The only connection between javascript and a server side programming language is the url, and only when you add the programming language file extension to the url. I think the concern; why do i need a whole library to add AJAX, is false because if you want you can extract the AJAX parts from the javascript libraries. If you apply this on CI you can say why do i need all those other libraries, i only want MVC. Maybe you don't need the functionality while you are developing one part but you could use it for another part of you application/site.
[eluser]Randy Casburn[/eluser]
[quote author="xwero" date="1229348798"]Javascript should have no ties with a server side programming language. The only connection between javascript and a server side programming language is the url, and only when you add the programming language file extension to the url.[/quote] @xwero, would you agree that JavaScript gets tied up into our presentation to a great degree if we're relying on javascript events to trigger AJAX calls and the like? When considering the entire JS event model (onClick(), onContext(), etc.) we're reminded that all those event handlers get built into our presentation logic when we're coding our View parts of the MVC. Whether this is a form or any other block level HTML element. Many times these are dynamically constructed with a View file using dynamic data as well. AJAX callbacks paths are often generated in this manner for View files. If we consider these points, it makes sense that the client-server environment we are in requires some construction of the client-side foundation on the server. That implies javascript and php will be linked up in some way. I think you hit the nail on the head, it's the choice in how one implements it that drives things. Choice in which library to choose is important to many of us. I'm personally hoping we'll be able to do a drop-in replacement of jQuery once it is included. Randy |
| Welcome Guest, Not a member yet? Register Sign In |
