yeah. but it doesn't seem like the focus of their initiative. but yes drawing inspiration from there too. ATM we are slower than I had hoped to complete this. crossing my fingers for soon
regards Lukas Roman Marintsenko <soul.in.twili...@gmail.com> wrote: >> Just to clarify, we are not building a RAD Bundle, we are building an >> "edition". As such we are of course looking quite closely at KnpRadBundle. > >To clarify, KNP also has a RAD edition (based on KnpRadBundle), see >http://rad.knplabs.com/ > >On Tuesday, June 4, 2013 11:59:11 AM UTC+3, Lukas Kahwe Smith wrote: > > >On Jun 3, 2013, at 19:09 , Gregory Scott Militello <ju...@thinkof.net> wrote: > >> 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. > >Just to clarify, we are not building a RAD Bundle, we are building an >"edition". As such we are of course looking quite closely at KnpRadBundle. > >> 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). > >Well with FOSRestBundle its is infact not any more complicated either. There >are a few configuration options to set but this is exactly where a >preconfigured solution will solve this. We can of course discuss if >FOSRestBundle should become part of the SE. However there we will need to base >things on the core serializer, which will work fine for most API's that are >just returning JSON or XML. Alternatively JMS serializer is much more >powerful, but requires a bit more learning .. also we would then again have >the licensing issue. > >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.
