I am currently evaluating grid components for our new portal project. I came across the jqGrid which I find quite interesting. One requirement I have is that the portal should work with javascript switched off.
I found this article on StackOverflow but it does not answer the question. Does anyone can tell me how jqGrid is dealing with this?
In the question which you referenced I could fine the following
Can we create the table using C# and then lay the JS over the top for
extra functionality?
Is it what you plan? Do you want that your portal works without JavaScript and produce pure HTML tables which hold the data without any Ajax requests, but in case of the user do has JavaScript on you want to use JavaScript, jQuery and jqGrid?
In the corresponding answer it was suggested to use tableToGrid function to convert the existing HTML table inclusive the contain to the jqGrid. It seems me the way which you can also follow. Why you are not satisfied with the answer?
To tell the trust I have no customers more where JavaScript is switched off. Do you want to develop the portal for some mobile devices or some other special endpoints which has no JavaScript? In my opinion JavaScript have to be on to be able to use Internet for the better productivity. So the portal which work without JavaScript will have the interface which is not up to date now. Either you have very special customer environment or the requirement seems me too hard.
Related
I am trying to include a ShieldUI chart and grid in an existing site that uses a View/Viewmodel setup. I have the underlying js functions pulling in the data from an API using an Ajax call and defining the ShieldUI controls but I have been unable to display the controls in the html pages.
I have tried to put the JavaScript code in the HTML pages but it is not able to access the API data. In any case, I would prefer to keep the JavaScript code in the HTML pages to a minimum.
Is it even possible to do this? Or is ShieldUI the wrong product?
It is possible. I have done it, having worked it out for myself. Although I paid for the premium Shield UI product, with support, Shield UI provided no support, documentation or examples to assist.
Even though Shield UI is less expensive, it is not the right product if you don't know exactly what you are doing. A more expensive product might be better. If you do know what you are doing, use a free product.
My users browse products and add some of them to their baskets.
I use KnockoutJS to update the listing of the basket content.
However, users can open product links on multiple tabs/windows in the same session and pick one product on the first, another product on the second tab. I'd like to display the same basket content on each page, of course.
Is KnockoutJS able to update the DOMs of different tabs simultaneously?
I'd like a solution which updates the changes only, and immediately as KnockoutJS does on a single page. I was mentioning a basket to illustrate the problem, but a basket's content is relatively small and could be retrieved by an AJAX call easily when the user brings up a background tab. The real problem is different views of a huge database, which can be updated in multiple tabs and should look consistent on every tab. It takes several seconds to build up the DOM of a tab.
(This question is NOT about jQuery UI Tabs. The situation is as described in http://thesocialtester.co.uk/20-days-of-web-testing-multiple-tabs-and-windows/)
If the answer is not possible, I'd like to hear about workarounds or good practices.
Thanks in advance.
Knockout does not address the underlying general problem of communicating across browser tabs with javascript. There are other questions on this topic, and the same solutions will be usable with whatever framework you pick.
But no, Knockout makes no attempt to solve this problem.
As stated in the accepted answer, Knockout does not solve the cross-tab problem.
If your problem is strictly confined to the case of synching several tabs in the same browser, then using localStorage to pass messages (as described in this answer cited in the accepted answer seems like a sane solution.
The question is whether you don't really want to go further in solving this problem, and implement some form of server push to your shopping page, which would then also work cross-browser and cross-machine.
In this case, you'd want some solution which uses WebSocket (real server push to the client), possibly combined with a HTTP polling fallback for older browsers (if you need to support those).
I wish to create a drag and drop feature for adding profile picture using CakePHP. Are there any samples which I can follow or a step by step guide?
I sourced many samples online but none of them cater for CakePHP.
I basically need a simple drag n drop for users to drag their profile image and the URL of the image is reflected in the database. The user will be able to edit another profile image. What approach should I use for this?
what you want to do is mostly about front-end, the back-end is generic server handling (in this case, PHP upload handling) and has little to do with Cake. That's why you don't see a specific cake tutorial for this. So, look up jquery drag drop and ajax upload. You'll also need to understand Cake rather well (well enough to adapt those online sample code to your Cake app).
I recommend you to use jQuery UI's draggable and droppable interactions.
Integrating them in CakePHP is quite easy, just follow the manual instructions to include Javascript files in a CakePHP application.
Finally, updating the database to reflect the URL of the image can be easily done with jQuery as well, using the AJAX related methods (e.g. post).
Is there a significant difference in performance between the two for relatively small post-backs? I'm taking in user input on a website, calculating some values from it and the returning it. Adding AJAX with update panel was really really quick obviously, but I'm wondering if I should just use jQuery instead.
Also, how to the two methods compare in their ability to degrade gracefully?
Thanks.
Not to sound like a salesman, but I recently picked up a copy of Ajax Security (http://www.amazon.com/Ajax-Security-Billy-Hoffman/dp/0321491939/ref=sr_1_1?ie=UTF8&s=books&qid=1278874728&sr=8-1) and it had a good one chapter explanation and comparison of various Ajax libraries and frameworks in terms of not only security but also speed. If you don't find your answer, I would recommend that book.
I personally would use jQuery because you have a finer control over what is actually loaded. The Update Panel, as I understand, updates all of its contents. You can't pick and choose what is updated inside it, whereas with jQuery, you have absolute control.
As for degrading gracefully: The only reason I can think of why the Update Panel or jQuery AJAX wouldn't work (assuming the server is configured correctly and there are no errors in the JS) is that the browser doesn't support Ajax. If this is the case, neither methods will work. So, I wouldn't worry about the differences between the two in that regard.
I am trying to find the optimal architecture for an ajax-heavy Django application I'm currently building. I'd like to keep a consistent way of doing forms, validation, fetching data, JSON message format but find it exceedingly hard to find a solution that can be used consistently.
Can someone point me in the right direction or share their view on best practice?
I make everything as normal views which display normally in the browser. That includes all the replies to AJAX requests (sub pages).
When I want to make bits of the site more dynamic I then use jQuery to do the AJAX, or in this case AJAH and just load the contents of one of the divs in the sub page into the requesting page.
This technique works really well - it is very easy to debug the sub pages as they are just normal pages, and jQuery makes your life very easy using these as part of an AJA[XH]ed page.
For all the answers to this, I can't believe no one's mentioned django-piston yet. It's mainly promoted for use in building REST APIs, but it can output JSON (which jQuery, among others, can consume) and works just like views in that you can do anything with a request, making it a great option for implementing AJAX interactions (or AJAJ [JSON], AJAH, etc whatever). It also supports form validation.
I can't think of any standard way to insert ajax into a Django application, but you can have a look to this tutorial.
You will also find more details on django's page about Ajax
Two weeks ago I made a write up how I implement sub-templates to use them in "normal" and "ajax" request (for Django it is the same). Maybe it is helpful for you.
+1 to Nick for pages displaying normally in the browser. That seems to be the best starting point.
The problem with the simplest AJAX approaches, such as Nick and vikingosegundo propose, is that you'll have to rely on the innerHTML property in your Javascript. This is the only way to dump the new HTML sent in the JSON. Some would consider this a Bad Thing.
Unfortunately I'm not aware of a standard way to replicate the display of forms using Javascript that matches the Django rendering. My approach (that I'm still working on) is to subclass the Django Form class so it outputs bits of Javascript along with the HTML from as_p() etc. These then replicate the form my manipulating the DOM.
From experience I know that managing an application where you generate the HTML on the server side and just "insert" it into your pages, becomes a nightmare. It is also impossible to test using the Django test framework. If you're using Selenium or a similar tool, it's ok, but you need to wait for the ajax request to go return so you need tons of sleeps in your test script, which may slow down your test suite.
If the purpose of using the Ajax technique is to create a good user interface, I would recommend going all in, like the GMail interface, and doing everything in the browser with JavaScript. I have written several apps like this using nothing but jQuery, state machines for managing UI state and JSON with ReST on the backend. Django, IMHO, is a perfect match for the backend in this case. There are even third party software for generating a ReST-interface to your models, which I've never used myself, but as far as I know they are great at the simple things, but you of course still need to do your own business logic.
With this approach, you do run into the problem of duplicating code in the JS and in your backend, such as form handling, validation, etc. I have been thinking about solving this with generating structured information about the forms and validation logic which I can use in JS. This could be compiled at deploy-time and be loaded as any other JS file.
Also, avoid XML. The browsers are slow at parsing it, it is a pain to generate and a pain to work with in the browser. Use JSON.
Im currently testing:
jQuery & backbone.js client-side
django-piston (intermediate layer)
Will write later my findings on my blog http://blog.sserrano.com