As haukex's code implies, you can program the backend to send json, text, excel, word-doc or html or pdf or ... to the client according to client's needs. It means you have a separate backend handler sub for each output format the client requests. The art is to not get lost in all those formats when you decide to make a change in the raw data (e.g. DB schema), it must be reflected in all the output formats: html, pdf and text etc., as transparently as possible.

hippo mentioned templates, which are not for HTML only btw (you can create TEXT templates with the same module just as easily). Using templates can be one way to make your process as painless as possible. You must create a template for each of your output formats and also create subs to convert a perl hash with the data you want to render to each of the formats by loading the template file and filling in the gaps, so-to-speak. Adding a new field to DB and sending it back to the client still means editing/adjusting each template file but this is more "tidy" IMO and you should not need to modify any perl code except db retrieval. Something like:

my $data = retrieve_from_db($params);
if( $params->{need_html} ){
  my $html = perl2html($HTML_TMPL_FILE, $data);
  render(html => $html);
} elsif( $params->{need_json} ){
  my $json = perl2json($JSON_TMPL_FILE, $data);
  render(json => $json);
} # ...

[download]

You are thinking of creating an intermediate layer to act as a translator from raw-data (perl-hash in my example, json in your setup) to HTML using LWP. In essense that's what I am doing above but I do it within the app and not using LWP at all. If you must go with separate layers then consider creating separate apps which send requests to each other within the same server, residing on different ports. Come to think of it, a DB is just one of these apps which can even reside in physically separate server. An advantage of using different apps is that you can distribute your load to different physical servers and isolate "sensitive" apps behind internal firewalls.

Alternatively, you have the choice of "templating" in the client using javascript. Essentially your client accepts only json and your javascript will take that, convert it to HTML or PDF or EXCEL (I guess there must be some libraries for the latters???) and inject the output dynamically into the client's browser's current page. HTML injecting is quite simple to do now-a-days.

bw, bliako

In reply to Re: a simple web front end by bliako
in thread a simple web front end by lis128

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.