rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Cooper <secoo...@apache.org>
Subject Re: Deprecating PageType
Date Fri, 21 Jun 2013 12:09:34 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message