[pLog-svn] r2091 - plog/branches/plog-1.1-ben/class/dao

[Oscar Renalias]

On 5/30/05, Benjamin Krause <ork at orkland.de> wrote:
> Oscar Renalias wrote:
> 
> > On second thoughts, we really need all the parameters.
> > ViewArticleActions uses them all at some point, take a look...
> 
> you're right.. i see that these parameters are passed. are you sure all
> of these parameters are really used?
> i see the status and the hiddenFields are not important, date, category
> and userId are preset with -1, but might be added to the request.
> 
> i guess categoryId is important, maybe we should add a
> getBlogArticlesByCategory()
> 
> i guess date is important as well, maybe we should add a
> getBlogArticlesByDate()
> 
> if both are present, we might add a getBlogArticlesByDateAndCategory()
> 
> i know it is nice to have one mighty method to handle all sort of
> requests, but i prefer small methods that are maintainable.

Regarding this one huge method, I didn't see any other option because
there are many different possible combinations of parameters. You
created a getBlogArticlesByCategory, getBlogArticlesByDate,
getBlogArticlesByDateAndCategory and so on, but how about a
getBlogArticlesByDateAndCategoryAndStatusAndUser? Or a
getBlogArticlesByDateAndUser? If you for example look at the
administration page, under "edit posts", you will see that you've got
plenty of filters... If we need a method for each one of those, we
could go mental :)))

Plus, somewhere in this discusison we forgot the fact that we were
talking about Articles::getBlogArticle and not
Articles::getBlogArtcles() :) -->

"as far as i see this, getBlogArticle will just be called with an id,
so we do not need to have that many parameters here."

So going back to getBlogArticle, we need at least the $status parameter...

> on the other hand we might want to include another cache only object
> like blogArticles, that will fetch all articles of a blog and sort them
> by some criteria like category and date. instead of fetching articles
> via Articles()->getBlogArticles() (which will do the db stuff), we might
> fetch them via BlogArticles->getArticles(), and this method will decide
> whether to look in the cache or to ask the db.
> 
> i've already done this for BlogLinks, instead of selecting all type of
> links from the db, i've added this class as a preparsed collection of
> all links of a blog. like some sort of search-index :)
> 
> we might want to implement something like that as well for BlogArticles,
> e.g. having just some arrays mapping categories and dates to articleIds.

This is where I get lost :( What would BlogArticles do? What is the
advantage for us? Why don't we build the caching logic in Articles as
you've done so far with all the other db-accessor classes?

I have to admit that I haven't looked at BlogLinks yet, sorry, so I
might be missing something obvious here...

Oscar