difference between create an api using magento
standards and create a php file in the root and
get and send response using simple php code.
is there any security reason we use magento standards ?
any difference in speed of response ?
is there any security reason we use magento standards ?
The standard Magento APIs have been tested significantly more than anything that has yet to be written, so, yes, in terms of security, it's better to avoid writing something custom.
any difference in speed of response ?
Yes, Magento's SOAP APIs are terribly slow. Haven't done much testing with the newer REST API, so I'm not sure if that's any faster.
A third, somewhat obvious, point is that Magento's APIs are already written and can be used on any site out of the box (with minimal configuration). Writing a custom API means that it has to be installed on the site before it can be used.
Also, thinking outside of the box, sometimes it's beneficial to reverse the process. Instead of Foo talking to Magento, let Magento talk to Foo. Of course, this depends on what you're doing, but sometimes this is a much better way of implementing a form of communication between Magento and another system.
Related
I have a very-simple php-based website.
I would like to add "subsribe for information" box and send it to some list-management tool.
I found that phplist is quite a good one. However, I don't find any api which allows me to subscribe users using ajax.
(I would like to avoid the pages of phplist in order to avoid confusion due to different design, and also I want the interface to be multi-language).
Of-course I can touch the code, but I doubt that it misses this feature, so I assunme I simply missed it.
Thanks!
Hopefully you have managed how to achieve this already. I have a different use case not requiring AJAX.
Anyway, I've found a script that tries to ease the addition of subscribers to your list. Maybe you could use it as the backend to support your AJAX request.
This is the thread in which the script is shared, as others have found it useful, also for unsuscribing users, even handling massive subscriptions/unsuscriptions:
http://forums.phplist.com/viewtopic.php?t=5009
Finally, be aware this code is using PEAR DB abstraction layer, probably I'm going to use this but without the PEAR package.
I look forward for what you could do through AJAX and this functions.
Currently I use php + ajax to create dynamic web applications. As I realized, sometimes I need to write much more javascript to achieve dynamic appearance than I would need to write just php for 'static' page.
After small research I found websockets / sockets.io. Can I use it instead client-side javascript to achieve the same dynamics (some pagination, reloading website parts without reloading whole page...)?
Another thing is server-side programming language (and framework) for that task. Languages I've been working with:
Python (I would prefer that one)
Javascript / CoffeeScript
Java
Do you know any web framework written in one of those languages that fits my needs?
Non blocking environments/frameworks you might want to take a look at.
JavaScript: node.js
Python: Twisted
Ruby: EventMachine
If your requirement is to reduce javascript ajax thus propose using websockets, it will not help u much. Maintaining socket is beneficial to avoid long polling ajax/rest requests, in your case it doesnt look like much if only to render json for dynamic contents.
Also im not sure where does stateful exist in your requirements.
So stick with your architecure as is
I'm still pretty new to AJAX and javascript, but I'm getting there slowly.
I have a web-based application that relies heavily on mySQL and there are individual user accounts that are accessed and the UI is populated with user specific data.
I'm working on getting rid of a tabbed navigation bar that currently loads new pages because all that changes from page to page is information within one box.
The thing is that box needs to reload info from the database, etc.
I have had great help from users here showing that I need to call the database within the php page that ajax is calling.
OK-so pardon the lengthy intro-what I'm wondering is are there any specific limitations to what ajax can call that I need to know about? IE: someone mentioned that it's best not to call script files and that I should remove scripts from the php page that is being called and keep those in the 'parent' page. Any other things like this I need to keep in mind?
To clarify: I'm not looking to discuss the merits/drawbacks of the technology. I'm wondering about specific coding implementation that I need to be aware of (for example-I didn't until yesterday realize that if even if I had established a mySQL connection on the page, that I would need to re establish that connection in my called page as well...makes perfect sense now).
XMLHttpRequest which powers ajax has a number of limitations. I recommend brushing up on the same origin policy. This is a pivotal rule because it limits where AJAX calls can be made.
First, you can't have Javascript embedded in the HTTP response to an AJAX call. That's a security issue.
No mention of the dynamics of the database, but if the data to be displayed in tabs doesn't have to be real-time, why not cache it server-side?
I find that like any other protocol, Ajax works best in tightly controlled conditions. It wouldn't make much sense for updating nearly the whole page, unless you find that the user experience is improved with an on-page 'loader'. Without going into workarounds, disadvantages will include losing the browser back button / history, issues such as the one your friend mentioned, and also embedded resources and other rich content can suffer as well, and just having an extra layer of complexity to deal with in your app. Don't treat it as magic sauce for your app - make sure every use delivers specific results that benefit your client / audience.
IMHO, it's best to put your client side javascript in a separate page and then import it - neater container. one thing I've faced before is how to call xml back which contains code to run such as more javascript - it's worth checking if this is likely earlier on and avoiding, than having to look at evals.
Mildly interesting.
Are there any disadvantages to using AJAX?
No integration with the browser's history.
If you build a site that requires Ajax to see content and perform tasks, you have several major problems. Ajax-only content/functions are invisible/unavailable to:
search bots
many mobiles
people with Javascript turned off
etc etc.
However, if you build a site using the progressive enhancement principle, those problems are solved, and you still get to serve nice-to-use Ajax to most users.
Progressive enhancement involves first creating your site using bare-bones (X)HTML, on REST-like principles (at least to the extent of requiring POST requests for state changes). Simple semantic markup; forget about CSS and Javascript.
Step one is to get that right, and have your entire site (or as much of it as makes sense) working nicely this way for search bots and Lynx-like user agents.
Then add a visual layer: CSS/graphics/media for visual polish, but don't significantly change your original (X)HTML markup; allow the original text-only site to stay intact and functioning. Keep your markup clean!
Third is to add a behavioural layer: Javascript (Ajax). Offer things that make the experience faster, smoother, nicer for users/browsers with Ajax-capable JS... but only those users.
Browser compatibility.
Asynchronized access to data means it's harder to make things go correctly in every combination of actions.
Dependency of javascript makes the site unusable for some. Also javascript performance can be a bottleneck in resource limited environments.
User may not know via the client that an AJAX operation was made, or if it failed. It can be difficult to recover from client side errors caused by a failed AJAX call.
Makes it really Hard to do functional testing .
Inability to update the client without "polling", which means querying the server every X seconds.
It requires javascript. And you have to admit to your friends how "Web 2.0" you are. Instead of being hard core old school: It's all tables for layout and frames for navigation for me.
Yes, Ajax is not supported by old browsers or browsers which don't have javascript enabled. Nowadays, most of the browsers do have support for Ajax -- even mobile browser like the one on the IPhone.
The biggest issue for me is that Ajax adds complexity to the project.
There are many ajax libraries out there, which are suppose to make life easier. In most cases, these libraries are easy to use to create a "Hello World" application. One of the main issues which is most of the times kept asside by Ajax libraries is (client-side) error handling/logging.
For larger projects, the developer has to understand the internals of the library, which adds a new learning discipline to the project.
Some of our big clients -for security reasons- took a corporate decision of having javascript switched off. Therefore no AJAX is possible.
If you are going to develop something using AJAX for a given client be sure that your client are allowed to use javascript.
Restrict your application to a reasonable number of browsers and browsers versions.
Crossbrowser compatibility can make your life miserable.
Ultimately, the problem is that it introduces is complexity. Most problems inherent with AJAX sites (bookmarking, browser history, graceful degradation, etc...) can be overcome with a good design, so there are not really any disadvantages to a well designed AJAX enabled site. The problem is a creating such a site requires a lot of design and very good developers who can manage the complexity.
Our team is experienced in web development (tomcat/Oracle) but not with AJAX on our existing projects. This is new technology for us, so I want to introduce this carefully and correctly.
What should I look at in terms of frameworks or best practice or common pitfalls?
read this:
progressive enhancement
and use a library such as jQuery, mootools, or YUI it'll save you many headaches with cross-browser implementation. this will show you why you want to use a library.
My first recommendation would be to explore the different frameworks available and see what your team prefers in terms of coding style. Most of the frameworks have the same basic features so a lot of it comes down to preference. I prefer jQuery, so that is my first recommendation, but I worked with YUI, MooTools, Prototype and EXT JS before making my decision.
Secondly, I would recommend working AJAX functionality as a progressive enhancement, allowing your apps to work with and without JavaScript. I find that this approach also ensures a solid, working application before worrying about adding the bells and whistles.
Head First Ajax is a good book IMO for getting started with the basic concepts behind working with Ajax. It would probably be a good place to start for your team to gain some knowledge of what is happening behind the scenes in whatever framework you choose.
One thing we struggled with when starting to use ajax was how often to use it.
We had no exact requirement as to where we were supposed to use ajax and not, and initially we erred to the side of using it too much. This affected application complexity quite a lot.
If you think of your inter-page-structure as a state-machine, ajax introduces nested state-machines within each page-state. The moment your sub-state machine ends up with a number of distinct states (I'd say anything over 2), you should think really hard about using a traditional approach.
The best starting point is to try to get a mix og full page reloads and ajax, and be conservative until you're sure you're getting really good at it.
Don't use it where you don't need it.
Long running operations that need to send the client some status updates? Use AJAX.
Markup for major UI elements (menus, ect)? Use plain old HTML.
Basically, use AJAX for transmitting data only. If you try do fancy things like dynamically pulling in UI elements on the client side with AJAX, you are in for a world of hurt when you get a client who wants to use ie5 (they exist), or a non-pc based browser.
first, look at the user interface you already have, and consider where it might make sense for its elements to be able to change/react independently. This is where your ajax enhancements might make sense
second, look at libraries as noted in the other answers (I like AJAXPRO for its simplicity, but it has been discontinued)
if you find that all of your page elements tie together and cannot change independently, then there is really no need for ajax
otherwise, consider how you will access the page state from your ajax enhancement points - depending on which ajax framework you use, you may or may not have access to the entire page object, session state, original request parms, etc. Consider these issues up front to avoid coding yourself into a hole and/or having to make messy workarounds.
If you were on .Net or Mono I would encourage you to use Ra-Ajax which abstracts away JavaScript completely. Though I work for Ra-Ajax (inventor) so I am biased...