|
Sie sind hier: Home • Documentation • Conf vs. Convention
Configuration vs. Convention
Most new frameworks for scripting languages praise themselves that they
do not need configuration files. They do everything by convention, so,
there is no need to configure. Seems to be the better way, because it
shortens the development time as many J2EE vs. X comparisons show. In our opinion J2EE's configuration is really the meta-data hell as people
say. But configuration has its benefits, too. If you only work with
conventions, you have the problem, that you have to change every code
location were an identifier is used whose name was based on a convention
and for example the corresponding class name changed. Let me make this
a bit more clear: If you have an action class in a Ruby On Rails
programm the name of the class tells you which URL you have to use
to target this action class. If you used this specific action class in
300 locations in your code and you want to rename this class, you have
a lot of "fun" (as the Ruby on Rails and Zope/Plone people name it) in
renaming each link to this action class (and we all know that automatic
replacing is extreme "fun" if it does only work in 99,9% of the
occurences). If you have a configuration file were you have the
possibility to register the renamed class with different mapping names,
you can simply add a registration with the new mapping and change the
old mapping to the new class name. The code adjustments for the links
can be done over time (or never).
You
ask yourself when there will be a need to rename classes or the
reorganize them? In bigger projects refactoring takes place! In
PHPinChains it is possible to split a bigger web application into
several "modules". If an application has grown over time and later is
splitted into modules to keep it maintainable, you will be extremely
glad, if the configuration capability of your framework supports
you in doing so and makes to change as less code as possible. Understand that right: convention is a fine thing, but it is very helpful if you are able to use configuration if you need to. PHPinChains offers you a way to mix things up. You can use convention where its possible and you can use configuration where you need to. In the above example you can use an action class without ever registering or configure it. But if the class name changes you can use it by convention with the new name and register/map it with the old name, that you do not have all the old code.
PHPinChains
does things in a hybrid way. You can configure things, but you do not
have to. You can simply choose an application skeleton that fits your
need and use it. There are skeletons, that allow you to develop without
ever configuring anything (splitting your application in modules needs a bit of copy-n-paste configuration in app.xml). But you still have the ability to do so, if
you need to.
On the other hand there is the filter chain. It allows you to use tested and working filter components to do things like XSL transformations by simply configuring them. The filter part if PHPinChains is the one, that would be impossible without configuration, because it relies on it. Configuration is in those cases less error prone than programming. With the filter architecture it is possible to use the most efficient and appropriate way to do specific things, because you can configure the application controller to act under one path and the XSLT filter with a specific xsl program under another. This results in a better and easier to understand architecture of your application, than doing everthing in a action classes and methods respectively. If a part of your application has not much business logic, you can use the DispatcherViewFilter filter that implements the dispatcher view pattern to keep you from writing action classes and to put your little business logic into view helpers or directly into the view.
|
[zurück...]
Benutzerkommentare / User comments:
|
|
