All posts in the topic SBMicroContent or Image/Video (Short link)
Summary
- There are 4 posts — by 3 authors — in this topic.
- Latest post made by Phillip Pearson at 2007 Nov 01 07:13 UTC
I am wondering why if I upload an jpeg from the page
post_content.php?sb_mc_type=media/image page it is stored as a Content item
with the type SBMicrocontent, but if I upload a jpeg from the page
upload_media.php?type=Images it is stored as a Content item with the type
Image.
In other words, when I upload an image as a blog post it is stored as
SBMicroContnet but when I do so to a gallery it is stores as an Image.
I think I may be missing it, but I don't see how to access the file path when
an item is stored as SBMicroContent short of parsing the html in the body.
I am also very curious about whether one of these methods is going to be
favored in People Aggregator development going forward?
Curious and wondering
Hi Jerry,
sbmicrocontent is special type of content. This was developed to support
different type of micro contents. If you use upload_media page then it
is type image content. In sbmicrocontent we store the whole xml schema.
thanks,
Arvind
jerry palmisano wrote:
> I am wondering why if I upload an jpeg from the page
post_content.php?sb_mc_type=media/image page it is stored as a Content item
with the type SBMicrocontent, but if I upload a jpeg from the page
upload_media.php?type=Images it is stored as a Content item with the type
Image.
>
> In other words, when I upload an image as a blog post it is stored as
SBMicroContnet but when I do so to a gallery it is stores as an Image.
>
> I think I may be missing it, but I don't see how to access the file path when
an item is stored as SBMicroContent short of parsing the html in the body.
>
> I am also very curious about whether one of these methods is going to be
favored in People Aggregator development going forward?
Hi Arvind,
Thanks for you quick reply. I have figured out how to create content items of
the different types (upload_media.php vs. post_contnet.php) What I am wondering
is why the properties (for instance, the file name) are only accessible to
SBMicrocontent items by parsing the xml that is stored in the DB. And, is this
a direction that People Aggregator is going to continue toward? That is,
storing images as two different types of content depending on where they are
introduced to the system from? Please be as technical in your answer as you
can - see the final paragraph of this email to see the areas of the application
that I have explored before posting to the group (I think I have covered all
the bases! :-).
My problem is that I would like to retrieve an item of the SBMicrocontent type,
check that it's sbmicrocontent_type is media/video (for example), and then be
able to access the video resource through the SBMicrocontent class.
For example,
$content_item = new SBMicrocontent()->load(42);
$file_path = $content_item->getContentFileResource();
This way I can decide how I would like to embed the video based on the context
in which it is being viewed.
I have figured out that uploading an image to the gallery creates a content
item with the type image (through upload_media.php) and that uploading an image
as a blog post stores it as a content item with the type sbmicrocontent. I have
explored the database and am aware of the content_types table and the
sbmicrocontent_types table. I have seen the
MicroContent->PAMicroContnet->SBMicroContnet classes and have explored the xml
files in MCdescriptions regarding the creation of the XML that is stored in the
DB via XPath and the various classes in mc_renderers.php.
thanks for your help!
Hi Jerry,
The quick answer here is that we're going to simplify things at some
point, so that there'll only be one way of doing each thing.
I hope we'll be able to do this in a fairly backward compatible way.
I've got some half baked code that does the following:
- gets rid of the images, audios, videos tables and moves the file and
perm info into the contents table (contents.media_file and
contents.perm, I think).
- gets rid of contents.display_on and contents.collection_id and adds a
new content_links table that links content to collections (so you can
cross post without having to duplicate the content, and so user blogs,
group blogs and network blogs behave the same internally).
Planned after that is:
- move the Structured Blogging microcontent type field right into the
contents table so you don't need to join on two tables to find it.
- for images/audio/videos that have been stored as SBMicroContent, parse
out the filename and store it in the expected place
(contents.media_file), and also set the relevant type so it looks the
same as
At this point you should be able to forget about the difference for
media files at least, as whatever way you upload, you'll end up with the
same data in contents.type and contents.media_file :)
This is still a way off -- hoping to get it done by the end of the year
though.
For the moment, if you have some media that's been uploaded and stored
as SBMicroContent, the only way to get the filename is unfortunately to
pull out the XML chunk and parse it out of there. At least we have
XPath... the code boils down to something like this (which I haven't
checked so probably won't execute, but should give you an idea of how to
do it):
$dom = new DOMDocument;
$dom->loadXml($xmlString);
$xp = new DOMXPath($dom);
$filename = $xp->query("/micro-content/media/@title")->item(0)->nodeValue;
I think it's a bit harder than that, but if you grep for DOMXPath in the
code there'll be more clues!
(If you want to implement this as a method on SBMicroContent, that would
be cool. Let me know if you need a hand with anything, and of course
we're happy to merge stuff like this back into the core code - then
perhaps we could leave the method there later on once things change on
the backend...)
Cheers,
Phil
jerry palmisano wrote:
> Hi Arvind,
>
> Thanks for you quick reply. I have figured out how to create content items of
the different types (upload_media.php vs. post_contnet.php) What I am wondering
is why the properties (for instance, the file name) are only accessible to
SBMicrocontent items by parsing the xml that is stored in the DB. And, is this
a direction that People Aggregator is going to continue toward? That is,
storing images as two different types of content depending on where they are
introduced to the system from? Please be as technical in your answer as you
can - see the final paragraph of this email to see the areas of the application
that I have explored before posting to the group (I think I have covered all
the bases! :-).
>
> My problem is that I would like to retrieve an item of the SBMicrocontent
type, check that it's sbmicrocontent_type is media/video (for example), and
then be able to access the video resource through the SBMicrocontent class.
>
> For example,
>
> $content_item = new SBMicrocontent()->load(42);
> $file_path = $content_item->getContentFileResource();
>
> This way I can decide how I would like to embed the video based on the
context in which it is being viewed.
>
> I have figured out that uploading an image to the gallery creates a content
item with the type image (through upload_media.php) and that uploading an image
as a blog post stores it as a content item with the type sbmicrocontent. I have
explored the database and am aware of the content_types table and the
sbmicrocontent_types table. I have seen the
MicroContent->PAMicroContnet->SBMicroContnet classes and have explored the xml
files in MCdescriptions regarding the creation of the XML that is stored in the
DB via XPath and the various classes in mc_renderers.php.