What is the best approach?

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

Replies are listed 'Best First'.
Re: What is the best approach? by jZed (Prior) on Nov 14, 2007 at 19:02 UTC
I'm not sure why you'd want the database to be XML, but if you do, DBD::AnyData can read and write XML databases using XML::Twig. You'd probably be better off with SQLite, PostgreSQL, or MySQL as a backend. You probably want to use a web application framework like CGI::Appplication or, for heavy duty Catalyst or Jifty. You probably want a database ORM such as DBIx::Class or Class::DBI. There are a number of threads on this site on all of those modules including some recent ones on comparing the web app frameworks.	[reply]
Re: What is the best approach? by moritz (Cardinal) on Nov 14, 2007 at 19:07 UTC
I'd recommend CGI::Application (easy but powerful) or Catalyst (even more powerful, but not that easy to learn at first). If you use a MVC framwork like catalyst it abstracts away the interface layer to the web server, so you can use either mod_perl or FastCGI (or perhaps plain CGI, but that's not recommend).	[reply]
Re: What is the best approach? by talexb (Chancellor) on Nov 15, 2007 at 04:46 UTC
.. and if possible I would prefer the database to be xml based. I would bet that it's too early to make that decision. .. should I use mod perl? Sure, why not? You understand the pros and cons of using mod_perl, right? Or is that just a flavour of the month decision? .. what modules do I need given that Im developing on apache2 on ubuntu gutsy gibbon? The same you'd need on any Linux platform, I'd imagine. Oh, and I strongly recommend and endorse CGI::Application as a starting point. It just works. .. what background reading do you suggest? Hard to guess -- what don't you know about building a database-backed web application? Read up on those areas. In other words, I don't know either. .. btw ive been told enough times to use strict etc!! And there's a reason for that, as well as for doing Test Driven Development -- you make sure that you understand exactly what the software is doing. I recommend you think a little about your database structure, but leave it flexible and get something simple up first. Don't spent weeks and weeks obsessing over some feature and never have anything to demo. Once you have something dead simple up and running, that will keep you energized and moving the project forward. My fellow monks suggest seprarting the logic and the presentation layer -- this is sound advice. Never, never let there be HTML found in your scripts or your modules. Never. No, NEVER. (ps: N-E-V-E-R) And for heaven's sake use some sensible version control system. I like subversion myself. Oh, and do have fun with it. :) Alex / talexb / Toronto "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds	[reply]
Re: What is the best approach? by rootcho (Pilgrim) on Nov 15, 2007 at 02:57 UTC
At all cost try to separate HTML/CSS/JS via some sort of templating (TT/Mason) from your real work.. I would start creating the app as a separate modules to do the work not thinking of the web side. I mean just to have at least somewhat working variant with console scripts. When you have something implemented see what would be the best way/framework you may use. What framework you will use depends on who will do the work. If you expect you to be the primary person who will do the job, then you can go abit low-level i.e. no ORM and may be Mason over TT/Something If you expect more collaborative work then think about DBI-ORM's, Catalyst and TT/Mason If you don't use ORM, try to pack the SQL in small sub's. It is still good idea to read ORM docs so you can get some idea how they abstract the access. Thinking for the front end, here is a good advice to use some framework like JQuery (pure JS for more complex stuff is a pain). I will definitely go with mod_perl. Unless you go with Catalyst which last I heard come with lighthttp which in some cases can be very good solution. (i.e. after you install it u have almost zero configuraiton) For XML i think XML::Twig is good, don't know does it support namespaces yet..;(, last time I used it it didn't If it was me I would not use XML :)) if possible...better SQLite or DBM::Deep (seems like a good candidate) or JSON,YAML. Design, but don't over-design ! do the stuff, but have some idea how the stuff will work i.e. design :) And last If you abstract your logic in clases, I would recommend you to take a look at Moose, definitely worth it. hth	[reply]
Re: What is the best approach? by sundialsvc4 (Abbot) on Nov 14, 2007 at 19:36 UTC
First... DESIGN IT, completely. Absolutely ignore all considerations of "how," and include technical requirements such as XML along with all other user-requirements. Write them down. Review them with your client or boss or the internal client or whatever. Next, "there's more than one way to do it," and plenty of high level frameworks exist: review them carefully, and spend more than one day on each one. Construct a good working-pattern for how you would actually approach this in each of several cases. Some frameworks, like CGI::Application, are low-level whereas others such as Catalyst or Gantry are high. Apache has lots of XML-based app servers. By all means, give very serious consideration to the very real possibility that you will wind up not having to write any new custom-code at all! The odds are extremely good that, if you look hard and long enough, the "wheel" you want already exists.
Re^2: What is the best approach? by chromatic (Archbishop) on Nov 15, 2007 at 03:51 UTC
First... DESIGN IT, completely. Absolutely ignore all considerations of "how," and include technical requirements such as XML along with all other user-requirements. Write them down. Review them with your client or boss or the internal client or whatever. Has that ever worked for you? Me neither.	[reply]
Re: What is the best approach? by bart (Canon) on Nov 15, 2007 at 12:22 UTC
It is going to be a database driven interactive site, and if possible I would prefer the database to be xml based. Hmm, what do you mean, that the database is an XML file? That won't be too speedy... Im not anticipating having to store more than a few megabytes of user data as this is going to be a highly specialised service. "A few megabytes" is, IMO, already too much for an XML file. should I use mod perl? Duh? First you make it dead slow by abusing an XML file as a "database", and then you'll use mod_perl to speed up the startup time?? My recommendations, since you asked: Don't use an XML file as a database. You can use SQLite, if you want to have a file as a database and yet have a very low startup overhead. Or, if installing is a bit of a problem (while all you need to do is to compile the module, it contains the database engine), perhaps a Pure Perl module like DBM::Deep will appeal to you. Don't start with mod_perl if it's your first time. Do it in CGI first. When you're happy with its functionality and it needs just a little bit of improvement on startup speed, then you can port it to mod_perl, or fast_cgi, or something else in that vain... You'll be happy to find that your code probably won't need too many changes, if you've done it right. By the time you get there, mod_perlite might already actually be usable for production. Like others said: use templates for the HTML, let your app just drive it and provide the data to fill in. Template Toolkit, HTML::Template... pick your favourite. But don't generate raw HTML in your code.	[reply]
Re: What is the best approach? by pc88mxer (Vicar) on Nov 15, 2007 at 14:04 UTC
I would start with an existing Content Management System. For instance, consider Drupal. Maybe it's not Perl, but the moment you download it you'll have more features than you'll ever be able to implement if you start from scratch.	[reply]


Think about Loose Coupling
	PerlMonks