You know what I am afraid of? The huger the documentation is, the quicker it becomes outdated. Look at the old symfony cookbook. There isn't even a 1.4 version. If you search something about google, you find always outdated documents, that create more problems then they help solve, because the framework evolved so quickly. Obviously the dev guys never need to look something up about symfony on google, so they are probably not even aware of the problem, even if it pops up around once a month on the mailing list (last time http://groups.google.com/group/symfony-users/browse_thread/thread/ef99ed9fdcd435bb). If I hear about a (security) system that is so complex that no normal developer can use it without reading a lot of docs, that gives me the creeps. This post does not mean that I do not think that everyone of you is making an exceptional job, and symfony is choosen by many developers because of it's superior documentation. I just wanted to point out that the more compley a sytem is, the greater the need for pre-configured solutions for standard problems, and the more important an update for the docs is each time the code is changed. And this will be difficult if symfony keeps it's development pace.
Georg Am 20.04.2011 12:34, schrieb ryan weaver: > To be clear, I think I was referring to the security *docs* when I said > that, which just need to be written starting with the easiest cases first :) > > I like the recipes idea - it could be a set of cookbook articles with > the config+code needed to accomplish a few common scenarios. > > @weaverryan > > On Apr 20, 2011 4:49 AM, "Christian Schaefer" <[email protected] > <mailto:[email protected]>> wrote: >> hi all, >> >> The security system as it is now is overcomplex and underdocumented. >> It seems to be very flexible to cover a whole lot of use cases (maybe >> even all there can be?). But that flexibility comes with the price of >> being complex. >> >> I think the next step should be to create recipes on a per-use-case >> base with individual documentation of that use case, its integration >> into the system and out of the box configurations that can be used at >> will. >> >> I believe that the number of classes will not be a huge drawback as >> they won't be used if your use case doesn't require them. Or that's >> what I think should be the case. >> >> But! >> >> Especially in bigger companies or working for big client projects the >> internal requirements to security (legacy SSO services, custom made >> active directory structures, SAP authentication, whatever..) will not >> follow any standard for which there can be such a standard recipe. In >> such a case you're pretty much on your own. >> >> On your own with the security system that is. There's a lot of >> opportunity to get things wrong by just not understanding the concepts >> (yes plural). If you ask Java developers when faced with Spring >> Security you will often hear how they dreaded touching it as it >> demands a lot of attention to understand. >> >> I'm not saying it is not possible to achieve pretty much anything with >> the security system but the learning curve is steep. >> >> What is missing imho are some class and flow diagrams for a better >> understanding. As I discovered some classes are only executed when >> populating the cache, some classes/methods are never called except >> from generated classes and of course everything is completely >> decoupled (good for flexibility) which makes it hard to understand the >> relations between classes (bad for understandability). >> >> I personally think it is vital for the future of Symfony2 to smoothen >> the edges by simplifying things like this chunky security system and >> making it more usable. If that requires a new concept or just some >> more complete documentation I can not say at the moment. But I see a >> danger that people will go for easier options and might end up >> prefering i.e. Silex over Symfony even if their use case would require >> Symfony. >> >> To put it in the words of Ryan Weaver: the Symfony2 security system >> needs (much) more love. >> >> >> /Christian >> >> >> On 20 Apr., 11:21, Jordi Boggiano <[email protected] > <mailto:[email protected]>> wrote: >>> On 20.04.2011 10:50, Matthias Nothhaft wrote: >>> >>> > - "loadByUsername()": Is this really intended to load a user by >>> > username? Or can username also be the ID ? Loading users by username >>> > will make the system instable if users have the possibility to change >>> > their usernames. >>> >>> As far as I know, username can be anything, and I can't believe that we >>> still didn't fix this naming issue. It's been discussed many times, a >>> really clear and appropriate term could not be found, but what's sure is >>> that username is confusing. >>> >>> Cheers >>> >>> -- >>> Jordi Boggiano >>> @seldaek ::http://seld.be/ >> >> -- >> If you want to report a vulnerability issue on symfony, please send it > to security at symfony-project.com <http://symfony-project.com> >> >> 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] > <mailto:[email protected]> >> To unsubscribe from this group, send email to >> [email protected] > <mailto:symfony-devs%[email protected]> >> For more options, visit this group at >> http://groups.google.com/group/symfony-devs?hl=en > > -- > If you want to report a vulnerability issue on symfony, please send it > to security at symfony-project.com > > 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 -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com 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
