On Tue, 2005-11-15 at 09:54, Yonatan Ben-Nes wrote: > Hi All, > > I want to start using a framework to my future sites and I saw that > there are quite alot of options out there at the net, if anyone got any > experience with frameworks I would really like to receive some > suggestions, recommenditions and even ideas. > > The framework need to achieve the following goals (Doesn't have to be > all of them): > 1. Reusability of codes as components. > 2. OO. > 3. PHP 5. > 4. Code & logic should be seperated from design (MVC and such..). > 5. Easy to use & learn. > 6. Extreme flexibility to handle also special requirements. > 7. Easy usage of PEAR. > 8. Should have a good living community. (I don't want to choose a > project which will fall in a year...) > 5. InterJinn - http://www.interjinn.com/about/index.phtml Since I'm the InterJinn guy :) I'll comment on your list of reqs... 1. Re-usability is more a symptom of the developer, but InterJinn does generally provide a nice design for creating small chunks of highly re-usable and adaptble code. 2. InterJinn is 99% OO except for a few functions that are used mostly by the framework itself. A list of all services, components, classes, and functions can be viewed here. http://www.interjinn.com/jinnDoc/index.phtml Unfortunately as mentioned by Richard Davey older stuff isn't well documented as far as the API goes, although there's plenty of documentation about services in general. 3. InterJinn was NOT written to exploit PHP5 in particular, however it has been updated to be cleanly compatible (though I haven't checked with the most recent version of PHP5). That said such updates are usually fairly trivial due to it's clean nature :) 4. Modules are comprised of components, components implement the MVC paradigm. The template engine was specifically designed with said modules/components for easy interfacing with the data. Unlike Smarty, the code never touches templates, but rather makes data available, that a template may or may not use. Modules and components are imported/bound by templates, not the other way around. 5. InterJinn is not particularly easy to learn, but once you do it is easy to use -- although your mileage may vary since a lot of the "easy to use" people out there are cut and paste goons. 6. Very flexible with highly modular and customizable service/modules. Services are akin to cross application libraries which are registered in the project configuration. This makes it possible to share often used code across the application, with the exception that since the service is requested by registered name it is easy to drop in functionally different (yet API equivalent) replacements. To date I've patched in support for InterJinn into existing legacy web applications and in some cases into existing dirty frameworks like the eZ framework system with no problem. In these cases InterJinn is treated like a drop in super library. 7. PEAR is a library of it's own, there's no reason why it couldn't be easily used anywhere. InterJinn especially makes consideration for other libraries by having an extremely small footprint in the globals names space. Additionally classes and functions are named such that they generally don't conflict. With respect to PEAR interJinn also provides a wrapper for the PEAR:DB API for it's own database service which can act as a drop in replacement. http://www.interjinn.com/jinnDoc/interjinn.service.PearDbManager.phtml 8. InterJinn does NOT have a good community *lol*. But it's not about to fail since I'm using it actively with several clients and for my own projects. Although I must say, releases are slow, but then I usually use the most up to date snapshots since I know they are more stable than the last release version, as well as having many more undocumented features. Either way if you decide to try it out more I'm always available to answer questions. Feel free to email me directly. The Future... While the API documentation sucks for most of the existing code, future service/components/whatever will be documented nicely. For instance I recently found myself working with a lot of XML feeds and so I knocked up my own SimpleXML service to simplify the tedium of working with XML. This illustrates how future code (and slowly but surely older code) will be documented: http://www.interjinn.com/jinnDoc/interjinn.service.JinnSimpleXml.phtml You can click on the "Implemented via Class JinnSimpleXml" for full class API documentation (or click the following:) http://www.interjinn.com/jinnDoc/interjinn.class.JinnSimpleXml.phtml Currently I am working towards adding a convenient Javascript integration system that will allow to include javascript modules via a system similar to including InterJinn services. This will have full XmlHttpRequest support (Ajax if you must *puke*). You can view details of the HttpRequest service here: http://www.interjinn.com/jinnDoc/interjinn.class.JinnHttpRequestService.phtml Anyways let me know if I can help you more. Cheers, Rob. -- .------------------------------------------------------------. | InterJinn Application Framework - http://www.interjinn.com | :------------------------------------------------------------: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `------------------------------------------------------------' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
