[geeklog-devel] Geeklog Topics and Blocks

Sat Sep 10 08:24:40 EDT 2011

Currently for a block it sticks "all" or "homeonly" in the tid if the block
is to display for all topics or for a homepage only. (There actually is a
small bug here since you can create topics with the same ids)

For the new topic assignments table, what would be considered "better"
practice. Coding it similar to above and restricting the use of topic ids or
adding an extra column or two to the table?

Tom

From: geeklog-devel-bounces at lists.geeklog.net
[mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Tom
Sent: September-09-11 9:22 AM
To: 'Geeklog Development'
Subject: Re: [geeklog-devel] Geeklog Topics and Blocks

Right, I see what you mean. 

For me I see the user being able to only view one topic at a time, therefore
if a story belong to multiple topics it would have multiple views (depending
on which topic the user is currently in). I guess doing it this way though
would require a story to have a default topic. This topic would be used if
the story was the first page the user visited when going to the website.

Doing it this way also makes more sense for when I hope to eventually allow
topics to have their own themes.

Does this sound good to everyone?

Tom

From: geeklog-devel-bounces at lists.geeklog.net
[mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Vincent Furia
Sent: September-09-11 3:57 AM
To: Geeklog Development
Subject: Re: [geeklog-devel] Geeklog Topics and Blocks

I believe the use case I was thinking of is when viewing a single
story/article that is a member of several topics.

On Thu, Sep 8, 2011 at 19:27, Tom <websitemaster at cogeco.net> wrote:

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

Hey Vinny,

Why are you saying here that most calling functions to COM_showBlocks needs
to handle multiple topics? The user will still be only viewing one topic at
a time so only one topic will still need to be passed into the function. I
will just have to update the function to take into account the new
topic_assiginments table and the fact that blocks can appear in 1 or more
topics.

Tom

From: geeklog-devel-bounces at lists.geeklog.net
[mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Tom
Sent: August-22-11 8:41 PM

To: 'Geeklog Development'
Subject: Re: [geeklog-devel] Geeklog Topics and Blocks

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

_______________________________________________
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/20110910/90d61a3e/attachment.html>