I realize this, but it defeats the "EASY" that 4.2 had. Why would they require more things to have to do in 5.0? Sessions, DB, etc worked "out of the box" in 4.2.

I agree with @jimgwhit. Shouldn't it work "out of the box" as in laravel 4.2 since Session is in the alias array in config/app.php?

	'Session'   => 'Illuminate\Support\Facades\Session',

This is a php thing, in laravel 4.2 you probably did not nameapace your classes. When you namespace your classes you need to import/use the classes you want to use in your own class (or type out the whole namespace every time you use them).

http://php.net/manual/en/language.namespaces.php

If you're accessing the facades, you should be able to use the syntax

\Session::get('foo');

You're accessing it the same way, but it's accessed through the root namespace. Give it a try.

But why a backslash now::

\Session::get('foo');

instead of a simple:

Session::get('foo');

I understand namespaces some, but seems to me namespacing makes things harder. What was so wrong with the way things worked in ver 4.2? Are people using namespacing because it's the latest fade?

jimgwhit said:

But why a backslash now::

\Session::get('foo');

instead of a simple:

Session::get('foo');

I understand namespaces some, but seems to me namespacing makes things harder. What was so wrong with the way things worked in ver 4.2? Are people using namespacing because it's the latest fade?

Because that is how namespacing works. If you don't want to back-slash, put a

use Session;

at the top of your file. You also might want to actually learn about namespacing and not just "some" since it is after all a pretty standard day two beginning developer concept and not in anyway a "latest fad"

Also, Laravel 5 is not even beta yet, so it's a little absurd to think there should be docs.

On the laravel site click Dev, THERE ARE DOCS, just not totally up to date. That's Dev. I predict the namespace thing will be replaced by another crazy fad in only a few months. Believe me it's a fad. Ditto with autoloading, way too much is autoloaded, eventually the PHP world will go back to loading "as needed". And no one totally understands someone elses name spacing, its their embedding, which needs instructions on usage. I.e., where the slashes go. I have no problem with how laravel 5 works, can't wait for good up to date manual. I don't care if they namespace, crawlspace, or whatever, as long as I have applicable instructions on how to use it.

You would have only been able to do Session::get('foo') if the calling code wasn't namespaced, as it would read off the global namespace. The full namespace or at least use Session would have always been required if within namespaced code, and is not an issue with Laravel, but rather a part of the way PHP works.

This is a huge plus for laravel 5. L5 is one of the very few frameworks which enforces psr-4 standards. Please go through the below link.

https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-4-autoloader.md

This enables more interoperability and less framework locking. It is definitely good for building enterprise level applications.

Can't believe some people are complaining over an app that is not even in beta yet. Why on earth would Taylor keep up the docs for an alpha version of the framework? Unrealistic to expect that from him.

Then why the laracast, not much difference in current docs verses current videos. But I do agree the final version isn't out yet. But I guess it's like a kid at Christmas, the can't wait syndrome. I do like laravel 4.2, I just don't like drastic changes. I guess that 4.2 didn't use namespaces. But I have already got used of how laravel 5 has to load things. I have used zend some and knew about namespacing already. Like I said I don't care how things are called as long as there are instructions and as long as eloquent works. Eloquent to me is a good database wrapper, I have tryed doctrine orm, didn't like the syntax, however I like doctrinne Dbal, to me it's similar to eloquent. Could these two be kissin cousins?

jimgwhit said:

On the laravel site click Dev, THERE ARE DOCS, just not totally up to date. That's Dev. I predict the namespace thing will be replaced by another crazy fad in only a few months. Believe me it's a fad. Ditto with autoloading, way too much is autoloaded, eventually the PHP world will go back to loading "as needed". And no one totally understands someone elses name spacing, its their embedding, which needs instructions on usage. I.e., where the slashes go. I have no problem with how laravel 5 works, can't wait for good up to date manual. I don't care if they namespace, crawlspace, or whatever, as long as I have applicable instructions on how to use it.

You need to take a step back and do some beginners courses in PHP and understand what autoloading, namespaces, etc actually is. I've been using since 2009 as have most PHP developers, and I use developers in the actual sense of the word, not just someone who can throw up a phpinfo() page.

As far as "And no one totally understands someone elses namespacing," I again go back to you need to do some beginners courses.

Documentation? Try opening up the code and looking at it, all of the documentation you need is right there.

Post Titles like yours "Yet another laravel 5 problem" just make me shake my head, then throw on comments complaining about a lack of documents, then throw on calling stuff like namespacing a "fad that will go away". It makes me feel sorry for your employer or clients, because they are getting screwed.

First of all, a framework is to use. If I had to figure everything about it out, I may just as well just use php alone with pdo. Believe me namespacing is yet another cute little faddish toy. Nothing a simple include can't handle. Namespacing is currently needed because some frameworks have zillions of files to use in the background. A session class for example. In reality MVC doesn't need 10.7 billion files to work. All could be done with PDO, and php built-in items, I.e., sessions, request, etc. It's the size of some frameworks that make autoloading and namespacing a necessary evil. I have seen some very large and complex php frontends that only need to include a file on an as needed basis. So in reality if you have to depend on autoloading and namespacing, it's you that needs to go take a refresher on the basics. Look up using eloguent outside of laravel, you might actually learn how to program some php correctly. Also in laravel 4.2 namespacing is used in the background, mostly transpaent to enduser like Capsule manager:

<?php namespace Illuminate\Database\Capsule;

use PDO;
use Illuminate\Events\Dispatcher;
use Illuminate\Cache\CacheManager;
use Illuminate\Container\Container;
use Illuminate\Database\DatabaseManager;
use Illuminate\Database\Eloquent\Model as Eloquent;
use Illuminate\Database\Connectors\ConnectionFactory;
use Illuminate\Support\Traits\CapsuleManagerTrait;

class Manager {

	use CapsuleManagerTrait;
//more code

But it wasn't required in the controllers.

<?php

class BaseController extends Controller {

	/**
	 * Setup the layout used by the controller.
	 *
	 * @return void
	 */
	protected function setupLayout()
	{
		if ( ! is_null($this->layout))
		{
			$this->layout = View::make($this->layout);
		}
	}

}

Above is laravel code, not mine. In fact do a web search on using doctrine DBAL and you might learn something. Yek, how did you even end up on a laravel 4.2 forum when namespacing isn't required in controllers? And also, believe it or not include is still in the php manual. Go to my pagination example where I simlpy include my pagination class. http://laravel.io/forum/11-13-2014-laravel-5-pagination

A simple dbal example:
initdbal

<?php
    use Doctrine\DBAL\DriverManager;
    require_once "vendor/autoload.php";
    $config = array(
    'dbname' => 'pbackdate',
    'host' => 'localhost',
    'user' => 'root',
    'password' => 'zzzzzzzzzzzz',
    'driver' => 'pdo_mysql',
    );

    $conn = DriverManager::getConnection($config);
   

Yes dbal uses namespace and autoload, but had instructions and after this namespacing is transparent (in background).
Using this:

<html>
<head>

<link rel="stylesheet" href="include/locked-column.css" type="text/css">
</head>
<body>
<?php
require_once 'initdbal.php';
include 'include/paginatormd.php';
include 'include/auth.php';
$t1 = (isset($_POST['t1']) || isset($_GET['t1']) ? $_REQUEST['t1']:"");


        echo '<br>';
        
        $search = $t1;
        $search = $search."%";
         $stmt = $conn->prepare("SELECT count(petid) as kount FROM pets where petname like :search");
        $stmt->bindValue("search", $search);
        $stmt->execute();
        while ($row = $stmt->fetch()) {
           //echo $row['kount'];
           $kount = $row['kount'];    
        }
//$num_rows = $conn->executeQuery("SELECT count(petid) as kount FROM pets where petname like :search", ['search' => $search]);
echo $kount;
$pages = new Paginator('5','p');
$pages->set_total($kount);
echo "<body>";
echo "<br>";
echo "<div id=tbl-container>";
echo "<table border=1 id=tbl style=behavior:url(move-lock-col.htc)>";
echo "<thead>";
echo "<tr>";
echo "<th>PET ID</th>";
echo "<th>PET NAME</th>";
echo "<th>SPECIES</th>";
echo "<th>SEX</th>";
echo "<th>OWNER ID</th>";
echo "<th>PET OWNER</th>";
echo "<th>STREET</th>";
echo "<th>date</th>";
echo "<th>ocheck</th>";
echo "<th>PIC</th>";
echo "<th>EDIT</th>";
// echo "<th>VIEW</th>";
echo "</tr>";
echo "</thead>";
echo "<tbody>";
        
        
        
        $queryBuilder = $conn->createQueryBuilder();
       //->select('petid', 'petname')
        
        $queryBuilder
        ->select(
            'petid',
            'petname',
            'species',
            'sex',
            'ownerid',
            'petowner',
            'ostreet',
            'odate',
            'ocheck',
            'dogpic')
        ->from('pets')
        ->where('petname like :search')
        ->orderBy('petname', 'ASC')
        ->setFirstResult($pages->get_limit2())
        ->setMaxResults($pages->get_perpage())
        ->setParameter('search', $search);
//->where('petname like ?')        
//->setParameter(0, $search);
        $rows = $queryBuilder->execute()->fetchAll();
        //print_r($rows);
//  $queryBuilder['petname'];
//foreach ($queryBuilder->execute()->fetchAll() as $pets_Row){
foreach ($rows as $pets_Row){
   $tmppage = $page;
			$tmppetid = $pets_Row['petid'];
			echo "<tr onMouseover=this.bgColor='lightgrey' onMouseout=this.bgColor='#FFFFFF'>";
			echo "<td>".$pets_Row['petid']."</td>";
			echo "<td>".$pets_Row['petname']."</td>";
			if (empty($pets_Row['species'])) {
				echo "<td> </td>";
				}
			else {
				echo "<td>".$pets_Row['species']."</td>";
				}
			if (empty($pets_Row['sex'])) {
				echo "<td> </td>";
				}
			else {
				echo "<td>".$pets_Row['sex']."</td>";
				}
			if (empty($pets_Row['ownerid'])) {
				echo "<td> </td>";
				}
			else {
				echo "<td>".$pets_Row['ownerid']."</td>";
				}
			if (empty($pets_Row['petowner'])) {
				echo "<td> </td>";
				}
			else {
				echo "<td>".$pets_Row['petowner']."</td>";
				}
			if (empty($pets_Row['ostreet'])) {
				echo "<td> </td>";
				}
			else {
				echo "<td>".$pets_Row['ostreet']."</td>";
					}
			if (empty($pets_Row['odate'])) {
				echo "<td> </td>";
				}
			else {
				echo "<td>".$pets_Row['odate']."</td>";
				}
			
			
			//if (empty($pets_Row['ocheck'])) {
				//echo "<td> </td>";
				//}
			//else {
				echo "<td>".$pets_Row['ocheck']."</td>";
				//}
			
			
			
			
			if (empty($pets_Row['dogpic'])) {
				echo "<td> </td>";
				}
			else {
				$tpic = $pets_Row['dogpic'];
				echo "<td><a href=\"upload/$tpic\" target=\"_blank\"><img width=\"80\" border=\"0\" src = \"upload/$tpic\"></a></td>";
				 }
			// echo "<td><a href=\"powners_Edit.php?id=$tmppetid&page=$page&t1=$t1\"> EDIT </a></td>";	
			echo "<td><a href=\"petedit.php?petid=$tmppetid\"> EDIT </a></td>";	

}
echo "</tbody>";
echo "</table>";
echo "</div>";

echo '<br>';


echo $pages->page_links('?','&t1='.$t1);

$areturn = "http://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];
echo "<br>";
$haystack = $areturn;
$needle   = '?';
$pos      = strripos($haystack, $needle);
if ($pos === false) {
    $_SESSION['areturn'] = $areturn."?p=1&t1=".$t1;
} else {
    $_SESSION['areturn'] = $areturn;
}
echo "jimmie here is a return:  ".$_SESSION['areturn'];

echo "<a href=\"mdestroy.php\">logout</a>";

?>
    <a href="petsearch.php">     back to search</a>
 </body>
</html>

Taking note of:

$queryBuilder
        ->select(
            'petid',
            'petname',
            'species',
            'sex',
            'ownerid',
            'petowner',
            'ostreet',
            'odate',
            'ocheck',
            'dogpic')
        ->from('pets')
        ->where('petname like :search')
        ->orderBy('petname', 'ASC')
        ->setFirstResult($pages->get_limit2())
        ->setMaxResults($pages->get_perpage())
        ->setParameter('search', $search);
//->where('petname like ?')        
//->setParameter(0, $search);
        $rows = $queryBuilder->execute()->fetchAll();

And

require_once 'initdbal.php';  //a simple include

Its initialized and ready for use, I don't have to:

\this\that\whatever\this is crazy\etc

To use the querybuilder.

In fact dberry37388 I will teach you namespacing: In java,using servlets the following is very common:

import java.io.*;
import java.util.*;
import javax.sql.*;
import javax.servlet.*;
import javax.servlet.http.*;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;

This would be like namespaces in php. But the point is the folks that program java/oracle created all this and the end user using java-servlets-bean classes do not have to worry about whats inside these imports, nor should they. The only thing that's important is knowing which ones to import. For example if I know I will be dealing with a resultset then I know I need:

import java.sql.ResultSet;

But I have never ever never even wondered what's inside of java.sql.ResultSet;
But because of applicable instructions, I know when to use this. Now later in the servlet code I can:

ResultSet rs = null;
other code
rs = stmt.executeQuery("sql here");

Notice i did not have to:

\ResultSet

or worse yet:

\folder1\folder2\folder3.....\folder9000

Now I hope you understand my original post, I want to use DB::whatever, not:

\folder1\folder2\folder3.....\folder9000\DB::whatever.

Ok answrer one question if you are so so so smart. Why did this work in laravel 4.2 without namespacing at top of controller and without the \folder1\folder2\folder3.....\thing:

$data['owners'] = DB::table('powners')
                        ->where('oname', 'like', $ownersearch)
                        ->orderBy('oname', 'asc')
                        ->Paginate(5);

If this works without namespacing I guess you think the laravel programmers also need more lessons. How did they make it work in ver 4.2 can you explain that? That's the only point my original post was trying to make.

is this a joke ? Either way, welcome to modern PHP.

For example if I know I will be dealing with a resultset then I know I need:

import java.sql.ResultSet;

...

Notice i did not have to:

\ResultSet

but you did have to

import java.sql.ResultSet. 

That's pretty analogous to

use Session;

And then here's this gem:

I predict the namespace thing will be replaced by another crazy fad in only a few months. Believe me it's a fad.

Really? Namespacing is a fad? Get off my lawn.

lagbox said:

is this a joke ?

I hope so, because it's so funny!!! :D

All I've been referring is being able to:

$data['owners'] = DB::table('powners').   

Instead of

$data['owners'] = \Illuminate\Support\Facades\DB::table('powners').

If you like the psr4 so much why do you use laravel 4, where. $data['owners'] = DB::table('powners') alone would work without all the backslashes?

Defination of fad:
A fashion that is taken up with great enthusiasm for a brief period of time; a craze. Take the PSR-0 spec it seems that now PSR-4 is replacing it, thus a fad. So I guess if
a PSR-5 suddenly comes out PSR-4 will be hated and PSR-5 will be the new following.
When all along a simple:

include 'include/whateverclass.php';

still works.
I guess that I programmed java prior to php and just got used of simply putting an import at the top of a servlet. The main difference is:
In java the programmer didn't have to worry about the imports, rather just stick with programming the database stuff and user interface.
My way of thinking is the same in php. If I am using laravel, then follow the instructions as to how and what (includes or imports, or use statements to use) the laravel programmers have decided this, and all I want to do is use eloquent, and sessions, request, etc to do my programming. So why do some of you worry so much about namespacing and autoloading? To me the only people who should be concerned with this is the actual team maintaining laravel (like the people who maintain java or asp.net).
As long as there are clear instructions as to what to put at the top of a file / controller what difference does it all make.
Bottom line:
If you are writing a framework, know namespacing and autoloading.
If you are programming a database frontend for someone the namespacing / autoloading isn't your concern.(if using a framework).

Wow this wasn't a joke ... my heart, it hurts so bad.

lagbox said:

Wow this wasn't a joke ... my heart, it hurts so bad.

Now that's funny

I have nothing against namespacing / autoloading as long as there are applicable instructions that come with a framework on usage. As an example Doctrine dbal has these instructions:

<?php

    use Doctrine\DBAL\DriverManager;
    require_once "vendor/autoload.php";
    $config = array(
    'dbname' => 'pbackdate',
    'host' => 'localhost',
    'user' => 'root',
    'password' => 'zzzzzzzzzzz',
    'driver' => 'pdo_mysql',
    );

    $conn = DriverManager::getConnection($config);

Take note of the lines:

use Doctrine\DBAL\DriverManager;
require_once "vendor/autoload.php";

These two lines are applicable instructions from doctrine dbal, NOT MY CODE.
That's one of my points, tell me what to stick at the top to make things work.
After I put these two lines at top, following any and all applicable instructions, I
do not need to know anything else about namespacing or autoloading. The folks at
doctrine dbal has already pre-figured all of this out. Again, one more time:
I just need to follow their applicable usage instructions. Could almost make
a sad country song out of it. Now yes that's a joke.

This is hilarious and painful at the same time.

What is truely painful is how php has to change things so often please see this post:
http://laravel.io/forum/11-18-2014-do-no-harm-laravel In both asp.net and servlets/java classes the simple way to use/import has been stable for years and years.
Whereas it seems to change too often in php. Another framework I was using did the same thing and started using the psr-4. Some folks and companies spent many many hours / days / weeks programming a php frontend, and suddenly
to stay up to date has to struggle to stay up to date with the framework.
In fact I've been learning laravel 4.2 for a while now, and I have also installed 5.0 beta. I couldn't believe the changes.
Why can't the php world come up with a good way to include the files thats needed and at least stick with that
method for a few years. Again the way import works in java is the same as it was in the year 2003.
I'm fine with psr-4, but for crying out loud LEAVE IT PSR-4 FOR A WHILE. LEAVE THINGS ALONE.

What's the hilarious part?

Have you tried...

\DB::foo();

?

That should work since DB is in the alias list

Someone has no idea what modern PHP is...

What is modern php to you? To me it's using database wrappers like eloquent or dbal, or active record to query
a database and list/edit/update the data. Nothing more - nothing less. Once upon a time it was as simple as including your database wrapper and perhaps your getters/setters. Modern people who truely don't know how to program (but in their minds think they know) has turned it into a rig-a-ma-roo. I was programming dbase 3 + applications in the 80's. I have programmed in visual foxpro java and php.
Now two questions: Do you dislike dbal and the way their instructions are. Because frankly doctrine orm and dbal are very stable, established tools to interact with a database.
And do you disagree with the way java uses imports at the top of a class? And the fact it's stayed stable for many years. (Meaning didn't change every month so programmers didn't have to revamp code on a monthly basis).
Funny, you said modern php, I'm also using laravel 4.2, now are you saying that's not modern php?

I'm not really sure why you continue to compare Java to PHP - Java absolutely has namespaces (they're not a 'fad' - many languages use them), and the 'use' statement in PHP that you're complaining about is very close to Java's imports.

Don't get me wrong, I was once a procedural programmer, as well. It's very difficult for me to break out of the mindset sometimes. But I can tell you from experience, a spaghetti mess of includes - even well-maintained ones - are nowhere near as maintainable as properly-structured OO code. There's certainly a new set of skills you need to have to learn and follow - ones that I still don't fully have. But I have no interest in going backwards.

Modern PHP is OO, and all of the features, terminology, and quirks that go along with it.

So using dbal as per their instructions on their site is wrong, and I have never had more than 2 or 3 includes. Are you also saying that using laravel like the manual and videos show is wrong? I know of no other way to use laravel except following applicable usage instructions.
I am not complaining about a "use" statement! Rather pick a psr-spec and stick to it. Yes all modern program languages have namespacing, but they don't change it every other day requiring people to revamp/redo code. One spec in laravel 4.2 yet another in 5. I don't give a rats a-- which one is there, just pick one and leave it alone a for at least a few years. The problem is at the top of almost any programming classes you have imports or includes or whatever.
That's fine, I am happy happy happy with that. But if today you:

use whatever\whatever;

Don't change that to another technique overnight. Now instead of just a "use statement, you also require a namespace. Yes java and asp.net also have this, but the technique doesn't change every 24 hours on usage.
In fact i could care less about the stuff at the top of a class or controller, as long as it makes eloquent do what eloquent is supposed to do, (WORK WITH A DATABASE).
If writing at the top of a controller:

Why did the chicken cross the road, to get to the other side

If that line was the applicable instructions to make eloquent work then that's what I would place at the top.
Why are some of you so fixated on what goes at the top of a class or controller to make eloquent work.
When the laravel team has this decided for you, something you have no control over? The most important thing is having that information in the manual or a video so the "end user" of laravel knows what statement(s) to place at the top of the file or class or controller or model to make everything work.
Am I in a laravel forum or is this a psr-4 until psr-5 comes to save the day goodbye to psr-0 forum.

You do realize that large frameworks take a long time to implement, right? Laravel 4.0 was released in May 2013. PSR-4 did not see its first public mention until August, and was not 'released' as a standard until December of that year. I imagine it's one of the reasons Laravel is moving to version 5, rather than simply '4.3'.

Besides, you know that you can use Eloquent outside of Laravel, right? There are plenty of tutorials on the topic. You won't have to namespace anything you don't want to. Or stay on 4.2. You're the only one fixating on 'what goes at the top of a class or controller'. You reference it in every single post; people's responses only explain or rebut the aimless ranting.

PHP is an evolving language, with evolving practices. That's what makes it such a great language, but is also what makes it somewhat of a constant learning experience. Some people aren't into that. Why not develop in Java, then, if you enjoy that stagna-- er, 'stability'?

Like you, I come from a procedural background. I have had my frustrations with OO code, but you're asking the wrong questions. Instead of 'Why do I have to do this?', you should be asking "Do I want to learn how to do this, and what it's for?" - Only you can answer that, but that answer should help you decide which direction to take. There are many people who would be very willing to help you, if you just switch your attitude into learning mode.

Morgon said: Besides, you know that you can use Eloquent outside of Laravel, right? There are plenty of tutorials on the topic.

You didn't see my dbal example above? I do use eloquent and dbal sometimes. I have been using laravel for a while now, and I have received help from the forum and I have helped others by answering questions. I feel you miss the main point of this post.
By the way it was solved, and I know I need to place

 use \Illuminate\Support\Facades\DB;

at top. I have no problem with this, and I fully understand it.
Now my ONLY CONCERN IS:
Larvel 5 has this technique:

use \Illuminate\Support\Facades\DB;

to be able to use eloquent. DON'T change the technique next month for crying out loud
leave this way of doing it around for a while.
I do agree that php hasn't been as stable as java, and constantly evolving. But come on
it's been around a while now shouldn't it be a little more stable by now?
You yourself agree that 4.2 and 5 use a different psr spec. If these psr specs are so good why do
they have to change them all the time?
So bottom line thanks for your post, and I do want to continue to learn laravel 5, but with the hopes
that a new psr spec doesn't come out only a month after I have completely programmed something
in laravel 5.
See this post
http://laravel.io/forum/11-18-2014-do-no-harm-laravel

The thing that really troubles me the most is the fact that you call namespacing & autoloading "fads".

Who in their right mind wants to go back to include/require statements? And naming conflicts?

If you're griping about the "large" change from Laravel 4.2 to Laravel 5 or even backward-compatibility issues, then that's one thing. But publicly posting "trust me, these are fads" is misinformation and harmful.

EDIT: I think you could HUGELY benefit from this series on Laracasts: https://laracasts.com/series/object-oriented-bootcamp-in-php

Many things will make much more sense once you understand these basic concepts.

OK I mis-spoke about the fad. But I still believe that v4.2 to v5 is a big change.
I had just got used of how things work in 4.2. I just hope that the psr-4 is it for a while.

Of course 4.2 to 5 is a big change. That's the entire point of it being version 5 and not 4.3. I've said that twice now.

Laravel 5 is not even beta software yet. While it's definitely a good idea to try learning it if you intend to use it, you have to fully commit it in your head that things about the software are going to change while it's still in development. I've had to dump and re-install it several times over the last couple of months to manage some of the large changes. This is acceptable.

If you like how 4.2 works, please continue to use 4.2, there is nothing stopping you, and it may continue to be supported for some time. (I don't know specifics... ASK if you are curious, because it's a good question - but just don't throw a tantrum about it.)

When the final v5 is out, will I be able to do a composer update, or will I need to do a new install?

No more tantrums.

A simple composer update? Pretty doubtful, only because a good portion of changes are to the project skeleton, not just the Illuminate libraries (which is the part that's installed via composer).

Undoubtedly there will be documentation (whether official or via the community) on how to upgrade to L5, if it interests you. But with official release not scheduled until January, there's still a month-and-a-half's worth of potential changes to be made, so you likely won't find a proper upgrade document until then.

Ok answrer one question if you are so so so smart. Why did this work in laravel 4.2 without namespacing at top of controller and without the \folder1\folder2\folder3.....\thing:

$data['owners'] = DB::table('powners')
                       ->where('oname', 'like', $ownersearch)
                       ->orderBy('oname', 'asc')
                       ->Paginate(5);

If this works without namespacing I guess you think the laravel programmers also need more lessons. How did they make it work in ver 4.2 can you explain that? That's the only point my original post was trying to make.

Well I'm not that smart, just a little smarter than you... It works in L4 because Your controller was in the global namespace, whereas it's not in L5.

I'm sure that was not quite the complicated answer that you were looking for.

And you don't have to do

\Illuminate\Support\Facades\DB::table

You could do:

<? namespace What\Ever\Your\Namespace\Is;

use Illuminate\Support\Facades\DB;

protected myFunction()
{
    $data['owners'] = DB::table('powners');
}

First of all, a framework is to use. If I had to figure everything about it out, I may just as well just use php alone with >pdo.

Well @jimgwhit, that's why you're in here asking dumb questions, blaming a framework for your lack of ability and I'm not.

jimgwhit said: I feel you miss the main point of this post.
By the way it was solved, and I know I need to place

use \Illuminate\Support\Facades\DB;

at top. I have no problem with this, and I fully understand it.

First, I noticed the namespacing at the top of the controllers that shipped with Laravel and realized hey, those are in the default namespace anymore. Then I opened up my browser and looked at the laravel docs and sure enough, yup the app folder is now in the "App" namespace by default.

Then I "used" what i needed to use.

Also in the docs, which you clearly didn't read, there is a page that you might find useful

http://laravel.com/docs/master/facades#facade-class-reference

Also, namespaces aren't new to L5, most of use used them pretty heavily in 4.2

#MindBlown

Some people have a short ------. I promised no more tantrums. So I will nicely say:
I had almost no trouble learning and using ver 4.2. Also as you said namespacing was global for controllers, thus transparent to me. So I still feel the big issue is why can't someone in the php world pick out a psr-spec
and stick with that spec a while? And that is not a dumb question. A year isn't a while, a decade (10 years)
would be a while. And I already said, fine psr-4 will be in v5. Fine, but I hope it doesn't go changing every few days. If controllers are the one thing that will be used often why couldn't they be global in v5?

And frankly, why do you need to use namespacing so often in your own code? I understand the framework having it.
With the framework already having hundreds of files, how many more could you possibly need to get crud? A model, a view, and the controller. Where namespacing wasn't applicable on any of these in v4.2(global remember). So what in the yek are you doing with all that namespacing? Anything can be over done and over used I guess. I almost look at you as a namespace programmer and nothing else. You are so into those namespaces.

I do not care about namespacing unless it is required to slap it at the top of the darn file to make stuff work. I care about database management and security PERIOD. Laravel to me is a tool. It may be something else to you such as a namespace designer, that's fine. Dag-gum dberry37388 you sure do love namespaces, and I love database management.

After I place

<?php namespace App\Http\Controllers;

at the top of my controller (which is now required), I cannot see in my wildest dreams what other need I could ever ever ever have for namespacing.

jimgwhit said:

Also as you said namespacing was global for controllers, thus transparent to me.

That is a big part of the problem, is you didn't take the time to understand what was going on under the hood.

jimgwhit said:

And I already said, fine psr-4 will be in v5

Since PSR-0 was deprecated in October, the switch to PSR-4 doesn't just make sense in regards to Laravel, it was warranted.

jimgwhit said:

why can't someone in the php world pick out a psr-spec and stick with that spec a while?

If it were changes that really had no impact on performance or overall quality, I would agree. That is not the case however. You're a developer and as a developer before anything else, you are a constant student. The minute you stop learning, stop digging into source, stop following what is going on with your language, you're done, go ahead and hang p your hat, because outside of the fundamentals, everything that you learn today will be old tomorrow.

jimgwhit said:

And frankly, why do you need to use namespacing so often in your own code? I

Because I build actual applications, not CRUD guis. I have authentication, rest and other services that sometimes aren't unique to the current application and are packages that I've build so I can easily pull them in, hence they aren't in the global namespace.

jimgwhit said:

With the framework already having hundreds of files, how many more could you possibly need to get crud?

smh

jimgwhit said:

I almost look at you as a namespace programmer and nothing else.

I don't even know what that means.

jimgwhit said:

Laravel to me is a tool. It may be something else to you such as a namespace designer,

Again, I have no idea what to say to that.

jimgwhit said:

I cannot see in my wildest dreams what other need I could ever ever ever have for namespacing.

That may be very true and for the simple apps that you are doing, you may not need anything outside of the global namespace, that's not the contention The contention stems from 1) you are indeed actually using it whether you know it or not so you should have some clue as to what it is. 2) you are part of the reason PHP devs get such a bad wrap.

I love that you refer to yourself as a crud developer, because finally we agree on something, although we are probably using the word differently.

Again I started out in java jsp and servlets. I was using mvc when php was still procedual. I admit one thing, I did not fully understand namespacing at first. Probably because as already mentioned at the top of a servlet all you had to do was:

import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

and of course others as needed.
Normally I'd use

 RequestDispatcher dispatcher= getServletContext().getRequestDispatcher("whatever.jsp");
 dispatcher.forward(request, response);

This is like in laravel sending results to the view where you use a foreach to loop over.
The point is I knew that stuff had to go at the top of my servlet in order to DO THE THINGS I NEEDED TO DO in that servlet. Ditto with laravel. To me that is the way it was, a golden rule certain things had to go at the top of
a servlet. If dealing with an arraylist:

import java.util.ArrayList;

Or whaterver import you needed.
Now here's where the difference comes in: My concern was and is and always will be the coding that comes after
this top stuff:

import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

I do not even care what is in this stuff, I never looked it up, researched it, thought about it, it was as though
the top stuff didn't even matter, except it had to be there for my coding to work. To further explain with a simple
explaination. No this-

import java.util.ArrayList;

means I couldn't work with arrays. So no big deal, simply stick

import java.util.ArrayList;

at the top of the servlet. So lets look now at a laravel controller:

<?php namespace App\Http\Controllers;
use App\Http\Requests\LoginRequest;
use Illuminate\Http\Request;
use Illuminate\Contracts\Auth\Guard;
use App\Http\Requests\RegisterRequest;

As long as I have this "TOP" stuff the below stuff will work.

class AuthController extends Controller {

	/**
	 * The Guard implementation.
	 *
	 * @var Guard
	 */
	protected $auth;

	/**
	 * Create a new authentication controller instance.
	 *
	 * @param  Guard  $auth
	 * @return void
	 */
	public function __construct(Guard $auth)
	{
		$this->auth = $auth;

		$this->middleware('guest', ['except' => 'getLogout']);
	}

	/**
	 * Show the application registration form.
	 *
	 * @return Response
	 */
	public function getRegister()
	{
		//return view('auth.register');
                return view('user.register');
	}

	/**
	 * Handle a registration request for the application.
	 *
	 * @param  RegisterRequest  $request
	 * @return Response
	 */
	// public function postRegister(Request $request)
        public function postRegister(RegisterRequest $request)
       	{
		// Registration form is valid, create user...
                
             //$user = \App\User::create($request->all());
                $user = new \App\User(); 
                $user->userid = $request->input('userid');
                $user->password = \Illuminate\Support\Facades\Hash::make($request->input('password'));
                $user->save();

                $this->auth->login($user);

		return redirect('pets');
	}

	/**
	 * Show the application login form.
	 *
	 * @return Response
	 */
	public function getLogin()
	{
		//return view('user/testview');
                return view('user.login');
	}

	/**
	 * Handle a login request to the application.
	 *
	 * @param  LoginRequest  $request
	 * @return Response
	 */
	//public function postLogin(LoginRequest $request)
       // public function postLogin(Request $request)
	public function postLogin(LoginRequest $request)
        {
	echo 'made it here';
        $tvar = $request->input('userid');
            $pw = $request->input('password');
            if ($this->auth->attempt(['userid' => $tvar, 'password' => $pw]))
		{
                    echo 'logged in';
                    //return redirect('olist');
		}
                echo 'ac===='. $this->auth->check().'====';
                if ($this->auth->check())
                {
                    echo 'The user is logged in...';
                    return redirect('pets');
                }
                else {
                    echo 'The user is NOT logged in...';
                }

		//return redirect('/auth/login')->withErrors([
			//'email' => 'These credentials do not match our records.',
		//]);
	}
        
        public function postLogin_original(LoginRequest $request)
	{
		if ($this->auth->attempt($request->only('email', 'password')))
		{
			return redirect('/');
		}

		return redirect('/auth/login')->withErrors([
			'email' => 'These credentials do not match our records.',
		]);
	}

	/**
	 * Log the user out of the application.
	 *
	 * @return Response
	 */
	public function getLogout()
	{
		$this->auth->logout();

		return redirect('/');
	}

The bottom code is the important stuff.
This is no different in java or asp.net.
So there is a rule:
You need some top stuff to get the bottom stuff to work. I'll admit this, I was not current on the newest top stuff to use in laravel. That was the original point in my post. But it takes 5 to 10 seconds to learn that new top stuff is now required. It's not some magical mystery.
Liken it (compare it to) to the import java.util.ArrayList; Even a modern ide will tell you you are missing an import and offer to import it for you. I doubt that any java programmers were ever concerned about what was actually contained in import java.util.ArrayList; Like me, they were more concerned with actually using an arraylist in their code.
Oh I'm sure some delved into the import itself.

lol, yeah you're right... no need to actually look at java.util.ArrayList, or \Illuminate\Http\Request or any underlying code to actually understand how it works, what it's doing, how you can utilize it better, learn from it to make you better, or take advantage of things that you didn't know were there.

jimgwhit said: I doubt that any java programmers were ever concerned about what was actually contained in import java.util.ArrayList; Like me, they were more concerned with actually using an arraylist in their code.

With that being said, I rest my case and feel like there is really nothing left say.

Cheers and happy (pseudo) coding :)

Believe me I verify classes and functions in someones framework like laravel. There is a big difference in a writer of a framework and java, now oracle/java. Are you telling me you dig into every file in the php folder to investigate? I trusted java.com. By the way how did you open php_mysql.dll to study it? I know what you meant and actually appreciate you for saying it. I would verify files in a framework, but I probably wouldn't worry so much about the ones that come directly from php, or java, or asp.net.
That would be like trying to verify your windows or linux operating system code. I am sure those folks that made those java imports knew what they were doing. But no matter what have a blessed thanksgiving. Sorry I get a little arrogant, I used to work on b-52's what can I say.