How about this: I will put together some rule-based code (I'm thinking Common Lisp would be good here) to patch the stable version for namespace support. We'll test it rigorously and iron out the kinks. Once the LTS version comes out, we can run the source through this processor, and then any necessary refactoring could be done. I've taken a brief look at the code base for this purpose before, the amount of manual effort to correctly convert the framework to namespaces is staggering.
On Tue, Mar 4, 2014 at 1:11 PM, Niklas Närhinen <[email protected]> wrote: > Hello all. > > For debugging purposes there is already ADT which is quite abandoned these > days. > > The source code can be found from > https://github.com/nnarhinen/AgaviDebugTools > > I don't use Agavi on daily basis anymore, but when I still was using it, > it worked great for us. > > It already has some of the discussed features: SQL Query logging (for > Propel ORM at least), Request parameter inspection (pre/post-validation) > etc. Maybe you should look into to it at least first before doing all the > job from scratch. > > IIRC I did patch it to support Agavi 1.1 breaking global filters changes. > > > 2014-03-04 12:55 GMT+02:00 Dominik del Bondio < > [email protected]>: > > Hi Mike, >> >> See my inline responses >> >> Am 04.03.2014 um 09:52 schrieb Mike Seth <[email protected]>: >> >> > I am delighted by the news and eager to lend any assistance; Agavi 2.0 >> has been my dream for a long, long time. Some of the things I would like to >> implement, off the top of my head: >> > >> > - Namespaces, god, please! >> >> Not just namespaces, since this is 2.0 anyways i'd like to break many >> other things as well. Mainly fixing some really bad naming decision (like >> AgaviUser/AgaviStorage for session, etc) >> >> > - A more abstract configuration backplane, so that configuration >> sources aren't necessarily XML >> >> You probably remember that we had support for multiple configuration >> formats back in the day. >> I think what we want today is a configuration system written to be used >> from PHP alone. And the XML configuration as a frontend to that system. >> >> Something which is largely related to the configuration system would be a >> general introspection module which could form the basis for a new build >> system >> and could be used for IDE integrations. >> >> > - A more general class loading and instantiation subframework >> encouraged for userspace code >> >> You mean DI? Yeah, we definitly need something more generic than we have >> now >> >> > - A forge-type repository of configuration, enhancements and plugins, >> and modules and submodules as a stronger abstraction >> >> I don't think we need a custom forge for that, providing a strong >> module/plugin system would be enough. Installing of modules could be done >> with composer then. >> >> > - Change in the builder and application structure that would allow MVC >> components and other resources to be grouped by their logical relationship >> instead of their component rank and otherwise customizable layouts >> >> I think Agavi should still provide a strong emphasis on how things should >> be organized. But i agree that the current layout is far from optimal >> >> > - Stronger native support for command line consoles >> >> agreed >> >> > - Stronger native debugging facilities >> >> Like a debug toolbar? Agreed! >> >> > - A more evolved logging system >> >> Even more evolved? I think the system we have now works quite well for >> general logging. Where we should improve is >> context specific logging (like slq statements, framework internals) which >> would be required for a great debug toolbar >> >> > - Framework-supplied cryptographic services >> >> Care to explain that one? >> >> > - Breakup of complex code pieces (e.g. routing and FPF) into something >> more manageable >> >> Absolutely. For the routing that would be rather straightforward. The FPF >> on the other hand is probably pretty hard to do in an >> easier way. That definitly needs some evaluation. >> >> > - Removal of hacks that support legacy webservers and use of new PHP >> APIs >> >> I don't like the way we handle the webserver intricacies right now. This >> will need some major refactoring >> >> > - Support for closures >> > - Support for event driven programming, particularly a >> subscriber-observer approach for the binding between the controller-view >> chain and the models >> >> This is something which needs some serious thought. I don't think we >> should base the framework itself on an event driven model (this makes the >> code >> really hard to follow/grasp) but rather provide defined insertion points >> for custom stuff. This also needs lots of discussion first >> >> > - PSRx compliance >> >> See my other mail for that ;) >> >> > My obvious question is, before any and all work is ever done: for 2.0, >> what is preferable: refactoring the existing codebase? Rewriting from >> scratch? Somewhere in the middle? >> >> I am leaning towards a refactoring approach. I think if the lay the right >> groundwork for 2.0 >> >> There are some more stuff which definitly need some overhaul, like the >> validation system, especially the configuration/array handling. >> >> My focus for now is the 1.x line. We need to finish all the stuff we have >> planned until 1.2. We can definitly discuss 2.0 stuff before then, >> but we shouldn't get lost in 2.0 stuff before 1.x is in the state we like >> it to have >> >> Kind regards >> >> Dominik >> >> >> >> _______________________________________________ >> users mailing list >> [email protected] >> http://lists.agavi.org/mailman/listinfo/users >> > > > _______________________________________________ > users mailing list > [email protected] > http://lists.agavi.org/mailman/listinfo/users > >
_______________________________________________ users mailing list [email protected] http://lists.agavi.org/mailman/listinfo/users
