The response is an array because it is a query. Jane Doe has multiple portal pages.
On Fri, Jun 21, 2013 at 8:09 AM, Sean Cooper <[email protected]> wrote: > I like the idea of having an array of subjects, I've been thinking that we > need to allow for pageId aliases so the end user can see meaningful URLs > instead of having a database id reference in the URL. However, I don't > think your simple example will work because if I understand it correctly > you could have multiple pages matching a single URL reference. > > e.g. > Page 1 > context: portal > subject: ['canonical1', 'john.doe', 'jane.doe'] > > Page 2 > context: portal > subject: ['canonical2', 'jane.doe', 'roger.doger', 'roger.roger'] > > GET /pages/portal/jane.doe > is undefined because jane.doe appears in two subjects. > > Perhaps I am misunderstanding your example. We should allow the array of > subjects but we must guarantee that the subject options are unique in the > context. > > -Sean > > > On Tue, Jun 18, 2013 at 4:12 PM, Erin Noe-Payne > <[email protected]>wrote: > >> I think we need to modify the page model with generic attributes to >> represent context and subject. >> context - String - formerly known as pageType >> subject - Array<String> - matches against identifier >> >> GET /pages/{context}/{identifier} then corresponds to >> select from pages where page.context={context} AND {identifier} in >> page.subject >> >> In the case of the profile page for user canonical >> context: profile >> subject: ['canonical'] >> >> In the case of a portal page owned by canonical and shared with two other >> users >> context: portal >> subject: ['canonical', 'john.doe', 'jane.doe'] >> >> On Tue, Jun 18, 2013 at 3:25 PM, Erin Noe-Payne >> <[email protected]> wrote: >> > I'm trying to relate the endpoints to the queries. At the moment our >> > endpoint is: >> > /pages/{context}/{identifier} >> > >> > If pagetype is a string, then /pages/{context} is a query from pages >> > where page.pageType={context}. >> > {Identifier} is a moving target. In the case of portal, I want pages >> > of type portal which are visible to userId. In the case of profile, >> > you want pages of type profile owned by userid (I think?). >> > >> > If I add a new context like project portfolios, I will want the >> > identifier to correspond to a project's id or title. So how do we >> > implement the idea that a context has a subject? >> > >> > On Mon, Jun 17, 2013 at 2:15 PM, Matt Franklin <[email protected]> >> wrote: >> >> On Mon, Jun 17, 2013 at 2:12 PM, Erin Noe-Payne < >> [email protected]>wrote: >> >> >> >>> How do you see context of pages being defined instead? >> >>> >> >> >> >> The simplest approach is to change the pageType property of the page to >> be >> >> a string. Alternative suggestions welcomed. >> >> >> >> >> >>> >> >>> On Monday, June 17, 2013, Matt Franklin wrote: >> >>> >> >>> > As we move to a more generic context (workspace) model for Rave, we >> will >> >>> > need to remove current constructs like the PageType enumeration. >> This >> >>> > enumeration statically defines the types of pages that can be queried >> >>> from >> >>> > Rave. A more appropriate model is to use the context name as the >> "page >> >>> > type" and allow that to be passed all the way through the stack. >> >>> > >> >>> > Assuming lazy consensus, I will commit code that deprecates the >> PageType >> >>> > enumeration in 0.22 before the end of the week. >> >>> > >> >>> > -Matt >> >>> > >> >>> >>
