Javascript: Display Logic or Business Logic?

[perlfan]

I tried to search around and find the answer to this, but it's a hard question to search for; so here's a new node asking it. Feel free to point me to nodes that might answer this in some way.

Say I am creating a web app; say with CGI::Application and Template Toolkit. Given some strict separation between my business logic and display logic (using various methods, including those espoused by metaperl, I am unsure where Javascript fits in.

There's a ton of stuff to say what HTML generation and separation options exist, but not so much when it comes to the Javascript.

I have:

• MyApp.pm (which ISA CGI::Application)
• app-driver.pl
• HTML templates (or some Xth generation method)
• some reliance on Javascript

The Javascript is responsible for:

• providing a more "enriching" UI to interface with some set of data (i.e., report controls)
• asynchronously fetching data
• potentially transforming and caching data
• displaying data (e.g., a chart or datatable, potentially pagination and result filtering)

Like "powerful" templating systems, the temptation here is to muddle the Javascript with logic that is part of both the business and display domains. However, it seems like a much darker and more treacherous place than the dark alley provided for by overly powerful templating systems.

Where does one draw the line? Is Javascript also strictly to be taken as a means of implementing the display logic? Or, as YUI encourages you, is it part of the business logic?

What is Perl's role when creating an application? Is it possible that the answer is, "it depends"? In which case, you need to make a decision in the beginning and stick with it?

For example, investing heavily in the client side potential of something like YUI makes it possible to do the MVC thing in the Javascript, treating Perl simply as a way to provide a 2-way pipe with a remote database (for example). It is also possible to do as much as possible on the Perl side (e.g., even pagination) and treat the Javascript like it's just a box of dumb widgets for the browser part of the "view".

Depending on the answer, the question then becomes: do you maintain the Javascript statically (inside of some static HTML template or Javascript file) OR do you insome way attempt to generate the Javascript using some Nth generation templating paradigm?

In otherwords, once you decide what side of the application the Javascript plays a role (shouldn't be both, right? or can it?), how do you include the Javascript as part of your "code" base (including HTML templates/gen, MyApp.pm, app-driver.pm)?

Perhaps the name of the game is to be disciplined in one way or the other. But regardless of what Perl framework you use, what is the right way to deal with the Javascript?

Thank you.

[suaveant]

Well, it partially depends on what you want to do. We use ExtJS when we want a highly interactive UI, and that clearly lends itself to AJAX calls back to the server. Of course you also end up with some business logic in the front end unless you want to make hundreds of calls back to the server to validate data and what not. Of course then you need to validate on both end since it is very easy to send data to the server without the JS in the middle.

If you are generating regular looking HTML pages then you could do it with Javascript but may as well use a Perl Templating system.

[chrestomanci]

suaveant++

You should never rely on JavaScript to validate data from the end user, as it is too easy a hacker to disable or modify your JavaScript so that invalid data gets sent to the server. Also if you rely on JavaScript validation then you lock out users who have disabled JS, or don't have support for it in their browsers (eg. phones)

There is nothing wrong with doing client side validation to help the end user (eg, highlight empty form fields in red), but any client side validation must be duplicated on the server as well.

Given all that, I don't think JavaScript can form part of your business logic, it can only ever be part of your display logic.

I take your suggestion about using contemplating to generate JS, and I can see it might make sense for validation. For example suppose you have a list of valid values for a field. Rather than hard code the list into the validation logic in both perl on the server, and JS on the client, and attempt to keep them in sync, you could store it in the database, and then generate the validation JS code on the fly.

An alternative approach (that I have used in the past), is to store it once in the JS validation code, and then write some perl to parse the JS and extract the list of valid values. This was rather fragile, but it avoided maintaining two lists.

[Rhandom]

You could use CGI::Ex::Validate and write your validation once and have it available in perl and javascript.

[perlfan]

Thank you, this is more general. It's not just about validation, though that's a huge consideration.

[metaperl]

For completeness, here is the list of push-style templating systems. FWIW, these days I use Mojo's built in system again and again because it's there and it works :) For a total javascript solution express seems pretty complete, but there are certainly other options for full-stack JS.