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 <[email protected]> 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 <[email protected]> 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 >[email protected] > > > >-- >-- >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 [email protected] >To unsubscribe from this group, send email to >[email protected] >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 [email protected]. >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 [email protected] To unsubscribe from this group, send email to [email protected] 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
