[Hippo-cms7-user] Identifying same-name child-nodes of a document

Ard Schrijvers a.schrijvers at onehippo.com
Wed Dec 5 14:32:34 CET 2012


On Wed, Dec 5, 2012 at 2:06 PM, Ard Schrijvers
<a.schrijvers at onehippo.com> wrote:
> On Wed, Dec 5, 2012 at 1:56 PM, Tobias Jeger <t.jeger at onehippo.com> wrote:
>> Hi Ard,
>>
>> for some (undocumented?) reason, my custom resource container, which appears
>> to intend to
>> make sure the resource's filename is part of the URL, also stripped off the
>> hippo:resource piece
>> of the path. By now, I learned that this piece would have the [x] suffix for
>> additional siblings.
>>
>> I now no longer strip off this piece, and things work well in all situations
>> relevant to the project's
>> current state. This means that "hippo:resource[x]" has become part of the
>> URL, and people may
>> find this undesirable, but I have currently no indications that this would
>> be unacceptable, so I'll
>> stay off the UUID stuff for now.
>>
>> Either way, I, too, wonder if we shouldn't have preferred assets over
>> embedded resources.
>
> Depends on whether the resources need workflow or not. I think there
> are now three things you can choose between:
>
> 1) Store asset in assets : These assets contain no workflow
> 2) Store asset embedded in dedicated custom document
> (my-resource-document) and link from documents to this document. The
> asset will piggyback on the workflow of the 'my-resource-document'
> 3) Store the asset just directly embedded in your document: The asset
> now has workflow by piggybacking on the document workflow AND the
> asset its text will be text-indexed on the document that contains the
> asset, hence, the document will be searchable by search terms part of
> the asset
>
> I think all of the above 3 use cases have their own strengths and
> weaknesses and should be evaluated per case

ps since I wrote the above, I thought it would be nice to add it to
the onehippo.org, so, with also some extra info about strengths and
weaknesses per choice, see

http://www.onehippo.org/7_7/library/concepts/images-and-assets/where-to-store-asstes.html

Regards Ard

>
> Regards Ard
>>> > repository will all have the same name (but different content).
>>> >
>>> > In my project's site, a resource container has been setup which, during
>>> > the
>>> > rendering of a link to download a certain resource,
>>> > creates a URL that uniquely identifies the resource by stripping the
>>> > node
>>> > name off the node's path, and replacing it with a
>>> > unique attribute of the resource, such as its filename. When the
>>> > resource is
>>> > requested (downloaded), that URL needs to be
>>> > translated back to the correct instance (node) in order to retrieve the
>>> > content. This is currently supported by the resource
>>> > container looking for the resource with the matching filename.
>>> >
>>> > Now, I also have to support the situation where my document has a
>>> > "multiple"
>>> > compound, which in turn contains a resource
>>> > (or even a "multiple" resource). This means that homonymous (same name)
>>> > child nodes exist at arbitrary locations in the URL,
>>> > and there may be even multiple homonymous parts. The way to map a node
>>> > to a
>>> > URL and back described above fails for this
>>> > situation.
>>> >
>>> > I expect that this problem has been tackled before. Is there a best
>>>
>>> well, same name siblings for resources in same name siblings for
>>> multiple compounds...I would be surprised if that has been tackled
>>> before!
>>>
>>> > practice? Do I have to start using the resource's UUID as part
>>> > of the URL in order to avoid the path jeopardy? Should I be indexing the
>>> > homonymous nodes, like ".../mydoc/resource-3/filename.ext"?
>>>
>>> Note that the resource containers 'rewriting' trick was imo already
>>> kind of a workaround solution for the unfortunate same name
>>> hippo:resource nodes. However having multiple same name siblings in
>>> multiple same name compounds hasn't been catered for. Also, I doubt
>>> whether this is really desirable in general : An embedded resource is
>>> meant to have a resource that piggybacks on the workflow  of a
>>> document. Having *many* resources in a single document (below
>>> compounds included) becomes very heavy and imo undesirable.
>>>
>>> Any way, that said, back to your problem:
>>>
>>> Would it be acceptable that for links of the resources, you use the
>>> path to the handle, and then after the handle, use the uuid of the
>>> resource node: Creating such links should be doable, right? Then, when
>>> retrieving the link, I think your resource container could then just
>>> fetch the node by uuid and make sure you map the found node to the
>>> live or preview facetselect context. Only thing is that I am not sure
>>> whether the customer is ok with that url. You could also just map the
>>> handle, and include the uuid in the url as a query parameter
>>>
>>> Ard
>>>
>>>
>>> >
>>> > thanks
>>> >
>>> > Tobi
>>> >
>>> >
>>> > --
>>> > Amsterdam - Oosteinde 11, 1017 WT Amsterdam
>>> > Boston - 1 Broadway, Cambridge, MA 02142
>>> >
>>> > US +1 877 414 4776 (toll free)
>>> > Europe +31(0)20 522 4466
>>> > www.onehippo.com
>>> >
>>> >
>>> > _______________________________________________
>>> > Hippo-cms7-user mailing list and forums
>>> > http://www.onehippo.org/cms7/support/forums.html
>>>
>>>
>>>
>>> --
>>> Amsterdam - Oosteinde 11, 1017 WT Amsterdam
>>> Boston - 1 Broadway, Cambridge, MA 02142
>>>
>>> US +1 877 414 4776 (toll free)
>>> Europe +31(0)20 522 4466
>>> www.onehippo.com
>>> _______________________________________________
>>> Hippo-cms7-user mailing list and forums
>>> http://www.onehippo.org/cms7/support/forums.html
>>
>>
>>
>>
>> --
>> Amsterdam - Oosteinde 11, 1017 WT Amsterdam
>> Boston - 1 Broadway, Cambridge, MA 02142
>>
>> US +1 877 414 4776 (toll free)
>> Europe +31(0)20 522 4466
>> www.onehippo.com
>>
>>
>> _______________________________________________
>> Hippo-cms7-user mailing list and forums
>> http://www.onehippo.org/cms7/support/forums.html
>
>
>
> --
> Amsterdam - Oosteinde 11, 1017 WT Amsterdam
> Boston - 1 Broadway, Cambridge, MA 02142
>
> US +1 877 414 4776 (toll free)
> Europe +31(0)20 522 4466
> www.onehippo.com



-- 
Amsterdam - Oosteinde 11, 1017 WT Amsterdam
Boston - 1 Broadway, Cambridge, MA 02142

US +1 877 414 4776 (toll free)
Europe +31(0)20 522 4466
www.onehippo.com


More information about the Hippo-cms7-user mailing list