[geeklog-devel] Geeklog Topics and Blocks

Vincent Furia vfuria at gmail.com
Fri Sep 9 03:56:45 EDT 2011 

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/20110909/e7774177/attachment.html>

More information about the geeklog-devel mailing list