> Of course the code that fetches and possibly massages the raw data belongs > in the model >
This was the point I was getting at, this is why I used the word Generating not Displaying, I am aware XM(ark-up)L is a mark up langauge I was merely pointing out that genertaing ie building not displaying XML document is normally done in the model layer. I think its more of a terminology issue because in response to my original mail, A.J Brown said that: "Generating XML feeds should NOT be done in the model", I think the word generating needs to be defined in this context, as I meant generating to mean to actually build/create the XML document, but by the sounds of it A.J. Brown does not? Thank You Daniel Latter 2008/12/15 Michael Tramontano <[email protected]> > The markup surrounding data in an xml document / feed is no different than > the markup of an html page. This belongs in the view layer. Of course the > code that fetches and possibly massages the raw data belongs in the model, > but the idea is to be able to use this data for anything, xml feed, html > page, etc. The model doesn't and shouldn't care where the data will end up. > > Feed specific view <-> light feed specific controller <-> model > HTML specific view <-> light html specific controller <-> model (same as > above) > > You might even be able to use some generic controller as well, though I > haven't done that myself. I'll let others chime in on that... > > -mike tramontano > > -----Original Message----- > From: Daniel Latter [mailto:[email protected]] > Sent: Friday, December 12, 2008 8:17 PM > To: A.J. Brown > Cc: [email protected] > Subject: Re: [fw-general] Newbie quesiton - How do queries that join > multiple tables fit into the model in the MVC > > Yes, thanks, you are right, but say you were creating a specific XML > file from scratch using domdocument for example, that involved > creating / appending a lot of elements, and this was wrapped up in the > form of a custom class you created, wouldnt you store this in the > model? And the use in your controller? > > > > On Dec 12, 2008, at 23:24, "A.J. Brown" <[email protected]> wrote: > > > > > Generating XML and Feeds should NOT be done with the model. Those are > > representations of the data, and should be done with in the > > controller and > > view layers. The controller layer should determine which > > representation to > > use by selecting the correct view, and the view should render the > > data. > > > > -- > > A.J. Brown > > Zend Certified PHP Engineer > > WEB: http://ajbrown.org > > > > > > > > > > Daniel Latter-2 wrote: > >> > >> As a very loose, and general rule of of thumb the things that should > >> be part of your model would things like generating / creating XML > >> feeds , ie the code that does this, processing data you've got from a > >> database, ie to prepare the data so your app can more easily use it, > >> and generally things like that, basically it's the meat of your > >> application, the controllers would then use the model classes. > >> > >> This is a very general description I've explained but I think it's a > >> good starting point. > >> > >> > >> On Dec 11, 2008, at 18:56, Bill Karwin <[email protected]> wrote: > >> > >>> > >>> On Dec 11, 2008, at 9:48 AM, Julian102 wrote: > >>> > >>>> Can anyone explain to me or show me somewhere that explains on a > >>>> very high > >>>> level for a beginner how the model fits into a system and how one > >>>> should > >>>> think about it when designing an application. > >>>> > >>>> For example should the model be designed at the same time the > >>>> database is > >>>> designed? > >>> > >>> Not necessarily -- you design the Models as part of your object- > >>> oriented design for the application. The database design is for > >>> persistence; it doesn't always map directly to your OO > >>> architecture. As you've noticed, you could have a Model that uses > >>> multiple tables, and you might also use a given table in multiple > >>> Models. > >>> > >>> The Controller and the View have pretty specific roles in an MVC > >>> app, related to managing input and producing output respectively. > >>> The Model should be where everything else about your app is coded, > >>> and the database access is purely an internal implementation matter. > >>> > >>> Think of it this way: suppose you're in a team and you're > >>> responsible for coding the Model, but you're not going to be the one > >>> coding the other parts of the app. You need to publish your Model's > >>> interface to the other members of the team, and they'll call into it > >>> to fetch and save information managed by that Model. > >>> > >>> The problem is, you know from working with this team that they are > >>> untrustworthy bunglers (you suspect they are actually a troop of > >>> over-caffeinated chimpanzees banging on keyboards). You're sure > >>> that they will abuse a Table's createRow() and update() and delete() > >>> methods, messing up data integrity if they are given the chance. > >>> They'll call fetchAll() with improper and inefficient queries. And > >>> we won't even contemplate what they could do with getAdapter(). > >>> > >>> So you can't trust them to use a Table class directly. You need to > >>> make a Model class, that encapsulates the high-level things your > >>> Model can do, exposing _only_ those as task-oriented methods. > >>> Methods such as "createNewPost()" and "replyToPost()" and > >>> "countPostsInThread()" and "reportAbusivePost()." You can use the > >>> Model class to make sure these high-level tasks are done correctly, > >>> no matter how incompetent the person who's using your interface is. > >>> The Model should encapsulate all the code and all the data needed to > >>> accomplish the work for a related set of tasks in your app. Details > >>> of how data is stored in the database and how to query it should be > >>> known only to you. > >>> > >>> A few other resources: > >>> > >>> Esteemed ZF contributor Pádraic Brady posted a great blog articl > >>> e re > >>> cently called "The M in MVC: Why Models are Misunderstood and Unappr > >>> eciated." > >>> > >>> A free online resource is S. Lott's book, "Building Skills in OO > >>> Design." > >>> > >>> Craig Larman's book "Applying UML & Patterns: Introduction to > >>> Object- > >>> Oriented Analysis & Design, & Iterative Development" talks about > >>> "assignment of responsibilities" which helps you decide what code > >>> goes in what class. That's a good in-depth resource to read more > >>> about the process of OO design. > >>> > >>> Regards, > >>> Bill Karwin > >> > >> > > > > > > ----- > > Regards, > > > > A.J. Brown > > Zend Certified PHP Engineer > > http://ajbrown.me > > -- > > View this message in context: > http://www.nabble.com/Newbie-quesiton---How-do-queries-that-join-multiple-tables-fit-into-the-model-in-the-MVC-tp20919944p20985372.html > > Sent from the Zend Framework mailing list archive at Nabble.com. > > >
