On Jan 3, 2010, at 1:33 PM, Michal Charemza wrote: > Hi, > > I have a number of related questions: > > - Is it possible to define my own "new" project, to be created using the > command line, like "agavi project-create"? I have found > http://blog.agavi.org/post/155569516/using-your-own-build-templates-from-second-zero > from a while ago, but can I check it is still accurate?
It is still accurate, if something doesn't work the way intended, let me know. > > - I would like this project to actually have a fair bit of functionality, but > I would like this to be part of a separate code base, so that if the code > base gets updated, this projects gets updates as well. How would I go about > doing this? Then you can't use the build system for that - or at least only partially. This is a tricky issue to solve, the best way to do this is to factor out common parts into a library-like collection of classes and use that to share code. > > By this I think I would like there to be some sort of "chain" of searching > for actions/views/models/templates. If there is no specified file in the > "sub" project, then at runtime Agavi will use the file in the "base" project. > (And if I was to specify an action/view/model in "this" project, then I think > typically it would extend the file in the base project). That's not doable using the build system. It's one custom build system directory and that's it. If the template is not found there, it will be resolved to the appropriate template in the agavi templates directory. There's no real way around that except for modifying your local copy of agavi. > > Configuration-wise as well, I'm thinking some sort of "chain" where the sub > project can override the configuration in the base project. You can use the "parent" directive in pretty much all config files to point to a parent config. So you can just provide empty configs that point to the parent config. If you need to specify a more specific config, you can do so in the "child". However, some config handlers are only moderately clever about merging (the ReturnArrayConfigHandler is notoriously stupid), so that may lead to quite a bit of duplication. > > Is this sort of thing possible? I think I'm trying to extend the concept of a > class hierarchy to a "project" hierarchy. Not in a simple and consistent way. I have tried some tricks and tweaks using a second "modules" directory to look up shared modules but that wrecks quite a couple of other things - caching, config handlers, validation etc are affected and partially broken. To sum things up, the best way of having a "base" project that I have found so far is using the merging capabilities of any VCS: You branch from the base and if you do changes on the base, you merge them into any appropriate derived project. Use whichever VCS suits you best (no semi-religious discussions here, please). That way, any project is standalone, but knows it's history. Still, changes can be pulled up or pushed down with relative ease. > > Michal. > Felix -- Felix Gilcher Bitextender GmbH Paul-Heyse-Str. 6 D-80336 München T: +49 89 57 08 15 16 F: +49 89 57 08 15 17 M: +49 172 840 88 28 [email protected] http://www.bitextender.com/ Amtsgericht München, HRB 174280 Geschäftsführer: David Zülke, Florian Clever _______________________________________________ users mailing list [email protected] http://lists.agavi.org/mailman/listinfo/users
