So let's see.. the majority of all of this is GREAT. Some very cool stuff in here.
I have issues with #10 (disable config checks) just because this has history with me... Being as I haven't been involved lately though, I'll go with whatever you guys think. What are my issues? Don't we still have a race condition with building that cached config file if it doesn't exist? I'd rather find a *real* solution to that problem rather than a hack to prevent a good number of the stat calls, but still have the (albeit slight) possibility of a race.. Again, I'm more than out of the loop, so feel free to argue this one. Extra point a): as long as you're going to do what was discussed in that mail thread, I'm all for it. Make me tell you where my agavi installation is (or rather the agavi installation I want to use (I might have many!)) in my index.php, but don't bother me otherwise. I should only have one place to worry about. Extra point b): see response to #10 ;) but: AG_AUTOUPDATE_CONFIGCACHE , AG_RECACHE_CONFIGS , whatever.. if this goes in we need a big fat wiki page about tweaking installations for "production" environments :) (probably a nice idea anyway) Extra point c): I like simplicity. Having defaults is a nice thing, and I agree the performance impact of a couple extra ifdefs should be nothing. I say go for that. Hope you guys are all doing well and have a great Thanksgiving (if you celebrate that sorta thing ;) ) If you don't, get drunk and eat a lot, but don't really *do* anything. Seriously though.. thanks for continuing to push and stay active. I hope you'll see more of me from now on. --Bob On 11/22/05, David Zülke <[EMAIL PROTECTED]> wrote: > Hi folks, > > I'd like to hear your opinions on the changes I made to my branch > (david_view-improvements). The name is actually misleading; I added many, > many more enhancements than just to the View. > > I'll give you an overview over what is new: > > 1) Changed View so decorate() and getSlots() is public; removed references > usage from decorate(); getSlots() does not return by reference anymore; > added clearDecorator() and clearSlots() methods; added setSlots() methods. > This was done so you have more control from inside a ExecutionFilter (which > has been pluggable for some time now). > http://trac.agavi.org/trac.cgi/changeset/208 > > 2) All config handlers now throw a UnreadableException if a config file > could not be found or read. http://trac.agavi.org/trac.cgi/changeset/264 > > 3) Added support for multiple credentials in Action::getCredential(). You > can now require one or more credentials, and you can supply a list of > credentials of which the user needs to have at least one. You can also mix > these, so users always have to have "foo" rights plus either (or both) of > "bar" or "baz". Also, comparisons are done in strict mode so no type-casting > is done, this prevents certain problems to occur when types are cast by PHP. > http://trac.agavi.org/trac.cgi/changeset/280 and > http://trac.agavi.org/trac.cgi/changeset/285 > > 4) Support for custom code template directories. Sweet for people who don't > want to backup their code_templates dir when updating Agavi, or for everyone > who has Agavi sitting in a central location and needs per-project templates. > http://trac.agavi.org/trac.cgi/changeset/283 > > 5) Templates can have templates, too, now (isn't that funny...). > http://trac.agavi.org/trac.cgi/changeset/283 > > 6) New Action and View class naming possibilities. If you have > modules/Default/Yellow/Sub/MarineAction.class.php, the class can be either > of "MarineAction", "Default_MarineAction", "Yellow_Sub_MarineAction" and > "Default_Yellow_Sub_MarineAction". > http://trac.agavi.org/trac.cgi/changeset/283 > > 7) The "agavi" helper script now support usage of sub-actions, too. Use > Foo.Baz.Baz, Foo/Bar/Baz or Foo\Bar\Baz as name. > > 8) AdoDBDatabase added (contributed by Steven Weiss). > http://trac.agavi.org/trac.cgi/changeset/284 > > 9) AG_WEBAPP_DIR and AG_APP_DIR are now auto-determined. > http://trac.agavi.org/trac.cgi/changeset/286 > > 10) AG_CHECK_CONFIGS (defaults to true) directive allows to disable config > checks altogether, so cached versions are always used without checks if they > exist or the non-compiled version is newer. If disabled, this can improve > performance a bit. > > So... yeah. Let's hear your opinions ;) I'm especially interested in what > Bob and Mike have to say. > > Oh... some more things: > a) Point 9 still requires that we specify the path to agavi.php in > index.php, so it's not much of a difference that people needn't supply it in > config.php anymore. You either define it in config.php and use the path in > index.php, or you only supply the path in index.php and thus let it > auto-determine in agavi.php, or you define it in config.php and use the > constant in index.php. Maybe we should take one approach. Ideas? We > discussed this once, > http://www.mail-archive.com/[email protected]/msg00145.html > > b) Number 10 might have a bad name. Specifically, it could be confusing that > you actually have to set the constant to false to make it work, since with > true, the checks will still be performed. Maybe we need a better name here > that will disable the checks when set to true. Ideas? See also > http://www.mail-archive.com/[email protected]/msg00141.html > > c) I'm wondering whether or not I should add more of these > if(!defined('...')) checks to agavi.php. I expect the performance impact to > be less than minimal, and we could make setting all the stuff (AG_DEBUG, > AG_ERROR_REPORTING, AG_CHECK_CONFIGS, AG_CACHE_DIR) optional in config.php. > Only the definition of AG_WEBAPP_DIR would need to be there, but it now > happens automatically (see points 9 and a). Combining a) and c) gives the > idea of only making AG_WEBAPP_DIR and AG_APP_DIR mandatory in config.php and > changing index.php so it uses AG_APP_DIR and "guesses" the config.php > location to ../webapp/config.php by default. Just a thought though. We can't > solve this one perfectly, unfortunately. > > I'd appreciate quick feedback, since 0.10 is really overdue and Veikko also > has a branch to merge if I'm not mistaken. > > - David > > > _______________________________________________ agavi-dev mailing list [email protected] http://labworkz.com/cgi-bin/mailman/listinfo/agavi-dev
