Umbilical cords mod

[gri]

Winding to

** http://grivit.tk/index.php?topic=Umbilical_cords_mod.msg1096#msg1096

In most cases
the nearest maternal parent post can be Guessed
when a child post is being born to public
directly where the child post germ has been conceived..
regardless of the number of the fatherly posts.

But sometimes the fruit is beared long
and appears far from the expected place
unlike the apple falled usually under its parent apple-tree.

Unfortunately smf developers
have chose not to preserve the umbilical cords.
Interesting, do they themselves have the navels at all.
If not, then it could be another reason of general smf predicament..

Grivitoutik to and grivitinik from
can be imagined as the edges of the umbilical cord relation vector
between the maternal post and its child post.

Grivitinik in the global quote header
in the child post
is the secondary reflection
of the grivitinik edge of the umbilical cord.
But the primary grivitinik should have been saved by default
when it is easily possible -
regardless of the replier's choice not to implement quoting.


For example,
if a human wanted to continue the discussion
about the evidence of the necessity
of the umbilical cords between the related posts -

he could produce only such Grivitinik from (in his child post)
(instead of relying on global quote of the maternal parent post) :
.. http://www.simplemachines.org/community/index.php?msg=313653 .


Or he could also add the grivitinik from any fatherly post :
.. http://www.simplemachines.org/community/index.php?msg=2007796 .


After the grivitiniks appearence -
a list of corresponding grivitoutiks could be produced and displayed.

And any Apple could freely choose
whose Head on the Earth to fall on..
grivitationally.

[Cookie]

You're a human.

[gri]

Additionally, I have never had any use, whatsoever for Gri's form of "tracking"...
and I don't see any use for it here, either.
Post/response tagging would be more useful than a tree view, IMO
(and I hate tagging as well, so that lets you know where tree-view sits, LOL)

Not sure why you're bringing up Gri in re:
Gri is off topic.

Default SMF has no even a database table column
for saving the info about the Parent posts.

An issue of operating and displaying of Parents' details
                            beside the Child posts -
is Secondary, relatively to the Care about Live Parents.

Humans understand what is a Milky Way -
beginning with the Mother's Milk, hunger Feeling..
      the indissoluble Attachment and Dependence.

It is relatively hard (impossible)
to pretent on Human Logic Carrier
declaring that Mother is offtopic
while Her child is still ontopic.

Do not be surprised that SMF developers' Memory
keep Gri as the Mother of Grivitational Future of SMF.
  Well, as the Father, along His Milky Way.

The basis for preserving the Umbilical cords
                            between the related posts
could be organised exactly at the moments of posting
                  of a Quick Reply from the definite Parent post.

I would fight against having this as a "feature"...
but if you want to release it as a mod, feel free.
That's why SMF has the whole mod section.

And that's why the banned Humans
should be armed by all Grivitational Weapons.

[Daddy]

Prepare for war on the monkeys

Also, actually adding a parent_id column and a link to the parent post wouldn't be too bad

[Clara Listensprechen]

Prepare for war on the monkeys

Also, actually adding a parent_id column and a link to the parent post wouldn't be too bad

This is the sort of arrangement I was looking for:



...I got lucky today and found a cache of one of the boards on the old PBS Discussions board. wOOt!!

The boardware was designed by DCScripts.com, which is now out of business. Whomever comes up with this level of functionality gets my business...which is something not considered by people designing stuff for free use. That they insult a person who would PAY for such a thing totally escapes these morons.  Er...monkeys.  I have now come 'round to agreeing with Gri's characterization of the monkeys.

[Daddy]

I suck at theme creation but that could essentially be done by changing the "reply" button each post to capture the message ID and save it to a newly created parent_id column and then create a theme where Display.template.php sorts things with different parent_ids in their own divs.

I'm terrible at theme creation though.

[?????]

I suck at theme creation but that could essentially be done by changing the "reply" button each post to capture the message ID and save it to a newly created parent_id column and then create a theme where Display.template.php sorts things with different parent_ids in their own divs.

I'm terrible at theme creation though.

I don't think that'd be a very efficient database, because it would first have to go to the topic, then the specific post that is being replied to. It would become worse with added levels/nodes.

[Daddy]

I don't think that'd be a very efficient database, because it would first have to go to the topic, then the specific post that is being replied to. It would become worse with added levels/nodes.

Yeah, it would create a drag on the database because rather than doing something like

Code Select

SELECT * from smf_messages WHERE id_topic like n ORDER BY msg_id where you do one query you'd have to do:

Code Select

SELECT * from smf_messages WHERE id_topic like n ORDER BY msg_id
Save as a result and include a loop that does

Code Select

SELECT * from `$result` WHERE parent_id like $context[`msg_id`] ORDER BY msg_id so the number of queries grows very quickly with each level of threading.

Easy to implement but slow on creation. The actual queries may be incorrect but the idea of what would be needed is similar.

[Clara Listensprechen]

I suck at theme creation but that could essentially be done by changing the "reply" button each post to capture the message ID and save it to a newly created parent_id column and then create a theme where Display.template.php sorts things with different parent_ids in their own divs.

I'm terrible at theme creation though.

In fiddling with SMF code, the first thing I fiddled with was the theme. I could pitch in that part.

[Clara Listensprechen]

I don't think that'd be a very efficient database, because it would first have to go to the topic, then the specific post that is being replied to. It would become worse with added levels/nodes.

If I'm not worried about that, you shouldn't be.

Now then--is there a manner in which a limit could be put on the size of a thread, and by which a new (related) thread can be "forced"? One of the problems on the PBS board is that multiple Topics on the same subject was posted by different people, so thread mergers under limits...oh hell, one objective at a time. Nevermind. Achieving Stage One in working condition before considering Stage Two and beyond. How 'bout lets' just damn the db torpedos and get something operational **as a starting point**

[?????]

If I'm not worried about that, you shouldn't be.

Now then--is there a manner in which a limit could be put on the size of a thread, and by which a new (related) thread can be "forced"?

You could place a maximum nesting level, but that would sort of defeat the purpose wouldn't it? I don't understand why you would want to use stuff from the '90s on your board.

Yeah, it would create a drag on the database because rather than doing something like

Code Select

SELECT * from smf_messages WHERE id_topic like n ORDER BY msg_id where you do one query you'd have to do:

Code Select

SELECT * from smf_messages WHERE id_topic like n ORDER BY msg_id
Save as a result and include a loop that does

Code Select

SELECT * from `$result` WHERE parent_id like $context[`msg_id`] ORDER BY msg_id so the number of queries grows very quickly with each level of threading.

Easy to implement but slow on creation. The actual queries may be incorrect but the idea of what would be needed is similar.

You'd need more than that. You'd have to check what level you are replying at first, and whether or not you're creating a new level or just a simple reply.

Not worth the effort.

[Daddy]

The level checking can be done by viewing the id of the parent message and adding a reply link to each post.

So you' have like

id_msg 100, id_parent 0 (root of topic)
-id_msg 101, id_parent 100
--id_msg_103, id_parent 101
--id_msg 106, id_parent 101
-id_msg 104, id_parent 100
--id_msg 500, id_parent 104
---id_msg 501, id_parent 500

Not sure how it'd grow mathematically but each level would take longer to generate than any previous level, so it'd slow to a crawl after a while.

[Clara Listensprechen]

For the record, the PBS Discussions board did experience slow loading, but that was a periodic thing for some reason. However, at this point, "paralysis by analysis" should be treated as an enemy to crossing one bridge at a time. That's a bridge we'll cross when we get to it, seems to me. Even God couldn't create the universe in a single day--it took time to develop.

[Daddy]

If you wish to make an apple pie from scratch.

[Clara Listensprechen]

You could place a maximum nesting level, but that would sort of defeat the purpose wouldn't it? I don't understand why you would want to use stuff from the '90s on your board.

Your grandma goes back to the '90's too, so how 'bout throw HER out. Levers were invented in prehistoric times and we still use them because they are...well...USEFUL. If you don't have a use for screws, screwdrivers, wheels or your grandma, I'm not going to force *you* to keep 'em. I tend to speak for myself and not other people, and I know what I want. K?

You'd need more than that. You'd have to check what level you are replying at first, and whether or not you're creating a new level or just a simple reply.

Not worth the effort.

I'll be the one to decide what's worth MY effort, thank you. I just ask for a helping hand from some kind hearted gentleman who knows more about coding than I do is all, and if you're trying to hinder, then please step aside and out of the way. Thank you.