Re: Web design and Perl/CGI business logic programming

First of all web clients are supposed to be * thin * clients. Although you can beef things up they will never match a * fat/rich * client developed in C++/VB/... etc.

Nowadays the MVC pattern is common good for web development, MVC is a term used to describe how to separate a web application into:

Model = business logic and data
View = the presentation to the user (HTML, CSS, JavaScript, Applets etc.) based on model data
Controller = handles the user input, controls the view and notifies model

This gives a clean separation. Your web application does need a certain critical mass otherwise it can be overkill.

There are several Perl modules around implementing the MVC pattern (google, Super Search...)

If you want your pages to look/behave better there are several options: use CSS (Cascading Style Sheets) and JavaScript to "enrich" the client but again don't overdo it. A web client should be a thin client.

Update

This site gives excellent examples of how not to do it:-)

Comment on Re: Web design and Perl/CGI business logic programming

Replies are listed 'Best First'.
Re^2: Web design and Perl/CGI business logic programming by Your Mother (Archbishop) on Aug 22, 2008 at 17:23 UTC
they will never match a fat/rich * client developed in C++/VB/... etc.* Never is a mighty long time. In just a couple of years Google's online apps have for many obsoleted desktop mail and calendar applications. The hard limitations on web applications are becoming historical (low bandwidth, dodgy embedded-code engines, lack of real layout facility). The single distribution point makes some amazing things possible too. How much would it cost to buy the entire app + DB of Google Maps? Since it's not a desktop app the cost of the thing can be spread out across the web in thousandths of cents instead of single-point $5,000 licenses. Not to say that it's the example to follow. It takes a huge amount of effort, expertise, and manpower to make apps like that. Agree about MVC. If done right it creates scalability in design. Start as small/thin as you like and the pieces can be moved up one at a time (like driving the View with JS with no change to the Model and little or maybe even no change to the Controller) or all together as you like.	[reply]
Re^3: Web design and Perl/CGI business logic programming by vit (Friar) on Aug 22, 2008 at 21:12 UTC
I found Catalyst for perl MVC. It it what I probably need?	[reply]
Re^4: Web design and Perl/CGI business logic programming by Your Mother (Archbishop) on Aug 23, 2008 at 01:04 UTC
I adore Catalyst. It has caveats (deployment requires a persistent environment -- cf, modperl or fastcgi -- to be reasonably fast) and it has a somewhat steep learning curve. But the docs are always improving, the code base gets wider and smarter all the time, there are more and more articles and examples online, the community is great, and many other Monks are Cat users/devs too so you can ask questions here as well as on the Cat list. Search in here for Catalyst and you'll find related stuff including possible reasons to use other things like CGI::Application.	[reply]
Re^2: Web design and Perl/CGI business logic programming by vit (Friar) on Aug 22, 2008 at 15:26 UTC
dHarry, thanks for such usefull comments. Could you clarify please, what you mean by /First of all web clients are supposed to be thin * clients. Although you can beef things up they will never match a * fat/rich * client developed in C++/VB/... etc./ Does it mean that with Perl/CGI I cannot do things which are possible with C++/VB/... ? and /A web client should be a thin client.*/	[reply]
Re^3: Web design and Perl/CGI business logic programming by dHarry (Abbot) on Aug 23, 2008 at 14:12 UTC
I agree with Your Mother (what a name) below, “never” is a bit long. With fat- or rich clients I mean for example a C++/Visual Basic application. You can create great GUI’s in it and you compile it into an executable that resides on the client (in general, there are other architectures possible). With the thin client most of the processing is done on the server side, for example the web server. The server processes the user input and returns html to the clients’ browser (again in general and simplified). So the only thing a client needs is a web browser. You can enrich a thin client to behave like a fat client so you can use Perl/CGI to make flashy applications. Keep in mind that it takes effort though. How big is your application? How many screens do you foresee? How complex is the User Interface logic? Are you proficient in JavaScript/CSS? Frameworks based on MVC definitely have a learning curve (I am with Your Mother again). If your application is simple, not too big, it might be overkill, like trying to shoot a mosquito with a canon. That’s why I said you need a certain “critical mass” before you go MVC. Cheers, dHarry	[reply]