I spent hours arguing with a friend who does exclusively .NET stuff about
event driven web apps. As long as you have to reload the entire page,
procedural seems like a much more logical way to go. You start at the top
of the page, and go until you get to the end of the page, and then stop.
But that isn't the only option - Flash widgets (or even full Flash apps) mean that a single rendered page can make multiple requests to the server before the page needs to be reloaded. That's an important step forward and a reason why event-driven applications are important. Flash allows genuinely asynchronous events, breaking down the procedural model.
That "driven by an XML file" statement pretty much
gives it away. If it's declarative, the order is fixed when it's coded, not
runtime, and is therefore procedural.
Actually declarative programming - a la Prolog etc - is specifically *not* procedural. That's the whole point of a declarative approach: the engine can implement the solution in any order it wishes, as long as the declarative rules are obeyed.
Mach II, for example, allows a single incoming event to generate multiple additional events. At present, those events are queued in the order they are generated but there is no real reason why that needs to be the case. One of the experiments I intend to conduct with Mach II is to change the event processing mechanism to process the queue in different orders to see how far the model can be pushed.
Consider a simple web form that accepts user feedback, writes it to a database and says "Thank you". There's no requirement that the database be updated before the thank you page is generated - they could be done in parallel (if the language allowed it) and could certainly be done in either order even in CF. Mach II allows you to process the submitFeedback event and generate updateFeedbackDatabase and sayThankyou events but those could be processed in any order (and then the output generated by 'sayThankyou' would be returned to the browser).
I'm curious. At a very high level, is this a fair description of what
happens in a typical Mach-II request cycle?
1) Fire an event (click a button/link)
2) Let the event handlers do whatever, possibly firing additional events
3) get page content
This is the result of one or more event handlers as part of step 2.
4) add layout(s)
There's no specific layout mechanism but you can either: cascade one view into another (using content variables); or use a view plugin. The cascading happens as a result of an event handler (and is therefore part of step 2).
5) return the page to the client
Yes.
So in reality what it does is:
1) An external event comes in
2) Process events until they are all processed
Processing an event may generate additional events
3) Return result to external systemAnd in between various processing points, plugins are called:
- preProcess
- preEvent
- postEvent
- preView
- postView
- postProcess
Some of these will be called multiple times depending on what events are processed and which views are selected.
To me there is a very distinct line between the first two steps and the last
three steps.
Hopefully, the above explanation makes it clearer?
It is my humble opinion that using an object system to do procedural work is bad
I think you're confusing several things here. OO and procedural are not actually exclusive - almost every single OO language is procedural. Declarative languages are few and far between - and all of them require an execution framework under the hood that is procedural. Why? Because we rely almost entirely on a procedural execution architecture: the register-based, sequential CPU. OO allows for a less sequential procedural system because the execution framework often permits parallel and/or asynchronous operation. Declarative programming takes that a step further by not imposing procedural ordering.
Procedural programming is about specifying 'how' things happen and, usually, 'when' (i.e., in order).
Declarative programming is about specifying 'what' needs to happen (but not 'how' - or 'when').
OO is (generally) a form of procedural programming that provides polymorphism, inheritance and encapsulation - which provides a high-level idiom to model the problem space. Most OO systems rely on synchronous messaging - procedure calls.
An implicit invocation architecture (events, listeners) lets you mix declarative programming (specifying the events, listeners and some operations) with procedural programming (inside the listeners - for the sequence of operations that is executed when a specific event is processed).
Back to my simple web form example - it has three events:
- submitFeedback
- updateFeedbackDatabase
- sayThankyou
There would be a feedbackDatabase listener and a thankyouView. You would declaratively say something like:
on event submitFeedback(args):
raise updateFeedbackDatabase(args)
raise sayThankyou on event updateFeedbackDatabase(args)
notify feedbackDatabase('add',args) on event sayThankyou
view thankyouViewIn CSP (Communicating Sequential Processes - a stylized language specifying programs for parallel systems), you have the choice of grouping operations with parallel or sequential qualifiers. Occam is a good example of a concrete language based on CSP. In such a language, the first declaration above could be written:
on event submitFeedback(args):
parallel
raise updateFeedbackDatabase(args)
raise sayThankyou
or: on event submitFeedback(args):
sequence
raise updateFeedbackDatabase(args)
raise sayThankyouIt should be clear that there is no reason in this scenario why the declarative version needs to imply the second (sequential) form - the first (parallel) form is a valid option and may be more efficient.
Sorry for the length of this but it touches on a subject dear to my heart - computer language design and implementation, which was my post graduate research work in the 80's, and my first few jobs.
Sean A Corfield -- http://www.corfield.org/blog/
"If you're not annoying somebody, you're not really alive." -- Margaret Atwood
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
