i made two critical breakthroughs this weekend on the framework:
- support for passing arguments in xml documents
- simplified dispatch pattern for the handlers
argument replacements in xml templates
first, i can now support a simple argument pattern within xml documents that are treated as templates. for example:
<x:include href="/xcs/data/weblogs/?category=$category$" />
will match the ?category=1 from the request url and pass it along to any $category$ with the value of "1."
i also added a $_qs$ argument which represents the *entire* query string. so far, this has worked well for passing filters to the data-oriented requests. i'll continue to beat this up over the next several days to make sure it's all working as expected and without nasty side effects.
simple dispatch pattern
thanks to some serious inspiration from brad wilson, i now have a much more scalable dispatch pattern using a custom attribute and reflection. now, instead of having to craft a special handler factory to respond to all xcs calls, i have a single factory that can san all loaded assemblies for eligible handlers/factories that can respond to requests.
it works by decorating my handler (or factory) class with a new attribute:
[UrlPattern("/xcs/data/weblogs/(.*).xcs")]
and there's a single factory class that scans all loaded assemblies and catalogs all classes with this attribute. then, upon each request, the collection is checked and, if a match is found, the associated class is loaded and executed for that request.
again, i need to beat it up a bit to make sure it covers all the bases, but - so far - this is working quite well. hopefully, it will scale well as the number of handlers increases for a single web app - time will tell.
so, improved dispatching and solid arg-passing for xml templates (btw - i have solid xml templates!). that covers another set of important features.
i'm now very close to completing the templates for the blog. once that is done, i need to put together the editor tools.
- support for passing arguments in xml documents
- simplified dispatch pattern for the handlers
argument replacements in xml templates
first, i can now support a simple argument pattern within xml documents that are treated as templates. for example:
<x:include href="/xcs/data/weblogs/?category=$category$" />
will match the ?category=1 from the request url and pass it along to any $category$ with the value of "1."
i also added a $_qs$ argument which represents the *entire* query string. so far, this has worked well for passing filters to the data-oriented requests. i'll continue to beat this up over the next several days to make sure it's all working as expected and without nasty side effects.
simple dispatch pattern
thanks to some serious inspiration from brad wilson, i now have a much more scalable dispatch pattern using a custom attribute and reflection. now, instead of having to craft a special handler factory to respond to all xcs calls, i have a single factory that can san all loaded assemblies for eligible handlers/factories that can respond to requests.
it works by decorating my handler (or factory) class with a new attribute:
[UrlPattern("/xcs/data/weblogs/(.*).xcs")]
and there's a single factory class that scans all loaded assemblies and catalogs all classes with this attribute. then, upon each request, the collection is checked and, if a match is found, the associated class is loaded and executed for that request.
again, i need to beat it up a bit to make sure it covers all the bases, but - so far - this is working quite well. hopefully, it will scale well as the number of handlers increases for a single web app - time will tell.
so, improved dispatching and solid arg-passing for xml templates (btw - i have solid xml templates!). that covers another set of important features.
i'm now very close to completing the templates for the blog. once that is done, i need to put together the editor tools.
No comments:
Post a Comment