Feature proposal #7535
closed
Improve support for passing Target and Object variables around streams
Description
Currently this is parsed out of the asset on demand, which is fine and works, but we need a means of setting these as part of the stream cache when the stream object is first created. This way child streams know who the target is or the object. Currently this is done as follows.
Parent: groupjive.group.10
Activity: 1
This for example is a comment stream of the activity entry with the ID of 1, which has an asset of groupjive.group.10. Ideally you'd just have the following.
Target: GROUP_OBJECT
Object: ACTIVITY_OBJECT
The plan originally was to store these IDs, but they already exists as part of the asset so it's not necessary, but on DISPLAY handling it would be useful to be able to pass around and access these objects.
Updated by krileon about 5 years ago
- Subject changed from Better improve support for passing Target and Object variables around streams to Improve support for passing Target and Object variables around streams
Assets probably should be more strictly enforced as well. For example a comment on an activity entry is typically stored as "activity.ACTIVITY_ID", but it should probably be something like "activity_asset.activity.ACTIVITY_ID". Example as follows
profile.PROFILE_ID.activity.ACTIVITY_ID
This would mean the comment is on the stream profile.PROFILE_ID for activity.ACTIVITY_ID. We'd always know the parent. So for example a comment on a GJ activity entry would have the below asset.
groupjive.group.GROUP_ID.activity.ACTIVITY_ID
This structure is already being used for integrations like the following.
groupjive.group.GROUP_ID.gallery.photos.PHOTO_ID
In short the asset usage is not being consistent enough and it needs to enforce this. The asset is supposed to determine what we are and where we are so needs significant thought on how to improve all of this.
Updated by krileon almost 5 years ago
Object is also called Source and is retrieved with getSource. Maybe it would be better to just serialize the Object and store it with the activity entry? This could result in significantly increasing the storage requirements for the data for little gain. Regardless the function should be renamed to getObject or getSource should also prepare $object and $target. Maybe also add a getTarget.
Updated by krileon almost 5 years ago
- Related to Feature proposal #7444: Improve core activity parsing for comment replies added
Updated by krileon almost 5 years ago
- Target version changed from 6.0.0 to 5.0.0
Updated by krileon almost 5 years ago
This basically is to try and make nested streams consistent. If a stream is within a stream it stands to reason its stored rows should reference that. Example as follows.
Standalone Stream: article.42
Embedded Stream: activity.101
With the above the standalone stream is a comment stream for a Joomla article. The embedded stream is a comment stream for an activity entry of an activity stream. This means the embedded entry should ALWAYS prefix its asset. For a profile stream this would mean it would become profile.42.activity.101. If this is maintained throughout ALL usages then the consistency should allow for easily referencing access checks and permissions. Example with CB GroupJive:
CB Gallery: groupjive.group.10
CB Gallery Comments: groupjive.group.10.gallery.photos.30
In short we're treating CB Gallery as streams as well. Basically anything with an Asset should be treated as such. There should be no issues with migrating existing entries as well since we just need to convert activity.%, gallery.%, etc.. to grab their rows asset.
Updated by krileon almost 5 years ago
To avoid massive migration queries simply output multiple assets in the streams for B/C. So for example it should become the following.
ROW_ASSET.comment.COMMENT_ID,comment.COMMENT_ID
The primary asset is the first one, but the previously used asset will still be maintained allowing existing entries to display and work as expected but new ones will be stored properly with the new asset.
Updated by krileon almost 5 years ago
Migration won't be necessary. The direct assets can still be displayed and likely makes sense. The queries have been improved to guarantee index usage when more than 1 asset is supplied, which completely eliminates the performance issues.
Updated by krileon almost 5 years ago
Prefixing the assets so much is starting to negatively bloat them. There needs to be a better way to keep track of this. Currently 'parent' is set for the Stream, which indicates the stream is a child of another stream. This might be entirely sufficient and need no further additions. One option is to pass this 'parent' value to storage in a new Target column.
Example of a prefix nightmare: profile.42.comment.12.comment.13
This would be a comment (reply) to a comment on a post on profile 42. The path makes sense, but this just doesn't bring any benefit. You can parse all of that out by working backwards through objects.
With that said the display and source parsing code all needs improved to accept these scenarios. So for example the ^activity.ACTIVITY_ID parsing needs to accept that there could be pathing before it. This would allow handling prefixed scenarios perfectly fine. This usage is already implemented in and working for CB Gallery.
Updated by krileon almost 5 years ago
Parent asset is now just officially a part of the Stream API (e.g. getParentAsset). Parent = Target and Asset = Object. No need to rename everything either. Parent is NOT stored. There's not much reason to do so. If the parent is needed for SQL or other parsing behavior outside of PHP control just prefix it to Asset. This may change at a later time with Parent being stored in the database, but for now it's entirely unnecessary.
Updated by krileon almost 5 years ago
- Status changed from Assigned to Resolved
- % Done changed from 30 to 100