Re: HTML_FlexyFramework

Alan Knowles wrote:

DG wrote:

Hello Alan, I would like to know if you plan to import your HTML_FlexyFramework in pear ?

Thats the $1,000,000 question. I have learned to be causious about contributing too much (I have enough trouble keeping up with bug reports and features on my existing packages) - It would be nice to propose it, (hint to paul Yawp may be better as HTML_YawpFramework), but see the notes below about refactoring..

I think the package could interest a lot of developpers, so you can maybe get some help. And if it remains light (it is its advantage), bearing on other packages already maintained (db_do, flexy, auth...), the work could be focused on the 2 main components : the url=>object and the page-controller classes.

Are you going to maintain it in the future ?

Yes, It is being mainted as I have over 10 major sites depending (both mine and clients).

Or is it deprecated?

Not yet, but there are a number of reasons I want to refactor it, enough to break old applications. - Some of the current issues that have grown out of It's history * configuration - I'd rather pull the majority of the configuration stuff out and put it in the index.php that calls the constructor.

Why ? Bad performance caused by the heavy guessing work for default options, directories, etc. ? May be this guessing work could be done (writing of ini file) only once at setup stage (*.ini directly parsed after, with mandatory options ?) ?

* start() / getAuth() returning redirects was a bad idea.. Framework::run('page/name') is far more intuative..

I agree it takes me some time to understand this ;-). But will you keep this 2 methods automatically called ? Is it possible to use an other package than auth (liveUser eg) ? How must it be done (auth_class_file in ini file is sufficient)?

* caching support needs removing/seperating.. - it adds to much cruft to the core, that's rarely used. * url reading needs simplifying (I used the wrong _SERVER vars)

Could you explain ? internal code improving ?

Obviously that will break old applications - so it may end up as FlexyFramework2, I'm hoping that the changes to support the new version will not be too problematic, as I will probably have to modify my old code to support it. Mind you - this is all vapourware, so dont expect a timeframe on it... I don't expect any timeframe, and thank you for your work anyway... but import in pear would be fine as christmas gift ;-)

I'm looking for a light and highly modular framework for my apps, and it looks very fine (I already heavily use flexy and db_DataObjects).

If it works, and it's easy to understand - go for it.. - I suspect the config stuff in it at the moment may be the death of that.. (which is why I want to remove it..)

Regards Alan