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

Flourish Gentoo ebuild

posted by audvare 7 years ago

Gentoo ebuild available on my overlay. https://github.com/tatsh/tatsh-overlay

Once you get the overlay (you may need to unmask):

emerge dev-php/flourish

Make sure php.ini has /usr/share/php in include_path. Make sure all your php.ini files do (that means CLI and apache2 if you use that, php-fpm (what I use), and cgi).

To test with CLI (php -a):

php > require 'flourish/fLoader.php'; fLoader::best();
php > print fGrammar::underscorize('IInstalledFlourish');
i_installed_flourish
php > 

USE="sutra-patches" will give you 3 useful patches:

That's pretty cool. Although I'd be kinda concerned with breakage (even thought backwards compatibility breaks are relatively uncommon). Are you using flourish for shell scripts of various sorts? Otherwise, I tend to keep Flourish on the project level.

posted by mattsah 7 years ago

I have a number of shell scripts that use Flourish, but most are for use with a website, and as such, they are run within the site root so database details can be found, etc.

The Sutra project (which is basically Flourish+addons+Moor) I am working on has a few scripts that come with it that are for command line use only (I know this kind of blows for Windows users, but I am not a Windows user and haven't been for years).

https://github.com/tatsh/sutra/tree/master/site/scripts

I tend to find command line much easier than having to require a browser (which is why the Sutra project doesn't really yet have a complete /admin browser interface as I do not find it necessary).

One of the most important scripts is fsql.php which takes a file name for an argument, and runs the Flourish SQL contained in the file with fDatabase::translatedExecute(). This is for installing new schemas.

As far as backward compatibility, I do not plan on changing the version number on this ebuild file. With Portage, even if the ebuild changes, it is not considered an update unless the version number on the ebuild is greater than the current version installed. So there is no automatic update (when I run emerge --sync && emerge -uvDN world, which updates everything). Also, like you said, backward compatibility breaks are uncommon, so I do not get too worried about it. The same rules apply for my Moor (which has not seen an update in a while) and CssMin (same story, hence my patches to fix things) ebuilds. I would have to force an update by manually doing emerge dev-php/flourish.

Once Flourish starts having release version numbers, I will begin numbering the ebuilds as such, and with Gentoo I can mask a version away until all sites on that server using Flourish are ready to use it if there is a backward compatibility break. And if any immediately need the new version, I'm ready to simply change (what is in Sutra as /site-root/global.php):

require 'flourish/fLoader.php';

to:

require '/somewhere-else/flourish-new-version/fLoader.php';

temporarily. The Sutra project loads its classes much the same way https://github.com/tatsh/sutra/blob/master/classes/sLoader.php (however it has router and model classes to load as well).

posted by audvare 7 years ago

Although it takes a bit more work (and certianly requires testing) -- it is possible to do PHP shell scripts in windows. Only requirement is generally that PHP is in the path, which I think most installers will do.

inKWell (also based on Flourish and Moor) uses wrapper scripts for the console:

On *nix systems:

./iw.console

On windows:

./iw.console.bat

The wrapper scripts call PHP with various options and pass the actual arguments to the wrapper to the hidden .console PHP script. The console itself does all the bootstrapping for the framework, and basically allows the location of a script to include be passed as the argument.

The wrappers also allow, for example, for rlwrap (readline wrap) to be used, for command history on systems that don't have readline support in PHP -- although the console itself does not yet support readline, basically because every install I have doesn't provide it for licensing reasons. I expect to do readline support based on the php extension at some point.

Windows console (amazingly) doesn't require anything additional for such things, it basically "rlwraps" all programs and scripts internally.

You can see the wrappers here:

https://github.com/dotink/inKWell/blob/master/iw.console https://github.com/dotink/inKWell/blob/master/iw.console.bat

And the console itself is here:

https://github.com/dotink/inKWell/blob/master/.console

Rather than independently bootstrapping the framework in external jobs or shell scripts that need to run, you can just do something like the following:

/location/to/inkwell/iw.console /location/to/script.php

Instead of going into interactive mode, the console will include the script and exit right after the bootstrap process, so similarly the script can use all the classes, database connections, etc, available in inKWell.

On Moor and Flourish updates:

You may be interested in the .inK fork of both. Each are independently maintained with bug fixes and feature improvements which are not upstream yet (although may be). They remain API compatible with upstream and generally the differences are minor. If you don't mind, I may include your change for supporting HTML5 attributes with dashes into it as well.

Whenever Will updates Flourish on github I do merge, so they stay up to date as well.

The .inK fork of Moor is a bit more robust. It provides a new MoorBaseController -- which is purely for static controllers if you use them. The default MoorAbstractController has some construct() logic which I'm not too fond of. I've kept it the way it was though to remain closer to upstream -- but realistically I think Moor could throw away a lot of the Reflection requirements, instantiate controllers directly, and call the action methods directly.

The .inK fork also has a fix for the default Not Found page throwing a ContinueException, and, perhaps most importantly, Moor::run() actually will return, in static instances, the return value of the action, in the event of object instances, the instantiated controller.

This allows, for example for you to handle view rendering at a lower level rather than having to call it in each action on it's own. Granted you could use "before" and "after" methods on the ActionController to do something similar... but I think the return value is nice.

It's not yet in inKWell, but at some point it will take that return value and attempt to render it dependent on what is returned. inKWell uses late-instantiated controllers, so the actions themselves tend to return the view directly... but it would be nice to be able to return other values, especially simple ones such as a string, and have those logically "rendered" the same.

Also want to be able to return fFiles, for images and similar.

posted by mattsah 7 years ago

Feel free to use any patches I make for Flourish.

Sutra has a patch for Moor as well (it's also with my Moor ebuild).

https://github.com/tatsh/sutra/blob/master/patches/moor-1.0.0b4-exit-after-dispatch-except-for-post.patch

The reason is because of how a request goes through sCore::main() (where if POST, sRouter::handle() will never be called since a redirect or exit happens in sPostRequest::handle()) https://github.com/tatsh/sutra/blob/master/classes/sCore.php

The reason for the Moor patch: I guess I am incredibly annoyed with that message that browsers will give about re-submitting POST data if you press the back button and last request was via POST. It is unclear, 99% of people have no clue what it means, and worst yet, they might hit OK on a message like that.

So what I have always done in PHP is a 301 redirect after a POST request because the back button in most browsers (all the ones I care about) won't try to re-submit a POST request if immediately redirected.

Moor in its current form won't allow for this as it exits immediately after the dispatch.

https://github.com/tatsh/sutra/blob/master/classes/sPostRequest.php

The sPostRequest::handle() method (called from sCore::main()) expects Moor::run() to return when complete so that the 301 redirect if necessary (if not AJAX really) can be completed. Old values are stored in session and can be optionally restored in the next page request if an fValidationException is caught by sPostRequest. For a GET request, no return is necessary (so it exits) as all routers handle the data printed back to the client, which can be anything from HTML to JSON, CSS, etc.

posted by audvare 7 years ago