[geeklog-devel] Geeklog Topics and Blocks

Mon Aug 22 20:40:31 EDT 2011

You covered most of my points but I hadn't thought of 5, 6 and 9.

5. I would probably leave this as a feed for articles only and not other
types since clicking on a topic  itself would still only display articles.

6. Handling of featured topic articles. I guess the first question would be
is should an article be allowed to be featured for only one topic or many
topics. If it is many then either we will need a new table or I will have to
add a column to topic_assignments

Tom

From: geeklog-devel-bounces at lists.geeklog.net
[mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Vincent Furia
Sent: August-22-11 5:06 PM
To: Geeklog Development
Subject: Re: [geeklog-devel] Geeklog Topics and Blocks

First the easy part. Defining the tables:

1.	Remove 'tid' from the story table.
2.	Create a new table "topic_assignments". It should have columns
"type" varchar(30), "sid" varchar(40), and "tid" varchar(20). It's primary
key should be on "tid" and with a INDEX on "type" and "sid" (this key could
also just be on sid).
3.	The topics table is sufficient as is, though that depends on the
full set of features you want to change.

The underlying code changes get complicated. Here is what I recall looking
at originally, though I'm sure there is more that will have to be modified
to incorporate the changes. Since you're implementation allows a single
article (or other item) to be belong to multiple topics, you're changes are
going to be more extensive than what I had looked at. At a minimum you're
going to want to look at lib-common.php, article.php,  and lib-security.php.

1.	COM_siteHeader may need some mods to recognize when you are looking
at plugin/block/etc that is associated with a specific topic. Also,
COM_siteFooter.
2.	COM_showBlocks will have to be modified to handle a topic array as
well as a single topic. Most calling functions to COM_showBlocks functions
will also need to be modified to handle multiple topics.
3.	COM_topicArray will have to understand the new underlying database
structure.
4.	SEC_hasTopicAccess probably doesn't need to change, but keep an eye
on it.
5.	COM_rdfUpToDateCheck will need to be expanded to handle topic feed
updates for non-article types.
6.	COM_featuredCheck assumes tid will be in the article table. You'll
also have to figure out how you want to handle featured article flag on
stories with multiple topics, this could get really confusing if not taken
into account at the start.
7.	COM_adminMenu will need to handle topic assignments. Again, it
assumes tid in the article table.
8.	Everywhere COM_getTopicSQL is called will need to be rethought (and
the function itself will probably go away). That code currently generates an
"IN" clause against the tid in the article table. All queries that use it
will have to do a double join to the topics table and topic_assignments
table. I imagine this is where A LOT of the work for this project will be
invested.
9.	COM_emailUserTopics will need some mods since you don't want the
informational email to repeat articles. Also, you might want to add a plugin
API for plugin items be included in topic emails.
10.	Obviously a new interface will be required to submit/administer
articles with multiple topics. Some generic functions here will make it easy
to add topic support to other plugins.
11.	Webservices may be impacted, though I haven't looked at that code at
all to even make an educated guess as to how much (or even if they would be
impacted).
12.	I think story.class.php will require extensive modifications, though
it didn't exist when I first looked into modifying topics. I'm sure my notes
on article.php are useless for the same reason...

That should get you started. It's a pretty big undertaking. You might want
to reconsider implementing subtopics, with all the work needed already the
extra cost wouldn't be great (though I do understand your desire to limit
the scope at least a little bit).

It's a shame we didn't do GSOC this year, this probably would have made a
great project for a summer intern...

-Vinny

On Mon, Aug 22, 2011 at 07:28, Tom <websitemaster at cogeco.net> wrote:

>Any change that modified the database would require quite a bit of work (as
my suggestion in the first paragraph would). If you end up going with any of
these ideas, I had >thought out quite a bit more detail if you want it.

Sure. J

From: geeklog-devel-bounces at lists.geeklog.net
[mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Vincent Furia
Sent: August-21-11 7:20 PM
To: Geeklog Development
Subject: Re: [geeklog-devel] Geeklog Topics and Blocks

I had done some thinking on this several years ago. The most flexible design
I came up with is using "tag" style backend. Instead of having tid's
associated with stories, there would be topic_assignments (or some better
named...) table allowing a many-to-many relationship between stories (or
blocks, or plugins, etc) and topics.

I went so far as to also consider how to handle sub-topics. Easy way: you
could define topic relationships by having a topic separator (e.g. "-" or
"/") in the topic name. Hard way: create a hierarchal data structure in the
database (parent child relationship, or tree representation similar to how
comments are not handled). The latter design would allow more flexibility,
though the former would be significantly less work to implement.

Any change that modified the database would require quite a bit of work (as
my suggestion in the first paragraph would). If you end up going with any of
these ideas, I had thought out quite a bit more detail if you want it.

-Vinny

On Sun, Aug 21, 2011 at 14:31, Tom <websitemaster at cogeco.net> wrote:

I have started to do a bit of research/work on my feature request about
allowing topics to be associated with other objects like staticpages, etc.

http://project.geeklog.net/tracking/view.php?id=1155

I was also thinking about (I haven't decided to tackle it yet):

- Allowing blocks to be assigned to one or more topics and not just one or
all.
- Allowing stories (and other objects)  to be assigned to one or more
topics.

Does anyone have any thoughts or opinions...

Tom

_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://eight.pairlist.net/mailman/listinfo/geeklog-devel

_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://eight.pairlist.net/mailman/listinfo/geeklog-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20110822/bea85ab7/attachment.html>