Phritz Homepage :: Forum

Re: Phritz kernel todo [by mrfritz379]

Sat, 30 Sep 2006 07:28:11 -0400

Kernel Development:: Phritz kernel todo
Here are some more ideas that I'm considering.

Regarding the View aspect of the framework, I'm considering following the pattern established by most other frameworks by having the controller classes instantiate their own views. As mentioned in my previous post, I think I want to have a single View class that has its own private methods to compile the templates in the appropriate format. I'm also considering, now, having each controller specific View compile the content of that View and returning that View to the front controller (the bootstrap file) via some accessor method to compile the complete template at display time. This would allow for customized handling of the View's data for each controller, making the framework more flexible. The only issue that I see is the Ajax response, since Ajax merely returns the XML tree that is compiled over the course of the script execution. We can't really return an entire XML document everytime the view is instructed to fetch a template.

Also, regarding the View, I'm thinking that there should be a compile() method that can be bound in the Event management. The View class can have a template_body property that can be accessed by filtering methods that would be responsible for performing the pre/post filter functions. The filtering of templates are easy enough to implement now using the register_pre(post)filter methods of the TPl class, but some more dynamic method of filtering may be a good idea (it would certainly help to support the attempts to cut down on the passing of objects around as method parameters or even the calling of static accessor methods such as Phritz::getView()).

Phritz events [by mrfritz379]

Wed, 27 Sep 2006 21:44:45 -0400

Kernel Development:: Phritz events
Currently, in the source, there's a candidate for a Phritz event management system. I thought about instituting a typical Observer/Observable interface to handle events, but I think I like the idea of a centralized event managent system that allows objects to bind themselves to other objects and their methods. Of course the observable object needs to send a global notification of the event using the PhritzEvent::notify() method. This allows an element of control on the part of the observable regarding which methods can be bound.

The current bind() method allows observers to bind themselves to events triggered by specific objects (using a GUID created at the object's instantiation) or by any object of a given class (including subclasses). The idea is to save a certain amount of passing objects around as parameters as the observer object never has to have 'contact' with the observed object until the event is triggered.

One plan that I have for implementing this interface is to allow the User management system (that hasn't been created yet) to change display themes according to user preferences while running in the backround. It offers a lot of room for customization of the running application without having to modify the kernel. Loaded modules could interact with any of the kernel objects without having to every really have contact with the kernel objects.

Phritz module todo [by mrfritz379]

Wed, 27 Sep 2006 21:31:21 -0400

Module Development:: Phritz module todo
Here's the plan for module development for the Phritz framework.

Currently, there are only two modules in the source-- the db module that has the DAO interface, the DB instance and the PhritzDbObject class. The other module is just the Test module that's up at dev.fritz-works.com.

I'm currently torn between keeping the DB classes in a module or moving them into the core of the framework. Initially, my thinking was that a database is not absolutely essential to a running application. A calculator application shouldn't really need any kind of database instantiation to run simple calculations. Perhaps the database should be moved to the lib directory, still keeping it seperate from the kernel, but not a seperate module.

Other modules that I want to see implemented at some point in the future are many of the basic parts of an application including User management, Session management and Authorization. Ultimately, I'd like to see a PhritzCMS package that would be kind of a meta-package that loads all of the above-mentioned modules. But that's a long way off.