I'm using PhpStorm 10 to work on a craftCMS project, and I'd like to register *.html as a pattern for Twig files as discussed here.
My question: Is there a way to do this in a manner that it will only affect this particular project, allowing my other projects to still use that pattern to identify HTML files?
...that it will only affect this particular project...
Unfortunately no.
https://youtrack.jetbrains.com/issue/IDEABKL-6335 -- watch this and related tickets (star/vote/comment) to get notified on any progress.
Right now this ticket is located in "IDEA Backlog" project .. which means that it's quite unlikely that it will be implemented any time soon. Plus, developers clearly stated (comment 1 & comment 2) that they do not really plan to implement such stuff.
That being said, it is something that could be written into a plugin (an example).
To use twig in PHPStorm for CraftCMS one can simply rename those .html files to .twig and Craft will load them fine.
I've been an avid user of CGI.pm since the previous millennium so I was a bit surprised when it disappeared from my old Ubuntu server when I upgraded it recently. My short-term fix was sudo cpan install CGI, but a quick web search to find out why it was missing in the first place revealed CGI::Alternatives which explains why it has gone and offers some suggestions for alternatives. For my purposes, HTML::Tiny looks best for replacing my programmatic HTML generation, but Alternatives is strangely silent on the subject of HTTP headers and CGI parameters.
I broadened by search and found lighter alternatives to CGI.pm on perlmonks where one response suggests CGI::Simple, but the recommendation is less than whole-hearted - "its not quite as up to date as CGI.pm".
So is CGI::Simple the way to go, or is there a better alternative?
Please don't spend time suggesting "rewrite everything using framework XXX". I really don't have the time or energy for that. I'm happy to replace all my HTML generation with HTML::Tiny, so I'm looking for something with a similar (or lower!) amount of rework to replace header() and param().
You're missing the point if you're looking for an alternative that provides header and param.
The argument for the removal of CGI.pm from core (but not from CPAN) is that you shouldn't have to deal with CGI yourself; you should be using a framework that handles this for you.
If you don't agree with this — if you're looking for an equivalent to header and param — go ahead and keep using CGI.pm.
If you do agree, CGI::Simple is no better than CGI.pm.
As others have said, there's no reason not to use CGI together with HTML::Tiny. So that's the answer to your question. For the last five years that I was using CGI, my programs all started something like:
use CGI qw[param header];
which is the approach you're talking about here.
If you wait a year or two, the plan is for the HTML generation functions to be removed from the main module, so your problems will all go away at that point.
But that's not what I'd do in your situation. I'd switch to using PSGI and Plack. You said that you don't want anyone to suggest a new framework, so I'm not going to do that. Plack isn't a framework, it's a toolbox for writing PSGI applications. Certainly, I'd use a framework like Dancer, but you don't have to. You can happily use Plack without any of the frameworks built on top of it.
You'll still get most of the advantages of PSGI. You'll be able to deploy your applications in any way you like. You'll have access to all the awesome Plack middleware. Testing your program will be far easier.
When you're using "raw" Plack, the equivalent of CGI::param is Plack::Request::parameters and the equivalent of CGI::header is Plack::Response::headers.
So there are three answers to your question.
Carry on using CGI.pm. Just stop using the HTML generation functions and replace them with HTML::Tiny
Use raw PSGI/Plack and bring your web development into the 21st century
Use one of Perl's many great web frameworks.
Unfortunately, you don't seem to like any of those answers.
The issue with CGI.pm is not that it's going away, merely that it will no longer be distributed as part of the core Perl distribution. However that doesn't mean you have to install from CPAN. On your Ubuntu system you can just do:
sudo apt-get install libcgi-pm-perl
and you'll be off and running with the same old CGI you know and love :-)
The correct answer to my question is that use CGI::Simple is better than use CGI qw(header param) because it loads faster.
Answers along the lines of "Use Plack, it's the future of Perl for websites" weren't helpful to me because I didn't have time to learn a new programming paradigm or to discover how to reconfigure my web server to make it work, no matter how insistent the Plack Evangelists were that I was wrong in what I was trying to do.
I've now had a bit of time to wade through the links to documentation and presentation slides I was offered and I can see what they were getting at, but one failing in what I've read so far is the lack of a concise end-to-end working example to help get my head around things ... so here's what I knocked together to get me started (and, no, I haven't finished yet!). I hope that others beginning the journey from CGI to PSGI will find this useful to help get them underway...
First you need to install Plack. I'm running an Ubuntu 14.04 installation so it was simply a matter of running sudo apt-get install libplack-perl. The generic way is to install Task::Plack from CPAN.
Next you need to know where your cgi-bin directory is located. You ought to know already if you're a CGI die-hard! Since I'm running Apache mine is defined in /etc/apache2/conf-available/serve-cgi-bin.conf by ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/.
Now for the magic. We're going to create a CGI script that runs a PSGI app, handing it data from the CGI environment. This is good for experimentation and testing but NOT for deployment, as you don't get any of the speed benefit that PSGI can give you (for that you need something like Plack::Handler::Apache2, Plack::Handler::FCGI or mod_psgi in Apache, or a dedicated PSGI server such as Starman or Starlet, or one of the other handlers mentioned on PlackPerl.org). Create /usr/lib/cgi-bin/psgi-cgi.pl with the following contents and make it executable:-
#!/usr/bin/perl
use Plack::Util;
use Plack::Handler::CGI;
my $app = Plack::Util::load_psgi($ENV{PATH_TRANSLATED});
Plack::Handler::CGI->new->run($app);
Next we need to tell Apache to pass PSGI app files to this handler. I did this by creating /etc/apache2/conf-available/psgi-cgi.conf containing:-
Action psgi-cgi /cgi-bin/psgi-cgi.pl
AddHandler psgi-cgi .psgi
then loaded it into my Apache server by running sudo a2enconf psgi-cgi and sudo service apache2 reload. Basically you need to get these lines into your httpd.conf file and restart the server.
Finally, my first PSGI script, which I created in my server's DocumentRoot as /var/www/html/hello.psgi:-
use Plack::Request;
my $app = sub {
my $env = shift;
my $req = Plack::Request->new($env);
my $par = $req->parameters;
return [
200,
[ 'Content-Type', 'text/plain' ],
[ "Hello world!\n",
map("$_ = ".join(", ", $par->get_all($_))."\n", sort keys %$par),
]
];
};
The application is a coderef which returns a 3-element arrayref: the first is the HTTP status code, the second is the name,value pairs for the HTTP header, the third is the body of the response (which could be generated using HTML::Tiny for a web page). The first 2 elements answer the question of what you need instead of the CGI::header function - nothing! (though for more complex handling you'll need Plack::Response::headers). The example also shows how to replace CGI::param - use Plack::Request::parameters, which returns a Hash::MultiValue object containing the values of URL (GET) and BODY (POST) parameters, including the ones with multiple values.
Finally, a test:-
$ wget -q -O- 'http://localhost/hello.psgi?a=1&a=2&a=3&b=1&b=4'
Hello world!
a = 1, 2, 3
b = 1, 4
I hope this is useful to other CGI die-hards in taking their first steps towards PSGI proficiency, and I hope the Plack Evangelists will acknowledge that it takes a lot of reading and comprehension to get even this far.
CGI::Minimal would a good option, it is much lighter than CGI & CGI::Simple, but it lacks advanced methods like CGI & CGI::Simple
I was trying to build a simple auth mechanism using madvoc and interceptors but it seems that the tutorial at
http://jodd.org/doc/example/auth-with-interceptors.html
is a little bit outdated.
I think that the tag was removed and I was not able to find the substituent.
How should we use the form in general and what is the recommended auth mechanism?
P.S. - I`m using latest jodd version.
The shortest answer is to check module jodd-joy. Look at the package jodd.joy.auth. It contains latest AuthTag, AuthAction that may be used, etc. This module contains some helpers for build an web-app even faster.
I will update this answer later, with more info - actually, I will try to update the website, too. But in general, the idea behind the auth is not much changed;)
I need to perform push-ins for my json controllers, however, doing it via STS will make it really tedious. For my demo project, it works since it only contains 10 pojos, but for real world project this may become 20-50 pojos.
Is there a way to perform push-ins via command line or any way to automate it?
I am asking due to my previous issue which cannot be solved by spring-roo's current version :
RooWebJson and KendoUI Grid
No, there is no way to push-in code via command line. The best way is to use STS, but note you will push-in the code only one time.
I am a front-end guy using Windows for design and html/js/css coding. My work is separate from the back-end guy using .NET. I am also new to Haml/Sass thing as well as Ruby. And definitely not using Rails. After few search, I decided to pick Sublime Text 2 for Sass/Haml support and get rid of my old Notepad++. My first question is:
1. What is the best practice / efficiency to automatically convert whole folder of Haml (primary) and/or Sass to static documents (html/css)?
I have a separate solution for Sass by setting the "watch". I was searching for Haml automatic conversion solution and found few options:
Library for making static websites with HAML/SASS/CSS framework
2. Should I use StaticMatic?
Google search said it is the best. But there seems no update for 2 years
https://github.com/staticmatic/staticmatic
There is also this site (Is it the same?): http://staticmatic.rubyforge.org/how_to_use.html
If I use StaticMatic, I can setup a build system in Sublime Text to run from the Build Menu (http://docs.sublimetext.info/en/latest/file_processing/build_systems.html)
3. OR should I go with all-in-one solution like this (may cost few bucks)? Is there free one?
http://fireapp.handlino.com/
I don't mind to have Sass -watch running separately and another polling mechanism for Haml. I just want to make sure I have the "latest" out there.
Hope to get some advise for my unique situation. Thanks.
The answer is Middleman
http://middlemanapp.com/
It's the replacement for out-dated StaticMatic
HAML:
For automatic conversion from haml to sass you can use this gist: https://gist.github.com/3898955. If you want to automate even more the workflow process, you can use https://github.com/alexnj/SublimeOnSaveBuild sublime package to run the command on file save.
SASS:
For SASS here is the needed setup. https://gist.github.com/3899112.
For automatic conversion on save, the same rules are applied here too, but it's important to include the .sass and .haml extension in SublimeOnSaveBuild.sublime-settings file.
So your file should look like this:
{
"filename_filter": "\\.(css|js|sass|less|scss|jade|haml)$",
"build_on_save": 1
}
You can extend this list at your own wish.