|
View:
New views
4 Messages
—
Rating Filter:
Alert me
|
|
|
Jamaica Request MapperI'm beginning to organize first thoughts on a request mapper for
Jamaica. The general idea is that it should (of course) build on the class(es) already present in the code base and implement (at least) the Front Controller pattern. This is less far-fetched than one would think at first glance: Xaraya, in particular Jamaica, already looks somewhat like a form of MVC. Any thoughts/ideas on this? _______________________________________________ Xaraya_devel mailing list Xaraya_devel@... http://xaraya.com/mailman/listinfo/xaraya_devel |
|
|
Re: Jamaica Request MapperOn 20 jul 2009, at 13:52, marcinmilan@... wrote:
> Any thoughts/ideas on this? I suggest looking at the Zend Controller implementation. ⇢ http://framework.zend.com/manual/en/zend.controller.html marcel -- Marcel van der Boom -- http://hsdev.com/mvdb.vcf HS-Development BV -- http://www.hsdev.com So! web applications -- http://make-it-so.info Cobra build -- http://cobra.mrblog.nl _______________________________________________ Xaraya_devel mailing list Xaraya_devel@... http://xaraya.com/mailman/listinfo/xaraya_devel |
|
|
|
|
|
Re: Jamaica Request MapperOne reasonable point of departure for developing the mapper, given that
we want to use what is already there to the extent possible, is to begin looking at how to enhance the xarRequest object. This object up to now has been a sort of backwater of the core :) It is used for mainly its getInfo() method and in a couple of cases its getVar() method. Faced with a request mapper, the functionality needs to be cast more generally to take into account short urls and potentially more exotic request types. As a consequence of this, the idea presents itself to pass to a hypothetical mapper not information returned by the request object, but the object itself. This gives us more flexibility in the types of requests we'll be passing. This however means creating instances of the request object. At present iirc all the core objects just run static methods, so this would sort of break that mould, and in doing so we open the door to a more differentiated OO code in the core. With increased use of instances in turn the idea of lazy loading for performance gains in importance. That means more sys::inport lines, scattered in the codebase. Luckily php5 has the __autoload function which can make this easier. Even without instances, with an autoload function we can save over 60 lines of code in the core and core modules for the DataObjectMaster calls alone. But in order to have a manageable __autoload function we need to adjust the locations, filenames and names of classes into some sort of standard schema that can be codified. So from the idea of a request mapper we have wandered all the way to the idea of renaming and restructuring the OO classes :) That said there will never be a "one size fits all" solution , the classes we are using are in too many different diverse locations. But surely we can reduce the number of sys::import calls substantially. Furthermore such a renaming can be done incrementally over time. Thoughts? _______________________________________________ Xaraya_devel mailing list Xaraya_devel@... http://xaraya.com/mailman/listinfo/xaraya_devel |
| Free embeddable forum powered by Nabble | Forum Help |