From: Evan R. <eva...@gm...> - 2006-05-01 13:07:07
|
maybe i'm wrong, but i've always thought that CRUD is often split between controller and model. a controller should interpret an event and translate it into an action to the data. granted, if you have a stored proc or something, you have a clean seperation there, but this is often tough to achieve in php alone. further, i think you might have misinterpreted Brooks. At least, if i remember way back to learning his theory (although i've never read the entire book), he meant to say that adding people late in a project makes it even later...but you should still start with the correct number of people that you might need. thus, since we are getting started with this mini-project, there's really no risk there, but we should still divide it up the best way possible. i also think that we should focus on simply restructuring the code so that it works in the best way possible for us, rather than debate theory. for me, that means slimming down the view big time and chopping up init.php (and whatever else has too much logic) into the various objects. those objects, as andrew mentioned, probably should not contain any markup of their own...unless of course they are objects intended for such a purpose. if our model and controller are still stuck together quite a bit, then so be it. On 5/1/06, Andrew Turner <ajt...@hi...> wrote: > Kevin, you're correct that a lot of what you're doing is the Model. > Model interface is the CRUD stuff (for those who don't know - Create, > Read, Update Delete). The controller is any of the business-logic (as > Kevin mentioned). > > Evan - I don't expect someone to sit and rewrite all of FoFRedux - > though I did all the refactoring of FoF on the original fork (or > 'reduxing' :) since FoF was even worse about not DRY (Don't Repeat > Yourself). But if you subscribe to the Brooks 'Mythical Man-Month' > theory, then projects should have 1 architect and lots of monkeys. :) > I'm not prescribing that, but thought it a good idea to have 1 person > rip through and lay out functions and then as you mentioned, everyone > fill those functions in. > > The alternative is what has happened, which is some init.php functions > have HTML in them, some don't, some have diff't params, etc. > > So Kevin - don't worry too much about getting everything, but if it's > ok - just put out what functions and parameter interfaces there is to > the Model code (the db-side, which you are the expert at :) > > Khaled - I thought you were going to just create a "from-scratch" > HTML/CSS layout and then we would fill in the actual PHP code? (Btw - > nice reboot ;) > > Andrew > > On 5/1/06, Kevin <ke...@dr...> wrote: > > Kevin wrote: > > > Evan Roth wrote: > > > ... > > > > > >> in any case, in regards to my 2 points above: > > >> 1. i see that Kev began laying the foundation for this yesterday. > > >> i'm going to simply jump in and help out there, whenever i need a > > >> function, i'll simply add it to a class. this will eventually tone > > >> down init.php over time. if someone has a better idea on how to > > >> systematically chop at this let me know. in any case, i'd start in = on > > >> the options and users, since that's what i had on the table for the > > >> next step towards multi-user. > > >> [note: Kev, i'd recommend you rename actions/entities to > > >> controllers/models respectively, since that is more standard > > >> terminology] > > >> > > > I am by no means an expert at this sort of stuff, so I started with > > > the easiest. I created a class for each noun in the system. Most of > > > them conveniently map to db tables. I think of them as just simple > > > data objects with little/no behavior of their own. It should be the > > > job of something else to store/retrieve/alter them in the database. > > > (maybe that's the model) I didn't want them to be weighed down with > > > lots of methods. > > > > > > I pictured the actions directory as containing both the model stuff > > > and controller stuff. Essentially everything that is in init.php > > > right now. There will be classes for CRUD operations for persisting > > > and retrieving the entities from the database. Then there would be > > > other classes for higher level operations like updating feeds, > > > tagging/marking items, performing searches, and filtering/reformattin= g > > > the contents of items. > > > > > > Now that I think more about it, I can see where the entity > > > persistence related operations (model) really don't belong in with th= e > > > actions/controller. > > > > > > > I needed to refresh my memory on MVC. Here are a few good websites I f= ound. > > > > http://codesnipers.com/?q=3Dnode/247 > > http://www.phppatterns.com/docs/design/archive/model_view_controller_pa= ttern > > http://www.onlamp.com/pub/a/php/2005/09/15/mvc_intro.html > > > > So, I now realize, all of my thoughts/plans/ideas thus far have been > > devoted completely to the *model*. Essentially reorganizing the data > > access and other "business logic layer" activities. > > > > -Kevin > > > > > > ------------------------------------------------------- > > Using Tomcat but need to do more? Need to support web services, securit= y? > > Get stuff done quickly with pre-integrated technology to make your job = easier > > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geron= imo > > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat= =3D121642 > > _______________________________________________ > > Fofredux-devel mailing list > > Fof...@li... > > https://lists.sourceforge.net/lists/listinfo/fofredux-devel > > > > > -- > Andrew Turner > ajt...@hi... 42.4266N x 83.4931W > http://highearthorbit.com Northville, Michigan, USA > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job ea= sier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim= o > http://sel.as-us.falkag.net/sel?cmdlnk&kid=120709&bid&3057&dat=121642 > _______________________________________________ > Fofredux-devel mailing list > Fof...@li... > https://lists.sourceforge.net/lists/listinfo/fofredux-devel > |