From: "Daniel Kluev" <[email protected]>
> On Sun, May 22, 2011 at 6:44 PM, Octavian Rasnita <[email protected]> wrote:
>> Because of its flexibility, Perl offers more advanced modules and libraries
>> which are not available for Python.
>
> What 'flexibility' are you talking about? This seem to be very biased
> statement, based on lack of according python experience.
I am talking about that flexibility which was criticized in the previous
messages telling that this flexibility allows any programmer to use his own way.
Perl doesn't force anyone to indent the code, don't force the programmer to
define a hash element before using it, allow the programmer to interpret the
variables in strings directly. These things should be not used always, but if
in some cases if the programmer wants to use them, he can use them with no
problems. And this means flexibility.
> There are many python web frameworks which allow you to use w/e
> interfaces, template languages and ORMs you want - Pyramid/Pylons is
> good example.
> 'Very powerful' and 'great' are 'very useless' descriptions of these
> modules. Please, show us what exactly is so 'advanced' about them
> which cannot be done in python.
Every language can do almost anything, so this is not important, because the
Python programmers didn't chose Python because it can do what other languages
cannot do.
It is important how easy is to create an app with it, and while Python offers
helpful features for creating desktop apps, for creating web apps Perl is
better.
Here is a text from the documentation of Pyramid/Pylons:
"We finally need to add some routing elements to our application configuration
if we want our view functions to be matched to application URLs.
...
# routes setup
config.add_route('list', '/')
config.add_route('new', '/new')
config.add_route('close', '/close/{id}')
"
...
First, this is a bad style of mapping urls, because this list must be
maintained every time the programmer changes something in a controller that
makes the app need to use other urls.
Catalyst don't need this overhead and don't need to specify the url mapping in
a separate module. If the controllers change, then the url dispatching also
changes.
Second, this way of url dispatching is not so flexible, because it doesn't
allow as many types of url mappings.
Catalyst allows to dispatch the urls to actions based on controllers and
subroutines names, globally or locally (based on the current controller), it
allows dispatching based on regular expressions, it allows a chained dispatch
where more actions are executed in a certain order on a single request, and all
these without typing code outside of the subroutines that do the actions.
The module DBIx::Class which is used usually as an ORM can create the class
files for all the tables from a database (MySQL, Oracle, PostgreSQL, SQLite, MS
SQL, etc), and it can be used to search using unions, sub-selects, can define
views at ORM level, can accept to insert different types of objects like
DateTime objects and can also return those type of objects, and many other
things, and most of the things it can do can be done without using SQL code at
all, but only standard Perl code and Perl data structures.
HTML::FormFu form processor is one of the most used form processors in Catalyst
applications and it can generate and parse forms created directly in the code
of the application, or as external configuration files defined using JSON, or
YAML, or Apache configuration style, or Perl data structures, or XML...
The forms defined are very easy to create and the elements from those forms,
for example the list of elements in a combo box can be taken directly from a
database by specifying just a few configuration elements. The results of a form
submit can be also inserted in a database using a connector with DBIx::Class
without specifying any database table column name in the programming code, and
for doing this are required just a few lines of code that checks if the
$form->submitted_and_valid() and that does the redirection after the submit,
the insertion in the database requiring just:
$form->model->create;
or
$form->model->update( $db_record );
...after that record was defined using just something like:
my $db_record = $c->model( 'DB::TableName' )->find( $record_id );
And HTML::FormFu can do filtering based on many conditions, impose the
specified constraints, specify different inflators/deflators from the inserted
strings to their corresponding object types, do a validation eventualy based on
a database query that checks for duplicates or other things, transform the data
automaticly after the form was processed, can use I18N for displaying the field
labels or values translated in the active language, have its own rendering
engine or can render custom form fields made using Template-Toolkit, etc.
Yes, for web apps I have seen more things which can be done much better in
Perl, much easier and clear, with less code, and not because the programmer
needs to do not-recommended tricks for shortening the code, but because there
are very many modules on CPAN that do the hard work.
Octavian
--
http://mail.python.org/mailman/listinfo/python-list
