Flourish PHP Unframework
This is an archived copy of the forum for reference purposes

inKWell is Beta

posted by mattsah 8 years ago

For anyone who is interested in the MVC Framework based on Flourish (discussed here previously) it has officially moved to Beta status as of a couple weeks ago. I am looking for feedback, suggestions and ideas, as well as bug reports. Currently the best documentation is available in the Wiki section on the GitHub page https://github.com/dotink/inkwell - Over the course of the next 3 months or so I will be trying to garner as many bug reports and feedback as possible to approach a 1.0 release candidate. Despite being Beta, the framework is very mature, is currently used on a few commercial sites, and has a stable API. In addition to this, there are planned features additions for all of the following over the next three months:

One of the things to keep in mind is that inKWell depends on a forked version of Flourish maintained by .inK -- We keep upstream merges current but some of the code differs slightly. That being said the Flourish API is 99% the same, and we contribute back all ideas and code to Will for inclusion in Flourish at his discretion.

The main feature of inKWell is it's sane configuration and default directory structure which prefers common-convention of similar MVC frameworks and the Flourish core, but offer all the flexibility you're used to with Flourish as a base library. If anyone has questions, comments, suggestions, they are welcome to submit them here or e-mail us directly at info@dotink.org

Check out some of the videos we've posted of inKWell in action including it's console which is an amazing tool for debugging: http://vimeo.com/dotinkweb -- apologies in advance that some of the videos have frozen images or missing audio for portions (these are noted in the descriptions).

Congratulations on reaching beta :)

posted by mblarsen 8 years ago

Congrats on reaching beta! Hopefully I will beat you to a stable release though. :-)

What changes to Flourish are in your fork? I'd be interested to see if they made sense to merge into the main repository.

posted by wbond 8 years ago

Will, most of them were mentioned or suggested here at one point or another. One is early support for the JSON Serializable interface, which, if added on an object will call $object->jsonSerialize() via fJSON::encode(), this also required the addition of a parameter to fJSON::encode() and fJSON::decode() to force operation through flourish. Right now there are three types of hypothetical environments:

1) Systems without json_encode or JSONSerializable interface 2) Systems with json_encode and no JSONSerializable interface 3) Systems with json_encode and native JSONSerializable interface

inKWell adds the JSONSerializable interface to the ActiveRecord class which extends fActiveRecord, and by default simply makes all columns public properties on the returned object. Since the class exists in inKWell, but is not native to stable versions of PHP yet, I also make use of the force parameter to force encoding via flourish. The addition of the interface and the logic to determine if it is native or not is built into inKWell. My guess is without json_encode() then JSONSerializable likely won't be on a PHP system, so it's sort of a moot point once support is there.

https://github.com/dotink/flourish/commit/a503070f5dffcf628f38488a91cb4b1e4a1e689f https://github.com/dotink/flourish/commit/ea2f4a2a0a628fb8ebeda70d5981afc8e3d5173c

I have also, I think, mentioned the concept of ob_start() and including JS/CSS in the minification process. This is another change which is in the .inK fork, and allows for embedding PHP in your JS/CSS. This is nice for ensuring dynamic URL linking on AJAX requests for example. I don't use it in CSS much, but could be useful there too. The way I saw it the files are already stat and read anyway, the minimal PHP which would be added is worth it for some of the benefit.

https://github.com/dotink/flourish/commit/f7d8c93b882eebe227add8e0710837c16b8cff28

I think the remainder have actually been either "fixed" or included in Flourish, the fURL::makeFriendly $delimeter parameter being the most recent. But another was the addition of throwing an fEnvironmentException for failed imagemagick command: https://github.com/dotink/flourish/commit/6a9f733356b0a2811b3fdf2e0f56834d3e3c3cd6 -- I *think* you added more graceful handling of this at some point.

That about it. Like I said, for the most part it's 90% the same in master -- my other "weird" tests aren't ready for the light of day yet. It may actually be closer to 99% -- it's just that the 1% off is somewhat integral part of the principles of inKWell, JSONSerializable being an aspect of easily creating RESTful/HTTP compliant controllers which easily work with the Accepted types, and the JS/CSS include (ability to parse PHP), although not documented (I don't think), is used for allowing Controller::makeLink() in your AJAX.

Any other questions, let me know.

posted by mattsah 8 years ago

For inKWell you might be interested in the new fCache backends added in r1015. It now supports using databases, directories and redis to store values.

posted by wbond 8 years ago

I will certainly look into those. One of the things I'm trying to achieve is to keep the configurations as simple and uniform as possible. So there would likely be a single caching.php global configuration with whatever number of options, as it stands apc and xcache don't need additional data stores... memcache actually needs an object instantiaton, which in itself needs a host, possibly port, and depending on other things, more information.

With that said, I may only do a subset of what is supported to begin with to maintain a level of uniformity. The caching will be written in such a way that the system configured caching will be used for internal caching only, with a number of configuration switches like cache_view_ttl => '3 minutes' or something like that, cache_config_ttl => '5 days'.

If people want to work with the configured fCache object for additional caching there will be a method such as iw::getCache() to return it. I want to keep caching as simple as possible.

It didn't look like there was any information in the actual Class Documentation yet on these new options, any idea when that will be available? I presume if using a database you will have to supply it a table of some sorts?

posted by mattsah 8 years ago