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

Ard Schrijvers a.schrijvers at onehippo.com
Wed Dec 5 15:12:32 CET 2012


On Wed, Dec 5, 2012 at 2:53 PM, Mathijs den Burger
<m.denburger at onehippo.com> wrote:
> I corrected the document's name to:
>
> http://www.onehippo.org/7_7/library/concepts/images-and-assets/where-to-store-assets.html

Ahum, that is better...thanks! :)

>
> Mathijs
>
>
>
> On Wed, Dec 5, 2012 at 2:32 PM, Ard Schrijvers <a.schrijvers at onehippo.com>
> wrote:
>>
>> 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
>> _______________________________________________
>> Hippo-cms7-user mailing list and forums
>> http://www.onehippo.org/cms7/support/forums.html
>
>
>
> _______________________________________________
> 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


More information about the Hippo-cms7-user mailing list