[symfony-users] Re: Bigger or smaller modules ?
I think "the good reason for it" is because that's how the Symfony tutorials are written. I often find that 2 apps aren't justified - admin is usually a single module. It's not often that there is a whole suite of backend stuff for admin. Creating admin generated backend modules for CRUD for all of your objects is dumb - "just because you can" isn't justification. Don't even get me started on the whole naming convention of "frontend" and "backend"! On 10 Mar 2009, at 14:28, Richtermeister wrote: > Either way, when I read "most people separate their > projects into 2 apps" I usually assume that there's a good reason for > it and try to imitate first, rather than explore if I can be > different.. Then again, there are cases where one app is justified. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~--~~~~--~~--~--~---
[symfony-users] Re: Bigger or smaller modules ?
> Also, in a well-build app you should be able to separate things out > with minimal effort, once you decide that you stuffed too much into > one module. +1 I couldn't have said it better :) On Wed, Mar 11, 2009 at 3:28 AM, Richtermeister wrote: > > Also, in a well-build app you should be able to separate things out > with minimal effort, once you decide that you stuffed too much into > one module. Either way, when I read "most people separate their > projects into 2 apps" I usually assume that there's a good reason for > it and try to imitate first, rather than explore if I can be > different.. Then again, there are cases where one app is justified. > > Daniel > > > On Mar 10, 2:59 am, Fabrice B wrote: >> When trying to architecture an application, the best is to find an >> objective justification to your design. The simplest I would suggest >> is : one crud = one module >> >> In your case, the question is : do you have a separate page to edit >> user's preferences ? Then it's a separate crud and deserves its own >> module user_preferences. Is the form of the user's preferences >> included in the "edit user" page ? Then it surely deserves to stay in >> the user module. >> >> Regards, >> >> Fabrice Bernhard >> --http://www.theodo.fr > > > -- Blue Horn Ltd - System Development http://bluehorn.co.nz --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~--~~~~--~~--~--~---
[symfony-users] Re: Bigger or smaller modules ?
Also, in a well-build app you should be able to separate things out with minimal effort, once you decide that you stuffed too much into one module. Either way, when I read "most people separate their projects into 2 apps" I usually assume that there's a good reason for it and try to imitate first, rather than explore if I can be different.. Then again, there are cases where one app is justified. Daniel On Mar 10, 2:59 am, Fabrice B wrote: > When trying to architecture an application, the best is to find an > objective justification to your design. The simplest I would suggest > is : one crud = one module > > In your case, the question is : do you have a separate page to edit > user's preferences ? Then it's a separate crud and deserves its own > module user_preferences. Is the form of the user's preferences > included in the "edit user" page ? Then it surely deserves to stay in > the user module. > > Regards, > > Fabrice Bernhard > --http://www.theodo.fr --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~--~~~~--~~--~--~---
[symfony-users] Re: Bigger or smaller modules ?
When trying to architecture an application, the best is to find an objective justification to your design. The simplest I would suggest is : one crud = one module In your case, the question is : do you have a separate page to edit user's preferences ? Then it's a separate crud and deserves its own module user_preferences. Is the form of the user's preferences included in the "edit user" page ? Then it surely deserves to stay in the user module. Regards, Fabrice Bernhard -- http://www.theodo.fr --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~--~~~~--~~--~--~---
[symfony-users] Re: Bigger or smaller modules ?
You misunderstood. Set the default to whatever the majority of your modules should be (secure or unsecure) Then selectively change it for the modules that are the exception to the rule. That keeps it all in one place, and means you're not having to create a security.yml for each individual module On 10 Mar 2009, at 06:01, Lawrence Krubner wrote: > > > > On Mar 9, 11:11 pm, Sid Bachtiar wrote: >>> I probably caused myself 30 minutes of >>> extra work, because I had to set security for each of the 27 modules >>> individually, instead of being able to lock them down at the level >>> of >>> the app. >> >> Why couldn't you set it from security.yml of the app level? > > Because I only had one app in the entire project, and it included the > public-facing portion of the site - the portion of the site that the > public was suppose to see. If I locked down the app, I'd also be > locking down the project, and I'd be cutting the public off from > seeing what they are suppose to see. I could then go through, one by > one, and open up those modules that the public should see, but that > would cost me about the same delay that doing it the opposite way also > cost me. > > --- lawrence > > > > > > > >> >> In the apps/yourapp/config/security.yml you can write >> >> default: >> security: on >> >> And that will lock all modules in the app. >> >> On Tue, Mar 10, 2009 at 4:04 PM, Lawrence Krubner >> >> >> >> wrote: >> >>> On Mar 9, 9:05 pm, "Patrick Fong" wrote: Hi Guys, >> I'm looking for a bit of guidance in the design on my application, mainly how much to place in a particular module. The case that I am currently looking at is my user module. As well as the standard, profile, credentials etc, my user has preferences and other properties but I am unsure whether or not I should encapsulate crud for all of these user properties through one big 'user' module/action or separate them out into separate modules/actions 'user_profile', 'user_preferences' etc. Is there any standard approach ? >> >>> I've been wondering the same, mostly about apps. Apparenty most >>> developers prefer to have 2 apps: a frontend and a backend. For my >>> first two symfony projects, I simply did these as two modules inside >>> of one app. >> >>> My current project has 27 database tables, so I created 27 >>> modules. I >>> then created 2 extra modules: "dashboard" for the backend and >>> "content" for the frontend. I then grouped the 27 modules on the >>> dashboard. On the dashboard, I probably caused myself 30 minutes of >>> extra work, because I had to set security for each of the 27 modules >>> individually, instead of being able to lock them down at the level >>> of >>> the app. Otherwise, I haven't seen much of a downside to keeping >>> everything in one app. >> >>> It would be good to know what is considered best practice in this >>> area. One of the main purposes of using framework like CakePHP or >>> symfony or Ruby On Rails is to have a project that works like other >>> projects. Especially where PHP is concerned, I think most large >>> firms >>> are embracing frameworks as a way to escape the anarchy that was >>> previously associated with PHP projects. >> >> -- >> Blue Horn Ltd - System Developmenthttp://bluehorn.co.nz > > "There are only 2 things in the world that give us absolute total happiness. One is, unwrapping a newly bought CD. And the other is, seeing other people fail." -- Armando Iannucci Lee Bolding l...@leesbian.net --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~--~~~~--~~--~--~---
[symfony-users] Re: Bigger or smaller modules ?
On Mar 9, 11:11 pm, Sid Bachtiar wrote: > > I probably caused myself 30 minutes of > > extra work, because I had to set security for each of the 27 modules > > individually, instead of being able to lock them down at the level of > > the app. > > Why couldn't you set it from security.yml of the app level? Because I only had one app in the entire project, and it included the public-facing portion of the site - the portion of the site that the public was suppose to see. If I locked down the app, I'd also be locking down the project, and I'd be cutting the public off from seeing what they are suppose to see. I could then go through, one by one, and open up those modules that the public should see, but that would cost me about the same delay that doing it the opposite way also cost me. --- lawrence > > In the apps/yourapp/config/security.yml you can write > > default: > security: on > > And that will lock all modules in the app. > > On Tue, Mar 10, 2009 at 4:04 PM, Lawrence Krubner > > > > wrote: > > > On Mar 9, 9:05 pm, "Patrick Fong" wrote: > >> Hi Guys, > > >> I'm looking for a bit of guidance in the design on my application, mainly > >> how much to place in a particular module. The case that I am currently > >> looking at is my user module. As well as the standard, profile, credentials > >> etc, my user has preferences and other properties but I am unsure whether > >> or not I should encapsulate crud for all of these user properties through > >> one big 'user' module/action or separate them out into separate > >> modules/actions 'user_profile', 'user_preferences' etc. Is there any > >> standard approach ? > > > I've been wondering the same, mostly about apps. Apparenty most > > developers prefer to have 2 apps: a frontend and a backend. For my > > first two symfony projects, I simply did these as two modules inside > > of one app. > > > My current project has 27 database tables, so I created 27 modules. I > > then created 2 extra modules: "dashboard" for the backend and > > "content" for the frontend. I then grouped the 27 modules on the > > dashboard. On the dashboard, I probably caused myself 30 minutes of > > extra work, because I had to set security for each of the 27 modules > > individually, instead of being able to lock them down at the level of > > the app. Otherwise, I haven't seen much of a downside to keeping > > everything in one app. > > > It would be good to know what is considered best practice in this > > area. One of the main purposes of using framework like CakePHP or > > symfony or Ruby On Rails is to have a project that works like other > > projects. Especially where PHP is concerned, I think most large firms > > are embracing frameworks as a way to escape the anarchy that was > > previously associated with PHP projects. > > -- > Blue Horn Ltd - System Developmenthttp://bluehorn.co.nz --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~--~~~~--~~--~--~---
[symfony-users] Re: Bigger or smaller modules ?
> I probably caused myself 30 minutes of > extra work, because I had to set security for each of the 27 modules > individually, instead of being able to lock them down at the level of > the app. Why couldn't you set it from security.yml of the app level? In the apps/yourapp/config/security.yml you can write default: security: on And that will lock all modules in the app. On Tue, Mar 10, 2009 at 4:04 PM, Lawrence Krubner wrote: > > > > On Mar 9, 9:05 pm, "Patrick Fong" wrote: >> Hi Guys, >> >> I'm looking for a bit of guidance in the design on my application, mainly >> how much to place in a particular module. The case that I am currently >> looking at is my user module. As well as the standard, profile, credentials >> etc, my user has preferences and other properties but I am unsure whether >> or not I should encapsulate crud for all of these user properties through >> one big 'user' module/action or separate them out into separate >> modules/actions 'user_profile', 'user_preferences' etc. Is there any >> standard approach ? > > > I've been wondering the same, mostly about apps. Apparenty most > developers prefer to have 2 apps: a frontend and a backend. For my > first two symfony projects, I simply did these as two modules inside > of one app. > > My current project has 27 database tables, so I created 27 modules. I > then created 2 extra modules: "dashboard" for the backend and > "content" for the frontend. I then grouped the 27 modules on the > dashboard. On the dashboard, I probably caused myself 30 minutes of > extra work, because I had to set security for each of the 27 modules > individually, instead of being able to lock them down at the level of > the app. Otherwise, I haven't seen much of a downside to keeping > everything in one app. > > It would be good to know what is considered best practice in this > area. One of the main purposes of using framework like CakePHP or > symfony or Ruby On Rails is to have a project that works like other > projects. Especially where PHP is concerned, I think most large firms > are embracing frameworks as a way to escape the anarchy that was > previously associated with PHP projects. > > > > > > > > -- Blue Horn Ltd - System Development http://bluehorn.co.nz --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~--~~~~--~~--~--~---
[symfony-users] Re: Bigger or smaller modules ?
On Mar 9, 9:05 pm, "Patrick Fong" wrote: > Hi Guys, > > I'm looking for a bit of guidance in the design on my application, mainly > how much to place in a particular module. The case that I am currently > looking at is my user module. As well as the standard, profile, credentials > etc, my user has preferences and other properties but I am unsure whether > or not I should encapsulate crud for all of these user properties through > one big 'user' module/action or separate them out into separate > modules/actions 'user_profile', 'user_preferences' etc. Is there any > standard approach ? I've been wondering the same, mostly about apps. Apparenty most developers prefer to have 2 apps: a frontend and a backend. For my first two symfony projects, I simply did these as two modules inside of one app. My current project has 27 database tables, so I created 27 modules. I then created 2 extra modules: "dashboard" for the backend and "content" for the frontend. I then grouped the 27 modules on the dashboard. On the dashboard, I probably caused myself 30 minutes of extra work, because I had to set security for each of the 27 modules individually, instead of being able to lock them down at the level of the app. Otherwise, I haven't seen much of a downside to keeping everything in one app. It would be good to know what is considered best practice in this area. One of the main purposes of using framework like CakePHP or symfony or Ruby On Rails is to have a project that works like other projects. Especially where PHP is concerned, I think most large firms are embracing frameworks as a way to escape the anarchy that was previously associated with PHP projects. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~--~~~~--~~--~--~---
