MercuryNewt said the following on 09/16/2009 04:23 PM:
> I appreciate all the suggestions guys!
>
> Zack,
>
> I believe you've done exactly what I'm trying to do. Is there any
> chance you could pass along an example?
>
Zack, if you are willing to share. I would suggest you create a wiki
entry and then just send out the link. These kinds of advanced
techniques are exactly what the wiki needs.
> Peter,
>
> I don't think the viewLoader will work for me because my views are
> essentially generic portlets that apply to clients based upon what
> services they subscribe to. Can you help me understand how Mach-II
> loops through the views you define in an event in order to display
> them to the screen? I think what I want to do is hijack that
> mechanism.
>
Sounds like you need to something that will make decisions for you then
call the correct view or possibly subroutine. Both <view-page> and
<execute subroutine=""> make calls to the EventContext to do this, so
you should be fine creating some event-filters and call the EventContext
from there. Take a peek at the framework files under
MachII.framework.commands.ViewPageCommand/ExecuteCommand to see the how
simple those commands are. The heavily lifting is all done in the
EventContext methods and onwards.
> Adrian,
>
> Thanks for your ideas as well. I'm hoping to not break with Mach-II
> conventions, which is why I was looking for some way to load up the
> appropriate views into perhaps the eventContext? I'm not sure what
> mechanism drives views based upon what views were defined for an
> event. It seems to me that I should be able to insert, delete or
> otherwise modify the "view queue" similar to the way the eventQueue
> can be altered with plugins.
>
Mach-II doesn't have a view queue at all. I think what Adrian is
getting at is that there is not way to dynamically choose the view-page
name at runtime. This is exactly what event-filter are for -- changing
the flow of an application and to do dynamic programming.
You could mock the type of view to show like this:
<filter name="dynamicView">
<parameter name="views">
<struct>
<key name="nike" value="nike.quantityPod"/>
<key name="asics" value="asics.quantityPod"/>
<key name="puma" value="puma.quantityPod"/>
</struct>
</parameter>
</filter>
This is why I was asking if you are going to deploy and individual copy
of the application per client or if all the clients are sharing the one
loaded application and what gets served to the user depends on there
request. How are you going to do this?
If you deploy one app per client, then it's simplier to just do
something like:
* if loading Nike, have the view loader views from /views/nike/**/*.cfm
* if loading Puma have the view loader views from /views/puma/**/*.cfm
Then you just do:
<view-page name="pod.quantity" contentArg="pods" append="true" />
Because since it's one client per application, then you like that when
the application is loaded up for nike -- it's only there views.
Now you mentioned something about subscribing to services, then you
perform security before that service (probably making the service in
subroutines you can queue up in event-handlers to call):
<subroutine name="subscription.quantity">
<filter name="subscriberCheck">
<parameter name="subscription" value="quantity"/>
</filter>
<view-page name="pod.quantity" contentArg="pods" append="true" />
</subroutine>
If they haven't subscirbed to "quantity", then the filter returns
"false" (it calls a service or checks something) and the subroutine is
exited and the calling event-handler or subroutines continues. That why
you end up with event-handlers like:
<event-handler event="home">
<execute subroutine="subscription.quantity"/>
<execute subroutine="subscription.foo"/>
<execute subroutine="subscription.bar"/>
<view-page name="home" contentArg="layout.mainContent"/>
<execute subroutine="doMainLayout"/>
</event-handler>
Just many ways to peel a banana here.
.Peter
--~--~---------~--~----~------------~-------~--~----~
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/
-~----------~----~----~----~------~----~------~--~---
