rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erin Noe-Payne <erin.noe.pa...@gmail.com>
Subject Re: Deprecating PageType
Date Fri, 21 Jun 2013 13:05:47 GMT
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 <secooper@apache.org> 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 <erin.noe.payne@gmail.com>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
>> <erin.noe.payne@gmail.com> 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 <m.ben.franklin@gmail.com>
>> wrote:
>> >> On Mon, Jun 17, 2013 at 2:12 PM, Erin Noe-Payne <
>> erin.noe.payne@gmail.com>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
>> >>> >
>> >>>
>>

Mime
View raw message