|
in reply to Alternative to CGI.pm
I feel your pain since we do a lot of CGI where I work. It's fast and easy and I really don't have any complaints about it.
An alternative to most of the CGI input parts would be CGI::Simple. It will give you params() and such just like CGI.pm did ... if you don't want to install CGI.pm yourself.
For the output parts, there's HTML::Tiny. I haven't tried it but it's there if you want something like that.
FWIW, I've looked at some of the PSGI frameworks and all the examples I've seen are pretty small and have so much overhead I don't see the advantage of them. I suppose I'd need to find more than "tutorial examples" to see what they really offer. Back in time, someone here created a few pages with Mojolicious and they are a real pain to maintain and seem to have a lot of "black magic" compared to CGI, creating a negative impression IMHO. In fact, we'll probably end up ripping out Mojolicious and converting those pages to CGI to simplify our software code base.
|
Re^2: Alternative to CGI.pm
by Your Mother (Archbishop) on Mar 24, 2017 at 20:43 UTC
|
IMHO. In fact, we'll probably end up ripping out Mojolicious and converting those pages to CGI to simplify our software code base.
This comes off sounding a bit like: In fact, Perl 5.10 has so many weird conventions and features we don't use, we'll probably end up converting all our scripts back to 5.4.
| [reply] |
|
|
LoL :)
It's meant in a practical way and more like: All of our programs are in Perl, except for a few that are in Python and no one here knows Python, so if we can get those translated to Perl then we can ditch the Python stuff and our code base will be easier to maintain because we'll have fewer technologies to know. (That was reality for us too until I rewrote the last Python program in Perl a few months ago.)
In the abstract, there's nothing wrong with Python for those of you who like it. In the practical sense, it's an issue for us here because no one here knows Python so it makes our job harder.
Since ~97% of our code is CGI, why maintain a vast minority of code in a framework no one here really knows and slows us down? (How did it get here? Someone wrote it as a proof of concept and then checked it in just before they left for another job and at the time there was no one to prevent that -- a sad tale.)
| [reply] |
|
|
| [reply] |
Re^2: Alternative to CGI.pm
by Anonymous Monk on Mar 24, 2017 at 20:50 UTC
|
"Back in time, someone here created a few pages with Mojolicious and they are a real pain to maintain ..."
Without showing us what you are up against, we cannot really have a meaningful discussion. | [reply] |
|
|
If the PSGI frameworks work for you and speed you up, that's really great and I'm happy it's a positive there.
For us here, no one really knows Mojolicious, so it's a struggle to work on it when something goes wrong. Yes, we could invest the time to learn it, but it's only like 3% of our code and we have so many other important things to do.
When we do have to work on the code, we find it hard to figure where/when things are happening or how it gets called. There appears to be a lot of "black magic". Now, if we understood the framework, it probably wouldn't be considered magic, but as it is, it looks like subs get called for no reason we can discern.
I don't particularly like all the code that gets pulled in because of the framework, as in many thousands of lines in extra modules no one else uses, plus an extra service (I guess you'd call it): morbo. This appears to be a problem only because our entire app isn't written with Mojo. If it was, I probably wouldn't complain about it because it'd be used for everything. But when only a tiny amount of our app uses it, it seems like a large overhead.
Mojo forces another templating system on us; we normally use Template Toolkit. OK, Mojo's templates aren't not overly hard to understand and there are even a few cool things about them, but the problem is that it's yet another exception to the rest of our code base.
There are probably a few other issues, but those are the main ones. Sure, some of this you can throw into the category of "you don't like it because it's different" and I'll even agree. But a large part of my problem with Mojo is that I can't see the benefit the framework is supposed to give me ... the small examples in the tutorials don't strike me as "wow, that'd be so helpful". Maybe I haven't found the right tutorials. (shrug) It might be great tech, but I just haven't seen why. I'm open to understanding if someone can explain it.
If you're wondering how did that bit of Mojo code get here, the answer is someone wrote it as a proof of concept and then checked it in just before he left for another job. At the time there were no controls in place to prevent that like there is now. It was also from before I started working here.
| [reply] |
|
|
Mojo forces another templating system on us; we normally use Template Toolkit. OK, Mojo's templates aren't not overly hard to understand and there are even a few cool things about them, but the problem is that it's yet another exception to the rest of our code base. You can pick and choose a templating system in Mojo just like in everything else
Mojolicious::Plugin::TemplateToolkit -Template Toolkit renderer plugin for Mojolicious
Template::Provider::Mojo - Use Mojolicious to provide templates
| [reply] |
|
|
|
|
| |
|
|
|
|
