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

Mathijs den Burger m.denburger at onehippo.com
Wed Dec 5 14:53:58 CET 2012


I corrected the document's name to:

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

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onehippo.org/pipermail/hippo-cms7-user/attachments/20121205/ad1c3fdd/attachment.htm>


More information about the Hippo-cms7-user mailing list