Menu
▾
▴
fofredux-devel — Developers discussion, bug fixing, and coding of fofredux
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(92) |
Dec
(142) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(33) |
Feb
(65) |
Mar
(76) |
Apr
(172) |
May
(124) |
Jun
(45) |
Jul
(76) |
Aug
(78) |
Sep
(1) |
Oct
(20) |
Nov
(6) |
Dec
(2) |
| 2007 |
Jan
(12) |
Feb
(7) |
Mar
(17) |
Apr
(3) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: Evan R. <eva...@gm...> - 2006-05-01 22:12:35
|
nothing has changed there...so it's strange. i'm assuming that fof_get_feeds is not coming back, which leads me to believe that the options are not being pulled out correctly. probably more non-php4-compliant code on my parts or a default value which was missing is causing something to break. - go to /options.php and see if the options fields are filled in with any values? any stored values will be populated. - try to change each value and save it. (to force it into the database) - if you know how, you could export the fr_config table. you should have 7 name/value pairs. if somethings missing, you were using a default, which is no longer stored...i need to add this to install.php yet (or an object init function would be better actually) if you get errors doing that...let me know. /evan On 5/1/06, Miles Beck <mil...@gm...> wrote: > On 5/1/06, Evan Roth <eva...@gm...> wrote: > > ah, then you heard the man, Miles. yank out all those publics, there > > should be 3 of them, and hopefully it works. > > for the line we mentioned, change public to var, like this... > > var $vals =3D array(); > > That fixed the previous error I was getting. Now I am getting the > below error when I click on a feed with unread items in it. And also > when I View New Items. > > Fatal error: Call to a member function on a non-object in > /var/www/fofredux-20060501/view.php on line 83 > > > ------------------------------------------------------- > 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 > |
|
From: Kevin <ke...@dr...> - 2006-05-01 21:35:24
|
Hi Dan,
Welcome! I am definitely interested in seeing an example of your work.=
=20
I haven't tried rails yet, but hear really good things about it.
> Hi Guys,
>
> Been using FOFR since Khaled wrote about it the first time on his
> site... And have since been reading this mailing-list...
>
> I love the MVC implementation in Rails and have implemented a
> Rails-inspired proof-of-concept View-Controller in php 4 (old class
> layout), its a while back I did it, and it was just for seing how
> "less" code it was making it work as light as possible...
>
> To give a small hint of the implementation:
>
> <?php
>
> class ArticleController extends ApplicationController
> {
> function view()
> {
> // business logic
> }
> }
>
> ?>
>
> after wards the file
>
> ./views/article/view.php
>
> is included and "evaluated"...
>
> I could put up a small example where you could browse the source as
> well...
>
> Best regards,
> Dan (A happy user)
>
> PS. Good work on this project...
>
>
> -------------------------------------------------------
> 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=120709&bid&3057&dat=12164=
2
> _______________________________________________
> Fofredux-devel mailing list
> Fof...@li...
> https://lists.sourceforge.net/lists/listinfo/fofredux-devel
>
--=20
Kevin
|
|
From: Miles B. <mil...@gm...> - 2006-05-01 21:20:05
|
On 5/1/06, Evan Roth <eva...@gm...> wrote: > ah, then you heard the man, Miles. yank out all those publics, there > should be 3 of them, and hopefully it works. > for the line we mentioned, change public to var, like this... > var $vals =3D array(); That fixed the previous error I was getting. Now I am getting the below error when I click on a feed with unread items in it. And also when I View New Items. Fatal error: Call to a member function on a non-object in /var/www/fofredux-20060501/view.php on line 83 |
|
From: Dan T. <rum...@gm...> - 2006-05-01 21:04:47
|
Hi Guys,
Been using FOFR since Khaled wrote about it the first time on his
site... And have since been reading this mailing-list...
I love the MVC implementation in Rails and have implemented a
Rails-inspired proof-of-concept View-Controller in php 4 (old class
layout), its a while back I did it, and it was just for seing how
"less" code it was making it work as light as possible...
To give a small hint of the implementation:
<?php
class ArticleController extends ApplicationController
{
function view()
{
// business logic
}
}
?>
after wards the file
./views/article/view.php
is included and "evaluated"...
I could put up a small example where you could browse the source as well...
Best regards,
Dan (A happy user)
PS. Good work on this project...
|
|
From: Evan R. <eva...@gm...> - 2006-05-01 21:04:37
|
ah, then you heard the man, Miles. yank out all those publics, there should be 3 of them, and hopefully it works. for the line we mentioned, change public to var, like this... var $vals =3D array(); /evan On 5/1/06, Kevin <ke...@dr...> wrote: > > > hrmm, i think php4 has trouble typing the only var in the class as an > > array. > > > > go into that file, change the line... > > public $vals =3D array(); > > ...to simply... > > public $vals; > > PHP4 doesn't use the public, private, protected, static keywords for clas= s > methods or data members. That's the cause of the error. > > > -- > Kevin > > > > ------------------------------------------------------- > 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 > |
|
From: Kevin <ke...@dr...> - 2006-05-01 20:01:14
|
> hrmm, i think php4 has trouble typing the only var in the class as an > array. > > go into that file, change the line... > public $vals =3D array(); > ...to simply... > public $vals; PHP4 doesn't use the public, private, protected, static keywords for clas= s methods or data members. That's the cause of the error. --=20 Kevin |
|
From: Miles B. <mil...@gm...> - 2006-05-01 19:50:57
|
On 5/1/06, Evan Roth <eva...@gm...> wrote: > hrmm, i think php4 has trouble typing the only var in the class as an arr= ay. > > go into that file, change the line... > public $vals =3D array(); > ...to simply... > public $vals; I'm still getting the same error after making the suggested change in option.php. -Miles |
|
From: Evan R. <eva...@gm...> - 2006-05-01 19:45:20
|
hrmm, i think php4 has trouble typing the only var in the class as an array= . go into that file, change the line... public $vals =3D array(); ...to simply... public $vals; and then report back. i'm on php 5...might need to install a php switcher to test this a bit better. thanx. On 5/1/06, Miles Beck <mil...@gm...> wrote: > On 5/1/06, Evan Roth <eva...@gm...> wrote: > > must be my error, since that's the new class i added. although line > > 16 is simply initializing the variable. > > > > - can you tell me what php version you are running? > > - are you able to do anything with the app (other than install)? i > > suspect not, since it's trying to load options...but better to ask. > > > > /evan > > I'm using php4 on Debian. I cannot do anything with the snapshot. I > get the same error no matter what I try. > > -Miles > > > ------------------------------------------------------- > 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 > |
|
From: Miles B. <mil...@gm...> - 2006-05-01 19:40:56
|
On 5/1/06, Evan Roth <eva...@gm...> wrote: > must be my error, since that's the new class i added. although line > 16 is simply initializing the variable. > > - can you tell me what php version you are running? > - are you able to do anything with the app (other than install)? i > suspect not, since it's trying to load options...but better to ask. > > /evan I'm using php4 on Debian. I cannot do anything with the snapshot. I get the same error no matter what I try. -Miles |
|
From: Evan R. <eva...@gm...> - 2006-05-01 19:26:43
|
must be my error, since that's the new class i added. although line 16 is simply initializing the variable. - can you tell me what php version you are running? - are you able to do anything with the app (other than install)? i suspect not, since it's trying to load options...but better to ask. /evan On 5/1/06, Miles Beck <mil...@gm...> wrote: > I get the below error when trying to check out the latest snapshot. > I've tried running install.php and get the same error. > > Parse error: parse error, unexpected T_STRING, expecting > T_OLD_FUNCTION or T_FUNCTION or T_VAR or '}' in > /var/www/fofredux-20060501/lib/actions/option.php on line 16 > > -Miles > > > ------------------------------------------------------- > 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 > |
|
From: Miles B. <mil...@gm...> - 2006-05-01 18:43:58
|
I get the below error when trying to check out the latest snapshot. I've tried running install.php and get the same error. Parse error: parse error, unexpected T_STRING, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or '}' in /var/www/fofredux-20060501/lib/actions/option.php on line 16 -Miles |
|
From: Kevin <ke...@dr...> - 2006-05-01 16:40:56
|
> 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 :) The model is a little more then the db interface, but not much. One exam= ple of this is an operation like "update feed". This is a purely model activity, IMHO. It has many steps, only some of which deal with database access. Now, update feed is meaningless without the controller to tell *when* or *if* a feed should be updated. That's just my take on it. As long as the line between view and everything else is clear, that's wha= t matters, and that's where we will get the most benefit from this exercise= . --=20 Kevin |
|
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 > |
|
From: Andrew T. <ajt...@hi...> - 2006-05-01 12:37:53
|
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/reformatting > > 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 the > > actions/controller. > > > > I needed to refresh my memory on MVC. Here are a few good websites I fou= nd. > > http://codesnipers.com/?q=3Dnode/247 > http://www.phppatterns.com/docs/design/archive/model_view_controller_patt= ern > 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, 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?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 |
|
From: Kevin <ke...@dr...> - 2006-05-01 06:34:12
|
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/reformatting > 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 the > actions/controller. > I needed to refresh my memory on MVC. Here are a few good websites I found. http://codesnipers.com/?q=node/247 http://www.phppatterns.com/docs/design/archive/model_view_controller_pattern 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 |
|
From: Kevin <ke...@dr...> - 2006-04-30 20:31:10
|
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/reformatting 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 the actions/controller. -Kevin |
|
From: Evan R. <eva...@gm...> - 2006-04-30 20:06:36
|
so, as my comments earlier...i've redone all the options stuff, so it's required me to commit lots of the files...be sure you've all got the newest versions. as this change can be turned back, if we so decide, i've commented out the stuff in init.php which is now obsolete. now it looks like this: $opts =3D new Options(); //construct our options object and load vals from= DB ...and... $opts->vals[name] =3D value; //the stuff that was in the $config array bef= ore quite straight-forward actually. i still need to add an init() class function, which will store any default values which aren't already present in the database...since we've essentially made deafult.config obsolete as well. /evan |
|
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
>
|
|
From: Evan R. <eva...@gm...> - 2006-04-30 16:00:16
|
Re: Khaled: well, when it comes to the actual site markup...which you see by viewing source in the browser...there probably won't be so much that changes. what should change is how it's put together on the backed...which would provide for simple source files which you (or anyone) can peek at and understand, rather than needing to view the source in your browser. currently, this is near impossible with some of the older scripts. again, not our fault, but i've got the confidence that this team can improve on it. |
|
From: Andrew T. <ajt...@hi...> - 2006-04-30 15:52:57
|
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
|
|
From: khaled A. A. <bro...@gm...> - 2006-04-30 15:47:56
|
Reason I'm not saying much is because I'm kinda out of my depth here with regards to reasons for starting from the ground up etc. I will say that we really should be aiming for a tabless design as this will make anyone wanting to play around with the look of their install, a pretty easy task. I'm going to wait until the dust settles as to which route we're planning o= n going down, but needless to say I'm well looking forward to applying the style to interface. On 4/30/06, Evan Roth <eva...@gm...> wrote: > > Hey guys, > > me again. i've spent the last day thinking about all of this stuff > more intensively. > > i was going to start on making everything multi-user, which is not so > complicated, but it requires a lot of adding/rewriting of core > logic...since we always need to retrieve only the logged in user's > stuff. and i can't bring myself to take that step when everything is, > as we say in the office, spaghetti code. > > in order to solve this problem, there are two things that need to be > done first, which i'm going to just jump in and get started on: > 1. the code desperately needs to be refactored. > 2. the view needs to be broken up and simplified. > > my initial thoughts yesterday were that the only option was to apply a > professional framework here. i spent most of the day playing with > CakePHP, which is pretty damn cool. but in the end, i admit that i > was probably wrong, as it would be, as they say in german "mit Kanonen > auf Spatzen schie=DFen" which is a nice figurative that translates like > "shooting at sparrows with cannons"...in other words, way overkill for > what we need. [although, if we were starting the application brand > new, it may still be a decent choice] > > 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] > > 2. essentially each of the existing scripts is in some way or other > the view, but in most cases more than needed. i'd like to be able to > split this apart into more code blocks doing 1 small task each. we > could choose to use some sort of templating engine (such as smarty), > but i doubt it's necessary. in the end, this makes it super simple > for Andrew to plug in his ajax stuff and for Khaled to create a decent > stylesheet. > > ok enough from me...it'd be interesting to hear thoughts from the rest of > you. > /evan > > > On 4/30/06, Evan Roth <eva...@gm...> wrote: > > hey, > > > > kev, i see that you've started to put in the...um...framework for a > framework. > > > > after chopping apart the options page today, i became a little > > disheartened. currently our controller is a big fat blob and the view > > is a mess. > > > > in order to get any kind of css to play nicely, we really need to > > strip out a nice view and keep it super simple: > > for example, the feeds list, should be 1 view, which is then invoked > > from the panel or frameset or whatever. right now, this same list is > > coded almost identically in feeds.php (framed) and panel.php (normal). > > > > i'm really getting the feeling that we should just bite the bullet and > > switch to a php framework...which will make everyone's job easier in > > the end, even if it is a bit of work up front. > > i've never used any php specific ones (only struts for our jsp stuff > > at work), so can't make a good suggestion. been reading quite a bit > > about symfony lately, but it might be only php5. otherwise, i've > > heard good about cakephp, since it seems to be emulating rails, and > > thus riding the popularity wave. > > i'd imagine we'd be much better off implementing something that's > > already available, rather than trying to build our own. > > > > in any case, my concern is not so much the fat init.php, but the view > > that is all over the place. and if we want to really push out a nice > > tableless, css based UI, we need a really efficient view. (this also > > helps if we decide to go down the ajax road as well) > > > > anyway...just thought i'd add my 2 cents...perhaps some of the other > > devs have some thoughts. discussion is always good. if it should be > > done, i don't mind jumping in the cold water and starting with it. i > > just want to pass off some clean simple markup to khaled ASAP, so we > > can begin seeing some initial versions of the new UI...that will be > > really exciting... > > > > /evan > > > > > ------------------------------------------------------- > 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 > easier > 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 > |
|
From: Evan R. <eva...@gm...> - 2006-04-30 15:37:05
|
Hey guys, me again. i've spent the last day thinking about all of this stuff more intensively. i was going to start on making everything multi-user, which is not so complicated, but it requires a lot of adding/rewriting of core logic...since we always need to retrieve only the logged in user's stuff. and i can't bring myself to take that step when everything is, as we say in the office, spaghetti code. in order to solve this problem, there are two things that need to be done first, which i'm going to just jump in and get started on: 1. the code desperately needs to be refactored. 2. the view needs to be broken up and simplified. my initial thoughts yesterday were that the only option was to apply a professional framework here. i spent most of the day playing with CakePHP, which is pretty damn cool. but in the end, i admit that i was probably wrong, as it would be, as they say in german "mit Kanonen auf Spatzen schie=DFen" which is a nice figurative that translates like "shooting at sparrows with cannons"...in other words, way overkill for what we need. [although, if we were starting the application brand new, it may still be a decent choice] in any case, in regards to my 2 points above: 1. i see that Kev began laying the foundation for this yesterday.=20 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] 2. essentially each of the existing scripts is in some way or other the view, but in most cases more than needed. i'd like to be able to split this apart into more code blocks doing 1 small task each. we could choose to use some sort of templating engine (such as smarty), but i doubt it's necessary. in the end, this makes it super simple for Andrew to plug in his ajax stuff and for Khaled to create a decent stylesheet. ok enough from me...it'd be interesting to hear thoughts from the rest of y= ou. /evan On 4/30/06, Evan Roth <eva...@gm...> wrote: > hey, > > kev, i see that you've started to put in the...um...framework for a frame= work. > > after chopping apart the options page today, i became a little > disheartened. currently our controller is a big fat blob and the view > is a mess. > > in order to get any kind of css to play nicely, we really need to > strip out a nice view and keep it super simple: > for example, the feeds list, should be 1 view, which is then invoked > from the panel or frameset or whatever. right now, this same list is > coded almost identically in feeds.php (framed) and panel.php (normal). > > i'm really getting the feeling that we should just bite the bullet and > switch to a php framework...which will make everyone's job easier in > the end, even if it is a bit of work up front. > i've never used any php specific ones (only struts for our jsp stuff > at work), so can't make a good suggestion. been reading quite a bit > about symfony lately, but it might be only php5. otherwise, i've > heard good about cakephp, since it seems to be emulating rails, and > thus riding the popularity wave. > i'd imagine we'd be much better off implementing something that's > already available, rather than trying to build our own. > > in any case, my concern is not so much the fat init.php, but the view > that is all over the place. and if we want to really push out a nice > tableless, css based UI, we need a really efficient view. (this also > helps if we decide to go down the ajax road as well) > > anyway...just thought i'd add my 2 cents...perhaps some of the other > devs have some thoughts. discussion is always good. if it should be > done, i don't mind jumping in the cold water and starting with it. i > just want to pass off some clean simple markup to khaled ASAP, so we > can begin seeing some initial versions of the new UI...that will be > really exciting... > > /evan > |
|
From: Evan R. <eva...@gm...> - 2006-04-29 22:33:10
|
hey, kev, i see that you've started to put in the...um...framework for a framewo= rk. after chopping apart the options page today, i became a little disheartened. currently our controller is a big fat blob and the view is a mess. in order to get any kind of css to play nicely, we really need to strip out a nice view and keep it super simple: for example, the feeds list, should be 1 view, which is then invoked from the panel or frameset or whatever. right now, this same list is coded almost identically in feeds.php (framed) and panel.php (normal). i'm really getting the feeling that we should just bite the bullet and switch to a php framework...which will make everyone's job easier in the end, even if it is a bit of work up front. i've never used any php specific ones (only struts for our jsp stuff at work), so can't make a good suggestion. been reading quite a bit about symfony lately, but it might be only php5. otherwise, i've heard good about cakephp, since it seems to be emulating rails, and thus riding the popularity wave. i'd imagine we'd be much better off implementing something that's already available, rather than trying to build our own. in any case, my concern is not so much the fat init.php, but the view that is all over the place. and if we want to really push out a nice tableless, css based UI, we need a really efficient view. (this also helps if we decide to go down the ajax road as well) anyway...just thought i'd add my 2 cents...perhaps some of the other devs have some thoughts. discussion is always good. if it should be done, i don't mind jumping in the cold water and starting with it. i just want to pass off some clean simple markup to khaled ASAP, so we can begin seeing some initial versions of the new UI...that will be really exciting... /evan |
|
From: Andrew T. <ajt...@hi...> - 2006-04-29 21:40:59
|
Sorry I've been out of it - finishing up a big assignment. As kevin mentioned, I usually have taken care of the changelog. Any dev is free to add/modify the changelog and check it back in. When a release occurs, I generally: put out a call on the dev-list for known changes, pull in any features/bugs that were closed on the current rev off of SF, and glance through the cvs (now svn) log messages. If you can, please not in your repository log messages if a bug/feature was addressed: examples Implemets FEATURE REQUEST #49382022 Fixes BUG #498395035 Andrew On 4/29/06, Kevin <ke...@dr...> wrote: > Evan Roth wrote: > > do we have someone in charge of keeping the changelog up to date, or > > is that for whoever has made the changes? > > > In the past, Andrew would add stuff to the changelog shortly before > release. I like the idea of sharing responsibility so things don't get > overlooked. > > > > ------------------------------------------------------- > 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?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 |
|
From: Evan R. <eva...@gm...> - 2006-04-29 21:10:19
|
well, technically it will be...if someone still has that old version which caused problems, and now wants to jump to 0.4 when they see our super new interface On 4/29/06, Kevin <ke...@dr...> wrote: > Evan Roth wrote: > > hey guys, > > > > i've redone the options page in preparation for the redesign of the sit= e: > > - according the design images, i've changed all the yes/no radios into > > checkboxes > > - it is now valid xhtml without tables (except for a few lines coming > > from header.php, which are still on the todo list) [so khaled can go > > nuts] > > - i've reorganized the list of items a bit, beginning to group them in > > various sections. i've just thrown it together quickly, so we can > > change that as needed > > - on the backend, i've redone the saving of items, since we were > > always saving a value, regardless of what it is. i've put a bunch of > > checks in there, so we only change it when it's actually been changed. > > this also means that if a user sticks with a default value, it will > > not show up in the database > > > > I've added 1 bug that i've found in the process to the tracker at > > sourceforge. for whatever reason, you guys drop the table and set it > > back up in install.php. in the past, this was probably not an issue > > with only 2 options...but now that our list is growing, we can't > > afford to do this as it will lose all the user's settings. > > > The explicit drop/recreate of the config table was due to the table > originally having a different structure. That was a few months ago, so > I don't think it's needed anymore. > > -Kevin > > > ------------------------------------------------------- > 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?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat= =3D121642 > _______________________________________________ > Fofredux-devel mailing list > Fof...@li... > https://lists.sourceforge.net/lists/listinfo/fofredux-devel > |
5 messages has been excluded from this view by a project administrator.
