Comment by amishforkfight | Hacker News Reader

Comment by amishforkfight | Hacker News Reader

Parent Full thread

> Thats idea is lovely and all but Flourish never made it out of BETA after years of development.

I'm happy to see Flourish getting some notice, even though there doesn't seem to be a lot of love for it with the small mention. I'm happy Flourish user for well over a year now, and I feel as if Flourish's BETA tag is akin to Google's BETA tag. I honestly haven't run across a single issue with the library that would discourage me from using it in a production environment.

It's an unframework, it doesn't force MVC, but you know what? I don't need MVC for 90% of what I do. What I need to do is validate form input, accept a few file uploads, log that to a DB, kick off a few internal emails, and provide user feedback.

I think that some day I'll dig into Code Igniter, but as the only web developer/designer in the marketing department for a small company a tool that lets me stay agile and do less than conventional setups, as well as easily integrate into existing environments has been a godsend for me. It smooths out a lot of PHP's weird quirks, comes pre-baked with an amazing focus on security (oh thank god for your passion for security, @wbond), and in general just helps me get my job done.

Oh, and when people ask me what framework I use, I say "Flourish, it's like jQuery for PHP".

/fanboy

edit: One downside to Flourish is that I'm almost useless without it. What do I use to sanitize a POST variable again? How do I unescape before output? I've gotten so used to the Flourish classes I spend more time on Google than coding when I don't have access to it.

Another fan of Flourish.

From the site: Please note that Flourish has undergone a good deal of real-world testing, and can generally be considered production ready.

I have of course seen that, but it doesn't fill potential users with much hope when they see it. I'm sure it's lovely, but in the scope of the article it is just not solving the problem unframeworks set out to solve.

It has also failed to keep up with progress, for example: fDate is basically the same as the recent DateTime object in PHP, as are many other classes now.

Your comparison of fDate to DateTime is a good conversation starter. fDate was built precisely to provide such functionality as DateTime does, but it works in PHP 5.1. DateTime is only available in 5.1 if you explicitly enable it. fDate means you can use sane date handling on any version of PHP without worrying about what exact environment the code will be run on.

If you dig into Flourish for a bit, you'll find that Flourish is basically aimed at being a portable, secure base layer to build stuff on top of. It gives you a platform to work in PHP one layer above the PHP functions that are largely derived from C libraries. It includes stuff like UTF-8 string functions, input filtering, arbitrary precision math and whole bunch of other stuff that will work with any kind of (semi-popular) DB on any platform with any version of PHP 5.1+.

Because of this, it isn't going to use PSR-0, or namespaces, or other new language features in PHP 5.3+. However, due to the architecture, you can successfully use it with PHP 5.3 or 5.4 and use all of the new language features in your part of the code. However, when you need to actually send a standards-compliant email with an attachment including UTF-8 content and inline images in the HTML version, fEmail has your back. Oh, and it prevents email header injection along the way. :-)

What problems does it not solve that the unframework concept is supposed to solve? I'm a but curious on what I'm missing out on, as I continuously feel like it meets or exceeds all of my needs.

An unframework is designed to give you a set of classes that you can use to build your site. Sure, on that level it works but what about when you need more?

At some point you need to have more classes, and where do they come from? One team of developers cannot forever add in more and more classes, that would be ridiculous.

If they allow other people to add in other classes they have an ever expanding codebase. If they dont allow developers to add in other classes then you are back to the original problem: where do I find new classes that will work with my code.

By using a package management system you distribute the workload to people who need a class, and so make it. People who have a vested interest (client project, some web service they are making, whatever) are responsible for working on a set of classes that really benefit them, like a payment library that works with Recurly, Spreedly, whatever. That should be made buy one developer, and a second developer could add in a new driver - instead of building the whole damn thing from scratch.

That is the approach package managers take, and they are much more useful than a one-man-army trying to build all the libraries.

Again if Flourish meets your requirements then great, but it certainly doesn't meet all potential requirements of the whole PHP community, package managers can with the "use whats there, build what isn't" approach.

Reply on news.ycombinator.com