Physical Application Structure

[designermonkey]

One of the great things about Symphony is the ease that comes with installation; A website owner can just drop the package into their root http folder and hit up /install in their browser and get on with it.

Laravel works slightly differently in that the root http folder is part of the package, and there are lots of files surrounding that folder. This will make it more difficult for a website owner to install the package, as they will have to allow for this structure. We already know that a large number of our community use shared style hosting, and we cannot afford to just assume that all of these users can manipulate their hosting environment to allow a package like Laravel to be installed. It's ok for us developers, but what about the non-developers?

We will have to make some modifications to allow our product to be used by the same current base of users which will mean that we can't just create packages called 'Symphony Whatever' and allow them to be installed on Laravel. We are building our unique product based on a framework, so our folder hierarchy will be unique to us too.

I really like our current folder hierarchy (at a base level, not inside the /symphony folder) and it has lent itself to our terminology also, which we should try and keep intact too. I would like to see us mimic that as closely as possible with the obvious requirements that using Composer adds.

I've got a default Laravel working with the following structure, and so would like to propose it as our structure:

/install (new folder to run installation commands)
/manifest (replaces laravel's /app/storage folder)
    /cache
    /config (new folder for our xml config)
        /env-name (environment specific config)
    /logs
    /meta
    /sessions
    /views
/symphony (new sandbox folder)
    /app
        /commands
        /config
            /env-name (environment specific config)
        /controllers
        /database
        /lang
        /models
        /start
        /tests
        /views
    /bootstrap
    /vendor
/workspace (replaces laravel's /public folder)
    /packages
/.htaccess (moved from laravel's /public folder)
/index.php (moved from laravel's /public folder, paths are changed in file)
/server.php (moved from laravel's /public folder, paths are changed in file)

[designermonkey]

With thinking about separating concerns to keep the core api, backend and frontend as separate apps, I can envisage /install being a separate app also, but intrinsically linked to the core api.

As I don't have as much experience as some, I have some questions:

1. Can Laravel run code like controllers, and models from different locations, like /symphony/app/models and /workspace/models?
2. Could we possibly have our admin separate from the /symphony api app in another root folder /admin for instance? Having it's own separate routes, models etc?

[brendo]

Related, symphonycms/symphonycms/issues/1477

[iwyg]

@designermonkey have a look at the docs. Should explain a lot of Laravel's package handling and file structure.

Can Laravel run code like controllers, and models from different locations, like /symphony/app/models and /workspace/models

As long as they are registered on the autoloader you can run everything, e.g Route::controller('admin', 'Symphony\Admin\AdminController'); So theoretically it doesn't matter where Symphony\Admin\AdminController is located at.

[iwyg]

@designermonkey I had a brief look at how laravel's path configuration works and luckily they're not hardcoded.
Although I'd like to point out that for obvious reasons the application directory shouldn't be located within the public web root.

[designermonkey]

I'd like to point out that for obvious reasons the application directory shouldn't be located within the public web root.

Then we have a problem using Laravel for this project, as from experience, many web hosts won't allow deployment of files outside of a shared hosting environment's web root. This is why Symphony is currently the way it is.

[iwyg]

This isn't laravel specific. If you wan't to, you can alter all system paths to your liking. It's more a security related issue to have executable code outside the webroot. I personally haven't had the bad luck to work on a shared host that doesn't allow you to configure the webroot location, but yes, this surely is a big concern.

[DavidOliver]

More generally, I don't think that Symphony should feel the need to accommodate every hosting setup out there. Shared hosting, yes. Crappy/unduly restrictive shared hosting? I'd say not. Rather than spend time on stuff like this, we could point out to people that they need to move to a host that does allow for files outside of webroot/public_html.

However, I expect there are ways round it with Laravel 4 as there are with Laravel 3.

[michael-e]

You don't see the real problem: Even if your shared host allows to set the web root to a subfolder and thus actually have files "above" the web root, most people simply won't get it. Do you remember when you started with your first CMS? When I installed my first "system", I just wanted to:

• put it "in there" (required FTP, which I considered some sort of secret knowledge…)
• call it in the browser
• dance like… well, you know.

If somebody would've said that I should put something outside of the web root, I would've given up, probably.

So think of starters!

[ijy]

Keeping the application folder outside of the webroot is best practice across the board with the majority of applications, frameworks, and even some CMS's. But it is just that—best practice rather than a requirement. I agree with David in that you can't cater for everyone but as long as it's the majority then it's acceptable. If hosting environments meet the PHP 5.4 requirement then chances are they're geared up enough to allow for items outside of the public_html/ directory.

I've worked with a few shared hosting environments and I've not come across an instance yet where I've not been able to place files and folders outside the public directory. Maybe it's better to go on the presumption it's possible for the time being but keep an open list of any hosting environments which crop up which don't provide that level of access and determine if it will actually be a problem or not. Don't forget that again we're looking forward with the likes of PaaS and cloud hosting are really setting the new direction. In a year's time or more the hosting landscape will have shifted again so it's worth noting where things are heading.

[ijy]

@michael-e Yes I guess it does depend on the target market considerations and keeping things simple. Does this have to be a requirement or can it not be kept as a best practice? I know in EE this is highly recommended as a best practice (as with all apps etc) but it's kept in the "Post Installation Best Practices" section after performing the install. I've seen quite a number of setups and the vast majority follow this practice and I've not heard anyone so far having problems either keeping it in the web root or moving it above web root for those that understand why and want a bit more security. That would certainly cover all bases.

[michael-e]

Agreed.

[DavidOliver]

I'd be happy if both bases were covered, but my opinion is that it shouldn't place extra burden on Symphony's developers and the project as a whole.

You don't see the real problem: [...] most people simply won't get it.

That's not a problem to solve by catering to bad practice. It's a problem to solve with good documentation and education.

[iwyg]

I'm all with a "Easy First" approach but you have to draw the line somewhere, especially when it comes to security related decisions. I fully agree with @DavidOliver here. and I don't think that this is a real problem at all but a educational issue you have to get used to. Remember the first time you stuck with the W3c Boxmodel implementation? But you're still using CSS, don't you. And that's by far more complicated than having two separated directories :). Apart from that, having the obstacle of dealing with xslt as a starter,

most people simply won't get it.

really seems to be a bit of a lousy argument.

[designermonkey]

I already have this running with my adjusted layout, and I'm toying with a couple more ideas. I'm sorry to say that we need to cater for the easiest option, irrespective of whether it is industry best practice.

Without moving the discussion off topic, we have a great problem with community uptake of our product, and we have a great opportunity to break that cycle here, so lets not put any obstacles in our way from the offset. If it turns out we can get feedback on the use of our product, and our users have the opportunity more often than not to change the root, then we should re-address it then, as for now, I really think we should try the all in one folder approach that we currently have. As Ian states, we can opt to follow suit of EE and advise on how to adjust the structure after the fact.

Anyhoo, The main question here is to see how we separate the aspects of our app, the core, the admin, and the frontend.

[michael-e]

really seems to be a bit of a lousy argument.

??? No comment.

[bernardodiasc]

Why this can not be optional?

Edit: I'm a bit delayed on this comment. Now that I read this:

As Ian states, we can opt to follow suit of EE and advise on how to adjust the structure after the fact.

[jonmifsud]

I agree with John; it's got to be optional. Mind you I'd always go for the more secure option where possible; however simple install = potentially higher user base.

Just throwing this in; if one had to use this two-folder structure how would it impact users who are currently using git to deploy? Two separate git or would it also work with sub modules?

[bernardodiasc]

I like the idea of a "Security/Best Practices" article/documentation, as there are a lot more things that can be made in this way. Like file permissions, event filters, htaccess configurations, system folder placement, etc. But this is another subject...

[designermonkey]

how would it impact users who are currently using git to deploy?

Whatever we do, it would always be one package that we release.

I like the idea of a "Security/Best Practices" article/documentation

Already working on it ;o) (@designermonkey is a busy boy).

[designermonkey]

Already working on it

Documentation in general I mean.

[iwyg]

I still don't fully understand the the separated app directory != easy install thing, but that's more a personal problem I guess.

Keep in mind that with the one folder concept we have to shut down public access to all files and folders except of index.php and /workspace. Apart from that, I think having the choice to separate public directory would be a great benefit for more advanced setups. Maybe this will even work on the installation level, maybe something like this:

// pseudo code :)
detectLocation: no symphony directory here, must be one directory up;   
configureAppPath: ../../symphony/app/

[iwyg]

@designermonkey I was playing around with the directory structure you proposed. The only issue I encountered so far is the config path being hardcoded to the application path. If this is a big concern we might have to overload Illuminate\Foundation\Application::getConfigLoader() but that isn't a real problem.

I figure the next step is to replace laravel's configuration with the xml config. So, we maybe should discuss the structure of a config xsd schema first?

[designermonkey]

@iwyg I've jigged it around a little too myself. I'll fork the repo and get the code in there on my account and we can start to look at it.

This is all still high level stuff, and I still want us to focus on definition first, I've just been doing this while having some personal down time and a holiday.

I've got some ideas for a schema already, bearing in mind we will be loading only Symphony related config with xml, the app config will remain as such, but we will need to define the difference as well.

[bpierre]

I don’t know if it has already been discussed, nor if this is the right place to post this, but did you consider to directly use components of Symfony (the PHP framework), instead of Laravel?

Symfony is decoupled in small (and very high-quality) components, and Laravel reuses a lot of them.

Maybe it would be a better solution, there is no imposed structure with these components, and Symphony Next would not be restricted by the requirements of an “end-user framework” like Laravel.

Plus, the Symphony CMS would be powered by the Symfony framework :-)

[designermonkey]

I have to say, I have thought this.

[DavidOliver]

If Symphony CMS is not going to follow Laravel's conventions and file structure, perhaps Symfony is a better fit. And as has already been pointed out in other issues, Symfony can use XML for configuration already.

[iwyg]

that being said, the question is which ORM we are going to pick. Laravel's Eloquent? Doctrine?

[ijy]

The two frameworks differ in which layer of the software cake they operate. Laravel is one level up providing the syntactic sugar to make things a little sweeter whilst Symfony provides a few of the ingredients. Symfony is more of a full-stack framework (modularised of course) whilst Laravel just aims to provide a little opinion and set some sensible defaults and provide some common utilities from the get go. It's designed to make things easier to work with on a daily basis in a similar way Rails did to Ruby. Laravel is popular and lowers the barrier to entry as a result of this and that is a big selling point if the aim is also to increase adoption whilst making it easier for the core developers to work with on a daily basis

Laravel is actually more on a level with something like Silex (also from SensioLabs) so that again could be another option as are other micro-frameworks like Slim and the Fat Free Framework. Generally though I think having Laravel in the mix is one of the key ingredients as it provides the glue and an easy interface to work with on a daily basis for the core team and for potentially interested newcomers. It handles things with elegance and style and riding on the back of the Laravel wave can only be a bonus with the likes of features, documentation and marketing (to an extent) all taken care of.

I think it was mentioned earlier in this thread or another but this is a good discussion on Laravel vs Symfony2 with Taylor summing up a few key benefactors nicely:

http://www.reddit.com/r/PHP/comments/1bdln1/symfony2_vs_laravel

[ijy]

Eloquent would get my vote. That's one of Laravel's strongest points and surely one of the best ORM's available.

[brendo]

I based my layout (and I'm still playing) on using the 'Laravel' application but modified.

I think we're probably better off just using the actual framework. It'll give us a little more freedom and will save us having to 'hack' the Laravel defaults for our purposes. We'll build Next using the Laravel Framework, not the actual Laravel end product.

Is that what you imagined too @iwyg @nils-werner?

[designermonkey]

I am happy with that, as my biggest gut wrenching concern here is that I do not want us to just be a package to install on Laravel framework. That IMO would kill us as a separate community.

[lewiswharf]

I am happy with that, as my biggest gut wrenching concern here is that I do not want us to just be a package to install on Laravel framework. That IMO would kill us as a separate community.

I can appreciate this concern. Lets not cripple Laravel potential though.

[designermonkey]

How would we be crippling laravel's potential if we use the framework vs laravel's packaged app?

[lewiswharf]

How would we be crippling laravel's potential if we use the framework vs laravel's packaged app?

Sorry, wasn't referring to framework vs packaging. I just don't want to hack the structure and make it difficult to build upon using Laravel/composer package conventions.

[ijy]

Interesting...and slightly confusing... It may be a dumb question but what's the difference? And where does Illuminate fit into it all? The Laravel wiki makes mention of individual components coming from Illuminate but not on any difference between Laravel repos:

Laravel 4 uses Composer for dependency management as the framework itself depends on a number of external packages to function correctly. Each of the components used by Laravel 4 is available individually on the Illuminate GitHub repository. Laravel 4 ties together the Illuminate components to create the framework.

And this article touches on the difference between the repos but says laravel/framework pulls in all it's dependencies from laravel/laravel (develop branch) anyway:

First, we need to install Laravel 4. I’m not sure how people are currently doing this, but I get the feeling a lot of people are cloning the laravel/framework repository. There’s no need to do that. The laravel/framework repository contains the components that will be placed in vendor/illuminate vendor/laravel. But we also need to ensure that we get changes to the app directory which is in a different repository, laravel/laravel on the develop branch (master is Laravel 3). This is the confusing part for some as the app directory will contain our application specific code, so how do we ensure we don’t screw things up?

Okay, to install Laravel 4, we need to clone the laravel/laravel repository, specifically the develop branch (-b develop).

This will first install Composer and then Laravel from the laravel/framework repository as specified in composer.json (the composer.json in laravel/framework repository in turn pulls in everything it needs, such as the Symfony components etc.).

So what are the differences between laravel/laravel and laravel/framework and how do they fit in with Illuminate components?

[iwyg]

laravel/laravel is just the application bootstrapper if you want to call it so. laravel/framework is a repository that holds all illuminate components.

[iwyg]

oh, and illumiate components started as individual packages but they're now just a subtree split of laravel/framework

[ijy]

OK that clears it up a little. There really doesn't seem to be much information around to clearly explain the differences. So the proposal is to use the laravel/framework repo and not try to map up to the laravel/laravel directory structure? Just call in the illuminate (or other sourced) components via composer in a less opinionated way?

[iwyg]

I think that's the point.

[ijy]

Ok gotcha. Just checking. :)

[jensscherbl]

Maybe we should just wait until Laravel 4 is officially released later this month and the updated Laravel website and documentation sheds some light on those kind of things.

[DavidOliver]

Laravel 4 will be released on May 28th.

[nils-werner]

I may be a bit late to this discussion but I had to step back a little from this highly opinionated topic and have a deeper look into Laravel (app and framework, wich is called Illuminate by the way) myself.

First I did the usual things, creating a few components and writing a simple member-login enabled system (so easy, and everything is builtin already!).

Then I installed a few packages. And this was what blew me away:

You basically simply add

"require": {
    "vendor/package-name": "version-number"
},

to composer.json and run composer update. No matter if its a Laravel package or one of the hundreds from packagist. Re-using established and well-tested packages is such a breeze!

So, to try out writing a package myself I went on to create a simple scaffolding tool. At that time I wanted to change as few Laravel conventions as possible so I implemented it to basically consume any Eloquent model (their counterpart to our Data Sources) you throw at it and shows the data in a table and lets you edit it in a form; with pagination, validation, extensible fieldtypes and all that. And inherently compatible with any Laravel installation out there.

All this trying out made me think about how to possibly de-couple some Symphony components myself. We could for example ship a login-system (wich relies on Sentry or any other established login system), a scaffolding system and a schema-builder (the latter two automatically installing the login system via composer). And then maybe a meta-package that wraps it all up to get the entire "Symphony experience".

This means you can remove unneeded (and potentially unsafe) components like a schema builder from your production environment and have only the important stuff for your editors remain in the system.

Or, more importantly, give anybody the ability to say:

Add "require": "symphony-scaffold" to your composer.json and you
have a fully featured admin backend without having to write a single line of
code.

Oh and you already made a different login system? No problem, just re-route
the dependency using IoC and re-use whatever you may prefer.

This feature would penetrate the entire entire entire entire entire entire Laravel ecosystem in one big swoop.

Everybody from our community and everybody from theirs (at least ten times the size and growth) would instantly become a potential user of Symphony Next.

Everybody writing some Laravel specific packages would automatically write them for Symphony, too.

These thoughts after the few weeks of tinkering convinced me as to how I want Symphony Next to be: It must be one of the may packages that can be installed just like any other package; sitting side by side with everybody else in what the default Laravel installation.

Everything we know from Symphony is there in Laravel (the application), it just has a different name. The workflows are exactly the same, too. There is no point in rewriting everything just to have our dear old terminology back.

[jensscherbl]

I find this Laravel / Illuminate thing still a bit confusing. There's no mention of Illuminate on Laravel's website except as a namespace in the API docs.

To install the Laravel framework, download a copy of the repository from Github.

Anywhere else, it's just Laravel framework, so we should use this as described in the docs, I guess.

Everything we know from Symphony is there in Laravel (the application), it just has a different name. The workflows are exactly the same, too. There is no point in rewriting everything just to have our dear old terminology back.

Makes sense to me. One of the many points of conventions and using a framework is that other developers familiar with that framework could easily understand and contribute to your project without re-learning everything.

Sure, we could just use Laravel to build our application and stay away from (instantly repel) the Laravel community. But if we want to gain more traction and lure other developers in, that's not the way to go.

[nils-werner]

I find this Laravel / Illuminate thing still a bit confusing.

Think of Laravel being the root folder of your Symphony installation, Illuminate being the symphony folder.

Having them separated enables you to update one without touching the other.

[lewiswharf]

These thoughts after the few weeks of tinkering convinced me as to how I want Symphony Next to be: It must
be one of the many packages that can be installed just like any other package; sitting side by side with
everybody else in what the default Laravel installation.

Everything we know from Symphony is there in Laravel (the application), it just has a different name. The
workflows are exactly the same, too. There is no point in rewriting everything just to have our dear old terminology
back.

YES and YES . When I originally posted the Laravel thread on the forums this is exactly what I envisioned. I believe it to be obtainable as a project, highly flexible, and forward thinking.

[designermonkey]

Right, I think there's a massive communication issue here as to what Symphony is, and what were wanting to achieve here.

What you're all asking for is a framework with a Symphony style admin on top, where the Laravel /app folder is left empty for the developer to use to create a website. That's not what Symphony is, that's a developer level framework.

We are catering to users who don't know PHP. We are catering to users who want a system that they can use to easily create a website or application, by either developing xslt templates for a frontend, or another templating language.

We re building a product. A product sits on top of a framework and leverages the best of the framework. We are not building an extension of a framework which you all seem to be proposing.

Am I the only one who sees this from a viewpoint of a non developer? How is a non developer going to be able to create a site with what you are all proposing? Designers can learn XSLT easily, as they should already be familiar with the XML style markup of HTML, and the declarative style from using CSS. They would however struggle to learn PHP, I know I did.

Doing what you all want will instantly alienate most of our community, myself included, and that is a big problem.

[nils-werner]

I think the point of this discussion to figure out what exactly we are trying to achieve. None of the solutions proposed here should be simply ruled out because "we're trying to achieve something else". Same goes for "we're building a product, not an extension".

Argumenting with "that's not what Symphony is" leaves you limited to what Symphony currently is not to what it could become. Yes, my proposal does not fit with the definition of Symphony 2; but does that make it any less valid?

Look at it from this side: Why shouldn't we be able to create a suite of tools that creates generic Laravel code like models, Controllers etc.? Symphony currently does exactly the same: It creates Symphony PHP code.

[bernardodiasc]

It's possible to build a prototype with both developer and non-developer ways installation?

[nilshoerrmann]

I don't see a communication issue at all. There are two possible ways to recreate the Symphony experience that both have advantages and disadvantages. The question is:

• Should Symphony become a bundle (for Laravel) or
• should it use bundles (Illuminate or other framework's components).

Workflows, UX and UI are in out hand in both cases.

[nils-werner]

I agree. Maybe we should start a new Wiki page where everybody can chime in on what the pros and cons are? You know, to get a better picture of what we're talking about.

[jonmifsud]

@designermonkey @nils-werner I think from what I read through the evolving discussions; symphony is far more about the UI & Symphony Experience, when actually making use of the CMS.

I understand that there are pro's & con's for each way we could go about it. What I'm sure of is that there is not a single way to go about it.

I'm a php developer; and having to code some php doesn't bother me that much; however I fully understand that for new-comers it would be easier to have a zip file which lets you start working straight away. As long as the latter is possible without requiring any php I'm not too sure what @designermonkey's concerns are.

I also think that a reason for Symphony to move on to Next is to make it more powerful, attractive and usable.

[s-e]

I don't see why you wouldn't be able to have the best of both worlds here. Would a zipball containing a skeleton with an install script to fire off composer and set up migrations - similar to the web install Symphony has now - really be so complex to do? Symphony could still be a package for Laravel, but that doesn't prevent anyone from bundling them together with an easy install option.

[jensscherbl]

What you're all asking for is a framework with a Symphony style admin on top, where the Laravel /app folder is left empty for the developer to use to create a website. That's not what Symphony is, that's a developer level framework.

I don't see why you wouldn't be able to have the best of both worlds here.

Exactly what I was thinking. Are these two approaches really that exclusive to each other? Why can't we use the framework's conventions and ways of doing things (so developers could still use Symphony as a starting point for custom applications or easily write extensions with their knowledge from working with the framework) while also creating a self-contained product that non-developers can easily use?

What we're currently doing (offering an additional way to developers for installing the system and extensions directly via git) isn't that different, in my opinion.

[ijy]

With regard to installation, a good couple of recent examples include Ghost and Wardrobe CMS. Ghost—I'm sure most people are aware of—is a Node.js based publishing system which started as a hugely successful kickstarter campaign. Installing Ghost on a Mac requires the user to open the terminal, install Node (+npm), add to the global PATH variable, and install via npm. On a Linux server this is trickier still.

Wardrobe CMS is a CMS/publishing system built on Laravel which is designed to be small and simple. Installation of Wardrobe requires Composer to be installed and the Wardrobe itself is installed from the command-line with permissions and database adjustments in the config files. It then just follows through an on-screen installer much like Symphony.

It's worth nothing that the installation process or requirements of Ghost have certainly not stunted it's growth, outreach, or popularity. It's the publishing platform of the moment despite that. Wardrobe, although not as popular as Ghost is a demonstration of a CMS built in Laravel and fairly easily deployed. Although a few years ago people wanted a zip install and upload via FTP client I don't think it's so much of a barrier today as it's more the way of things. I don't think a public/ with uploads going here is too much to ask when it benefits in keeping in with modern day security best practices. They benefit in the long run when their application doesn't get hacked (did anyone see the pea.rs site hacked last week?)

It's also possible to create an installer to make things easier as Bitnami and others have done for Ghost. Another potentially useful addition to Laravel will be the Remote Component to be introduced in 4.1. This effectively provides a way to store a set of procedures which can be triggered for various remote tasks - such as deployment. Apps such as Rocketeer have already started popping up which use Remote Component to aid with deployment so I think we'll have plenty of options. At this point I don't think that should be a factor which slows down development as one way or another it can be made much easier and we have a very good use case in Ghost where installation hasn't stifled it's popularity. Wardrobe also goes to demonstrate that Laravel apps can have a simple setup process too.

[streaps]

Using nodejs for local development is far easier than setting up Apache and PHP, but there are far fewer nodejs hosting options (I'm looking for the everything included webspace package, with domain and email for a few bucks). The question is, how will it look in 2, 3 or 4 years? I think javascript on the server side will be the next big thing ;)

[jensscherbl]

I think javascript on the server side will be the next big thing

Exactly what people thought about Rails a few years ago...

[iwyg]

So? Rails is still there. I guess there's no such thing as "the next big thing". You choose what fits best (or what's most expensive, well, depends on the client:)).

[ijy]

Node.js and JS on the server-side is definitely the future but yes, as @iwyg mentioned, it's horses for courses. The main point I was making however was that in terms of installation concerns raised in this thread. It's not uncommon to require some usage of the CLI or have the odd dependency. It's mainly just the changing of the tide across the board. Ruby and Rails are probably the worst for that. Gems, passenger, rake operations etc. Ruby apps are most commonly are not the smoothest to install but it hasn't stunted the growth or popularity of the apps built on them.

PHP is an interpreted language which already has the biggest advantage in pretty much being able to drop anywhere and have it work. The odd directory move isn't too much to ask in comparison with other applications built in different languages and frameworks. So that shouldn't be an issue which slows down development. One way or another it can be solved but it's a bridge that can be crossed when we get there.

There are two possible ways to recreate the Symphony experience that both have advantages and disadvantages. The question is:

Should Symphony become a bundle (for Laravel) or
should it use bundles (Illuminate or other framework's components).

I wouldn't say it has to be an exclusive choice of either. We just build it as a standalone app which follows a common convention. It's a good idea to keep the domain specific logic in a symphony directory broken up as required but then it's all kept organised in their as standalone classes (as is the convention with any PHP app - including Laravel). It's namespacing that provide the glue here. The bulk of the application business logic is kept separate from the framework scaffold but injected into the IoC container and auto-loaded. This is the same if we're using Silex and Pimple or any other alternative. Any other generic Composer Packages that can help out can be called in as and when needed (again, not specific to Laravel).

So when looking at John's original directory structure if we keep the workspace as public to follow common convention (for now at least - these things can be changed later on if we need to) and the manifest folder back to app/storage and we're good to go. :) Symphony would be it's own app and Laravel and Composer would just help up in piecing it together. It can later on be turned into more of a package if needed.

Nothing's set in stone but it's not worth spending too much time on the odd directory name or two. Getting started is more important.