From: Evan R. <eva...@gm...> - 2006-04-30 16:23:48
|
re: Andrew i tend to agree. although, i think if kev wants to set up the framework (i hate using that word here) for the classes, then go for it. but we'll get the job done better if every adds the various functionality to those respective classes. in the end, off the top of my head, you only need the following classes: user (add, check_login, ...) option (set, get) feed (add, del, list, ...) item (add, del, list, mark) tag (add, del, add_to_item) category (add, del, add_to_feed) search (do, save?) that's what ran through my head this morning and essentially killed the idea of a real framework there. we are still a simple small application. i'd suggest kev make the classes with constructors (although i still prefer renaming actions/entities), and the rest of us simply migrate the code as we use it. we could hammer out the options quickly, since that is relatively independent (saved in 1 spot and read out into a global array in 1 spot)...and then review if we like the direction we're headed before we go further. asking 1 person to refactor all of init.php is like an after school detention. my stomach turns every time i open that file up =3D) thus, probably best if we all get our hands dirty. /evan On 4/30/06, Andrew Turner <ajt...@hi...> wrote: > Evan, I'm glad you agree that pulling in an existing framework is > overkill for us. Especially at this point with FoFRedux which has all > of its functionality already in place, it just needs to be > "refactored" > > I think it would be best to have 1 person architect the new FoFR > framework, with discussion/input from everyone concerned who has input > to offer. But I don't want the code to become a tug-of-war between > developers. Perhaps kevin can lay out his current design > layout/implementation vector (I just made that word up) > > My thoughts: > The view should be able to make calls like: > * Give me the array of feeds for a user > * Add this feed for a user > * Give me items which match * criteria > * Add this search, pull up by search > > etc. - the view just makes high-level requests and then gets back an > array that it can pull apart and display while iterating through each > row. Here is some rough pseudo-code > > "view_framework.php" > display_item(item_row) { > /* return HTML */ > } > display_feed_row(feed_row) { > /* return HTML */ > } > > view.php > <? display_menu('view'); ?> > <? items =3D get_items_for_view(params); ?> > <? for items { display_item(item))} ?> > > > Then the controller would be responsible for the "get_items_for_view" > functions and so on which would then query the db, build up a nice > array, and return it to the view > > What do you think? > Andrew > |