I need to develop a AJAX application as part of my new project.
Requirement is simple, keep client and server separate!!
Idea is, if tomorrow we remove HTML by android or IOS thing should work.
so as my previous project, i started with JSON object for communication, however a bug i left in my previous project now grown enough to bite me!
BUG is FORM!
how to generate form using json or keeping client and sever separate!
My solution of previous project, create HTML on server, get it on client and replace div by that is no longer a feasible solution as we are developing this application for web, ios and android.
So guys, please help me here.
WORK SO FAR 1. jQuery.dForm plugin --- ahh good, but bit cumbersome to work with, getting div, validation message in between is difficult to put
Why is that not a feasible solution? It is valid to generate the html on the server and return that chunk of code. In some cases it will be faster than looping throught the JSON on the client to build a form. You can also use a templating framework like handlebar.js or mustache.
I think your team should learn more about Software Engineering best practices.
You don't need to keep them "separated", you just need to encapsulate and abstract, in your server software, how it communicates with client. When you actually need to change client, you'll just need to refactor that component on server, without needing to touch anything else.
I myself like to develop Application Layer without thinking about UI, and with no way at all for it to be executed directly. It's like a lib that must be included in a executable. Then, I consume it: if it's a server-client, I create a server app that receives client/UI requests, sends it to Application Layer, gets its response and send back to client. If it's a standalone app, UI includes Application Layer and uses it.
If you really need different clients to access your server in different ways, consider using something easier to work then raw JSON, like SOAP or XML-RPC.
With Java EE you can have, in a single .war, a Web UI based on Servlet and JSP, and a WebService (SOAP) based on Axis2. This way, when the default Web UI can't be used, you develop another UI that communicates with your Application Layer using WebService (SOAP). Both Servlet and WebServer will consume your Application Layer services.
As you can see there are a lot of options to solve your need, you can choose what's best for you.
lol if it's just a HTML form sending a POST request, sure
He must face the facts, if he wanna keep the requirement of easily supporting all kind of clients, now and in the future, he must pay for it in the complexibility of handling generic server-side communication. And for that, for being able to support different and unpredicted technologies on client-side without having to make changes on his server, SOAP and XML-RPC are way easier then raw JSON without any operation/RPC support. Using any of those, he can freely develop new clients that will just need to use his WebService.
The other option is to give up that requirement, not support all kinds of clients, and choose exactally those technologies that will be used to develop clients. Narrowing the possibilities, he can also simplify server-side communication.
In either way, he must right now manage future changes on his server. Change management is most important. If the component that handles UI communication be less coupled with the rest of the software, when real need comes it will be easy to change it and support those needs. As I said, with Java EE it's even able to have WebApp UI and WebService on the same .war. That's very flexible and simple at the same time, to support all kinds of client needs
It was the best of times. It was the worst of times. It was a tiny ad.