> > 2. Filters > > A killer feature I miss is the old filters framework for requests. > > Should events be used in the future? > > Yep, we have events now. There are more flexible.
I have wondered about this since the first preview release. Lets say i wanted to add some sort of autologin when a cookie is found, what event would you use for that ? Thoose i have found doesnt give access to the response and request at the same time. On Jul 12, 10:47 am, Fabien Potencier <fabien.potenc...@symfony- project.com> wrote: > On 7/11/10 1:17 PM, Tarjei wrote: > > > Hi, here are my initial questions and comments regarding Symfony2. > > Wow, that's a lot of feedback! Thank you very much. My answers below.. > > > 1. Deployment. > > Are you planning a .phar deployment solution where the src directory > > gets bundled up as a .phar file and distributed to the server? Have > > you though through the different deploments scenarios for bundles? > > Possibly. Packaging and distribution is something we will take care of > late in the Symfony2 timeline as this orthogonal to everything else. > > > How do you plan to handle images and javascripts packaged with > > bundles? > > There is a command to install them under the web/ root directory. > > > 2. Filters > > A killer feature I miss is the old filters framework for requests. > > Should events be used in the future? > > Yep, we have events now. There are more flexible. > > > 3. Names > > The console command should start with a letter that no other directory > > in the same directory starts with. I.e. not console and config as that > > would reduce the number of redundant hits to tab. > > Any idea? > > > Also, I find the separation of templates into Resources/views a bit > > strange. Templates are a very important part of every webapplication > > and should be easier to find- I.e. they should have a toplevel > > directory in a bundle. > > The reasonning behind this decision is to put all non-classes into one > directory (the Resources/ directory). It contains templates, config > files, assets, ... > > > 5. Routing. > > How does a bundles routing fit within the routing of a complete > > system? > > > As I understand it, each bundle may be routed to a suburl where it > > then has complete control over the namespace, but also that you can > > route a single uri into a bundle. Is this essentially the idea? > > Correct > > > 6. Status of the security features. > > symfony has a nice and ready security system based on credentials. > > Will this system be used, or are you planning something new? > > > Has development of sfGuard for 2.0 started? > > We will of course have something... probably for Symfony2 PR3... but I'm > getting ahead of myself here ;) > > > > > When do you think the first version of the admin generator will show > > up? > > Not planned yet as we need everything else before even thinking about it. > > > 7. Bundles > > I like the concept of bundles and how they work, but one thing I found > > confusing when reading through the documentation and the examples is > > the difference between a bundle in src\Bundle and src\Application. The > > difference should be explained somewhere. > > src\Bundle is for generic bundles not related to the application (think > third-party bundles) > > src\Application is for bundles tied to the application (they cannot be > reused) > > > Another thing I think you'll want is a tool for creating / working > > with bundles and applications that is outside the application > > directory( i.e. a bit like mvn). > > That's possible. You can host bundles anywhere you want (just change the > getBundleDirs() in your kernel so that Symfony2 can find them). > > > Versioning of bundles is also something I think you'll want to add > > already now. Also a way to declare dependencies. > > That's part of the distribution process as you don't want to check > dependencies at runtime. So, that's something that we will work on after > the first beta. > > Fabien -- 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 users" 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-users?hl=en
