We have a web client built with GWT that talks to a server via gwt-rpc. One part of the app will now use html/js to replace the GWT GUI and we want that part to talk to the server but not via gwt-rpc. What ways are there to migrate a gwt-rpc call to something that will work with a none a gwt client? Today we send and receive java collections that contain object graphs like a list of order objects that have them self order detail objects and so on.
Thanks
Your best bet is using REST. Your data is sent using JSON, which is part of JavaScript so it will always be understood on the client-side. On the server side there shouldn't be any problems finding a suitable library to handle the rest (ha-ha, get it?).
If you're using GWT on the client and server side for now, resty-gwt and Jersey are a popular combo. There was a talk about it on the last GWT.create conference, it's a good starting point.
Related
I've developed an application that I would like to use meteor.js for real time updates (I want to enhance but not change my program, for example when a user adds a comments make it update in real-time ) . Problem is meteor.js uses node.js (so javascript as server-side code). I use LAMP stack, Is it possible to get PHP to feed data into meteor.js from mysql.
Meteor is more than just an 'interactive webapplication'-builder or javascript framework. The idea is to have only one programming language (besides HTML/CSS for markup) to do all the work. Basically it creates a 'remote server' (in the clients browser) it can push data to and at the same time it publishes various API's to the users system. The data passed through these API's / connections has a specific structure which has to be adhered at all time.
Meteor is built around NodeJS, which makes it hard (if not impossible) to run it without this backend. Sure you can try to mimic the backend using PHP, but it would be a waste of time. Reading your question you'll be better of using a javascript framework like jQuery or Prototype. Unlike Meteor you will need to do the AJAX calls (POST & CallBack) yourself, but you can actually decide which backend you want to use yourself (including PHP / MySQL).
If you want to do this anyway you need to check the Meteor & NodeJS source code to see what the minimum requirements are to make Meteor run under PHP. The PHP stack has to interpret the commands Meteor sends and receivers, but this won't be an easy task.
You can use comet (or reverse ajax) for realtime updates.
Trying to marry node.js with PHP doesn't sound like a worthwhile path to go down. If someone insisted on using a system like Meteor.js, yet with a PHP back-end, it would make more sense to look at AngularJS which is mainly the client side.
Of course, that is different technology stack. If someone really insisted on the blending, one could consider using server side sockets to interact with PHP Web services; and/or use mongodb and/or mysql-node to interact with the same databases.
I released a meteorite package that interacts with a Wordpress site that has the Wordpress JSON API. A quick fix. For now.
Comes with a backend call that will return the raw data, or a publication that stores the posts using their id's instead of a randomly generated mongoid. And some basic templates to get you started including a Session variable that keeps track of the currently selected post.
I'm working on it a lot more and will eventually have a version that directly makes mysql calls from node so you won't need php or Wordpress; just the ability to access the mysql database (which can be remote, with the appropriate configuration, or on the same machine).
I am a newbie in web development. I am in the process of building a food blog website. I want to pursue front-end-web-developer career. I have built my website only using client side languages like javascript, jquery, html and css. I have used json to store the data. my questions are -
1. I now want to make my website live. For that I want my website to be hosted on server. As I am not using any server side scripting, would my data related to website be visible to everyone if they do try to "inspect element" or "view source"?
2. how can I separate Json from client side code/scripting? I think for that I will have to seperate json data from other javascript code and store it into a separate file on a server. But in that case how can I access the Json data? For that I will have to make use of some server side scripting language. I prefer Asp.net(not that I know asp.net but I am familiar with C# hence). I also would have to make changes to my html code at client side to fetch the Json data from server. I am not really aware of this whole thing. Could someone spare some time and let me know how to go about it?
3. Does all the client side and server side code lies in a single asp.net project?
I have searched over internet. Mostly all the material/coding available over internet is mostly in php or python hence I am confused. There no definite guideline that I could find as how to handle the data part only using JSON?
to help you answer your 2nd question
2. how can I separate Json from client side code/scripting?
usually server side is in the controller so your HomeController.cs for instance will have an Index action (public ActionResult Index()) that method will basically be called whenever the browser hits the route Home/Index.cshtml
in order to separate these two, you may fetch or construct your Json in the controller and pass it to the ViewBag, from there you can access it in the view.
using $.ajax will help as well to get the json from the view and update the content of a specific part of your page for instance.
I'm working on a Parse web app and have run into some problems using the backbone.js based client side javascript sdk. I noticed the way I have things set up, the client can view all of my source code by simply using the dev tools to view source files and can also run code against the database (within the limits of the ACL's I've set). I've started working on rebuilding the app in cloud code using the Express.js module Parse provides so that all of my code is stored server side, but I was wondering how those using client side frameworks get around this obvious problem.
That's the issue with client-side code. Assume any code you send to the client is hacked, broken, and tampered with.
With JavaScript, your best bet is to use either Cloud Code and send AJAX or streaming data calls to the server, retrieve the data from the server at runtime (not super secure, but would fool some people), or accept that your code is vulnerable.
I typically work with frameworks in the MVC format, so I only expose a limited subset of the actual model via a REST API. I use both a client-side framework and a server-side framework. Any thing sensitive goes on the server.
I have asked this quesion few days before here and no one answered it.
I had asked it in forum.javascriptMVC.com too and now I have a answer, however I need a a bit more idea.
Question:
I read javascriptMVC's documents and I loved it.
But I don't know how to use it in a large scale project.
I think on the server-side a MVC framework is needed or can help so much. And I've worked with server side PHP frameworks.
I am confused, my understanding of JavascriptMVC projects is that they handle client side events on the browser capture events, execute AJAX requests, manage the responses/data from the server and also show them to user in a graphical interface.
I know that in PHP MVC projects we also have controllers (and actions) that any of them is a separate page with a single entry point, my point is that these pages are whole HTTP requests.
I think the combination of these two frameworks would be in a form of a single or few heavy files (including js , css , imgs etc) that loads and managed by another Javascript libary such as steal.js.
Now user can work with site and its actions (as events) that result in running js functions that may change something in the UI or cause a AJAX request, as in Yahoo Mail where most things happens in one page.
So how will this affect the design of controllers and actions in PHP ? I mean normally in PHP MVC frameworks a lot of controllers and actions means a lot of pages. I think because of AJAX the number of controllers and actions should be actually less. I also think because of JMVC most controllers (and actions) should turn to AJAX responders, however how are layouts and views to be handled in this context?
Finally
I want to know about different aspects of using this method(JMVC+MVC). (I am using Yii as my server-side MVC framework and JavascriptMVC as my client-side MVC).
I also want to know about management of data on the client-side.
I would like to understand how AJAX and web-sockets could be used, where we can use AJAX and where we can use websockets?.
I want to understand about local-storage how we can use it for simulated page data management and maybe caching, how we can cache data coming from server as JSON in a form of a page? I am working on a very large project and I want to build its foundation very strong.
Say that you jave a JMVC framework where
The model gets data from the server using AJAX request - expecting JSON results.
The view does not rely on the server, for more that providing the raw HTML.
The Controllers do not rely on the server, for more that serving the JS files.
Essentially you use the server what it "should" be used for, data storage and processing, while you let your client browser handle all the tedious stuff.
Now, lets see how to define a server-side framework. As I see it we have several options, all of them fairly similar, albeit somewhat different (all returning someing in JSON format):
A fully fledged MVC such as cakePHP
Custom implementation
WebService implementation
Personally I would use a WebService, and I already have. Or rather, I used a WebSocket based JSON-RPC WebService.
Using a fully fledged MVC will have it's drawbacks in maintainability and, not insignificantly, server load. But it is very possible, just implement a view which formats the page as JSON...
Making a JMVC client does not, in my view, mean that it cannot request new HTML from the server. But it does mean that that requested HTML should be free of data, other than meta-data the Java-View needs to know where to put data recieved from, for example, the WebService.
So a main page in the JMVC could just contain a single
<div id=content></div>
and menu clicks can fetch a subpage from the server and load the content into content. Then that loaded content can contain some more javascript which starts WebService requests to get data from the server, to display in the empty placefolders it in turn contains.
First check https://stackoverflow.com/a/4458566/718224 after that you can move forward.
Try this (from https://stackoverflow.com/a/8424768/718224)
No, you don't need to use it server-side, but it will help with organization / separation of application and business logic. Depending on the scale of your application, that could help tremendously in the future.
The key is just making sure you organize your backend code well, otherwise you will end up with a monolithic and/or difficult-to-maintain codebase.
Server-side views would contain your HTML and any JavaScript that may or may not make requests to the server. This assumes that you are actually using PHP to build the pages that a user navigates to.
If you have a static html page that builds itself using AJAX requests, then you may not need to use server-side views at all. Your controllers would more than likely be outputting JSON data. If this is the case, it doesn't make models and controllers any less useful.
Try this (from https://stackoverflow.com/a/8424760/718224)
If you are using any of the major PHP frameworks (CakePHP, Code Igniter, Symfony, etc.) then you ARE using MVC already. If your server side logic is more complex than just a few really simple scripts than you probably should be using one of those frameworks listed, using MVC on the server and the client.
Many (most?) larger web apps being built today are moving towards using an MVC framework for both client-side and server-side application code. It's a fantastic pattern for separating concerns for many large applications, especially request/response server apps and event-driven browser apps.
Try this (from https://stackoverflow.com/a/8427063/718224)
Backbone.js connects your application over a RESTful JSON interface. I honestly find that it works wonderfully in conjunction with the MVC framework. If you build a RESTful API, you can let you server manage CRUD updates quite easily. All your server side code will be responsible is saving and sending back JSON objects to Backbone.js. Then let most of your logic and magic happen within the Backbone.js framework.
Try this (from https://stackoverflow.com/a/8078282/718224)
First, a client-side MVC framework like Backbone isn't just for single-paged apps. You can also use it to add some rich interaction to one or many views of a more traditional app. They simply provide structure and data abstractions on the client.
Next, these client-side frameworks are designed specifically to work with your back-end MVC frameworks. Backbone.js (since you tagged it specifically) models and collections work with REST services. They will talk via GET/POST/PUT/DELETE verbs and will ultimately communicate with your controllers on the back-end when they make asynchronous requests.
In the case of Backbone, it talks JSON instead of HTML. In the case of Rails, this is really easily handled in the controller. If the request is an HTML one, then you return a view as HTML. If it is a JSON request (*.json or Content-type) then the controller returns a JSON representation of the data. I am assuming that it is as easy in Django as it is in Rails to have the same controller respond to multiple content requests (HTML, XML, JSON, etc)
may this help you.
client side web apps and rich client side web pages often use jmvc backbones and etc. and with that kind if js libraries and HTML5 technologies like webstorage you can have a more applocation like websites that all things happens in client side like templating management and etc. and just we have ajax request/response to servers to get/set data or update status. and abput first section they are right a jmvc site are more like a single pages websites. ie hotmail yahoo , etc.
I am researching how to PunchOut enable a webstore and from what I read, I have to use a server side language. Unfortunatly I am limited to only using Javascript. Can this be done? Does anyone have any best practices or can point me to a reference for enabling a PunchOut ecommerce store by only using Javascript?
According to the cXML Users Guide (http://xml.cxml.org/current/cXMLUsersGuide.pdf) on page 23 it states "PunchOut catalogs are made possible by Web server
applications, written in a programming language such as ASP (Active Server Pages),
JavaScript, or CGI (Common Gateway Interface), that manage buyers’ PunchOut
sessions.". Based on that it sounds possible as they call out JavaScript, but they also call out the fact that it is done by Web server applications. I have not used a strictly JavaScript myself, just ASP and recently .NET.
However, I'm not a JavaScript expert so YMMV. The main thing to keep in mind that most punch-outs (especially from Ariba) will be initiated via an HTTP POST with the cXML document XML as a form value. If you can use JavaScript to process that XML and send back a response without server side work, then you should be good to go.