Hi,

If you have to share functionnality accross multiple apps / customers / access 
the best way imho is to put everithing in plugins.

As in symfony 1.4 the application is required to access plugins, you can use 3 
kinds of plugins :
- Application plugins : direct port from the current app. It contains routing, 
layout, etc.
- Functionnal plugins : organized by domain (admin, reporting,...) contains 
modules with templates, reusable components, etc
- Utility plugins : they can be either third party (db, formextra, 
generators,etc.) or business specific. They almost contains no modules.

With this organisation, Functionnal plugins uses Utilities plugins, and 
Application defines routes and navigation to the Functionnal modules.
The best is Application plugins can override Functionnal modules actions and 
templates to provide anything specific : presentation for one customer app, 
additional module, etc...

Using externals in your version control you can have a flexible organisation 
even with multiple similar projects.

This is just an example and relies on a lot of conventions. But whatever code 
organisation you choose, I think you should keep modules as small and 
independant from other ones as possible, it eases refactoring a lot.

Regards
Benoit


-----Original Message-----
From: Kei Takahashi <bzit...@gmail.com>
Sent: mercredi 18 août 2010 06:39
To: symfony users <symfony-users@googlegroups.com>
Subject: [symfony-users] APPs vs Modules/Actions: Pro's and Con's????

Hi, I am seeking opinions.

We have a group of about 5 developers and we are engaging in a
discussion about how to structure a project. In the past, each
developer has made a separate configuration system for various
websites. One is reporting, one is configurations and settings, etc.

Now, we are adopting symfony as a framework as these systems are
refactored. We want a centralized administrative application, and we
want to refactor the old systems all together to be accessed by this
one administration system. Now, here is where I am seeking opinions,
as none of us are authority's on symfony. Do we:

- create a 'backend' and put all the functionality under modules and
actions?
PROs:
CONs:

- create a separate APP for each within the PROJECT, and manipulate
the routing and layout to be shared for a consistent back end, css,
etc?
PROs:
CONs:

That is the conversation that is taking place. Pro's and Con's for
keeping them separated by Application or by having everyone use the
same backend application and put their functionality into modules and
actions.

Opinions from experienced symfony developers is highly appreciated.
We're really just searching for information (IE: Pro's/Con's) so we
can make informed decisions in our planning process. Thanks.

-- 
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 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

-- 
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 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

Reply via email to