Admittedly -- however -- the location of the call isn't what is a stumbling block for me. The stumbling block for me is that all events are queued -- that there is no way to say "run this event _now_" and have it execute prior to anything else which may be waiting in the queue.
I'll probably need a concrete example of what you mean here, because in my experience, Mach-II executes events when they get called, and the next event doesn't get executed until the one running is complete. To me that means you can say "execute this event now" simply by calling the event, and events within events get executed in order they're listed in the XML file. Now what I *really* don't understand is why you're saying this is a bad thing, but I'll address that next.
There are of course ways to execute all the other smaller components (individual listener methods, page views) immediately and in fact I think they can only be executed immediately (within the current event-handler that is), however, if I have a larger component -- an event-handler for an entire event, I have to be rather careful about the order in which events execute and this determines in large part where I choose to place the announcements, whether they are announced in the xml or they are announced in listener methods.
I think "rather careful" may be overstating this. Computers do things in order, that's the nature of the beast, but I haven't once seen this as a problem in my Mach-II work. In onTap if you don't specify, from my understanding things still get executed in alphabetical order, so although you didn't specify the order, there is still an order to it. If you do need things executed in order, you have to number them. I don't see how this is radically different than putting listener and event calls in a certain order in Mach-II.
The other thing involved here is a little more conceptual. Not only are we after loose coupling in our development practices, but events and methods should also be highly cohesive, meaning that in general any event other than a view shouldn't really care about any other event. To me this really means that other than the view needing what it needs to display things on the screen, the event order really doesn't matter, and when it does, events get executed in the order you list them. As I said, I'll probably need a more concrete example of the issue you have with ordering and the event queue.
Unless there are ways to execute event-handlers immediately within plugins or filters that I'm not aware of, it's really not allowed. (And it may just be that I haven't looked deeply enough into the filters and plugins.)
I'll need a specific example of this--I'm just not getting what you mean by executing event-handlers "immediately."
The issue isn't simply having different code bits execute in a particular order -- it's executing a not-predefined set of events (specifically) within a single event-handler,
Not sure what you mean by "not-predefined." We have to put a stake in the ground somewhere otherwise the computer's not going to know what to do, so at some level the events have to be defined in order for the computer to be able to execute them.
without being forced to move my view into another event that must be announced last in the queue and therefore must be announced from a listener method or generally some place other than the xml template.
Now we may be getting to a fundamental issue with how I think about developing. In my mind, the view event will always be last. I can't think of a case where this wouldn't be true; you call an event, stuff happens in the background (getting data, etc.), and the result of all this "stuff" is then displayed to the user. End of event. (Events can also, of course, NOT terminate in a page view and can call other events, which at some point terminate in a page view.) This is probably part of the reason that page views in Mach-II aren't events, but rather they're called using view-page within an event. (That's not to say your event can't consist solely of a page-view, which is pretty common.) You announce all your events related to the view, get whatever you need, then display the view. It *almost* sounds like you want to be able to throw a view out to the user and still do some things in the background, which just wouldn't be the way I would ever think about doing things.
Granted this is partly the limitation of xml -- it being a static language and not having the Fusebox xml's <if><true></true></if> tags. (Which I don't like either. heh :) And also because when the xml is deserialized in ColdFusion, the xml object doesn't discern the order of non-identical xml elements, so, for instance, there's no indication in the deserialized xml node (that I know of anyway) if a <view-page> element occurs before or after a given <announce> element in the xml markup.
Related to above I just don't see why you would ever call view-page and *then* call announce within an event handler. The fact that you can or can't do this is a non-issue to me.
I assume (maybe incorrectly) that the framework simply chooses an order in which to process all the different xml elements which are allowed within the <event-handler> element, probably something like:
filter announce notify view-page
In my experience this hasn't been true; I do notify and then announce all the time and they get executed in the order in which I specify them in the event handler. Again, if I'm misunderstanding what you're saying please clarify.
To be fair, I would probably end up doing a lot more work with Filters and/or Plugins if I ended up doing a lot of work with Mach-II rather than trying to place most (if not all) of my logic in the events.
These are two aspects of Mach-II that I've barely touched on but will definitely cover at the next CFUG meeting. I just haven't had the need to delve into them quite yet. This does bring up the point I was making earlier, that you can handle your logic many places, and if things get really hairy, you can always put a method in your listener that calls other methods. But again, I have yet to run into a situation where I was saying "I guess you just can't do that in Mach-II."
I still really want to be able to execute events immediately before completing the current and all other queued events -- or at the very least insert an event into the queue immediately following the current event which still isn't perfect, but would get me closer to what I'd like to see. Of course, there may be a way to do that which I've just not seen in the documentation yet.
I'm still not getting this--the way you describe this it's almost as if you want to insert events on the fly while an event is processing, which I don't understand how you would do in any framework, language, or program. As I said above, in my experience events get executed immediately based on the order you call them, but if there's something I'm missing, please clarify.
> But in
all honesty, whether you call it an "action page" or not, you always end up writing the same code, so you're _still_ writing action pages (a web-accessible page that executes code in response to a form submittal) regardless of the framework, and regardless of what you call it.
True, but my point was that since the "action page" isn't really a page, but a method call to a CFC, it's a little more cohesive than your example seemed to indicate.
Perhaps I haven't understood the semantic of Mach-II quite the way it's been intended... I equate an event-handler to an onTap framework process -- which is to say, an encapsulated collection of smaller codebits which are all part of a larger reuseable structure.
This is more or less true, although I would think of it more along the lines of "an encapsulated sequence of method calls and/or events that may or may not terminate with a view-page call." That's probably splitting hairs a little, but I think given that onTap is largely file-based (from the little I know about it), whereas Mach-II is heavily CFC-based, there is a distinction as to where the "code bits" lie and this is directly related to the fundamental notions of how the frameworks behave in my mind.
... but for larger events which I suspect may require later expansion (any given element of a shopping cart for instance which may require new features later), I look to use a process to maximize code reuse.
And I can do the same thing in Mach-II, but I end up doing this funky dance around the event queue, determining how to make things execute in the right order.
Again, I've just never had an issue with how to do things in the correct order. I suspect this might be because when I write all my CFC methods, they're extremely generic and cohesive. They either do or don't take in an argument and return something. If I need multiple results, I call multiple listener methods and put the returned data into the request scope if necessary so I can use it in the view. I'll need a specific example of the "funky dance" you're referring to in order to see what the real issue is.
These are the sorts of things that I wouldn't necessarily want to put all in the listener methods because I expect they might need additional sub-component expansions (filters, plugins, notifying other listeners, etc.) which are available to an event-handler, but not available or at least not readily available to the smaller listener method component.
This may be true--I can't really say since I haven't messed with plugins and filters yet. I suspect, however, that if you were running into the issue you describe you would go about things in another way to avoid the issue (if indeed there is one). When you use words like "this might need that" it again sounds to me like the issue is with writing highly cohesive methods, etc. so nothing other than the view really "needs" anything else (other than maybe an argument to get the right data back).
Either or both of these may be processes which are liable to require further sub-components to be applied later and so whereas the listener method actually takes me further from the framework (yes, I realize there are framework tools -- core methods from the Mach-II cfc's you can extend) I prefer to stay in an area where more of the framework is available to me.
I don't want to sound like I'm trying to make work for you but without an example I don't quite get what you're saying here. I'm not sure why the listener method takes you "further from the framework"--the framework can call listener methods, and in fact putting more of the logic in your listener methods as opposed to the XML file seems like a good thing to me.
True, but the display page still has to be in your last event, and your last event has to be announced after all other event announcements. I'm starting to get a bit tired and I seem to have forgotten the example of why this was a difficulty for me, but... suffice it to say it was a difficulty for me. :)
I guess this is, as I stated above, how I always think of things. Except in cases where a view event isn't called at all, I don't know why you wouldn't want it to be the last thing called. In fact, in my understanding of MVC this is a sort of basic principle--you "do stuff" and then show the appropriate view, and the system subsequently waits for further event announcements.
Unless I'm missing something I don't think that analogy really works (pardon me if this paragraph is a bit abrasive, it's really not intended to be). Is there a way to "trump" the queue in a Mach-II request and manually change the order in which events occur within either the XML or the listener methods?
Based on what I've done with Mach-II the events get processed in the order they're called, so I'm not sure what the issue is. Events get executed immediately (again, based on what I've seen) when they're called. I'm not saying this is a good example, but let's say I have an event that gets some data and another event (not even a view necessarily, just another event) uses that data. So long as I call the first event first, the data will be available for the second event to use.
The onTap framework by default executes events immediately, so if you have some need to hold onto the content for later it's a fairly simple matter of using a <cfsavecontent> tag to do that or some other method of determining such as declaring a string variable representing a desired sub-process which can then be subsequently overwritten.
Content for when later exactly? Another event altogether? When you run a listener method that returns something (this could be a query, file content, whatever), you are free within the XML file to put it in any scope you want and this data can then be used subsequently in the event. I understand what you're saying about cfsavecontent, but in my mind that's just another way of accomplishing the same thing; you're simply grabbing stuff for use later. I think the real difference here is that cfsavecontent deals with page output, which I wouldn't mess with until the end anyway, so again, I just wouldn't do things this way.
... though imho, it's much more intuitive to have code execute by default when it's declared, than to default to placing it in a queue that gets processed in order and then having to guess about the order of the queue because it can be appended or inserted into via multiple indirectly related mediums (xml and cfc listener methods) with arbitrary processing order (knowing whether xml is processed before or after listener methods).
I think one of us is really missing something here. The order in which events get executed in Mach-II is not arbitrary. The XML file controls everything, so there is no "battle" between listener methods and the XML file as you seem to suggest above. The XML is ALWAYS processed first, and this XML event may contain calls to listeners which get executed in the order in which they appear within the XML event.
In Mach-II, I write out several lines of code and anywhere where I've put an <announce> xml tag or an announceEvent() method call, I have to remember that the very next line that executes isn't going to be in the event I announced, but that instead it's going to finish what I'm in the middle of often long before ever beginning on the part I just declared. Do I want that? Sometimes. But most of the time I just want things to run when I declare them.
I guess this is a fundamental difference in how I think about things--the situation you describe above I see as a non-issue, probably because for whatever reason (past experience, background, etc.), I just "think" like Mach-II does. I could see, however, that if this isn't the way you conceptualize things it might be counter-intuitive.
I do think the dialog is important. (And I'm hoping that others on the list are getting some benefit from it. :)
Yeah, let's hope we aren't totally annoying the rest of the list! At the very least this will be out in the open so the talk on Mach-II can just be about Mach-II as opposed to "onTap vs. Mach-II." Not that that's not important as well, but in my mind that's a separate talk altogether (and we're kind of having it here!).
Though IIRC Simon Horwith who used to work for Fig Leaf said something about working on an II-style framework himself for a while now that he's not entirely happy with, but that he also found Mach-II to be "too proprietary" (I think that's the phrase he used).
Well, as we discussed briefly today, ALL frameworks are to an extent proprietary. You have to do things "their way" in order for things to work. In my mind, however, just calling them "proprietary" isn't an argument against them. You give up some freedom in exchange for a great deal of coe organization, reuse, flexibility, and maintainability.
At any rate, thanks for the discussion--it's healthy to point out how each of these work in detail because one framework may make way more sense to one person than another one does. Good thing there's choice!
Matt ------------------------- Matthew P. Woodward [EMAIL PROTECTED] AIM: CaptainJavac http://www.mattwoodward.com
_________________________________________________________________
Find high-speed �net deals � comparison-shop your local providers here. https://broadband.msn.com
-----------------------------------------------
To post, send email to [EMAIL PROTECTED]
To unsubscribe: Send UNSUBSCRIBE to [EMAIL PROTECTED]
To subscribe / unsubscribe: http://www.dfwcfug.org
