Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Are there any issues with JSON

by taint (Chaplain)
on Jun 03, 2014 at 12:33 UTC ( [id://1088406]=perlquestion: print w/replies, xml ) Need Help??

taint has asked for the wisdom of the Perl Monks concerning the following question:

Greetings, Monks.

I'm looking to replace all the JavaScript bits in a CMS I've been building for some time now. In an effort to improve it, it looks like JSON would be the best choice, when combined with Perl. I really hate all those bloatware "web2" libraries floating around. So I'm hoping that I've made the right choice. But wanted to ask for a bit of feedback, before committing to JSON. Any things to look out for? Any "gotchas"? OH, and any suggestions are also greatly appreciated.

Thanks!

--Chris

P.S.
Probably should note: this is mostly for Form Field Feedback, and for the creation of an Online Editor.

¡λɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH

Replies are listed 'Best First'.
Re: Are there any issues with JSON
by Corion (Patriarch) on Jun 03, 2014 at 12:38 UTC

    Note that JSON is (at best) a transport format for structured data.

    You haven't told us what parts of the Javascript bits in your CMS you want to replace, but I'm not really sure how moving to data can replace code unless you want to send commands from Perl to a generic Javascript driver that then acts on these commands.

    The most important caveat with JSON is that it is implicitly UTF-8, so you will need to make sure that all your data processing is already UTF-8 before moving data through JSON to decouple the problems that UTF-8 brings from the other problems that your website change brings.

      Ugh. I was on my out the door, and realized just that -- I didn't say what I was using it for. Sorry. :P

      My intention(s) are for HTML form "ques" -- you know, discription inside the element, feedback (inproper entry), and the likes. Also, I'll be building a custom editor with it (JSON).

      Once again, sorry. I know better than to ask a question like that. :(

      As to UTF-8; I wouldn't have it any other way. The day "Locale" vanishes, won't be a day too soon. As far as I'm concerned. :)

      --Chris

      ¡λɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH

Re: Are there any issues with JSON
by marto (Cardinal) on Jun 03, 2014 at 12:41 UTC

    "I'm looking to replace all the JavaScript bits in a CMS I've been building for some time now."

    You do know that JSON is not a replacement for JavaScript code or a JavaScript framework? The module JSON is an encoder/decoder.

      Thanks marto.

      Right. It's a "push", "pull" (transport) layer. That will provide me the same "dynamic feel" that JavaScript does. I can provide a more responsive interaction with the client, and I can create an editor, for the Forum, and News/Blog.

      At least that's been my understanding, while researching it.

      --Chris

      ¡λɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH

        "Right. It's a "push", "pull" (transport) layer. That will provide me the same "dynamic feel" that JavaScript does."

        No, that's not what JSON is at all.

        JSON is a data format. That's it. Saying that JSON will provide you with a "dynamic feel" is like saying that Perl hash variables will provide you with a "dynamic feel".

        Hashes are just a place to put data. If you want to do something interesting with that data (like provide a "dynamic feel"), then you need to write code to manipulate the data in the hash in some way.

        Similarly JSON is just a data format. If you want to do something interesting with that data (like provide a "dynamic feel"), then you need to write code to manipulate the data in the JSON in some way. If you want that to happen in a browser, then that code probably wants to be Javascript.

        use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name

        Maybe my reading comprehension skills are low but it sound like you have some serious misconceptions about what JSON actually is -- it's just string data -- a way of representing data -- similar to serialized Data::Dumper output. You still need Javascript to get the data to/from the browser/server (at least if you want it to happen asynchronously) and you still need Javascript to add client-side behaviour to the data. I wouldn't be so quick to dismiss the web2 frameworks. JQuery has pretty much won that battle and Bootstrap is a nice layer on top of it. Other battles are looming but I'll let some blood spill before choosing sides. There is nothing inherently wrong with writing all your JS from scratch but that's a lot of wheel to re-invent and I'd rather spend my time elsewhere.

        -derby

        I think you either don't understand what JSON is, or aren't explaining your intentions in a way that anyone seems to understand. If the former please read the wiki entry I link to again.

        Update: Are you suggesting that your backend app (in perl?) will talk to your front end app (written in what?) using JSON?

        From Re^2: Are there any issues with JSON: "Also, I'll be building a custom editor with it (JSON)."

        Again, it's just a data format.

Re: Are there any issues with JSON # AJAX ?
by LanX (Saint) on Jun 03, 2014 at 16:21 UTC
    Could it be that you meant AJAX and not JSON?

    Please note that the J in AJAX stands for JS so even if you move logic to the server you'll need an at least minimal JS layer on client side.

    The X might stand for XML but using JSON instead is common place.

    Cheers Rolf

    (addicted to the Perl Programming Language)

      No. Altho I'd prefer that to most of the other options (JavaScript libraries) out there.

      It appears I had a very incorrect impression. Based on some of the links I came across, pertaining to JSON. One of which, was an editor.

      I guess the question I have now is. Is there any Perlish alternative for accomplishing what I'm after, that you, or anyone else, would be willing to recommend?

      Thank you very much for taking the time to respond, and better clarify, LanX.

      --Chris

      ¡λɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH

Re: Are there any issues with JSON
by perlfan (Vicar) on Jun 04, 2014 at 14:22 UTC
    Design a RESTful API on the server (Perl), using JSON as the data serialization format. This way, your browser is just one client - one that happens to require JavaScript to facilitate the back and forth communications and data serializing/deserializing.
Re: Are there any issues with JSON
by sundialsvc4 (Abbot) on Jun 04, 2014 at 15:56 UTC

    For all applications such as this one, the JavaScript program is the primary “application,” being made up of components that are delivered by the server.   The (Perl) server is simply the handler of remote procedure-calls (RPC), which occur over an HTTP transport using either XML or JSON as the encoding scheme.

    In some more-sophisticated schemes, the client requests JavaScript code from the server, and incorporates that code into itself.   Or, it requests HTTP pages which it cabbages for its DOM data-structures.   The server might be called-upon to prepare these things, say, using templates.   It can become quite complex, such that it always should be your goal (and, good luck with that ...) to discover “TAASWTDI = There’s Always A Simpler Way To Do It.™”

Re: Are there any issues with JSON
by sundialsvc4 (Abbot) on Jun 03, 2014 at 13:59 UTC

    Yeah, those bloatware libraries tend to get out-of-hand ... (if I never again saw another “bouncy dialog-box” or “marquee effect” again in my life, I’d be a Happy Boy™) ... but the real problem on the client-side is finding a way to do without them.   For example, in order to edit things, you’re going to need an editor, and so on.   Which pretty much means that some package like that is going to be driving the client-side, and talking JSON to your Perl code.   Fortunately, Perl provides several very-robust implementations for your coding pleasure.

    One useful bit of CPAN that I’ve used a lot is RPC::Any::Server, and you’ll quickly see what I mean when you get there.   You will have a lot of JSON requests flying about and you need to plan each one out very meticulously.   (In one project, I spent the first four weeks or so writing a manual for myself ... and discovering oodles of subtle issues that I might not have discovered until I was hip-deep in coding ... but, because I did work it all out in advance, wrote the actual system pretty much defect-free in about a week and a half.)

      If I never saw a twirly... I'd be a Happy camper, to0! :)

      Thanks for taking the time to suggest RPC::Any::Server. I see it also speaks JSON -- RPC::Any::Server::JSONRPC, and RPC::Any::Server::JSONRPC::HTTP. In your experience; does it provide for anything close to what I'm attempting to accomplish? I can see where it provides for pretty quick responses. But I fear, that now I've better articulated my needs, that this might not quite hit the mark.

      Sorry for any sort of misunderstanding I may have caused.

      --Chris

      ¡λɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH

        Yes, Chris, I think that it does ... if (smile! wink!) you have a clear idea of what you’re attempting to accomplish and how it must be done.   But I’m not quite sure that there is clarity on that point yet.

        As I see things, on the client side you are going to have to pick your poison as to (yeah, big phat) JavaScript libraries.   There is simply no other way to get the things that you want on that side, such as nice editors.   You are going to build-out your application substantially as a JavaScript program.

        Although, at this juncture, may I please send you to peek at http://www.haxe.org and ask you to look beyond the look of that site.   (Site sucks, tool does not.)   But, I digress.

        This leaves us with the Perl side, where you are going to be using the JS to issue JSON requests (or XML, pick your poison) to the server side, and where you are going to need to provide support for every single one of them.   I like RPC::Any::Server because it is quite logical and extensible, and I find that it scales-up nicely.   As I said, it will be very important that you “do your homework well” here, before you embark.   Stay in port with the sails furled until you have planned and researched the entire voyage, for there be dragons.

        Once you do “pick your JavaScript poison,” you ought to be able to find corresponding support for it in the form of other CPAN modules.   Take full advantage of these, because it means that someone else has banged his head mightily against something that, maybe, you at least won’t have to bang your own head against quite as much.   (Roll-eyes ....)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://1088406]
Front-paged by Arunbear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others avoiding work at the Monastery: (6)
As of 2024-03-28 23:38 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found