<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 01/14/2013 07:17 AM, Thomas Müller
wrote:<br>
</div>
<blockquote
cite="mid:hr3c6dm3x6uvmmsrgkgpydmi.1358143758361@email.android.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Can you please elaborate why this is necessary and what the
benefits are?
<div><br>
</div>
<div>I fine it suboptimal to have app dependencies for reusable
code.</div>
<div>And I assume the advanced-app-template will not get easier.
;-)</div>
<div><br>
</div>
<div>I like the idea of having an app framework, but this is
something to live in the core?</div>
<div><br>
</div>
<div>Thx,</div>
<div><br>
</div>
<div>Tom</div>
</blockquote>
Thanks for the feedback!<br>
<br>
True, the developement wont get easier and there should be an API
overview (which we should provide anyway, I'll try to do that once
ive got more time).<br>
<br>
The reason for the change was that people found it hard to
synchronize their app with the changes from the
advanced_apptemplate. If you wanted to incorporate changes you'd
have to do the following:<br>
<br>
* Compare all classloader classes for changes and adjust namespace
changes when copy<br>
* Compare the dependency injection container for changes<br>
* Adjust the routes file for routing logic changes<br>
* Copy all the files in lib/ and change the namespace of all the
copied files<br>
<br>
Other benefits include:<br>
* Classloader is containing only app specific classes<br>
* DI Container contains only app specific classes<br>
* less code in general<br>
* incentive for people to merge back improvements<br>
<br>
<br>
The disadvantage is of course that people who use the appframework
have to keep up to date when the framework changes in backwards
incompatible ways. If people wanted to not depend on that, the code
can be copied into ones app directory. This requires exactly as much
work as keeping stuff up to date.<br>
<br>
The reason why this is not yet in core is because first of all its a
very new project and I dont know if people are satisified with all
aspects meaning: I dont really consider it to have a fully stable
API. It might also get harder to test if we have dependencies on
core, especially finding out the requirepath for the parent classes
could prove to be tricky in the unittests.<br>
<br>
mfg<br>
<br>
Bernhard<br>
<br>
<br>
</body>
</html>