On the Laravel News site there's a new post sharing some of the new Blade directives coming in the 5.6 version of the Laravel framework.

Laravel 5.6 will include two new form blade directives for cross-site request forgery (CSRF) and HTTP method input, thanks to Taylor Otwell.

The new CSRF handling replaces the previously used format with a simple @csrf tag in the Blade template (inside of the form). The other is related to the method used to submit the form. The new addition allows you to submit the form via something other than POST using the method_field function.

The Scotch.io blog has posted a new tutorial for the Laravel+Vue.js users out there helping you effectively handle validation error messages output through the Vue.js portion of the application.

Recently, I launched a open source side project I was working on called Open Laravel. Open Laravel allows developers to submit open source projects that were built using the Laravel framework. The project submission page uses Vue.js to submit the form asynchronously through an AJAX request. Since I am no longer sending the form the default way (refreshing after form submission), I needed a way to show Laravel form validation error messages. After going back and forth with some forum questions and answers, I was able to make it work.

The tutorial starts you out with a fresh install of Laravel and runs a npm install to get the Laravel Elixir dependencies. They then add in the other dependencies (like Vue.js itself and the use-resource package). Next up are changes on the Laravel side: adding required routes, setting up a "Posts" controller and making a simple view with the form to take in post content. They provide the Javascript for the Vue.js side as well, making use of the vue-resource to connect the form with the POST request to the backend. Finally they tie in the "FormError" component and have it either show failure messages or success messages when everything's good.

For those out there that are speakers (or are wanting to try their hand at speaking) at a technology conference, Anna Filina has shared her own thoughts about how many talks to submit to a single conference...and what might be too many.

I read this interesting post by Cal Evans about submitting conference proposals. He makes some very valid points, but I’d like to add my own experience as an organizer, so that when you submit, you have multiple perspectives.

She responds to Cal's comments about filtering talks based on topics the conference has mentioned, submitting a max of four talks and submitting the best idea first. Anna also shares some of her own recommendations as an organizer from the Confoo conference(s).

I know how hard it is to go through so many talks. At ConFoo, we receive close to 1000 proposals. [...] I don’t mean to tell other conferences what to do. However, speakers should always bear in mind that conferences operate differently. Perhaps organizers can create a comprehensive guideline specific to their event.

If you've considered submitting to a Call for Papers to speak at a technical conference but aren't sure exactly what the process is like, Stefan Koopmanschap has shared some of his experience in a new post to his site.

Having been a conference organizer as well as a speaker, I've seen both sides of the CFP process. Because of that, I've made some decisions as a speaker on how I handle CFPs. Since I've discussed this with several people in the past year but it keeps coming up, I've decided to document one of my decisions here.

He talks about a "first world problem" of not knowing if you're accepted to one conference before applying to the CfP for another at the same time. He also looks at the usual Call for Papers process from the perspective of an organizer and how to sift through the (usually) hundreds of submissions that come in. He also shares his own personal rule for submitting to a conference: only submit if you're absolutely sure you can attend.

As is mentioned in this new post to the Ibuildings blog, the Call for Papers for the Dutch PHP Conference is currently open and accepting submissions until February 22nd.

This year Ibuildings will host the Dutch PHP Conference (DPC) in Amsterdam for the tenth time in a row, on June 23rd - 25th. As you may have noticed, since a couple of weeks you can send in your tutorial or talk proposals. The Call for Papers closes on February 22nd.

DPC offers a stage to veteran speakers as well as the less experienced and debuting speakers. [...] We're looking for speakers who talk about subjects that they're passionate about. Talks don't necessarily need to be about PHP development: any subject that might be of interest to PHP developers is welcome.

The post also includes some suggestions that could help you get accepted as a speaker for the conference including:

• sending more than one proposal
• getting reviews of the proposals either from coworkers or something like helpmeabstract.com
• practice giving presentations locally too

Be sure and get those proposals in the February 22nd deadline before

With another round of "conference season" and Call for Papers starting up, there's some timely advice from Lorna Mitchell with some suggestions about submitting a talk to the conference of your choice.

I've been a conference speaker for a lot of years now, which doesn't make me an expert but it does mean that people ask me for advice pretty regularly! With the Call for Papers open for PHP North West at the moment (awesome conference, first weekend in October, CfP at http://conference.phpnw.org.uk/phpnw15/call-papers/), I've taken this question a few times. Here's my advice in a nutshell.

She shares five tips that she feels can help you make for a better abstract and submission including writing it down before submitting and asking for peer reviews before hitting that submit button. She also links to a few other helpful resources that can provide even more tips to help you even once you've been selected.

If you've ever considered taking the leap and trying your hand at speaking at (technology) conferences but weren't sure where to start Beth Tucker Long, well known PHP community member and speaker, has posted a guide to help you submit a talk to your conference of choice.

I’ve been on both sides of the proverbial conference table. I have been the one submitting proposals, hoping against hope that they will pick mine, and I have been on the selection committee, struggling to choose between hundreds of awesome proposals when you only have a few talk slots available. Through these varied experiences, I’ve learned a few things about what works and what doesn’t when submitting a conference proposal.

She provides a "checklist" of sixteen things that she's learned over the years about submitting ideas to events and what to do/not do when giving the actual presentation including:

• First and foremost, remember to hit spell-check
• Don’t talk about yourself in your talk description
• Explain the practical applications of your topic
• Share past feedback in the comments or notes section
• Submit a lot of proposals
• Don’t submit multiple topic ideas or variable time lengths in one submission

The final three on her list have more to do with the presentation itself than the proposal and, in my opinion, are almost more important: don't talk down to your audience, be brief and be interesting.

If you've ever thought about submitting a topic to speak at a technology conference, but never quite knew how to take those first steps, check out this advice from Beth Tucker Long. It's a list of steps and reminders to follow when thinking about your topics and submitting.

I've been on both sides of the proverbial conference table. I have been the one submitting proposals, hoping against hope that they will pick mine, and I have been on the selection committee, struggling to choose between hundreds of awesome proposals when you only have a few talk slots available. Through these varied experiences, I've learned a few things about what works and what doesn't when submitting a conference proposal.

Her list includes things like:

• First and foremost, remember to hit spell-check
• Have someone else read your submission
• Identify a clear problem that the topic of your talk will help solve
• Be honest about your topic
• Share past feedback in the comments or notes section
• Submit a lot of proposals

On his blog today Jani Hartikainen looks at his experience learning Wicket (a Java application framework) from the perspective of a PHP developer.

My starting point with Wicket was basically zero, at least Java-wise: I had never used any Java web app framework, so I didn’t really know what to expect. Since as I said I’ve mostly used PHP and Python, I assumed the program flow would be something like in them. Of course, this was a completely wrong assumption.

He includes one specific example - handling a form submission. In PHP you work with the POSTed values and do something (insert into a database, email, etc) but with Wicket you really just display the form again - with a few other bits of configuration of course. You worry more about what's in the form instead of how to handle the results. He notes that it's a lot like working with a desktop application environment and recommends it as "an interesting way to do things".

New on the Ask About PHP blog today there's a tutorial about using PHP and jQuery to submit a form without having to submit the entire page.

Lately, I’ve been chancing on quite a number of posts at various places asking about how to perform a web action without the webpage reloading/refreshing? For example, dynamically updating a list on a page without a reload or submitting a form to PHP without leaving the webpage the form sits on. I guess this is as good a time to start branching into some posts on PHP and Javascript, or more specifically, jQuery.

You can just download the code of you want to get started right away or you can follow along with the tutorial for code, flow diagrams and a full definition of how it all works.