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
