> Some internal classes cannot be extended (sfI18N is an example of this).
> You need to actually replace the entire class. This is because the class
> name is used in a static call.
I totally agree. Symfony already has a generic factory, so why don't
use it everywhere?
Personally I'm a big fan of Java Spring and Inversion of Control and
would appreciate if that factory would evolve to a IoC pattern/
container. That would lead to much more decoupled code and offer
possibilities to extend everywhere and configure what class or
subclass is used for what and how dependencies are meet. The use of a
generic IoC factory would eliminate the need for classes to initialize
attributes itself, moving control over how that is done to the IoC
container. One familiar with IoC, if your are not you should
definitely read [Introducing the Spring Framework](http://
www.theserverside.com/tt/articles/article.tss?l=SpringFramework),
would note, that IoC would also bring in the strong need for
interfaces, a technique I would also appreciate apart from IoC
concerns.
"Your YAML is broken in line XY"-error would be nice, but since often
broken yaml results in parseable, yet incorrect interpretated config
settings, a extendable/overloadable default error handler for all that
sfExceptions that can occur accompanied by a (controlleable) default
error output for productive environment would be cool. See a blank in
prod-env and a plain (yet nice formated) exception in dev-env is just
to less.
Perhaps a more structured logging system, a combined-logger like the
one from PEAR::Log would be better desing than that leading {sFoo}
strings in logging messages to track the source of the message. Would
(if configurable, perhaps again via IoC) open a way for easy managing
log-levels and targeted logfiles for subsystems. When developing huge
and complex flows its simply necessary to have logging configurable
like linux syslogd with a precise control over what subsystems log to
what files (including redundant logging to catch all logfiles) and
onscreen logging. If seen big business-suites that produce more log
lines (at debug level) that some webapps have lines of code.
Global plugins, or a way to install a regular plugin global. Most of
our servers are dedicated to a single big client. At least things like
Auth are handled identically in all projects, so the need to install
plugins locally makes it more work and brings more redundancy.
(Since symfony uses pear packaging I guess plugins dependencies to
other plugins are already configurable, if not it would be nice)
Some kind of SQL-diffs/patches based on modified model YAMLs/XMLs that
would make it possibly to to modify the DB-structure without dumping
current DB-content als fixture, recreating the SQL from model,
reinserting the SQL and reloading fixtures. That is no real option in
prod-env.
Someone else out there who would like the idea of submodules to male
huge apps more overseeable. Would bring some order into a potentially
long list of modules. We all know that projects evolve and that it is
just a question of time unless you have quite a huge amount of modules
at least in backend-apps, but as projects grow also in frontend apps.
Some spoken_ideas2clean_code converter based on a open source voice
recognition, erm and my VoIP-routers knows how to get me a beer, also
a good improvement for symfony ;-)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"symfony developers" 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-devs?hl=en
-~----------~----~----~----~------~----~------~--~---
