On Friday, Jul 25, 2003, at 13:20 US/Pacific, Ovid wrote:
--- drieux <[EMAIL PROTECTED]> wrote:[..]Great Questions!
MVC - Model,View,Controller
it is a design pattern, a way of 'looking at' the problem and understanding which parts belong where.
<http://www.google.com/search?hl=en&ie=ISO-8859- 1&q=Model%2CView%2CController&btnG=Google+Search>
Just to really fan the flames here and ensure that we're not inadvertently creating innacurate memes,
The View in MVC is typically dynamically updated.[..]
[..]It's not always that way, but it's a far enough divergence from classic MVC that the distinction is worth noting. Anyone here who doesn't know that and starts talking about MVC to a Design Pattern purist is going to get a serious talking to :)
Silence is Evil http://users.easystreet.com/ovid/philosophy/indexdecency.htm
Ovid http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Ovid,
I love the smell of 'primate-ism' ....
It could be merely the way that you are presenting the problem - and a desire to defend an anachronistic model of MVC, based upon the underlying 'primate-ism', and the scary thought of 'recursion' in conceptual models that might mean sticking the primate in a chair, and leaving the heavy lifting to sentient life forms.
If we start with the premise that there can be but one 'view' then of course that 'view' MUST be the 'view' that the Monkey^H^H^H^H^H^H Primate Sees. So by definition we can 'rescue' ourselves from recursion.
So I am willing to question that opening premise, especially given your own assertion that 'typically' - allowing that there are manifestations of MVC in which the view need not be dynamically updated.
But let us begin at the begining here, with the OneTrueAndOnlyClassicallyPure - 'there can be but one view' model of the MVC - and it gives rise to an application. The Primate pokes it, and is amused.
Either all of software development ceases, or there is the threat that a second application, built upon the PureLand model of MVC arises, and so on and so on, until there are many pieces of software, all with 'but one view'.
Along comes an integrator, and notices, that with a replication of the basic paradigm, that information from two TrueMVC's can be used to stitch together a new synthetic MVC application. In this case of course maintaining the TrueDoctrine, that the Primate is the highest of all life forms, and that only the view that the Primate Sees is the True View.
Never Mind that the little pixies inside the new synthetic MVC application are looking at input from the two 'true views' of each respective applications, as if they were Primates, and spinning around quickly and obligingly handing out the NewAndImprovedTrueView to the Primate.
The downside to this approach towards MVC, besides the scary thought that there are pixies in our computers who might think of themselves as Primates, and start scratching for fleas, leaving bananna peels, and plotting to Go On Strike, or worse yet an LBO to take over the firm and install their guy on the Board.... is that it would mean 'empowering' the pixies that deal with the 'TrueViews' to understand what to do at 'upgrade time' - when the YUTZs decide that a new element needs to be added or subtracted to an underlying 'view'.
Now we have all watched Primates with their new toy going - 'what does this big red button do?'
But Pixies, unlike Primates, of course are the friends of sentient life forms who will RTFM, and make sure that they know when, where, and why they want to press the big red button.
Notice now, that the FriendOfThePixie who's 'view' has changed is the only one who needs to be informed that the 'view' has changed. All the Other Pixies, and their friends, in the application - including the artsey one who paints the pretty pictures for the Primate - can all stay out late partying and running around while the Poor Pixie who's view has changed must stay home, and update their way of dealing with the fact that their view has changed.
So the FriendOfThePixie and the Pixie stay up, drink much mountain dew, and mumble and swear about the evils of the Freaking Primates.... and then check all of the code back into the source code repository, including the online documentation, knowing full well that the Freaking Primate will merely go 'ook-ook' and not read line one of it!!!!
Where does this leave us:
a. we allow for recursion in the MVC pattern so that we can allow for software being built upon other software.
b. we demand that all software be written to bare metal, and that it does not require little pixies with pretensions to being flea picking primates.
c. we find a way to cage the primates and leave the land free for FriendsOfThePixies to roam freely across the much happier land where no one ever changes the Freaking Underlying Layer that they coded to...
d. we remember to take the whole source code tree and our compiler with us the next time we go out to see __TheMatrix::ReLinked__ so as to make sure none of the software feels left behind and becomes emotionally traumatized... I mean have you ever come back from a night out and your source code tree THINKS that it smells other source code??? Oh sure, just try to talk yourself out of that one...
ciao drieux
---
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
