Deprecating PageType

[Matt Franklin <m....@gmail.com>]

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

Re: Deprecating PageType

[Erin Noe-Payne <er...@gmail.com>]

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 <se...@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 <er...@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
>> <er...@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....@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
>> >>> >
>> >>>
>>

Re: Deprecating PageType

[Sean Cooper <se...@apache.org>]

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 <er...@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
> <er...@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....@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
> >>> >
> >>>
>

Re: Deprecating PageType

[Erin Noe-Payne <er...@gmail.com>]

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
<er...@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....@gmail.com> wrote:
>> On Mon, Jun 17, 2013 at 2:12 PM, Erin Noe-Payne <er...@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
>>> >
>>>

Re: Deprecating PageType

[Erin Noe-Payne <er...@gmail.com>]

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....@gmail.com> wrote:
> On Mon, Jun 17, 2013 at 2:12 PM, Erin Noe-Payne <er...@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
>> >
>>

Re: Deprecating PageType

[Matt Franklin <m....@gmail.com>]

On Mon, Jun 17, 2013 at 2:12 PM, Erin Noe-Payne <er...@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
> >
>

Re: Deprecating PageType

[Erin Noe-Payne <er...@gmail.com>]

How do you see context of pages being defined instead?

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
>