| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Php namespaces can’t begin with a number
|
|
Changed version to 3.2.99;
Attempt at fixing autoloading
fixed enough namespaces to have some demos running
|
|
|
|
|
|
|
|
|
|
|
|
with git
|
|
|
|
when using cache
|
|
TComponent Update: Behaviors, Class Behaviors, fx global events, and dy
one to one events.
This patchset was currently available only on svn trunk/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This adds global 'fx' events, behaviors, class-wide behaviors, intra-object/behavior 'dy' events, and tweaks the raiseEvent to be more advanced (yet backward compatible). A large amount of documentation is in here too. Slight changes to the TApplication object is made to provide events with priorities. TComponent has a massive amount of test cases as well… There are now 512 assertions. Test cases have been added for testing the GetJS and SetJS and ensure functionality of these new getters and setters.
The Behaviors are all tested and fully integrated into the TComponent Object. Behaviors are more transparently and widely integrated into TComponent.
Class Behaviors rely on the global events to add behaviors to instanced objects. Class behaviors also allow for behaviors to be added during the instancing of new objects of the class.
Dynamic events enable the object to send events directly to behaviors as intra-object events. Dynamic events can be chained as multiple behaviors may implement the event. This allows for parameter filtering.
RaiseEvent allows for raising global events, capturing results, and feeding results forward into the next handlers parameters should the need arise. This is a forward thinking feature to enable new processes to be designed into the code for PRADO version 3.3 and future version 4.0. This functionality is transparent when unused.
We are hoping this is fully backward compatible with the existing code base. It was designed for maximum backward compatibility while expanding the functional base exponentially.
This clears the way for a new way of thinking about how objects relate.
|
|
|
|
|
|
|
|
deleteLogs() method; refs #237
|
|
|
|
© 2005-2008 PradoSoft => Copyright © 2005-2011 PradoSoft)
|
|
undocumented changes; upported the "cgi workaround" to trunk/; large (fake) changeset are due to mixed cr/crlf used previously
|
|
|
|
successfully now
|
|
|
|
|
|
|
|
rewritten from scratch
|
|
|
|
|
|
|
|
|
|
request is empty
|
|
don't init properly. This outputs converts the xml into into text entities. The TDbLogRoute now also captures the control ids as well.
|
|
|
|
path for all objects.
TApplication- Adds final attribute to the parameters in the config so folder config.xml cannot override if set to true. Adds a mergeParameter function to unify parameter setting. Fixed a bug where loadParametersPhp wasn't getting the properties correctly.
TControl- calls the parent::__construct, Adds render blocking. (the PRADO class using this will be added in a week or two)
TParameterModule- Adds final attribute to the parameter option so folder configs cannot override if set to true. Uses the application mergeParameter function. Adds final to the php parameter loader
|
|
ArraySorter instead of TArraySorter
|
|
and controls. TLogRouter now can specify logs that require the header with the IHeaderRoute interface. so the TFirePhpLogRoute can work. TLogRoutes can be disabled and all of the routes can be gotten. Each TLogRoute also can have a control filter, user role filter (so, for instance, if you wanted a browser log route on a production site but only for developers), a meta id is also stored for linking to other data in the system, the user id if a user is logged in, active (so routes can be turned off but not deleted), and an error should something go bad with a log route it shouldn't take down the page. Updated the docs on the category filter having to be an array instead of a string. This includes some functions for serializing the Log Router classes as xml. Also the browser route does a quartile analysis on the times and memory footprint of each log item (independently), and highlights the log lines that are memory hogs or time hogs. We can use this as a basis for a set of analysis classes? This includes some interesting functions which does array of array key index to value sorting. For instance getting all rows from a database table. eg. $arr array(array('key'=>'value1', ...), array('key'=>...), array(...)). vsort($arr, 'key'). We may want to move some of this stuff around
|
|
|
|
/trunk:r2680,2692,2707-2736
/branches/3.1:r2682-2686,2694-2702,2705,2738-2762
|
|
|
|
sent / php.ini (output_buffering=Off, implicit_flush=On)
|
|
Beginning of Prado 3.2 development
|
