Create html form using json

[Praveen Kumar Singh]

Hi All,
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

[Eric Pascarello]

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.

[Hikari Shidou]

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.

In your case, if your UI is HTML based, you should consider using a layout that works both on desktop and haldhelds. If you use standard and valid HTML and CSS and Unobstructive JavaScript, it should work.

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.

If you really wanna use a form to send JSON requests, you can use JavaScript to capture its submit event and return false so that it won't be submitted. Instead, your AJAX JS code gathers all fields values, put them into an object, converts it into a JSON string, sends it as POST, receives server's response and handles it.

As you can see there are a lot of options to solve your need, you can choose what's best for you.

[Bear Bibeault]

Hikari Shidou wrote: consider using something easier to work then raw JSON, like SOAP or XML-RPC.

Are you kidding me? A REST API using JSON is so much easier to deal with on the client than SOAP or other web service dinosaurs!

[Hikari Shidou]

lol if it's just a HTML form sending a POST request, sure

But if he wants his server to support a variety range of clients (he does, otherwise he didn't want client access to server to be totally generic, this requirement makes implementation way harder), it's easier to use SOAP or XML-RPC then raw JSON. At least I believe it's easier to find a SOAP client lib than a HTTP client + JSON builder and parser, for technologies not so much familiar with WebSite development. Remember that JSON was originally meant for server-side easily send data to JavaScript.


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