>>So the major differences between onTap and Mach-II end up
>>being that Mach-II is much more stringent in its efforts
>>to make the code conform to a specific pattern. For
>>instance, events are never nested in Mach-II -- they're
>>processed in a queue, so when you want to announce
>>one event from within another event, you're forced to
>>think through your entire request in advance and figure
>>out how to get to your end result.
> Yes and no--you can of course have events call other
> events in places other than in the XML file, so I don't
> think it's quite as limiting as you may think. I'll
> address this more in your example below.
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. 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.
>>This was one of the things that tripped me up when I
>>started working with it, because I wanted to be able
>>to have an event and within it simply say "run this
>>other event, then display this view".
>>But Mach-II doesn't allow this.
> Maybe I'm not understanding what you're saying, but
> this is certainly allowed. If you think of it this
> way, the view is the end of any process. You can call
> events all day long before your display happens.
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.)
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, 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.
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. 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
I suspect announce occurs prior to notify because iirc when I was
doing some of my preliminary work with it, if I had put an announce
tag in the xml, anything I announced in a listener method entered the
queue after the xml announcement. Personally I think the reverse would
be more flexible and therefore preferable, but I think the decision
about order was probably fairly arbitrary. In any event, it's one more
thing to remember, and at that imho fairly obscure.
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. I
suppose these may in some way correlate (although admittedly there's
no direct relationship) to the /_local/ stage of an onTap process. And
they still don't provide the ability to do the one thing I really
wanted to be able to do , which imo would be easier than designing and
implementing a filter or a plugin. 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.
>>As an example:
>><event-handler event="showPageX" access="public">
>> <announce event="actionPageX" copyEventArgs="true" />
>> <announce event="displayPageX" copyEventArgs="true" />
>></event-handler>
>><event-handler event="actionPageX" access="private">
>> <notify listener="blah"
>> method="something"
>> resultKey="request.content">
>></event-handler>
>><event-handler event="displayPageX" access="private">
>> <view-page name="myViewPage">
>></event-handler>
>>Why would I do it this way instead of simply placing the
>>listener and
>>the page view in the showPageX event? Code reuse. I want
>>to reuse the
>>event actionPageX in other places... _but_ ... the event
>>ActionPageX
>>may also need to trigger some other events dependant on
>>conditions
>>known only to the listener (using the announceEvent
>>method). Now
>>suddenly my xml no longer works, because content in the
>>optional
>>triggered events is required to generate the view.
> Again, I may be misunderstanding, but I think you may be
> approaching this the wrong way, or at the very least
> there's more than one way to skin a cat.
> You don't have to do all these sorts of things in the
> XML file as you're doing it here. In other words, you
> don't have to have an event for actionPageX in order to
> reuse it (and this may be a semantic issue, but when
> I write Mach-II code I no longer even HAVE "action
> pages"), you can do all this with listener methods.
> In other words, in order to accommodate what I think
> you're saying, you might end up writing a method in
> your listener to handle things in a particular way,
> and the beauty of this is you can write extremely
> granular listener methods and then write a listener
> method that calls these other methods and groups them
> as you want. The XML file doesn't necessarily have
> to be the be all and end all of what happens in what
> order. So in short Mach-II doesn't prevent you from
> doing anything, it may just be that you're focusing
> too much on the XML file as opposed to utilizing
> the CFC listeners to handle more of the work.
It was probably a poor choice of names for the events... the name
"actionPageX" is really just semantic -- it could be anything. I was
trying to come up with something implementation inspecific (i.e. not
"doSomethingWithMembers"), and that's just what was in my head. 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.
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. And
that's really where my headspace is -- when I'm writing onTap apps --
yes, I have custom tag calls (my model components to manage the
database for instance), and I have view templates that get included,
and I have other general "this that and the other" code that executes
within the event 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. 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.
The example above shows part of the way I envision the separation of
the business logic from the view. showPageX is a public event-handler,
whereas the remaining two event-handlers are both private and only
receive announcement from the public event-handler. Which is somewhat
similar to an onTap framework page view (or some of the ones I've
written anyway) wherein the process being called by the user remotely
(the http request), executes several other events or sub-processes
which may or may not be directly accessible via a browser. 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.
> As an example (and this will show if I'm off-base in
> terms of what you're saying), let's say I have a page
> that runs some queries to get data for some drop-downs.
> Each of those queries could be announced as an event
> as you illustrate above, OR each of those could be
> called as methods within a single listener. The code
> reusability is the same--I either announce an event or
> call a listener method. I can do that as many times as
> I want or in any order I want before I display the page.
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. :)
>>So in order to accomodate that, I have to also remove the
>><announce> for the view event from the showPageX handler
>>and instead announce the event within the listener. Why?
>>Because when the announce tag is in the first event
>>handler, the event is announced before the listener is
>>notified and so the view is then queued prior to the
>>events which need to be triggered by the listener, so any
>>content generated by those triggered events won't be
>>available by the time the page view is displayed. Hence
>>the need to move the announcement of the 2nd event into
>>the listener.
> Again, what you're saying may be true, but this isn't the
> ONLY way to do things. I could equally say that in onTap
> execution of things is forced, and that you're forrced
> into nested events, although I know from your talk last
> night that this isn't *necessarily* true. It all depends
> on how you do things.
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? 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. It's possible it could
simply be easier to execute a process/event immediately using the
onTap framework than it is using Mach-II, 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). This is
after all the way that all languages operate by default, executing
each line of code as it occurs -- even in OO languages, the lines of
code within a method execute in order.
>>By contrast, the onTap framework nests events by default.
>>So in the onTap framework, you'd have a similar structure,
>>but the order of events wouldn't be as much of an
>>issue to trip over.
> But isn't this where the numbering comes in? If I want
> things to happen in a particualr order, don't I *have*
> to prefix my page names with numbers? Six of one, half
> dozen of another I know--just pointing out that order may
> matter, it may not, and you can accomplish both in either
> Mach-II or onTap.
Yes you can accomplish the same results in both frameworks. Whether
it's 6 or a half-dozen I think is debatable tho. And it all really
boils down to the paragraph above -- yes, in order to make things
execute in specific orders, you end up needing to "line number" your
templates in the onTap framework -- IF -- you're talking about code in
the same directory (and often times you're talking about code in
nested sub-directories which (i think intuitively) execute in a
top-down order). Or code which executes in the 7 different (well
documented) stages of the request (which is really much more like how
plugins work in Mach-II, allowing you to add code that would execute
at the beginning or end of every request for instance). But this isn't
the same sort of "first come first served" order provided by events in
a Mach-II app... 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.
So I wind up with a map that looks like this:
event
do stuff
do stuff
announce ---
do stuff |
do stuff |
/event |
event <---------
do stuff
announce ---
do stuff |
/event |
event / <-------
instead of like this:
event
do stuff
do stuff
event
do stuff
event /
do stuff
/event
do stuff
/event
Personally I think the latter is a lot more intuitive. With the
former, if I know in my first event what view I want to display
information from the 2nd event, I can't use it there -- I have to hold
off and use it in the last event. In the latter, my first event _is_
my last event, so if I know what view I'm going to use at the
beginning, I can declare it at any time.
>>So the onTap framework gives you more flexibility. Now
>>wether this is a good thing or a bad thing may depend
>>entirely on your point of view.
> This may be true from your perspective, but I think you
> may be limiting your view of Mach-II a tad. I have not
> run into anything in Mach-II yet (with four semi-large
> projects under my belt) that has forced me to do anything
> in a particular way. As we said after the meeting last
> night, I think maybe I'm just used to using CFCs a lot
> more heavily since I come from a Java background, but
> I'm not convinced Mach-II is limiting in the ways you
> describe. Please clarify if I'm misunderstanding, and at
> least we'll have some good background for my talk on 2/10.
I do think the dialog is important. (And I'm hoping that others on the
list are getting some benefit from it. :) And it's entirely possible I
may just not know enough about Mach-II and that I'll be much less
reticent about it once I know more (in particular I think about
Plugins and Filters). Hopefully I'm not the only one who could use
some clarification either. :)
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). Not that his
name should necessarily cary a huge amount of weight, but asside from
his being on Team MM, etc. he's also another big OO guy who I believe
has done a lot of Java work in the past, so it's an example of someone
coming from the same environment who still may have a similar opinion
about it (although I didn't bother to ask why he used that phrase to
describe it).
s. isaac dealey 214-823-9345
team macromedia volunteer http://www.macromedia.com/go/team
chief architect, tapestry cms http://products.turnkey.to
onTap is open source http://www.turnkey.to/ontap
-----------------------------------------------
To post, send email to [EMAIL PROTECTED]
To unsubscribe:
Send UNSUBSCRIBE to [EMAIL PROTECTED]
To subscribe / unsubscribe: http://www.dfwcfug.org
