fofredux-devel

[Fofredux-devel] Re: MVC rethought

[Evan R. <eva...@gm...>]

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
>

Re: [Fofredux-devel] Re: MVC rethought

[khaled A. A. <bro...@gm...>]

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
>

Re: [Fofredux-devel] Re: MVC rethought

[Evan R. <eva...@gm...>]

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.

Re: [Fofredux-devel] Re: MVC rethought

[Andrew T. <ajt...@hi...>]

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

Re: [Fofredux-devel] Re: MVC rethought

[Evan R. <eva...@gm...>]

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
>

Re: [Fofredux-devel] Re: MVC rethought

[Kevin <ke...@dr...>]

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

Re: [Fofredux-devel] Re: MVC rethought

[Kevin <ke...@dr...>]

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

Re: [Fofredux-devel] Re: MVC rethought

[Andrew T. <ajt...@hi...>]

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

Re: [Fofredux-devel] Re: MVC rethought

[Evan R. <eva...@gm...>]

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
>

Re: [Fofredux-devel] Re: MVC rethought

[Kevin <ke...@dr...>]

> 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

Re: [Fofredux-devel] Re: MVC rethought

[Dan T. <rum...@gm...>]

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...

Re: [Fofredux-devel] Re: MVC rethought

[Kevin <ke...@dr...>]

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

Re: [Fofredux-devel] Re: MVC rethought

[Dan T. <da...@an...>]

This is just proof of concept... So no routing etc have been implemented...

 http://v.rummanddan.dk/article/view/12344

You can get the source at...

 http://v.rummanddan.dk/vc.tar

I would happily contribute to this project, so let me know if its
something you would go for... I didnt implement an ORM (ActiveRecord
in rails) thats a whole lot of work itself, but I read you are
discussing to do that yourself anyway :)

/Dan


On 5/1/06, Kevin <ke...@dr...> wrote:
>
> Hi Dan,
>   Welcome!  I am definitely interested in seeing an example of your work.
> 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
> >
>
>
> --
> Kevin
>
>

Re: [Fofredux-devel] Re: MVC rethought

[Kevin <ke...@dr...>]

> This is just proof of concept... So no routing etc have been
> implemented...
>
>  http://v.rummanddan.dk/article/view/12344
>
> You can get the source at...
>
>  http://v.rummanddan.dk/vc.tar
>
> I would happily contribute to this project, so let me know if its
> something you would go for... I didnt implement an ORM (ActiveRecord
> in rails) thats a whole lot of work itself, but I read you are
> discussing to do that yourself anyway :)

Thanks,

Just a few quick comments after peeking at the code:

I like the REST style URI handling of the dispatcher.  It makes it clean
and  pretty easy to follow.

I'm not clear on what you mean by routing.  Is that like forwarding from
one controller to another?  (ex: redirecting to a login screen, etc)  If
you could provide an example on how that is used, it would help.

We have a fair amount of code around accessing the database.  I don't wan=
t
to try and convert it to an ORM package. It'd be too much work with littl=
e
benefit.

--=20
Kevin

Re: [Fofredux-devel] Re: MVC rethought

[Dan T. <da...@an...>]

Hi Kevin,

I have put some examples up on rendering other views, executing other
action, and howto redirect... Its in an updated tarball on the same
location /vc.tar :)

Regarding routing it was to control parameters and url layout... In
rails you do something like:

  map.connect 'profiles/:username', :controller =3D> 'profile', :action =3D=
> 'view'

I could easily implement something similar, as I've said in my two
earlier posts, this is just coded as proof-of-concept but it should be
fairly easy to make it fully usable...

Here goes examples for redirection as you requested...

Sorry for the long copy paste following:

  function red_string()
  {
    $this->redirect('/article/view/14231');
  }

  function red_array()
  {
    $this->redirect(
      array(
        'controller' =3D> 'article',
        'action' =3D> 'view',
        'id' =3D> '43223'
      )
    );
  }

  function view_render()
  {
    $this->some_var =3D "some var from other businness logic, id=3D" .
$this->get['id'];
    $this->someitems =3D array(
      'test other 1',
      'test other 2',
      'test other 3',
      'test other 4'
    );
    $this->render('/article/view');
  }

  function view_action_render()
  {
    $this->view();
    $this->render('/article/view');
  }


I would implement filters like in rails for a thing like Login screen,
when I have some sparetime here at work I will do that...

a before_filter is a method called return true or false wether or not
a action and view should be processed :)

/Dan

On 5/2/06, Kevin <ke...@dr...> wrote:
>
> > This is just proof of concept... So no routing etc have been
> > implemented...
> >
> >  http://v.rummanddan.dk/article/view/12344
> >
> > You can get the source at...
> >
> >  http://v.rummanddan.dk/vc.tar
> >
> > I would happily contribute to this project, so let me know if its
> > something you would go for... I didnt implement an ORM (ActiveRecord
> > in rails) thats a whole lot of work itself, but I read you are
> > discussing to do that yourself anyway :)
>
> Thanks,
>
> Just a few quick comments after peeking at the code:
>
> I like the REST style URI handling of the dispatcher.  It makes it clean
> and  pretty easy to follow.
>
> I'm not clear on what you mean by routing.  Is that like forwarding from
> one controller to another?  (ex: redirecting to a login screen, etc)  If
> you could provide an example on how that is used, it would help.
>
> We have a fair amount of code around accessing the database.  I don't wan=
t
> to try and convert it to an ORM package. It'd be too much work with littl=
e
> benefit.
>
> --
> Kevin
>
>

Re: [Fofredux-devel] Re: MVC rethought

[Andrew T. <ajt...@hi...>]

I had thought about the possibilities of a Rails-style PHP. I've
actually been doing a lot of rails programming recently (in addition
to this project :)

We don't need a full ORM, too much effort for something we don't
really need. I think the idea of routes is very interesting. Being
able to do fofredux/feeds/ajturner/new or something instead of the
nasty view.php?.. &... & .. & .. &
that we currently have. Though how are are we passing around these
view variables? Via a session?

And I think the views will be very similar to the rhtml files of Ruby.
Simple calls in the HTML to PHP commands.

Andrew

On 5/1/06, Kevin <ke...@dr...> wrote:
>
> > This is just proof of concept... So no routing etc have been
> > implemented...
> >
> >  http://v.rummanddan.dk/article/view/12344
> >
> > You can get the source at...
> >
> >  http://v.rummanddan.dk/vc.tar
> >
> > I would happily contribute to this project, so let me know if its
> > something you would go for... I didnt implement an ORM (ActiveRecord
> > in rails) thats a whole lot of work itself, but I read you are
> > discussing to do that yourself anyway :)
>
> Thanks,
>
> Just a few quick comments after peeking at the code:
>
> I like the REST style URI handling of the dispatcher.  It makes it clean
> and  pretty easy to follow.
>
> I'm not clear on what you mean by routing.  Is that like forwarding from
> one controller to another?  (ex: redirecting to a login screen, etc)  If
> you could provide an example on how that is used, it would help.
>
> We have a fair amount of code around accessing the database.  I don't wan=
t
> to try and convert it to an ORM package. It'd be too much work with littl=
e
> benefit.
>
> --
> 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
>


--
Andrew Turner
ajt...@hi...        42.4266N x 83.4931W
http://highearthorbit.com              Northville, Michigan, USA

Re: [Fofredux-devel] Re: MVC rethought

[Dan T. <da...@an...>]

Hi Andrew,

I dont know if you looked at my example...

> that we currently have. Though how are are we passing around these
> view variables? Via a session?

But in my example each controller (and view) has the variables in a
$this->get['id'] like the params[:id] or params['id'] in rails... :)

For /:controller/:action/:id its working allready...

Is it something I should take a shot at finishing for a simple
integration for this project?

Out of interest how many is reading this list? :) I have seen that not
that many different people interact in the discussions. :)

Regards,
Dan

On 5/2/06, Andrew Turner <ajt...@hi...> wrote:
> I had thought about the possibilities of a Rails-style PHP. I've
> actually been doing a lot of rails programming recently (in addition
> to this project :)
>
> We don't need a full ORM, too much effort for something we don't
> really need. I think the idea of routes is very interesting. Being
> able to do fofredux/feeds/ajturner/new or something instead of the
> nasty view.php?.. &... & .. & .. &
> that we currently have. Though how are are we passing around these
> view variables? Via a session?
>
> And I think the views will be very similar to the rhtml files of Ruby.
> Simple calls in the HTML to PHP commands.
>
> Andrew
>
> On 5/1/06, Kevin <ke...@dr...> wrote:
> >
> > > This is just proof of concept... So no routing etc have been
> > > implemented...
> > >
> > >  http://v.rummanddan.dk/article/view/12344
> > >
> > > You can get the source at...
> > >
> > >  http://v.rummanddan.dk/vc.tar
> > >
> > > I would happily contribute to this project, so let me know if its
> > > something you would go for... I didnt implement an ORM (ActiveRecord
> > > in rails) thats a whole lot of work itself, but I read you are
> > > discussing to do that yourself anyway :)
> >
> > Thanks,
> >
> > Just a few quick comments after peeking at the code:
> >
> > I like the REST style URI handling of the dispatcher.  It makes it clea=
n
> > and  pretty easy to follow.
> >
> > I'm not clear on what you mean by routing.  Is that like forwarding fro=
m
> > one controller to another?  (ex: redirecting to a login screen, etc)  I=
f
> > you could provide an example on how that is used, it would help.
> >
> > We have a fair amount of code around accessing the database.  I don't w=
ant
> > to try and convert it to an ORM package. It'd be too much work with lit=
tle
> > benefit.
> >
> > --
> > 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?cmdlnk&kid=120709&bid&3057&dat=121642
> > _______________________________________________
> > 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
>

Re: [Fofredux-devel] Re: MVC rethought

[khaled A. A. <bro...@gm...>]

Good to have you on board Dan. It's a damn good group of peeps on this list=
.

On 5/1/06, Dan Thrue <rum...@gm...> wrote:
>
> 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, 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
>

Re: [Fofredux-devel] Re: MVC rethought

[khaled A. A. <bro...@gm...>]

Just to confirm I'm going to mock up an html file with accompanying css fil=
e
that brings everything together (how I think that is). You guys can then
move forward and hack it to death then I'll come back at the end once the
dust has settled and do a final cleanup of the css.

Shouldn't be too difficult to deal with and I'll put a deadline for the end
of the week (if I get it to you guys sooner then that'll be a bonus :) ).

Re.Reboot Thanks Andrew, much appreciated, just need to updated the project
page so that there's more attention heading FOFR's way.

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
> found.
> >
> > 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
> easier
> > Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> > 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
> 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
>

Re: [Fofredux-devel] Re: MVC rethought

[Andrew T. <ajt...@hi...>]

Confirmed - make it very pretty and compliant. We'll then hack it "to
death" :) to hook it into FoFRedux.

On 5/2/06, khaled Abou Alfa <bro...@gm...> wrote:
> Just to confirm I'm going to mock up an html file with accompanying css f=
ile
> that brings everything together (how I think that is). You guys can then
> move forward and hack it to death then I'll come back at the end once the
> dust has settled and do a final cleanup of the css.
>
> Shouldn't be too difficult to deal with and I'll put a deadline for the e=
nd
> of the week (if I get it to you guys sooner then that'll be a bonus :) ).
>
> Re.Reboot Thanks Andrew, much appreciated, just need to updated the proje=
ct
> page so that there's more attention heading FOFR's way.
>
>
> 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
> found.
> >
> > 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, 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
> 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
>
>
>


--
Andrew Turner
ajt...@hi...        42.4266N x 83.4931W
http://highearthorbit.com              Northville, Michigan, USA

Re: [Fofredux-devel] Re: MVC rethought

[Kevin <ke...@dr...>]

Dan Thrue wrote:
> Hi Kevin,
>
> I have put some examples up on rendering other views, executing other
> action, and howto redirect... Its in an updated tarball on the same
> location /vc.tar :)
>
> Regarding routing it was to control parameters and url layout... In
> rails you do something like:
>
>  map.connect 'profiles/:username', :controller => 'profile', :action 
> => 'view'
>
> I could easily implement something similar, as I've said in my two
> earlier posts, this is just coded as proof-of-concept but it should be
> fairly easy to make it fully usable...
>
Thanks.  I also found this URL which covered it pretty well.
http://manuals.rubyonrails.com/read/chapter/65

Routes look pretty cool, but I don't think we need them right now.   We 
should be able to cover all of our actions/views by using the default 
'<controller>/<action>/<paremeters>' URI format.

The redirect examples were helpful.  It just goes to show how easy it is 
to extend.    You added one method to the base controller, and now 
there's a simple/flexible way of redirecting between pages.

I like it.  It's simple and easy to follow, yet pretty powerful.  It's 
based on rails, which a few of you already have experience with. I'll 
try and converting one of our pages to it and see how it goes.

-Kevin

Re: [Fofredux-devel] Re: MVC rethought

[Kevin <ke...@dr...>]

Andrew Turner wrote:
> I had thought about the possibilities of a Rails-style PHP. I've
> actually been doing a lot of rails programming recently (in addition
> to this project :)
>
> We don't need a full ORM, too much effort for something we don't
> really need. I think the idea of routes is very interesting. Being
> able to do fofredux/feeds/ajturner/new or something instead of the
> nasty view.php?.. &... & .. & .. &
> that we currently have. Though how are are we passing around these
> view variables? Via a session?
It is pretty ugly, isn't it?
view.php?feed=&what=new&when=&howmany=&how=&category=2&tag=&view=normal&order=asc&search=

With as many parameters as we use, some of them being mutually 
exclusive.  I have a hard time seeing how routes can fill this need.  I 
think our options are either session variables, or stick with query 
parameters.

With session variables the URI does not contain all the context needed 
to generate the view. That breaks external linking, if anyone should 
want to do that.  So we fall back to query parameters.  It's ugly,  It's 
not RESTful, but it works.

> And I think the views will be very similar to the rhtml files of Ruby.
> Simple calls in the HTML to PHP commands.
In Dan's implementation, the view page is loaded/executed from a method 
on the controller.  It has access to _$this_ as the controller object, 
so it can retrieve parameters or run methods on the controller.   I 
would prefer a little more separation here, but it's okay for now.  
We'll just have to keep an eye on the view and make sure they're not 
doing anything they're not supposed to do.

-Kevin

Re: [Fofredux-devel] Re: MVC rethought

[Dan T. <da...@an...>]

> In Dan's implementation, the view page is loaded/executed from a method
> on the controller.  It has access to _$this_ as the controller object,
> so it can retrieve parameters or run methods on the controller.   I
> would prefer a little more separation here, but it's okay for now.
> We'll just have to keep an eye on the view and make sure they're not
> doing anything they're not supposed to do.

As it is php you always can do everything you want in the view...

Anyway Im doing the view implementation a bit different where it
should be a bit more incapsulated... :)

Re: [Fofredux-devel] Re: MVC rethought

[Evan R. <eva...@gm...>]

hey guys, i get the feeling we are going in the right direction
here...perhaps even a bit over-doinging it, but if it's good, then why
not.

Personally, i'm not a fan of the url rewrite style...but i know i'm in
the minority there, so if you guys go for it, then i can play along.=20
i prefer my querystring with a few items that are changeable...whereas
we really don't have so much....and if you are still going to be
working in the frameset (which it looks like is included in our UI
redo), you won't really see the url much anyway...so it's ok for the
user.  but i really don't care...it's not a battle worth fighting for
me.

what could become more of an issue, is perhaps php4 vs php5, as we've
seen with the class structure and so on.  if we want to do something
OO in php, we might want to think about moving completely to php5,
since 4 is not considered real OO.  and it'd make our implementation a
bit easier to do once correctly.
but in doing so, we don't want to lose any users.  i've been on php5
for a long time now, but i can't talk for anyone else.  would it be
possible to take this step, or is it too early for something like
that?

in other news, i'll try to fix that bug in my php4 incompatible
options class tonight, but then i'll need to take some time off.  i've
got some urgent issues to take care of outside of the project.=20
hopefully i can be back up and running in a week, in time to start
implementing khaled's design.  but i still am available to mail, since
i can do that from work.

/evan

On 5/2/06, Kevin <ke...@dr...> wrote:
> Dan Thrue wrote:
> > Hi Kevin,
> >
> > I have put some examples up on rendering other views, executing other
> > action, and howto redirect... Its in an updated tarball on the same
> > location /vc.tar :)
> >
> > Regarding routing it was to control parameters and url layout... In
> > rails you do something like:
> >
> >  map.connect 'profiles/:username', :controller =3D> 'profile', :action
> > =3D> 'view'
> >
> > I could easily implement something similar, as I've said in my two
> > earlier posts, this is just coded as proof-of-concept but it should be
> > fairly easy to make it fully usable...
> >
> Thanks.  I also found this URL which covered it pretty well.
> http://manuals.rubyonrails.com/read/chapter/65
>
> Routes look pretty cool, but I don't think we need them right now.   We
> should be able to cover all of our actions/views by using the default
> '<controller>/<action>/<paremeters>' URI format.
>
> The redirect examples were helpful.  It just goes to show how easy it is
> to extend.    You added one method to the base controller, and now
> there's a simple/flexible way of redirecting between pages.
>
> I like it.  It's simple and easy to follow, yet pretty powerful.  It's
> based on rails, which a few of you already have experience with. I'll
> try and converting one of our pages to it and see how it goes.
>
> -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
>

Re: [Fofredux-devel] Re: MVC rethought

[Kevin <ke...@dr...>]

Evan said:
> what could become more of an issue, is perhaps php4 vs php5, as we've
> seen with the class structure and so on.  if we want to do something
> OO in php, we might want to think about moving completely to php5,
> since 4 is not considered real OO.  and it'd make our implementation a
> bit easier to do once correctly.
> but in doing so, we don't want to lose any users.  i've been on php5
> for a long time now, but i can't talk for anyone else.  would it be
> possible to take this step, or is it too early for something like
> that?

I've done quite a bit of OO using php4.  It's not as full featured as
php5, but I wouldn't go as far to say it is "not real OO".  For things
it's doesn't do natively, there are decent workarounds. (ex: use a GLOBAL
in place of a static member, etc)

php4 is still widely used, and I think we should support it if it's not a
burden.


--=20
Kevin