parent/child navigation best practices

hi,
what would be the best approach when creating a navigation system
beetwen parent/child relationships?
consider this:
* Post have many Comment
* we list all posts at /posts/index
* we list _all_ comments at /comments/index
* where do we list comments that belongs _only_ for Post.id=# ?
currently I've been listing them at /posts/view/# or at /comments/
index/post:#
but both would be no good if I wanted to:
* show _only_ Post data at /posts/view/#
* show _all_ Comment at /comments/index (no named params here)
should I have a different method like /comments/parent/# ?
any ideas?
Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions.
You received this message because you are subscribed to the Google Groups "CakePHP" group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en

There aren't any hard and fast rules to be followed, but I generally
try and index/view records within the controller they are from, it
just makes more sense that way.
I am currently designing a social portal where good causes publish
articles, blogs, events etc. which can be viewed by looking at their
profile (therefore only seeing their content) or within the portal
which indexes the combined content of all causes.
After many variations on how I should structure my controllers/urls I
have opted for having a main index action which by default lists all
records. I then have two other actions called 'cause' and 'tagged'
which set whatever extra variables are required for the view and then
call $this->index passing in some variables to alter conditions and
create required binding changes etc.
My urls are as follows
http://www.website.com/articles (Index of all articles)
http://www.website.com/articles/cause/CauseSlug (Index of cause's
articles)
http://www.website.com/articles/tagged/id:slug (Index of articles with
specified tag)
http://www.website.com/articles/view/id:slug (view of article)
The index action also checks if the file extension for any of these
views is RSS and creates an RSS feed. Users can also list articles
from causes in regions and categories of interest to them by setting
content filters, or from only the causes that they have added to their
supported list. All lists can be reordered by Date Published, Most
Viewed or Most Commented etc. so having the majority of this work done
by the one main index action saved me a lot of duplicated code.
Not sure if this is exactly what you were asking, but hope it's of
some help.
HTH
Paul.
P.S. I would provide some links, but it's very much a work in progress
still, hopefully launching the site at end of month.
Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions.
You received this message because you are subscribed to the Google Groups "CakePHP" group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en

function index($post_id =3D null)
If there's no post_id, grab all comments. Otherwise, only those for
that post.
On Feb 13, 5:06=A0am, bberg wrote:
> hi,
> what would be the best approach when creating a navigation system
> beetwen parent/child relationships?
>
> consider this:
> * Post have many Comment
> * we list all posts at /posts/index
> * we list _all_ comments at /comments/index
> * where do we list comments that belongs _only_ for Post.id=3D# ?
>
> currently I've been listing them at /posts/view/# or at /comments/
> index/post:#
>
> but both would be no good if I wanted to:
> * show _only_ Post data at /posts/view/#
> * show _all_ Comment at /comments/index (no named params here)
>
> should I have a different method like /comments/parent/# ?
> any ideas?
Check out the new CakePHP Questions site http://cakeqs.org and help others =
with their CakePHP related questions.
You received this message because you are subscribed to the Google Groups "=
CakePHP" group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at=
http://groups.google.com/group/cake-php?hl=3Den

I've found over the course of many years, that there are no hard fast
rules to this. There is not one single pattern to follow. Primarily
because the relationships and when you want to see the related
information is based on context. In other words sometimes you want to
see the related information because it has meaning in that context.
Other times the related information is meaningless or even confusing
in other context. Same information same relation different context.
I tend to build view that combine the output of many action/views via
ajax. And present the appropriate information at the right time. I
mostly use the basic actions of index, view, edit. making use of ajax
to place those child view actions inside the parent view container.
The best public view that demonstrates this well is Googles contact
management. Now googles contacts is NOT built on cake, but the design
follows very well the MVC model quite well and is easy to see the
different models and how they relate all on one page.
The main content is a list of contacts on the left and to the right is
a child view which changes depending on the number of contacts
selected. This Child view content changes based on the context of what
is selected in the list. you'll note the contact hasmany emails,
hasmany phones, hasmany addresses, hasmany dates etc. They are
displayed as though they are one record in context of the single
contact that is selected.
If multiple contacts are selected the contact view information is not
displayed as the information is meaningless with multiple contacts
selected. What is displayed is options to do actions on those contacts
that are selected, Delete, Merge, assign to Group etc.
If no contacts are selected the child view contains general help
information about what can be done in contact management.
The child view in my cake version of contact mgt is loaded via ajax
calls to the contact/view/id. The supporting models in this context
are displayed those would be the emails, phones, addresses, etc.
The contact/index only needs to display in the list the Name. However
I still build up portions of the supporting models emails, phones in a
seperate div for popup text when the user hovers over the list item.
If they want further info they can select the contact and it will load
the full view as described above.
Again I think you'll find there is no rule or pattern that covers all
as the relations are only relative in certain context.
On Feb 13, 3:06=A0am, bberg wrote:
> hi,
> what would be the best approach when creating a navigation system
> beetwen parent/child relationships?
>
> consider this:
> * Post have many Comment
> * we list all posts at /posts/index
> * we list _all_ comments at /comments/index
> * where do we list comments that belongs _only_ for Post.id=3D# ?
>
> currently I've been listing them at /posts/view/# or at /comments/
> index/post:#
>
> but both would be no good if I wanted to:
> * show _only_ Post data at /posts/view/#
> * show _all_ Comment at /comments/index (no named params here)
>
> should I have a different method like /comments/parent/# ?
> any ideas?
Check out the new CakePHP Questions site http://cakeqs.org and help others =
with their CakePHP related questions.
You received this message because you are subscribed to the Google Groups "=
CakePHP" group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at=
http://groups.google.com/group/cake-php?hl=3Den