Lukas, Congrats on your RAD bundle, I look forward to seeing it in the wild. You guys may want to start a discussion with KNP (if you have not already). Maybe there are gains for both projects. I know KNP seems to be going down the route of putting most of their customizations into their own bundle. Hopefully we'll see some of these things make their way into the core. Shortened syntax structures alone are priceless.
Ideally REST would not be such a pain that a specific edition would even be needed. For example, in Rails including active_model_serializers pretty much sums up the setup effort. A generator will build your model, a serializer (used to control serialized data output) and a controller. All you need to do is write some methods to get and set data, unless you need to customize output. Jango's REST is not much more complicated. SF2 would benefit greatly from simplified setup of these bundles, and maybe a couple of generators (Basic controller, basic customizable serialization control [XML/JSON, output format, etc). Since I became a freelance developer again all my projects have headed into REST development with JS front ends (Backbone/Angular/Ember/etc) I do not see this changing in the near future. I spent the last few weeks learning other platforms to reduce the time of development, and I've found virtually every other framework that supports REST does it better and easier. On Jun 3, 2013, at 11:36 AM, Lukas Kahwe Smith <sm...@pooteeweet.org> wrote: > > 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. > > -- -- 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.
