Forum OpenACS Development: content_symlink restricted to a content_folder parent

Hi,

What is a good reason why content_symlink should restrict it to have it parent to be a content_folder?

The current code restricts it to be that why.  Is there a good reason why?  I find it too restricting.

Without this restriction it will be easy to use content_symlinks under content_item and use this for getting related items to a content_item.

Is there something I am missing here?

You could always create your own content type and allow symlinks as children with content_type.register_child_type.

To store related items for content items I'd rather use cr_item_rels and its API, e.g. content_item.relate, because that doesn't quite fit into the parent-child model.

Collapse
Posted by Jun Yamog on
Hi Til,

Is one way of doing it, which I am thinking of doing too.  Although I am just puzzled why Karl G designed it this way.  I don't want to jump to that route too fast, we may be missing something that Karl G has thought of.

So far what I can think of are:

1. so when we get the relative path on CR we will not end up with /content_folder/content_item/content_symlink.  That will make content_folder irrelevant since content_item can be in a non leaf path.

2. content_symlink name might get duplicates since its not a child of content_folder which enforces a constraint that name must be unique.

So far that is all the good reason I can think of why Karl G is wanted to make content folder as the parent of content_symlink.  I am basing those from the code of content_symlink__new.

If no one else posts then I guess I can rest my mind.

Jun,

I am afraid I don't understand exactly what you mean - just a few remarks:

2) A unique name is enforced for children of all kinds of items, not only children of content_folder.

A general rule seems to be to organise page items (those that more or less represent a page) beneath folders, and make items that resemble components of a page direct children of an item.

I wouldn't make page items direct children of other page items, that just doesn't seem to be the intended way. Unfortunately I'm not able to think of any concrete benefits, except from the flexibility you gain when using the folder / index page concept, which allows you for example to move an index page somewhere else or delete it without affecting the URL of it's subpages.

Collapse
Posted by Jun Yamog on
Hi Til,

Thanks for telling me that its also enforced on other containers.  Anyway I have taken the relate stuff that you have suggested.

Although we can't come up of a good idea why it was that way, I will take the safer route that you have suggested.  One benefit that I can think of since if its use the same method as it was designed for.  Other packages like cms will know what to do.  So preserving the current way of this is ok.