[geeklog-devel] Geeklog Topics and Blocks
Vincent Furia
vfuria at gmail.com
Mon Aug 22 17:05:39 EDT 2011
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/8b3545db/attachment.html>
More information about the geeklog-devel
mailing list