Which Framework?

[designermonkey]

The question has again arisen as to which framework we should use to build Next.

Most votes are with Laravel, some are with Symfony.

[iwyg]

I mean, what's the purpose of having xml all over the place and what does that mean for the project. I can see one or two usecases, but what is all of the things?

[designermonkey]

It was a joke.

[jensscherbl]

I still haven't had the time yet to start learning Laravel, so I can't really say much about it. But what I've heard so far, it would be a good framework to start a new custom (non-symphony) project with, so I liked the idea of having a CMS that's based on the same framework one would use for other (non-symphony) projects.

[brendo]

Perhaps a good viability test for all these frameworks is to recreate the existing workspace ensemble. At least that's a common ground that we're all relatively familiar with :)

[nilshoerrmann]

The default workspace is one of the worst Symphony examples. That's why no one cares about it ...

[jonmifsud]

Agreed with nils its not quite the best of examples however; it's more about creating something which allows you us to create the same environment which can host workspaces like the 'default' one.

[brendo]

The design is definitively outdated, the XSLT is verbose, but the concept is solid. The workspace is a common ground, and demonstrates a couple of Symphony's abilities that we probably take for granted nowadays. On 5 Jul 2013 16:25, "Jonathan Mifsud" notifications@github.com wrote:

Agreed with nils its not quite the best of examples however; it's more about creating something which allows you us to create the same environment which can host workspaces like the 'default' one.

— Reply to this email directly or view it on GitHubhttps://github.com/symphonycms/symphony-next/issues/11#issuecomment-20502929 .

[iwyg]

@designermonkey we don''t have jokes here in Germany.

[designermonkey]

@iwyg sorry, completely forgot about that (heh)

[iwyg]

Just for completeness: The Yii (Craft is build on it) and Aurora

[iwyg]

I think we should draw out the application flow first. This way we have the ability to determine what's actually needed without having to write one single line of code.

[jensscherbl]

I think we should draw out the application flow first.

What to you mean by application flow? For me, Symphony Next shouldn't differ much from what we currently have, except of the things already mentioned (better api, decoupled templating, etc.).

[iwyg]

I'm speaking of outlining the application lifecycle … defining its business Model.

For me, Symphony's backbone is sections. We have to define how the concept of fields and sections can be implemented on top of a mvc framework and how we can translate sections and fields to a ORM. This will be our main business logic so we should concentrate on this first. Next, define users roles and ACL, plugin architecure, and so on and so forth.

Let's call it Business Driven Development.

By outlining the application flow we're able to avoid logical mistakes beforehand without writing one single line of code, plus everyone involved is on the same boat. Consider this as a blueprint. You wouldn't build a house without one, would you?

[jensscherbl]

You wouldn't build a house without one, would you?

Wouldn't even build one with it... ;)

[bpierre]

@iwyg Agree, what tool would you recommend? A new GitHub issue with ASCII diagrams?

[iwyg]

No preferences here, just anything that works for everyone involved.

[IbnSaeed]

hello

Have you taken a look at SillySmart as a framework (http://www.sillysmart.org/SillySmart/About.sls)

SillySmart is a lightweight and flexible MVC Framework written in PHP5 based on XML/XSL's parsing.

[iwyg]

$HTTP_SERVER_VARS So it still supports php 4.1?

[brendo]

Looks like a pretty fully featured framework. Really odd approach to XML/XSLT however...

[michael-e]

Yep, and the XSLT even looks sloppy, with its "random indenting" and lots of trailing whitespace in lines.

[IbnSaeed]

Guess, it leaves out SillySmart.

So are we still deciding between Laravel and Symphony ?

[iwyg]

how about stackphp and httpFoundation?

[jensscherbl]

Haven't we narrowed this down to Laravel and Slim already month ago?

[iwyg]

Have we?

[jensscherbl]

Have we?

Thought so.

[IbnSaeed]

Then just decide on one and move this forward.

Which ever framework you choose, i think we should not abandon the underlining foundation of Symphony and that XSLT templating.

[iwyg]

Why Slim?

[IbnSaeed]

someone mentioned that Laravel is heavy.

Then which framework does it leave behind, Symfony ?

[iwyg]

There's a significant large part of L4 which is swiftmailer. If you'd rather go with phpmailer or something else you can also do this. Actually I don't bother how "heavy" a server side framework is. If you prefer slim over a different solution because it has a small footprint, keep in mind, that it's just a routing/http layer (or did I miss something?).

If you ask me, I'd go with httpKernel and httpFoundation and add on top of it. Just my 2 cents.

[IbnSaeed]

Why not list 3 to 4 pros and cons of laravel, symfony2, silex, or stackphp etc each, list only those which would benefit Symphony CMS the most. Select the one which is best suited, and move on from there.

[michael-e]

I don't know much about these framworks, but I used Swiftmailer some years ago. It is a monster, and Symphony does a better email job with just a few lines of code. Indeed the usage of Swiftmailer is one of the strongest arguments against Laravel. It makes me feel uncomfortable that they accepted it as part of the framework.

[michael-e]

And generally speaking, I do care how big the framework is. Like with CMSs, isn't the big one potentially worse? (Remember why you love Symphony: It's small yet powerful.)

[IbnSaeed]

What do you suggest michael ?

[iwyg]

Symphony does a better email job with just a few lines of code

Yea, right. In what universe? Sending emails in Symphony is a pain in the bottom. However, Laravel's implementation is quite handy, works well and is sophisticated.

one of the strongest arguments against Laravel

Its un-testability and its weak system architecture is one of the strongest arguments against Symphony. So why do you use it anyway? I don't care much about swiftmailer, because most of the time I don't need a full smpt/imap stack php implementation.

isn't the big one potentially worse?

No, definitely not. Why do you think so?

Why not list 3 to 4 pros and cons of laravel, symfony2, silex

Are they actually comparable? When you say symfony2, do you mean the frameworkbundle or the components in general?

This might be an anti-example as I don't know much about joomla and haven't used it since like forever (and know there're many out there who don't like it. The pre 3 versions at least), but what they did is to write a framework for joomla, because they felt they need something that does it the 'joomla' way.

My believe is that many here feel the same about Symphony. So maybe this would also be a better way for Symphony. But I don't know, really.

[IbnSaeed]

I meant the complete framework, not its components. If all what is needed are components, as Drupal is doing it, would it benefit our cms ?

From what i see here, is that everyone has there own opinion as to why we should use this framework over the other.

I think we should compromise over some features if they are missing in the potential framework.

Then theres Yii framework as well.

If the majority is in favor of Laravel, then lets settle for Laravel and move on, even with its cons.

[michael-e]

Yea, right. In what universe? Sending emails in Symphony is a pain in the bottom. However, Laravel's implementation is quite handy, works well and is sophisticated.

I was referring to the SMTP and encoding stuff, which is pretty simple and works great. Have you, for example, ever compared the "source code" of emails? You will see what I mean.

If you ask me, I'd go with httpKernel and httpFoundation and add on top of it.

So you also prefer using smaller building blocks? ;-)

What do you suggest michael ?

I don't think that I can be a big help. I tried to install Laravel, but you need composer, which won't run without this (was it "brew"?) which in turn needs that, and in the end it didn't work without an Apple developer account (needed to download Developer Tools). So I stopped that for the moment, I was just too angry. From comments in other threads you may have noticed that currently I am bit fed up of "hip stuff" that — along the way — wants to change some important folder permissions on my machine in order to do its work and will create additional dependencies in my workflow, and technically as well.

So right now I would be happy if someone said "Let's simply develop Symphony." Which would, for example, prevent the pain of dropping our own email code in favour of Swiftmailer. But that is propably short-sighted. I know that @brendo and some others have a completely different horizon than me when it comes to programming. And they have good reasons for the undertaking that we call Next.

So a framework it is. Honestly I think that @allen and @brendo should decide, based on all the contributions that have been made.

@allen: Count me in if Next will be written in Haskell, I'd like to learn that, some day. And there is definitely nothing "hip" about it, which is a big plus! :-)

[ijy]

Indeed the usage of Swiftmailer is one of the strongest arguments against Laravel.

It can easily be removed as a dependency.

someone mentioned that Laravel is heavy.

It's all modular, you pick and choose what you want, exclude or remove components as well as dd. You can edit the folder structure as desired.

Then which framework does it leave behind, Symfony?

If you're talking full-stack then that's bigger. If you're talking components then what's different to Laravel?

If you prefer slim over a different solution because it has a small footprint, keep in mind, that it's just a routing/http layer (or did I miss something?).

Slim's cool. Love it for smaller projects and prototypes but yes it's just a routing framework. It starts getting messy when you need to start developing a larger app however (although perfectly possible). I don't think re-inventing the wheel there really provides any benefit. In terms of a working example Jeremy Kendall created a personal app (flaming-archer) based around the Slim routing framework but when you see how it progressed and look at the code, in hindsight you realise you just recreated a lot of the stuff that was already ready to go in an alternative framework such as Laravel. So you have basic routing, but you then need dependency injection so you add Pimple for an IoC container, you need an ORM so you add Doctrine, you need to make it testable so you create your service providers and interfaces and abstract away, you need logging so you add monolog, you need templating so you add Twig (and all of it's dependencies), you build to MVC so you create a similar folder structure, you need authentication so you add Zend Authentication, you want a CLI so you add PHP CLI Tools... etc etc. Suddenly you realise you just recreated what Laravel provides ready to go. There's nothing wrong with a micro framework but it's just one component and if you know ahead of time that you're going to need these things and something provides them (and arguably more integrated and more powerful with the likes of Laravel's IoC, Authentication, Routing is more powerful, Eloquent, Boris is also included in 4.1, etc) then it make sense to go with the shoe that fits from the start and save yourself some time. Anything else can be swapped out if desired but there's not a lot of fat in there. Not to mention many many other very useful additions such as migrations and seeding, generators, ease and speed of setup, easy resourceful routing, ability to use the CLI or interact via PHP, and the myriad of resources available.

And generally speaking, I do care how big the framework is. Like with CMSs, isn't the big one potentially worse?

We could look at it the other way and see what we would want to remove or swap out from the dependencies and see what it weighs in as. Other than Swiftmailer I'd imagine the other components would be needed and more on a project like Symphony.

If you ask me, I'd go with httpKernel and httpFoundation and add on top of it.

Good call. Also included with Laravel.

how about stackphp and httpFoundation?

From the release of Laravel 4.1 StackPHP's implementation of the HTTPKernel so it's possible to add your own layer of middleware to the HTTP Layer. The best of both worlds. :)

Then just decide on one and move this forward.

...

[ijy]

I don't think that I can be a big help. I tried to install Laravel, but you need composer, which won't run without this (was it "brew"?) which in turn needs that, and in the end it didn't work without an Apple developer account (needed to download Developer Tools). So I stopped that for the moment, I was just too angry.

Ha, yeah, and they say things are getting easier. :) Actually you can get away with only installing Developer Tools now without the full XCode package. You can just run this from the command line:

xcode-select --install

Homebrew isn't needed if you don't already use it and to install Composer you just need to run this:

curl -sS https://getcomposer.org/installer | php

That will install it globally so you can run "composer ..." without "php composer.phar". Then you can just install Laravel by navigating to the directory you want to install it to and running:

composer create-project laravel/laravel project_name

Then you should be up and running with Laravel. :)

[michael-e]

Thanks for that all your explanations, @ijy, I will give that stuff another try! I am just playing the "angry old man" sometimes. Still I know that (on the long run) some of the hip stuff will actually be the next step. (Where would be be, for example, without Git?)

[iwyg]

So you also prefer using smaller building blocks? ;-)

I bet both components have more code than symphony :)

[iwyg]

was it "brew"?

you'll love it. It's a package manager for OS X.

[iwyg]

so basically it's

> brew install node
> npm install -g bower grunt grunt-cli
> bower install <insert javascript lib here> 

[michael-e]

Thanks. Will do (when I find another time slot for "next steps").

[ijy]

No worries @michael-e, I know what you mean. Things seem to move so fast it's a full-time job just trying to keep up with it all as the next thing vies for our attention. :) Once you get the chance to play however they aren't as bad as they seem.

Homebrew is the only way I fly. brew update && brew upgrade and y'er done! ...And brew install composer in this case. :)

[michael-e]

brew update && brew upgrade

Actually I use Debian's apt-get a lot. :-)

[ijy]

Or yum on RPM-based Linux distro's (I generally prefer CentOS). Package managers FTW!

[designermonkey]

Right. I'm in a bad mood, so sorry if I ruffle some feathers here (having a nightmare exchanging house contracts over xmas). Again, sorry for this rant and possible language.

I am f*&king sick to death of this argument. This is why I am not having anything to do with current discussions on Symphony and it's future. Apart from now (I see the irony, yes).

The last thing we should worry about right now is what to use to build it. Plan the goddamn application first before you decide on a framework which may end up buggering you because you got it wrong. Personally, Slim is for me. I am developing v3 with Josh with a Symphony style project in mind to make it more modular and extendable so it doesn't just have to be a micro-framework, but instead becomes a proper http request > response routing package for other apps.

(Just a note here but Laravel is dropping HTTP Foundation because it is bloated out).

That's where my eggs lie right now anyway, I'm not saying it is the right choice, but it's a component for my ideal setup for Symphony. Other components will be had written, others also chosen from existing ones. Also personally, I will never hand over any project of this magnitude to a single framework like Laravel. What if the entire direction goes somewhere we don't agree with morally or license wise? What if the project is dropped? At least with smaller components we can pick parts out for replacement etc etc blah blah.

I haven't got the time or inclination to make community decisions any more, as I stated a while back, as no one ever agrees with them, but if I were to do it, I would tell you all to actually plan out what you want first before PHP framework decisions are made. The discussion would be off the table, period. @rowan-lewis has already made headway and tried to get the discussion back on track by making a new organisation, and repo for this type of discussion, yet no one has even tried to start! The guy is very busy right now settling in to Romania with the intent of being funded to get this project rlling, and all anyone else does is disagree by way of personal choice over framework.

It's not your choice, the choice will be made by the project and it's requirements.

8 months has gone by. 8 months, and no progress. That will be the legacy of Symphony CMS unless someone grows a pair of balls (like @rowan-lewis, I hear they're huge!) and actually try to get something done. I tried, but all your bickering just told me to leave it alone.

Rant over.

[iwyg]

Thanks for bringing this up. I have a quite similar feeling (funny that we both currently do basically the same, although with small progress on my side). So Daniel is still up to it? Maybe he shouldn't have been so silent about it. It actually felt a bit discouraging keeping this a big secret, but what do I know.

Anyway. Do the really drop httpFoundation? How's that possible, they've just implemented stackphp? Thought they'd only drop the routing component.

[lewiswharf]

Release notes...

Laravel 4.1 features a totally re-written routing layer. The API is the same; however, registering routes is a full 100% faster compared to 4.0. The entire engine has been greatly simplified, and the dependency on Symfony Routing has been minimized to the compiling of route expressions.

[michael-e]

@designermonkey: So it's @rowan-lewis going to Romania? And you have been developing v3? And @rowan-lewis did (or will do?) the same, or s.th. different? Why do I never get information like that until you are in ranting mode?