I'm glad you like the engineering behind the dashboard. Let me clue you
in why we are serving files via a Mach-II event-handler. We did this so
people would not have to drop assets (such as img / css / js) into a web
accessible location and therefore simplifying the installation of the
dashboard.
On the other hand, this approach is much more heavy handed. Now, the
CFML engine is having to process a request not only for the HTML
response, but for each asset. Considering the dashboard itself is an
extremely low volume module in the terms of concurrent users we feel
this to be an acceptable trade off versus performance.
Your most performant option is let the webserver handle the serving of
the assets instead of having your CFML engine take all the load.
However, you have a couple of options in using the HTMLHelper instead.
There are two forms of thought when it comes to building an application
in which you end up "skinning" for different clients:
a) Each client gets their own "version" of the application in memory.
Meaning each client has their own application name and therefore each
"version" is not sharing the same application context.
b) Each client shares a single "version" of the application in memory
and the "skinning" / "branding" is done on the fly dynamically for each
request.
It sounds like you are aiming more for option B. So I suggest you do
something like (you might use a session facade - however this is a
stripped down concept):
<view:script href="#session.thisAppVersionAssetBasePath#/prototype.js" />
thisAppVersionAssetBasePath could be something like "/clientA/js/" or
"/clientB/js/"
This way you can have all the power of the HTML Helper, but dynamically
change the base path for your assets on the fly.
HTH,
.Peter
neweller said the following on 18/02/10 09:01:
After spending some time looking at the dashboard. I must say I was
really impressed with the concept of the ServerFileFilter and how it
made CSS and Javascript abstract from the view. On the other hand the
HtmlHelp also has similar features for injecting inline CSS and
Javascript but I would like take the concept of ServerFileFilter and
use it on a global scale. For this I really mean a skinning engine for
say a catalog. If ServerFileFilter could have the basePath dynamically
changed due to user information I think skinning would be made simple.
Basically might thoughts are to change ServerFileFilter into
ServerFilePlugin. This would allow the plugin to check the
sessionFacade before rendering and change it's basePath. This would
make skinning very simple and you could keep one set of views for
multiple customers by adding folders to your asset folder.
I would like to hear the thoughts from the group on this change. Am I
missing something on EventFilters or would this be a good direction?
--
You received this message because you are subscribed to Mach-II for CFML list.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/mach-ii-for-coldfusion?hl=en
SVN: http://greatbiztoolsllc.svn.cvsdude.com/mach-ii/
Wiki / Documentation / Tickets:
http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/
