[Hippo-cms7-user] associating a binary file with a document
a.schrijvers at onehippo.com
Mon Aug 17 18:13:49 CEST 2009
On Mon, Aug 17, 2009 at 5:46 PM, Gerritb<gerritberkouwer at gmail.com> wrote:
> Good stuff to think about Ard, I see what you mean. lets see how stuff
> develops, I'm sure this subject will pop up some day some where :-)...
Ah, another brain training example(I actually recall this design
usecase from Berry a long time ago, so not my brilliant idea):
Suppose you have multiple languages as variants in a handle. Now, you
would like to link to a pdf from every language. You make a links to
the handle (umbrella container node) of the pdfs. As we have mirrors
with filters, these links are actually mirrors. Now, we have multiple
modes to the mirrors, *and* mirrors inherit the filter from a parent.
With this background info, you can see that we can build (actually,
you only need the make the mirrors) the following logic:
All my different languages documents, link to the same umbrella node
for the pdf, where, some languages have a custom pdf. So, there would
just be a pdf with a property: language=nl.
Through the dutch preview /live environment, we would get a filter,
returning the dutch linked pdf. So, all documents link to the same pdf
umbrella, but get the one in their language (context). It gets better:
I told you that filters can be configured. So, we can say: my document
is in the language=nl, so, look for the pdf with language=nl property,
but, if none found, look for a pdf without a language property: this
clearly would be the default pdf, that everybody gets, if it is not
This is really powerful, it is entirely exposed over jcr, and is
something I really like. As mentioned, to be sure, this idea, logic
and implementation is not born in my head. I am quite sure our sales
people don't even know we can do this :-)))
> Ard wrote:
>> Hello Gerrit,
>>> Ard, indeed, *if* workflow is supported on binaries I see your preference
>>> I would probably agree! :-).
>>> Then the use-case would be:
>>> - upload a binary, with it's meta-data (eg. title, publication-date,
>>> introduction text, body-text)
>>> - show this binary-hippo-document as a webpage: a page with some of the
>>> meta-data as text, and a link to the binary itself
>>> So to be honest that would mean that storing binaries in Documents would
>>> be necessary anymore...
>> This depends. We see a binary as a document, not only for meta data.
>> You are thinking now primarily about pfds / word etc. But, what about
>> images? I consider them binary. Would you consider the thumbnail,
>> 100x100, 200x200 and the normal size of one and the same image
>> uncorrelated? If so, you store them just as binaries. If you do think
>> they are related, just as I do namely, then, I would create a Document
>> (ImageSet = a hippo document), containing all these variants.
>> Other content documents, might now have a link to this document, and
>> the frontend application, decides whether to show the thumbnail, the
>> 100x100, or the normal size.
>> In case of a pdf, this might be a less obvious usecase. You might add
>> 2 pdf's to the same Document, and let the frontend resolve to 1 pdf
>> for logged in users, and to the other for non logged in users.
>> Furthermore, one other reason for it being documents, if you are not
>> yet convinced, is that we base versioning on Documents, not on
>> binaries. If you want to go back to an earlier version, the model
>> supports this on documents.
>> So, I am still pretty convinced of the model we use, but I also think
>> your model (the binaries in normal documents) is an excellent
>> usecase...as Chad also likes to use it in this way
>> Regards Ard
>>> Ard wrote:
>>>> If however you're usecase is less rigid, *and* we support workflow
>>>> (preview/live) on binaries, then, my preference would still be to
>>>> store pdf's in the assets folder. Then, this document in the asset
>>>> folder might contain next to the binary also other (meta)-information,
>>>> as it is just a document.
>>>> The reason for this is efficiency. Storing a binary once, and link to
>>>> it, will never trigger the re-storing of the binary, and having more
>>>> impact, the re-indexation. Fortunately, we are using the DataStore
>>>> from jackrabbit by default, making sure that a binary is stored with
>>>> some hash, making sure not every doc containing the same binary stores
>>>> it again. This however is not possible for indexing. Every document
>>>> that has some pdf, will during storing extract and index the pdf. For
>>>> large pdf's, this can become quite cpu & memory intensive (poi, tika,
>>>> lucene). Now, in your preferred model, a pdf would be stored in the
>>>> draft, preview & live. Every time the document is saved, the indexing
>>>> runs. When you start editing, as second version of the pdf is created
>>>> as draft, which triggers indexing.
>>>> So, I do agree on your usecase, and bottom line, it will perform fine
>>>> enough (unless your pdf's become really large), but I did want to
>>>> explain *why* we by default opt for the, perhaps in your eyes, less
>>>> logical solution. The reason is efficiency.
>>>> Anyways, you're usecase, will be made available out-of-the-box through
>>>> the cms and through the HST2. Stay tuned,
>>>> Regards Ard
>>>> Hippo-cms7-user mailing list and forums
>>> Greetz, Gerrit
>>> View this message in context:
>>> Sent from the Getting Started mailing list archive at Nabble.com.
>>> Hippo-cms7-user mailing list and forums
> Greetz, Gerrit
> View this message in context: http://n2.nabble.com/associating-a-binary-file-with-a-document-tp3441313p3459932.html
> Sent from the Getting Started mailing list archive at Nabble.com.
> Hippo-cms7-user mailing list and forums
More information about the Hippo-cms7-user