In this doc page chapter
6http://www.symfony-project.org/book/1_2/06-Inside-the-Controller-Layer#chapter_06_sub_alternative_action_class_syntaxare
an alternative way to write action: one per file.
I think this isn't the best solution. I can add a new deep level in the
route and use the parameter
Too many actions are often a sign of code duplication and/or shortcomings in
separation of concerns. You want fat models and slim controllers. Your
controller is either doing too much or you are putting actions into modules
where they don't belong or fit.
Care to share all your action names
This is my problem!
I need a third deep level to keep a good design.
like:
company/customer/new
but in the symfony structure company is not a application. It's
authentication, credentials, user etc are common.
I also have:
calendar/tasks/view/5
A beautifully solution maybe is:
company/
Hi,
like:
company/customer/new
Is this a route or a module/action breakdown ?
Before Printing, Think about Your Environmental Responsibility!
Avant d'Imprimer, Pensez à Votre Responsabilitée Environnementale!
On Wed, Apr 7, 2010 at 4:15 PM, Welington Veiga
welington.ve...@gmail.comwrote:
well...
if I use the routing:
myRoute:
url: company/:module/:action/*
I can use all modules in this pattern, but I want use just three [employers,
customers, group] inside company.
Its Possible? How can I configure this?
2010/4/7 Stéphane stephane.er...@gmail.com
Hi,
like:
try something like:
myRoute:
url: company/:module/:action/*
requirements: { module: employers|customers|group }
requirements is a pcre regex.
On Apr 7, 2010, at 10:35 AM, Welington Veiga wrote:
well...
if I use the routing:
myRoute:
url: company/:module/:action/*
I can use all
Thak you!
It was very usefull!
Other solution is implement a subclass of sfActions and in preExecute()
method instanciate another sfActions class, configuring it... etc
But it is reivent the wheel and loss o lot of pre-configurated issues in
symfony structure.
'routing' sounds better.
without knowing more about what you're trying to do, routing appears to be the
proper approach to what you're trying to do. there is no reason to instantiate
actions from inside an action (that's what forward() is for anyways).
On Apr 7, 2010, at 10:54 AM, Welington Veiga wrote:
Thak you!
Ideally you end up with one module per entity (customer, task,
whatever it is) and use the routing to compose the visible structure
of the app. Every other hack would be much harder to scale or change
if you need to change your visible structure at some point.
Daniel
On Apr 7, 8:00 am, Jacob