Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

which Web interface to DB should I prefer?

by vkon (Curate)
on Jan 31, 2009 at 12:19 UTC ( #740413=perlquestion: print w/replies, xml ) Need Help??
vkon has asked for the wisdom of the Perl Monks concerning the following question:

Hi,

I need to do a Web application, which will be DB-based (MySQL)

While I should consider the flexibility WRT DB, I also need to have a highly customizable UI, especially I want YUI to have available for my programming.

http://search.cpan.org advices me the CatalystX::CRUD::YUI and so my first glance is towards the CatalystX framework

My real question is - does anyone have real expereince and could advice towards it/against it/towards other real cool framework?
I am a novice in all this, so please bear with me :)

Thanks in advance for any useful advices!
再见!

  • Comment on which Web interface to DB should I prefer?

Replies are listed 'Best First'.
Re: which Web interface to DB should I prefer?
by zerohero (Monk) on Feb 01, 2009 at 00:29 UTC

    I have a bit of experience using YUI, ExtJS, etc, for creating web applications. Note that these are front-end technologies, not back-end. Javascript is the language that executes in the browser, for better or worse.

    If you are doing a simple "form based" web site, then the front-end toolkits don't matter too much. This is because these form based, low-interactivity applications can all be done using some backend language, usually PHP, although Perl+Mason, I think is a compelling alternative (Amazon uses this I think).

    The toolkits like YUI come in handy when you want to either: 1) do AJAX-like things (interactive client/server, incremental responses, high interactivity), or 2) do GUI-like things in the browser (e.g. ExtJS widget set). The commonality in these two aspects is they require lots of code in the browser to do interesting things.

    The first thing to look for in a Javascript toolkit is the lowest level tasks: normalizing the browser environment, DOM manipulation and basic animation. Part of normalizing the browser is the "event model", which generally includes ability to make calls to the server (the async ajax call, XMLHTTP). Normalizing the browser environment means that you can (theoretically) use the toolkit API and things will work the same on any browser. Note that the toolkits help but don't fix everything, they just make it _possible_ to not have to write a slightly different version for every browser. YUI, ExtJS and the other toolkits all have some aspect of this (look for the "event model" part of the toolkit). JQuery concentrates on DOM manipulation and is has more power in this area. YUI has won many awards and was originally one of the "trailblazers", ExtJS was originally based on YUI, but then yanked out the YUI code and did their own. There are many other JS toolkits out there as well (Dojo, etc.)

    One of my pet peeves is I really dislike toolkits that give people "the ability to program in language X because they don't like Javascript". These "program in X and translate to Y" approaches never work well. They do make things easier for people to write simple programs. Unfortunately, the whole reason for a Javascript front-end toolkit, is to do interesting things on the front-end that you can't do any other way. So I'd veer away from things like the Google toolkit (program in Java so you don't have to learn JavaScript), or Mochi (program in Python so you don't have to learn JavaScript). Just my opinion, my preference (other people probably love these approaches). I think these are knee jerk reactions to Javascript's initial problems, but these are largely solved, and now people are concentrating on making Javascript execute efficiently. So learning Javascript/DOM/Browser will in the end let you do interesting things.

    One interesting thing you will see if you take these toolkits apart is that they all do their magic by DOM manipulation and CSS. The browser gives a lot of display power by it's underlying technologies. You could contrast this to the types of code you might find in a desktop windowing application (if you've written for the GUI and looked under the hood). By using these browser technologies, the toolkits allow you to modify things at all levels (e.g. skinning is fairly trivial). This is one reason why I think people love JQuery => it assumes that you are going to do lots of manipulation via CSS/DOM and can achieve all sorts of custom effects. Contrast this to heavier weight things like YUI and ExtJS, which assume that programmers want "Browser widgets, similar to GUI widgets". ExtJS goes the furthest in this respect (see demos on website). Note that a lot of this power is wasted unless you use AJAX, or go one step further (attempt to build a standalone app in the browser). Most web applications show a form, let you enter things in the form, hit OK and then everything from that point on is handled on the back end.

    So what does it mean "have a highly customizable UI"? If it means you have lots of forms, then the CRUD approach is probably a good one. This is like Ruby on Rails or any of these systems that impose a simple CRUD framework on you. The benefit of these is you can make a lot of fast early progress, as long as your application fits the CRUD model. If it veers outside the framework model, then you have to learn the framework (and you may learn that you now need an expert in the framework to make the types of modifications you need). Personally, I prefer libraries to frameworks, but that's because I like to "know everything". If "highly customizable UI" means "I need something that acts like a desktop app", then you need to pay more attention to the Javascript part as the CRUD part won't really help you.

    I'd strongly recommend implementing a simple end-to-end piece of your application, something very simple. You need broad, shallow knowledge first, rather than deep knowledge of any particular piece. Once you see the uses and ways things fit together, you'll be in a lot better shape to understand which framework to pick. Just Keep It Simple, and code like the wind (prototyping). Then throw that away - it's just for learning. The first way I'd do it is using bare bones technologies to see how everything fits. Don't waste time making it perfect, just see how everything fits together. In fact, if you can find a sample on the web somewhere, just go through the motions of typing that in, e.g.: Perl DBI to access MySQL database, with PHP (or Perl+Mason) in apache, with a tiny bit of YUI. It's important to see how the pieces fit, and you'll have to do this eventually anyway (learn how things fit). Once you've done that you can select a framework successfully. I'd hold off on a decision until you did some really simple prototyping.

    BTW, I've used the following stacks for web design of reasonably complex projects: YUI|ExtJS|JQuery, apache, php|perl|c/c++, Perl::DBI|php_oc9, MySQL|Oracle.

    Note, since you are posting to perlmonks, I assume you are going to use Perl::DBI for the backend access (not sure, but I'd guess this is what Catalyst uses). So understanding that will be a useful starting point.

      So much thanks for a very useful recommendations you wrote!

      Indeed, by "highly customizable UI" I meant that it will have some visual effects, and further then it will use AJAX too.
      I made not a perfect phrasing, but you seemingly made a perfect guess so you've guessed right :)

      Some things you pointed out are known to me,
      but most points are not,
      so I very much appreciate your sharing of knowledge!

Re: which Web interface to DB should I prefer?
by sundialsvc4 (Abbot) on Jan 31, 2009 at 17:02 UTC

    As with all such things, foremost bear in mind that you are treading upon ground that many people have walked before. Therefore, start by defining your application requirements fully and carefully; then, systematically explore just how many “great big pieces” are out there on CPAN that you could more-or-less drop in to your new application.

    “Imitation is the sincerest form of intelligence.”
    Actum Ne Agas:   “Do Not Do A Thing Already Done.”

    In short, spend time right now on the what of your app (and the when), even though what's naturally keeping you awake these days is (of course...) how.

    What is unique about your particular application is “what” and “when,” not how. A great many Monks are treading the same well-worn path. Each of us is carrying a different, (only somewhat...) unique, load.

      Dictum Ne Agas: “Do Not Do A Thing Already Done.”

      This is completely off topic, but I've seen you use that phrase a lot (on LQ first I think). It doesn't mean what you think it does. The participle 'dictum' comes from 'dico, dicere', which is the Latin for 'say, speak'. So dictum ne agas means (oddly) "Don't do a thing already said."

      Maybe you were reaching for the Terence quotation: actum ne agas (Phormio 419)?

      That could be translated "Do not do a thing already done", but in context I think it means more like "Don't mess with what you can't fix (because it's already a done deal)."
Re: which Web interface to DB should I prefer?
by stonecolddevin (Parson) on Jan 31, 2009 at 17:17 UTC
Re: which Web interface to DB should I prefer?
by stonecolddevin (Parson) on Jan 31, 2009 at 16:20 UTC

    well, it's not YUI, but the recommended "Catalyst" way is typically LFB.

    meh.
Re: which Web interface to DB should I prefer?
by bradcathey (Prior) on Feb 01, 2009 at 02:27 UTC

    "Web application" is a bit vague. I'd ask just how complicated does this need to be? Catalyst is powerful, but has a huge learning curve. You might be better served by something as simple as CGI::Application.

    —Brad
    "The important work of moving the world forward does not wait to be done by perfect men." George Eliot
Re: which Web interface to DB should I prefer?
by vkon (Curate) on Feb 01, 2009 at 08:49 UTC
    I very much appreciate all useful answers that I've received!
    Thank you a lot!

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://740413]
Approved by ww
Front-paged by Arunbear
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (3)
As of 2018-07-21 23:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    It has been suggested to rename Perl 6 in order to boost its marketing potential. Which name would you prefer?















    Results (450 votes). Check out past polls.

    Notices?