|
|
Posted by Yonatan Ben-Nes on 11/15/05 19:20
Robert Cummings wrote:
> 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.
Well I got to admit that it sounds (and look :)) promising, I'll check
it out again and probably bug you alittle :P
Navigation:
[Reply to this message]
|