Hi Grant > Langdon - I am still in two minds as to whether a non-Javascript > version is really necessary. Because if it is, then I'll need to > write some alternative functionality in some places. But being able > to use the app on my mobile phone really does sounds neat. > Can you expand on what Ajax specific actions you may create?
Sure. The apps that I have created that use AJAX use it to combine multiple forms or functions into one page. This allows the user to see (and manipulate) multiple layers of information in one screen like: - A production Batch -- Its Operations --- Each Operation's Inputs and Outputs ---- Each Output's Storage Instances and so on. The best comparison would be something like Windows Explorer with the tree displayed on the left, versus Explorer without the tree. With the tree you can drill down into you file system without having to change the whole screen. Ajax can help you deliver this kind of functionality in an application. Without the tree you are only seeing one directory at a time. This is much more like the kind of functionality that a non-ajax application is limited/suited to. > The vast > majority of our controllers just have CRUD actions, so there is very > little difference whether the action is called from Ajax or a normal > form submission. Given that situation (and I have one the same in the big app I am working on at the moment) then I just revert to non-ajax. The performance benefit would be minimal since I would still be rendering most of the page. Also I don't see a benefit to the client and to me in complicating the development and maintenance of the site to support AJAX where it isn't really required. The only reason that I would do so would be to maintain consistent behavior in the interface (which may be reason enough of course). > Anyway, as for the method that I've currently employed. This is > working well, but I would appreciate any comments as to how this > method would / wouldn't be appropriate for your own applications. > > The problem identified is that while the actual functionality of a > controller action should be the same no matter how it was called, each > UI may expect a different format response (ie rendered HTML, > redirects, JSON, AMF). A simple example of a common action would be: <snip> > The disadvantage to this approach is that there are bound to be fringe > cases where something non-standard needs to happen, for one particular > UI. And this will mean either adding options to the passed array, or > adding UI request type checks to the actual actions... I'm > particularly interested if this looks like it could not work with your > app. Reading the above I got a strong feeling of complexity. I use Cake to try to speed up my development and maintenance of web applications. Therefore I am very reluctant to complicate things. I would want to have a very good business case before I built in so much complexity, which as you say is likely to have boundary cases that aren't covered. My personal opinion is: if it is not explicitly required by the project for its success, then don't include it. All it will do is make your maintenance and modification harder down the track. Hope that this might be useful :-) Regards, Langdon --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
