On Mar 9, 11:11 pm, Sid Bachtiar <sid.bacht...@gmail.com> 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
>
>
>
> <lkrub...@geocities.com> wrote:
>
> > On Mar 9, 9:05 pm, "Patrick Fong" <patr...@ddns.com.au> 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
-~----------~----~----~----~------~----~------~--~---
