On Jun 3, 2013, at 15:25 , Gregory Scott Militello <j...@thinkof.net> wrote:

> Here is my wish-list:
> 
>       • Changes that support the simple.  Currently SF2 is a leap for 
> developers.   Some concepts are extremely difficult to get your head wrapped 
> around and there are external initiatives that imo are trying to improve this 
> in their own ways (e.g. KnpRadBundle).   I am not saying that the SF2 base 
> distro needs to be more RAD like, but I would love to see more interaction 
> with initiatives that are trying to reduce the learning curve.  Some ideas to 
> think about:
>               • Defaulting to a one application Bundle development flow, with 
> the option to support multiple application bundles if needed.  (ala 
> KnpRadBundle)
>               • More generators.
>       • REST is something I have started to move away from in SF2.  SF2 has 
> some great initiatives in REST, but the APIs are still immature.  For 
> instance we have FriendsOfSymfony/FOSRestBundle, fsc/hateoas-bundle, and 
> schmittjoh/JMSSerializerBundle (also the SF2 Serializer for very basic 
> serialization).  3 packages, that compared to their counterparts in other 
> frameworks (and in other languages) are difficult to get working as you would 
> expect.  With REST being such a dominating focus of my current development, 
> this would be enormous for me.  Support standards (http://jsonapi.org/) and 
> simplified implementations would be my focus on these areas.  Other 
> frameworks and other languages could really influence SF2 in this as well.  
> Both Jango and Rails have a vastly improved REST setup over SF2, and frankly 
> so do some PHP counter parts.

I hope to release a first version of a Liip RAD Edition this week.
The general concept is that master can just be cloned and used as the starting 
point for a new project.
Additionally we aim to provide several feature branches (f.e. CMF, Sonata 
Admin, REST API, FOSUserBundle) which can simply be merged in to get started.
For each feature branch (as well as master) we would also provide an additional 
branch with example code.

As you mention the pain of configuring REST related bundles, this would then 
ideally for the most part be covered by this feature branch.

This will all be hosted on github. We will have open PRs for all those feature 
and example feature branches which will never be merged as sort of 
"documentation" of the relevant changes and other related information.

We are hoping to build a community around this edition. I want to stress again, 
imho we are now at a point in the Symfony2 life cycle where we need to focus 
innovation more on the layers above:
http://pooteeweet.org/blog/2205

regards,
Lukas Kahwe Smith
sm...@pooteeweet.org



-- 
-- 
If you want to report a vulnerability issue on Symfony, please read the 
procedure on http://symfony.com/security

You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Symfony developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to symfony-devs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to