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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
