Proposed ESME URL redesign

[Ethan Jewett <es...@gmail.com>]

Hi all,

[Note, this has been sitting in draft format for forever. So I'm just
cut-and-pasting it and throwing it out to everyone.]

I've been doing a fair amount of work on the front-end templates lately and
I've noticed that the template and URL organization isn't currently very
consistent. I think this has just happened over the last year or so as we've
added and changed things without a view to consistency, but maybe I'm
missing a greater organizational scheme here. If so, let me know :-)

I'd like to propose making the following changes to the URL scheme:

Current (mostly right, I think):

/ (index)
/info_view/public
/info_view/users
/info_view/streams
/info_view/contacts
/user/USERNAME (remapped from info_view/user)
/profile_view/edit
/track_view/
/action_vew/
/auth_view/
/pools_view/
/conversation/CONVID  (remapped from info_view/conversation)
/tag/TAGNAME
/logout
/info_view/search?SEARCHQUERY

/api (original api)
/api2 (new api)
/twitter (twitter api)


Proposed:

/ (index)
/public
/users
/users/USERNAME
/streams
/contacts (do we even need this any more?)
/profile
/tracks
/actions
/tokens
/pools
/conversations/CONVID
/tags/TAGNAME
/logout
/search?SEARCHQUERY

... plus API stuff, which would not change.

I'd also like to propose making the following change to template
organization:

Reorganize all the main templates under a single folder, so action_view,
auth_view, pools_view, profile_view, and track_view folders would go away.
We would change the name of the info_view folder to something like "views",
though this would never show up in the URL scheme, so we could stick with
"info_view".

Move signup.html into the new "views" folder.

My questions for everyone:

Does this all sound OK?
Any suggestions how it could be improved or anything I'm missing that is a
reason we shouldn't do this?
If we do it, what release should it go in to?
If necessary, we can set up rewrite rules so that old bookmarks still work.
Does anyone think this would be necessary?

If everyone is more or less OK with it, I'll create a ticket and then get to
work on it as time allows.

Thanks,
Ethan

Re: Proposed ESME URL redesign

[Ethan Jewett <es...@gmail.com>]

Cool :-)

Regarding the contacts page, I just think it is weird that if I click on "My
Contacts" or on my name "Ethan Jewett" next the picture, I get almost
exactly the same page. The only difference is that the user page has a
messages pane.

My mild preference would be to just get rid of the "My Contacts" page, but
maybe some people think it is important? Different applications take a
different view of the importance of this sort of functionality. Yammer makes
it very difficult to see a list of people you are following and people who
are following you. Twitter splashes it up on the main page. I'm not
particularly committed to either idea.

Ethan

On Thu, Apr 28, 2011 at 4:48 PM, Richard Hirsch <hi...@gmail.com>wrote:

> I'm up for anything to reduce clutter - I like the suggestion, because
> it is cleaner and removes all those pesky "views".
>
> Regarding the contacts page, what do you suggest as a replacement?
> Having some sort of a filter on the users page?
>
> D.
>
> On Thu, Apr 28, 2011 at 4:24 PM, Vladimir Ivanov <le...@gmail.com>
> wrote:
> > Ethan,
> >
> > First of all, I think your proposal will really simplify template
> structure.
> >
> > Just to clarify things about 'tags' page: when user makes request to
> > '/tag/tagname' it is then rewritten to '/info_view/tag' URL (with request
> > paramter 'tagname' added to it) which corresponds to /info_view/tag.html
> > template (it is then processed with specific snippet TagDisplay.display()
> ).
> > Am I right?
> >
> > Now I clearly see one possibility: place tag.html template under 'views'
> > folder (common folder for all templates) and then redirect user with
> rewrite
> > rule from '/tag/tagname' URL to '/views/tag' URL.
> >
> > I haven't completely understood another approach (or most probably my
> > english leaves a lot to be desired ;s) ) that you've mentioned: "Which
> makes
> > me wonder why we wouldn't just put the templates where they are supposed
> to
> > be and dispense with the rewrite rules completely (your suggestion #1)"
> >
> > Did you mean place tag.html template under root folder and then dispense
> > WITHOUT rewrite rules?
> >
> > Vladimir
> >
> >
> > 2011/4/28 Ethan Jewett <es...@gmail.com>
> >
> >> Hey Vladimir,
> >>
> >> I thought this idea might be half-baked :-) Thanks for taking a look at
> it.
> >>
> >> So, my thought was to do it like we do for the 'tags' page currently.
> But
> >> that uses a rewrite rule (your suggestion #3). Which makes me wonder why
> we
> >> wouldn't just put the templates where they are supposed to be and
> dispense
> >> with the rewrite rules completely (your suggestion #1).
> >>
> >> What do you think would be the best way?
> >>
> >> Cheers,
> >> Ethan
> >>
> >> On Thu, Apr 28, 2011 at 1:22 PM, Vladimir Ivanov <lester.mail@gmail.com
> >> >wrote:
> >>
> >> > Hi Ethan!
> >> >
> >> > Sounds reasonable for me. I have one question:
> >> >
> >> > Take, for example, public page. It is defined in Boot.scala
> >> > as: Menu(Loc("public", List("info_view", "public")... and it
> correspondes
> >> > to
> >> > '/info_view/public.html' URL.
> >> >
> >> > You've proposed to change this URL to '/public'. How should it be
> mapped
> >> in
> >> > SiteMap:
> >> >
> >> > 1) Menu(Loc("public", List("public")... which correspondes to
> >> 'public.html'
> >> > template in root folder?
> >> >
> >> > 2) Menu(Loc("public", List("public", "some_template")... corresponding
> to
> >> > /public/some_template.html ?
> >> >
> >> > 3) Rewrite request so that when user asks for /public URL it will be
> >> > redirected to /views/public.html (where views is a single common
> folder
> >> for
> >> > all templates )?
> >> >
> >> > Sorry if I missed something in your inital explanation.
> >> >
> >> > Thanks,
> >> > Vladimir
> >> >
> >> >
> >> > 2011/4/28 Ethan Jewett <es...@gmail.com>
> >> >
> >> > > Hi all,
> >> > >
> >> > > [Note, this has been sitting in draft format for forever. So I'm
> just
> >> > > cut-and-pasting it and throwing it out to everyone.]
> >> > >
> >> > > I've been doing a fair amount of work on the front-end templates
> lately
> >> > and
> >> > > I've noticed that the template and URL organization isn't currently
> >> very
> >> > > consistent. I think this has just happened over the last year or so
> as
> >> > > we've
> >> > > added and changed things without a view to consistency, but maybe
> I'm
> >> > > missing a greater organizational scheme here. If so, let me know :-)
> >> > >
> >> > > I'd like to propose making the following changes to the URL scheme:
> >> > >
> >> > > Current (mostly right, I think):
> >> > >
> >> > > / (index)
> >> > > /info_view/public
> >> > > /info_view/users
> >> > > /info_view/streams
> >> > > /info_view/contacts
> >> > > /user/USERNAME (remapped from info_view/user)
> >> > > /profile_view/edit
> >> > > /track_view/
> >> > > /action_vew/
> >> > > /auth_view/
> >> > > /pools_view/
> >> > > /conversation/CONVID  (remapped from info_view/conversation)
> >> > > /tag/TAGNAME
> >> > > /logout
> >> > > /info_view/search?SEARCHQUERY
> >> > >
> >> > > /api (original api)
> >> > > /api2 (new api)
> >> > > /twitter (twitter api)
> >> > >
> >> > >
> >> > > Proposed:
> >> > >
> >> > > / (index)
> >> > > /public
> >> > > /users
> >> > > /users/USERNAME
> >> > > /streams
> >> > > /contacts (do we even need this any more?)
> >> > > /profile
> >> > > /tracks
> >> > > /actions
> >> > > /tokens
> >> > > /pools
> >> > > /conversations/CONVID
> >> > > /tags/TAGNAME
> >> > > /logout
> >> > > /search?SEARCHQUERY
> >> > >
> >> > > ... plus API stuff, which would not change.
> >> > >
> >> > > I'd also like to propose making the following change to template
> >> > > organization:
> >> > >
> >> > > Reorganize all the main templates under a single folder, so
> >> action_view,
> >> > > auth_view, pools_view, profile_view, and track_view folders would go
> >> > away.
> >> > > We would change the name of the info_view folder to something like
> >> > "views",
> >> > > though this would never show up in the URL scheme, so we could stick
> >> with
> >> > > "info_view".
> >> > >
> >> > > Move signup.html into the new "views" folder.
> >> > >
> >> > > My questions for everyone:
> >> > >
> >> > > Does this all sound OK?
> >> > > Any suggestions how it could be improved or anything I'm missing
> that
> >> is
> >> > a
> >> > > reason we shouldn't do this?
> >> > > If we do it, what release should it go in to?
> >> > > If necessary, we can set up rewrite rules so that old bookmarks
> still
> >> > work.
> >> > > Does anyone think this would be necessary?
> >> > >
> >> > > If everyone is more or less OK with it, I'll create a ticket and
> then
> >> get
> >> > > to
> >> > > work on it as time allows.
> >> > >
> >> > > Thanks,
> >> > > Ethan
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Best Regards,
> >> > Vladimir Ivanov
> >> >
> >>
> >
> >
> >
> > --
> > Best Regards,
> > Vladimir Ivanov
> >
>

Re: Proposed ESME URL redesign

[Richard Hirsch <hi...@gmail.com>]

I'm up for anything to reduce clutter - I like the suggestion, because
it is cleaner and removes all those pesky "views".

Regarding the contacts page, what do you suggest as a replacement?
Having some sort of a filter on the users page?

D.

On Thu, Apr 28, 2011 at 4:24 PM, Vladimir Ivanov <le...@gmail.com> wrote:
> Ethan,
>
> First of all, I think your proposal will really simplify template structure.
>
> Just to clarify things about 'tags' page: when user makes request to
> '/tag/tagname' it is then rewritten to '/info_view/tag' URL (with request
> paramter 'tagname' added to it) which corresponds to /info_view/tag.html
> template (it is then processed with specific snippet TagDisplay.display() ).
> Am I right?
>
> Now I clearly see one possibility: place tag.html template under 'views'
> folder (common folder for all templates) and then redirect user with rewrite
> rule from '/tag/tagname' URL to '/views/tag' URL.
>
> I haven't completely understood another approach (or most probably my
> english leaves a lot to be desired ;s) ) that you've mentioned: "Which makes
> me wonder why we wouldn't just put the templates where they are supposed to
> be and dispense with the rewrite rules completely (your suggestion #1)"
>
> Did you mean place tag.html template under root folder and then dispense
> WITHOUT rewrite rules?
>
> Vladimir
>
>
> 2011/4/28 Ethan Jewett <es...@gmail.com>
>
>> Hey Vladimir,
>>
>> I thought this idea might be half-baked :-) Thanks for taking a look at it.
>>
>> So, my thought was to do it like we do for the 'tags' page currently. But
>> that uses a rewrite rule (your suggestion #3). Which makes me wonder why we
>> wouldn't just put the templates where they are supposed to be and dispense
>> with the rewrite rules completely (your suggestion #1).
>>
>> What do you think would be the best way?
>>
>> Cheers,
>> Ethan
>>
>> On Thu, Apr 28, 2011 at 1:22 PM, Vladimir Ivanov <lester.mail@gmail.com
>> >wrote:
>>
>> > Hi Ethan!
>> >
>> > Sounds reasonable for me. I have one question:
>> >
>> > Take, for example, public page. It is defined in Boot.scala
>> > as: Menu(Loc("public", List("info_view", "public")... and it correspondes
>> > to
>> > '/info_view/public.html' URL.
>> >
>> > You've proposed to change this URL to '/public'. How should it be mapped
>> in
>> > SiteMap:
>> >
>> > 1) Menu(Loc("public", List("public")... which correspondes to
>> 'public.html'
>> > template in root folder?
>> >
>> > 2) Menu(Loc("public", List("public", "some_template")... corresponding to
>> > /public/some_template.html ?
>> >
>> > 3) Rewrite request so that when user asks for /public URL it will be
>> > redirected to /views/public.html (where views is a single common folder
>> for
>> > all templates )?
>> >
>> > Sorry if I missed something in your inital explanation.
>> >
>> > Thanks,
>> > Vladimir
>> >
>> >
>> > 2011/4/28 Ethan Jewett <es...@gmail.com>
>> >
>> > > Hi all,
>> > >
>> > > [Note, this has been sitting in draft format for forever. So I'm just
>> > > cut-and-pasting it and throwing it out to everyone.]
>> > >
>> > > I've been doing a fair amount of work on the front-end templates lately
>> > and
>> > > I've noticed that the template and URL organization isn't currently
>> very
>> > > consistent. I think this has just happened over the last year or so as
>> > > we've
>> > > added and changed things without a view to consistency, but maybe I'm
>> > > missing a greater organizational scheme here. If so, let me know :-)
>> > >
>> > > I'd like to propose making the following changes to the URL scheme:
>> > >
>> > > Current (mostly right, I think):
>> > >
>> > > / (index)
>> > > /info_view/public
>> > > /info_view/users
>> > > /info_view/streams
>> > > /info_view/contacts
>> > > /user/USERNAME (remapped from info_view/user)
>> > > /profile_view/edit
>> > > /track_view/
>> > > /action_vew/
>> > > /auth_view/
>> > > /pools_view/
>> > > /conversation/CONVID  (remapped from info_view/conversation)
>> > > /tag/TAGNAME
>> > > /logout
>> > > /info_view/search?SEARCHQUERY
>> > >
>> > > /api (original api)
>> > > /api2 (new api)
>> > > /twitter (twitter api)
>> > >
>> > >
>> > > Proposed:
>> > >
>> > > / (index)
>> > > /public
>> > > /users
>> > > /users/USERNAME
>> > > /streams
>> > > /contacts (do we even need this any more?)
>> > > /profile
>> > > /tracks
>> > > /actions
>> > > /tokens
>> > > /pools
>> > > /conversations/CONVID
>> > > /tags/TAGNAME
>> > > /logout
>> > > /search?SEARCHQUERY
>> > >
>> > > ... plus API stuff, which would not change.
>> > >
>> > > I'd also like to propose making the following change to template
>> > > organization:
>> > >
>> > > Reorganize all the main templates under a single folder, so
>> action_view,
>> > > auth_view, pools_view, profile_view, and track_view folders would go
>> > away.
>> > > We would change the name of the info_view folder to something like
>> > "views",
>> > > though this would never show up in the URL scheme, so we could stick
>> with
>> > > "info_view".
>> > >
>> > > Move signup.html into the new "views" folder.
>> > >
>> > > My questions for everyone:
>> > >
>> > > Does this all sound OK?
>> > > Any suggestions how it could be improved or anything I'm missing that
>> is
>> > a
>> > > reason we shouldn't do this?
>> > > If we do it, what release should it go in to?
>> > > If necessary, we can set up rewrite rules so that old bookmarks still
>> > work.
>> > > Does anyone think this would be necessary?
>> > >
>> > > If everyone is more or less OK with it, I'll create a ticket and then
>> get
>> > > to
>> > > work on it as time allows.
>> > >
>> > > Thanks,
>> > > Ethan
>> > >
>> >
>> >
>> >
>> > --
>> > Best Regards,
>> > Vladimir Ivanov
>> >
>>
>
>
>
> --
> Best Regards,
> Vladimir Ivanov
>

Re: Proposed ESME URL redesign

[Ethan Jewett <es...@gmail.com>]

Ah ha! Excellent! :-)

On Thu, Apr 28, 2011 at 5:11 PM, Vladimir Ivanov <le...@gmail.com>wrote:

> Yes, I've read in Lift Google Group that David recommends to use Menu.param
> in preference to URL rewriting. Examples:
>
> http://simply.liftweb.net/index-3.2.html#toc-Subsection-3.2.7
> <http://simply.liftweb.net/index-3.2.html#toc-Subsection-3.2.7>
> http://simply.liftweb.net/index-3.4.html#toc-Subsection-3.4.5
>
> Vladimir
> <http://simply.liftweb.net/index-3.4.html#toc-Subsection-3.4.5>
> 2011/4/28 Ethan Jewett <es...@gmail.com>
>
> > Hi Vladimir,
> >
> > Yup, I think we are saying the same things. See below:
> >
> > On Thu, Apr 28, 2011 at 4:24 PM, Vladimir Ivanov <lester.mail@gmail.com
> > >wrote:
> >
> >
> > > Just to clarify things about 'tags' page: when user makes request to
> > > '/tag/tagname' it is then rewritten to '/info_view/tag' URL (with
> request
> > > paramter 'tagname' added to it) which corresponds to
> /info_view/tag.html
> > > template (it is then processed with specific snippet
> TagDisplay.display()
> > > ).
> > > Am I right?
> > >
> >
> > Yes, I think that is what is happening currently. And it is what I was
> > originally thinking in order to accomplish what I suggested in the
> > proposal.
> > Now I think the other option (below) is better.
> >
> >
> > > Now I clearly see one possibility: place tag.html template under
> 'views'
> > > folder (common folder for all templates) and then redirect user with
> > > rewrite
> > > rule from '/tag/tagname' URL to '/views/tag' URL.
> > >
> > > I haven't completely understood another approach (or most probably my
> > > english leaves a lot to be desired ;s) ) that you've mentioned: "Which
> > > makes
> > > me wonder why we wouldn't just put the templates where they are
> supposed
> > to
> > > be and dispense with the rewrite rules completely (your suggestion #1)"
> > >
> > > Did you mean place tag.html template under root folder and then
> dispense
> > > WITHOUT rewrite rules?
> > >
> >
> > Exactly. If we can do it without rewrite rules I suspect that would be
> > better. I keep seeing David telling people not to use rewrite rules on
> the
> > Lift list, so I guess I am hesitant to use them now if I can avoid it.
> I'm
> > worried I'll need to ask a question on the list and then have to show
> that
> > I'm using rewrite rules :-)
> >
> > Now, for the collections (/tags, /conversations, /users) we probably will
> > need a rewrite rule or something to make the path element available to
> the
> > snippet. And for users we will need to rewrite in some way in order to
> have
> > a snippet at /users and also display users at /users/USERNAME. But I
> think
> > we can figure out how this works when we get there.
> >
> > Ethan
> >
> >
> > >
> > > Vladimir
> > >
> > >
> > > 2011/4/28 Ethan Jewett <es...@gmail.com>
> > >
> > > > Hey Vladimir,
> > > >
> > > > I thought this idea might be half-baked :-) Thanks for taking a look
> at
> > > it.
> > > >
> > > > So, my thought was to do it like we do for the 'tags' page currently.
> > But
> > > > that uses a rewrite rule (your suggestion #3). Which makes me wonder
> > why
> > > we
> > > > wouldn't just put the templates where they are supposed to be and
> > > dispense
> > > > with the rewrite rules completely (your suggestion #1).
> > > >
> > > > What do you think would be the best way?
> > > >
> > > > Cheers,
> > > > Ethan
> > > >
> > > > On Thu, Apr 28, 2011 at 1:22 PM, Vladimir Ivanov <
> > lester.mail@gmail.com
> > > > >wrote:
> > > >
> > > > > Hi Ethan!
> > > > >
> > > > > Sounds reasonable for me. I have one question:
> > > > >
> > > > > Take, for example, public page. It is defined in Boot.scala
> > > > > as: Menu(Loc("public", List("info_view", "public")... and it
> > > correspondes
> > > > > to
> > > > > '/info_view/public.html' URL.
> > > > >
> > > > > You've proposed to change this URL to '/public'. How should it be
> > > mapped
> > > > in
> > > > > SiteMap:
> > > > >
> > > > > 1) Menu(Loc("public", List("public")... which correspondes to
> > > > 'public.html'
> > > > > template in root folder?
> > > > >
> > > > > 2) Menu(Loc("public", List("public", "some_template")...
> > corresponding
> > > to
> > > > > /public/some_template.html ?
> > > > >
> > > > > 3) Rewrite request so that when user asks for /public URL it will
> be
> > > > > redirected to /views/public.html (where views is a single common
> > folder
> > > > for
> > > > > all templates )?
> > > > >
> > > > > Sorry if I missed something in your inital explanation.
> > > > >
> > > > > Thanks,
> > > > > Vladimir
> > > > >
> > > > >
> > > > > 2011/4/28 Ethan Jewett <es...@gmail.com>
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > [Note, this has been sitting in draft format for forever. So I'm
> > just
> > > > > > cut-and-pasting it and throwing it out to everyone.]
> > > > > >
> > > > > > I've been doing a fair amount of work on the front-end templates
> > > lately
> > > > > and
> > > > > > I've noticed that the template and URL organization isn't
> currently
> > > > very
> > > > > > consistent. I think this has just happened over the last year or
> so
> > > as
> > > > > > we've
> > > > > > added and changed things without a view to consistency, but maybe
> > I'm
> > > > > > missing a greater organizational scheme here. If so, let me know
> > :-)
> > > > > >
> > > > > > I'd like to propose making the following changes to the URL
> scheme:
> > > > > >
> > > > > > Current (mostly right, I think):
> > > > > >
> > > > > > / (index)
> > > > > > /info_view/public
> > > > > > /info_view/users
> > > > > > /info_view/streams
> > > > > > /info_view/contacts
> > > > > > /user/USERNAME (remapped from info_view/user)
> > > > > > /profile_view/edit
> > > > > > /track_view/
> > > > > > /action_vew/
> > > > > > /auth_view/
> > > > > > /pools_view/
> > > > > > /conversation/CONVID  (remapped from info_view/conversation)
> > > > > > /tag/TAGNAME
> > > > > > /logout
> > > > > > /info_view/search?SEARCHQUERY
> > > > > >
> > > > > > /api (original api)
> > > > > > /api2 (new api)
> > > > > > /twitter (twitter api)
> > > > > >
> > > > > >
> > > > > > Proposed:
> > > > > >
> > > > > > / (index)
> > > > > > /public
> > > > > > /users
> > > > > > /users/USERNAME
> > > > > > /streams
> > > > > > /contacts (do we even need this any more?)
> > > > > > /profile
> > > > > > /tracks
> > > > > > /actions
> > > > > > /tokens
> > > > > > /pools
> > > > > > /conversations/CONVID
> > > > > > /tags/TAGNAME
> > > > > > /logout
> > > > > > /search?SEARCHQUERY
> > > > > >
> > > > > > ... plus API stuff, which would not change.
> > > > > >
> > > > > > I'd also like to propose making the following change to template
> > > > > > organization:
> > > > > >
> > > > > > Reorganize all the main templates under a single folder, so
> > > > action_view,
> > > > > > auth_view, pools_view, profile_view, and track_view folders would
> > go
> > > > > away.
> > > > > > We would change the name of the info_view folder to something
> like
> > > > > "views",
> > > > > > though this would never show up in the URL scheme, so we could
> > stick
> > > > with
> > > > > > "info_view".
> > > > > >
> > > > > > Move signup.html into the new "views" folder.
> > > > > >
> > > > > > My questions for everyone:
> > > > > >
> > > > > > Does this all sound OK?
> > > > > > Any suggestions how it could be improved or anything I'm missing
> > that
> > > > is
> > > > > a
> > > > > > reason we shouldn't do this?
> > > > > > If we do it, what release should it go in to?
> > > > > > If necessary, we can set up rewrite rules so that old bookmarks
> > still
> > > > > work.
> > > > > > Does anyone think this would be necessary?
> > > > > >
> > > > > > If everyone is more or less OK with it, I'll create a ticket and
> > then
> > > > get
> > > > > > to
> > > > > > work on it as time allows.
> > > > > >
> > > > > > Thanks,
> > > > > > Ethan
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best Regards,
> > > > > Vladimir Ivanov
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Best Regards,
> > > Vladimir Ivanov
> > >
> >
>
>
>
> --
> Best Regards,
> Vladimir Ivanov
>

Re: Proposed ESME URL redesign

[Vladimir Ivanov <le...@gmail.com>]

Yes, I've read in Lift Google Group that David recommends to use Menu.param
in preference to URL rewriting. Examples:

http://simply.liftweb.net/index-3.2.html#toc-Subsection-3.2.7
<http://simply.liftweb.net/index-3.2.html#toc-Subsection-3.2.7>
http://simply.liftweb.net/index-3.4.html#toc-Subsection-3.4.5

Vladimir
<http://simply.liftweb.net/index-3.4.html#toc-Subsection-3.4.5>
2011/4/28 Ethan Jewett <es...@gmail.com>

> Hi Vladimir,
>
> Yup, I think we are saying the same things. See below:
>
> On Thu, Apr 28, 2011 at 4:24 PM, Vladimir Ivanov <lester.mail@gmail.com
> >wrote:
>
>
> > Just to clarify things about 'tags' page: when user makes request to
> > '/tag/tagname' it is then rewritten to '/info_view/tag' URL (with request
> > paramter 'tagname' added to it) which corresponds to /info_view/tag.html
> > template (it is then processed with specific snippet TagDisplay.display()
> > ).
> > Am I right?
> >
>
> Yes, I think that is what is happening currently. And it is what I was
> originally thinking in order to accomplish what I suggested in the
> proposal.
> Now I think the other option (below) is better.
>
>
> > Now I clearly see one possibility: place tag.html template under 'views'
> > folder (common folder for all templates) and then redirect user with
> > rewrite
> > rule from '/tag/tagname' URL to '/views/tag' URL.
> >
> > I haven't completely understood another approach (or most probably my
> > english leaves a lot to be desired ;s) ) that you've mentioned: "Which
> > makes
> > me wonder why we wouldn't just put the templates where they are supposed
> to
> > be and dispense with the rewrite rules completely (your suggestion #1)"
> >
> > Did you mean place tag.html template under root folder and then dispense
> > WITHOUT rewrite rules?
> >
>
> Exactly. If we can do it without rewrite rules I suspect that would be
> better. I keep seeing David telling people not to use rewrite rules on the
> Lift list, so I guess I am hesitant to use them now if I can avoid it. I'm
> worried I'll need to ask a question on the list and then have to show that
> I'm using rewrite rules :-)
>
> Now, for the collections (/tags, /conversations, /users) we probably will
> need a rewrite rule or something to make the path element available to the
> snippet. And for users we will need to rewrite in some way in order to have
> a snippet at /users and also display users at /users/USERNAME. But I think
> we can figure out how this works when we get there.
>
> Ethan
>
>
> >
> > Vladimir
> >
> >
> > 2011/4/28 Ethan Jewett <es...@gmail.com>
> >
> > > Hey Vladimir,
> > >
> > > I thought this idea might be half-baked :-) Thanks for taking a look at
> > it.
> > >
> > > So, my thought was to do it like we do for the 'tags' page currently.
> But
> > > that uses a rewrite rule (your suggestion #3). Which makes me wonder
> why
> > we
> > > wouldn't just put the templates where they are supposed to be and
> > dispense
> > > with the rewrite rules completely (your suggestion #1).
> > >
> > > What do you think would be the best way?
> > >
> > > Cheers,
> > > Ethan
> > >
> > > On Thu, Apr 28, 2011 at 1:22 PM, Vladimir Ivanov <
> lester.mail@gmail.com
> > > >wrote:
> > >
> > > > Hi Ethan!
> > > >
> > > > Sounds reasonable for me. I have one question:
> > > >
> > > > Take, for example, public page. It is defined in Boot.scala
> > > > as: Menu(Loc("public", List("info_view", "public")... and it
> > correspondes
> > > > to
> > > > '/info_view/public.html' URL.
> > > >
> > > > You've proposed to change this URL to '/public'. How should it be
> > mapped
> > > in
> > > > SiteMap:
> > > >
> > > > 1) Menu(Loc("public", List("public")... which correspondes to
> > > 'public.html'
> > > > template in root folder?
> > > >
> > > > 2) Menu(Loc("public", List("public", "some_template")...
> corresponding
> > to
> > > > /public/some_template.html ?
> > > >
> > > > 3) Rewrite request so that when user asks for /public URL it will be
> > > > redirected to /views/public.html (where views is a single common
> folder
> > > for
> > > > all templates )?
> > > >
> > > > Sorry if I missed something in your inital explanation.
> > > >
> > > > Thanks,
> > > > Vladimir
> > > >
> > > >
> > > > 2011/4/28 Ethan Jewett <es...@gmail.com>
> > > >
> > > > > Hi all,
> > > > >
> > > > > [Note, this has been sitting in draft format for forever. So I'm
> just
> > > > > cut-and-pasting it and throwing it out to everyone.]
> > > > >
> > > > > I've been doing a fair amount of work on the front-end templates
> > lately
> > > > and
> > > > > I've noticed that the template and URL organization isn't currently
> > > very
> > > > > consistent. I think this has just happened over the last year or so
> > as
> > > > > we've
> > > > > added and changed things without a view to consistency, but maybe
> I'm
> > > > > missing a greater organizational scheme here. If so, let me know
> :-)
> > > > >
> > > > > I'd like to propose making the following changes to the URL scheme:
> > > > >
> > > > > Current (mostly right, I think):
> > > > >
> > > > > / (index)
> > > > > /info_view/public
> > > > > /info_view/users
> > > > > /info_view/streams
> > > > > /info_view/contacts
> > > > > /user/USERNAME (remapped from info_view/user)
> > > > > /profile_view/edit
> > > > > /track_view/
> > > > > /action_vew/
> > > > > /auth_view/
> > > > > /pools_view/
> > > > > /conversation/CONVID  (remapped from info_view/conversation)
> > > > > /tag/TAGNAME
> > > > > /logout
> > > > > /info_view/search?SEARCHQUERY
> > > > >
> > > > > /api (original api)
> > > > > /api2 (new api)
> > > > > /twitter (twitter api)
> > > > >
> > > > >
> > > > > Proposed:
> > > > >
> > > > > / (index)
> > > > > /public
> > > > > /users
> > > > > /users/USERNAME
> > > > > /streams
> > > > > /contacts (do we even need this any more?)
> > > > > /profile
> > > > > /tracks
> > > > > /actions
> > > > > /tokens
> > > > > /pools
> > > > > /conversations/CONVID
> > > > > /tags/TAGNAME
> > > > > /logout
> > > > > /search?SEARCHQUERY
> > > > >
> > > > > ... plus API stuff, which would not change.
> > > > >
> > > > > I'd also like to propose making the following change to template
> > > > > organization:
> > > > >
> > > > > Reorganize all the main templates under a single folder, so
> > > action_view,
> > > > > auth_view, pools_view, profile_view, and track_view folders would
> go
> > > > away.
> > > > > We would change the name of the info_view folder to something like
> > > > "views",
> > > > > though this would never show up in the URL scheme, so we could
> stick
> > > with
> > > > > "info_view".
> > > > >
> > > > > Move signup.html into the new "views" folder.
> > > > >
> > > > > My questions for everyone:
> > > > >
> > > > > Does this all sound OK?
> > > > > Any suggestions how it could be improved or anything I'm missing
> that
> > > is
> > > > a
> > > > > reason we shouldn't do this?
> > > > > If we do it, what release should it go in to?
> > > > > If necessary, we can set up rewrite rules so that old bookmarks
> still
> > > > work.
> > > > > Does anyone think this would be necessary?
> > > > >
> > > > > If everyone is more or less OK with it, I'll create a ticket and
> then
> > > get
> > > > > to
> > > > > work on it as time allows.
> > > > >
> > > > > Thanks,
> > > > > Ethan
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards,
> > > > Vladimir Ivanov
> > > >
> > >
> >
> >
> >
> > --
> > Best Regards,
> > Vladimir Ivanov
> >
>



-- 
Best Regards,
Vladimir Ivanov

Re: Proposed ESME URL redesign

[Ethan Jewett <es...@gmail.com>]

Hi Vladimir,

Yup, I think we are saying the same things. See below:

On Thu, Apr 28, 2011 at 4:24 PM, Vladimir Ivanov <le...@gmail.com>wrote:


> Just to clarify things about 'tags' page: when user makes request to
> '/tag/tagname' it is then rewritten to '/info_view/tag' URL (with request
> paramter 'tagname' added to it) which corresponds to /info_view/tag.html
> template (it is then processed with specific snippet TagDisplay.display()
> ).
> Am I right?
>

Yes, I think that is what is happening currently. And it is what I was
originally thinking in order to accomplish what I suggested in the proposal.
Now I think the other option (below) is better.


> Now I clearly see one possibility: place tag.html template under 'views'
> folder (common folder for all templates) and then redirect user with
> rewrite
> rule from '/tag/tagname' URL to '/views/tag' URL.
>
> I haven't completely understood another approach (or most probably my
> english leaves a lot to be desired ;s) ) that you've mentioned: "Which
> makes
> me wonder why we wouldn't just put the templates where they are supposed to
> be and dispense with the rewrite rules completely (your suggestion #1)"
>
> Did you mean place tag.html template under root folder and then dispense
> WITHOUT rewrite rules?
>

Exactly. If we can do it without rewrite rules I suspect that would be
better. I keep seeing David telling people not to use rewrite rules on the
Lift list, so I guess I am hesitant to use them now if I can avoid it. I'm
worried I'll need to ask a question on the list and then have to show that
I'm using rewrite rules :-)

Now, for the collections (/tags, /conversations, /users) we probably will
need a rewrite rule or something to make the path element available to the
snippet. And for users we will need to rewrite in some way in order to have
a snippet at /users and also display users at /users/USERNAME. But I think
we can figure out how this works when we get there.

Ethan


>
> Vladimir
>
>
> 2011/4/28 Ethan Jewett <es...@gmail.com>
>
> > Hey Vladimir,
> >
> > I thought this idea might be half-baked :-) Thanks for taking a look at
> it.
> >
> > So, my thought was to do it like we do for the 'tags' page currently. But
> > that uses a rewrite rule (your suggestion #3). Which makes me wonder why
> we
> > wouldn't just put the templates where they are supposed to be and
> dispense
> > with the rewrite rules completely (your suggestion #1).
> >
> > What do you think would be the best way?
> >
> > Cheers,
> > Ethan
> >
> > On Thu, Apr 28, 2011 at 1:22 PM, Vladimir Ivanov <lester.mail@gmail.com
> > >wrote:
> >
> > > Hi Ethan!
> > >
> > > Sounds reasonable for me. I have one question:
> > >
> > > Take, for example, public page. It is defined in Boot.scala
> > > as: Menu(Loc("public", List("info_view", "public")... and it
> correspondes
> > > to
> > > '/info_view/public.html' URL.
> > >
> > > You've proposed to change this URL to '/public'. How should it be
> mapped
> > in
> > > SiteMap:
> > >
> > > 1) Menu(Loc("public", List("public")... which correspondes to
> > 'public.html'
> > > template in root folder?
> > >
> > > 2) Menu(Loc("public", List("public", "some_template")... corresponding
> to
> > > /public/some_template.html ?
> > >
> > > 3) Rewrite request so that when user asks for /public URL it will be
> > > redirected to /views/public.html (where views is a single common folder
> > for
> > > all templates )?
> > >
> > > Sorry if I missed something in your inital explanation.
> > >
> > > Thanks,
> > > Vladimir
> > >
> > >
> > > 2011/4/28 Ethan Jewett <es...@gmail.com>
> > >
> > > > Hi all,
> > > >
> > > > [Note, this has been sitting in draft format for forever. So I'm just
> > > > cut-and-pasting it and throwing it out to everyone.]
> > > >
> > > > I've been doing a fair amount of work on the front-end templates
> lately
> > > and
> > > > I've noticed that the template and URL organization isn't currently
> > very
> > > > consistent. I think this has just happened over the last year or so
> as
> > > > we've
> > > > added and changed things without a view to consistency, but maybe I'm
> > > > missing a greater organizational scheme here. If so, let me know :-)
> > > >
> > > > I'd like to propose making the following changes to the URL scheme:
> > > >
> > > > Current (mostly right, I think):
> > > >
> > > > / (index)
> > > > /info_view/public
> > > > /info_view/users
> > > > /info_view/streams
> > > > /info_view/contacts
> > > > /user/USERNAME (remapped from info_view/user)
> > > > /profile_view/edit
> > > > /track_view/
> > > > /action_vew/
> > > > /auth_view/
> > > > /pools_view/
> > > > /conversation/CONVID  (remapped from info_view/conversation)
> > > > /tag/TAGNAME
> > > > /logout
> > > > /info_view/search?SEARCHQUERY
> > > >
> > > > /api (original api)
> > > > /api2 (new api)
> > > > /twitter (twitter api)
> > > >
> > > >
> > > > Proposed:
> > > >
> > > > / (index)
> > > > /public
> > > > /users
> > > > /users/USERNAME
> > > > /streams
> > > > /contacts (do we even need this any more?)
> > > > /profile
> > > > /tracks
> > > > /actions
> > > > /tokens
> > > > /pools
> > > > /conversations/CONVID
> > > > /tags/TAGNAME
> > > > /logout
> > > > /search?SEARCHQUERY
> > > >
> > > > ... plus API stuff, which would not change.
> > > >
> > > > I'd also like to propose making the following change to template
> > > > organization:
> > > >
> > > > Reorganize all the main templates under a single folder, so
> > action_view,
> > > > auth_view, pools_view, profile_view, and track_view folders would go
> > > away.
> > > > We would change the name of the info_view folder to something like
> > > "views",
> > > > though this would never show up in the URL scheme, so we could stick
> > with
> > > > "info_view".
> > > >
> > > > Move signup.html into the new "views" folder.
> > > >
> > > > My questions for everyone:
> > > >
> > > > Does this all sound OK?
> > > > Any suggestions how it could be improved or anything I'm missing that
> > is
> > > a
> > > > reason we shouldn't do this?
> > > > If we do it, what release should it go in to?
> > > > If necessary, we can set up rewrite rules so that old bookmarks still
> > > work.
> > > > Does anyone think this would be necessary?
> > > >
> > > > If everyone is more or less OK with it, I'll create a ticket and then
> > get
> > > > to
> > > > work on it as time allows.
> > > >
> > > > Thanks,
> > > > Ethan
> > > >
> > >
> > >
> > >
> > > --
> > > Best Regards,
> > > Vladimir Ivanov
> > >
> >
>
>
>
> --
> Best Regards,
> Vladimir Ivanov
>

Re: Proposed ESME URL redesign

[Vladimir Ivanov <le...@gmail.com>]

Ethan,

First of all, I think your proposal will really simplify template structure.

Just to clarify things about 'tags' page: when user makes request to
'/tag/tagname' it is then rewritten to '/info_view/tag' URL (with request
paramter 'tagname' added to it) which corresponds to /info_view/tag.html
template (it is then processed with specific snippet TagDisplay.display() ).
Am I right?

Now I clearly see one possibility: place tag.html template under 'views'
folder (common folder for all templates) and then redirect user with rewrite
rule from '/tag/tagname' URL to '/views/tag' URL.

I haven't completely understood another approach (or most probably my
english leaves a lot to be desired ;s) ) that you've mentioned: "Which makes
me wonder why we wouldn't just put the templates where they are supposed to
be and dispense with the rewrite rules completely (your suggestion #1)"

Did you mean place tag.html template under root folder and then dispense
WITHOUT rewrite rules?

Vladimir


2011/4/28 Ethan Jewett <es...@gmail.com>

> Hey Vladimir,
>
> I thought this idea might be half-baked :-) Thanks for taking a look at it.
>
> So, my thought was to do it like we do for the 'tags' page currently. But
> that uses a rewrite rule (your suggestion #3). Which makes me wonder why we
> wouldn't just put the templates where they are supposed to be and dispense
> with the rewrite rules completely (your suggestion #1).
>
> What do you think would be the best way?
>
> Cheers,
> Ethan
>
> On Thu, Apr 28, 2011 at 1:22 PM, Vladimir Ivanov <lester.mail@gmail.com
> >wrote:
>
> > Hi Ethan!
> >
> > Sounds reasonable for me. I have one question:
> >
> > Take, for example, public page. It is defined in Boot.scala
> > as: Menu(Loc("public", List("info_view", "public")... and it correspondes
> > to
> > '/info_view/public.html' URL.
> >
> > You've proposed to change this URL to '/public'. How should it be mapped
> in
> > SiteMap:
> >
> > 1) Menu(Loc("public", List("public")... which correspondes to
> 'public.html'
> > template in root folder?
> >
> > 2) Menu(Loc("public", List("public", "some_template")... corresponding to
> > /public/some_template.html ?
> >
> > 3) Rewrite request so that when user asks for /public URL it will be
> > redirected to /views/public.html (where views is a single common folder
> for
> > all templates )?
> >
> > Sorry if I missed something in your inital explanation.
> >
> > Thanks,
> > Vladimir
> >
> >
> > 2011/4/28 Ethan Jewett <es...@gmail.com>
> >
> > > Hi all,
> > >
> > > [Note, this has been sitting in draft format for forever. So I'm just
> > > cut-and-pasting it and throwing it out to everyone.]
> > >
> > > I've been doing a fair amount of work on the front-end templates lately
> > and
> > > I've noticed that the template and URL organization isn't currently
> very
> > > consistent. I think this has just happened over the last year or so as
> > > we've
> > > added and changed things without a view to consistency, but maybe I'm
> > > missing a greater organizational scheme here. If so, let me know :-)
> > >
> > > I'd like to propose making the following changes to the URL scheme:
> > >
> > > Current (mostly right, I think):
> > >
> > > / (index)
> > > /info_view/public
> > > /info_view/users
> > > /info_view/streams
> > > /info_view/contacts
> > > /user/USERNAME (remapped from info_view/user)
> > > /profile_view/edit
> > > /track_view/
> > > /action_vew/
> > > /auth_view/
> > > /pools_view/
> > > /conversation/CONVID  (remapped from info_view/conversation)
> > > /tag/TAGNAME
> > > /logout
> > > /info_view/search?SEARCHQUERY
> > >
> > > /api (original api)
> > > /api2 (new api)
> > > /twitter (twitter api)
> > >
> > >
> > > Proposed:
> > >
> > > / (index)
> > > /public
> > > /users
> > > /users/USERNAME
> > > /streams
> > > /contacts (do we even need this any more?)
> > > /profile
> > > /tracks
> > > /actions
> > > /tokens
> > > /pools
> > > /conversations/CONVID
> > > /tags/TAGNAME
> > > /logout
> > > /search?SEARCHQUERY
> > >
> > > ... plus API stuff, which would not change.
> > >
> > > I'd also like to propose making the following change to template
> > > organization:
> > >
> > > Reorganize all the main templates under a single folder, so
> action_view,
> > > auth_view, pools_view, profile_view, and track_view folders would go
> > away.
> > > We would change the name of the info_view folder to something like
> > "views",
> > > though this would never show up in the URL scheme, so we could stick
> with
> > > "info_view".
> > >
> > > Move signup.html into the new "views" folder.
> > >
> > > My questions for everyone:
> > >
> > > Does this all sound OK?
> > > Any suggestions how it could be improved or anything I'm missing that
> is
> > a
> > > reason we shouldn't do this?
> > > If we do it, what release should it go in to?
> > > If necessary, we can set up rewrite rules so that old bookmarks still
> > work.
> > > Does anyone think this would be necessary?
> > >
> > > If everyone is more or less OK with it, I'll create a ticket and then
> get
> > > to
> > > work on it as time allows.
> > >
> > > Thanks,
> > > Ethan
> > >
> >
> >
> >
> > --
> > Best Regards,
> > Vladimir Ivanov
> >
>



-- 
Best Regards,
Vladimir Ivanov

Re: Proposed ESME URL redesign

[Ethan Jewett <es...@gmail.com>]

Hey Vladimir,

I thought this idea might be half-baked :-) Thanks for taking a look at it.

So, my thought was to do it like we do for the 'tags' page currently. But
that uses a rewrite rule (your suggestion #3). Which makes me wonder why we
wouldn't just put the templates where they are supposed to be and dispense
with the rewrite rules completely (your suggestion #1).

What do you think would be the best way?

Cheers,
Ethan

On Thu, Apr 28, 2011 at 1:22 PM, Vladimir Ivanov <le...@gmail.com>wrote:

> Hi Ethan!
>
> Sounds reasonable for me. I have one question:
>
> Take, for example, public page. It is defined in Boot.scala
> as: Menu(Loc("public", List("info_view", "public")... and it correspondes
> to
> '/info_view/public.html' URL.
>
> You've proposed to change this URL to '/public'. How should it be mapped in
> SiteMap:
>
> 1) Menu(Loc("public", List("public")... which correspondes to 'public.html'
> template in root folder?
>
> 2) Menu(Loc("public", List("public", "some_template")... corresponding to
> /public/some_template.html ?
>
> 3) Rewrite request so that when user asks for /public URL it will be
> redirected to /views/public.html (where views is a single common folder for
> all templates )?
>
> Sorry if I missed something in your inital explanation.
>
> Thanks,
> Vladimir
>
>
> 2011/4/28 Ethan Jewett <es...@gmail.com>
>
> > Hi all,
> >
> > [Note, this has been sitting in draft format for forever. So I'm just
> > cut-and-pasting it and throwing it out to everyone.]
> >
> > I've been doing a fair amount of work on the front-end templates lately
> and
> > I've noticed that the template and URL organization isn't currently very
> > consistent. I think this has just happened over the last year or so as
> > we've
> > added and changed things without a view to consistency, but maybe I'm
> > missing a greater organizational scheme here. If so, let me know :-)
> >
> > I'd like to propose making the following changes to the URL scheme:
> >
> > Current (mostly right, I think):
> >
> > / (index)
> > /info_view/public
> > /info_view/users
> > /info_view/streams
> > /info_view/contacts
> > /user/USERNAME (remapped from info_view/user)
> > /profile_view/edit
> > /track_view/
> > /action_vew/
> > /auth_view/
> > /pools_view/
> > /conversation/CONVID  (remapped from info_view/conversation)
> > /tag/TAGNAME
> > /logout
> > /info_view/search?SEARCHQUERY
> >
> > /api (original api)
> > /api2 (new api)
> > /twitter (twitter api)
> >
> >
> > Proposed:
> >
> > / (index)
> > /public
> > /users
> > /users/USERNAME
> > /streams
> > /contacts (do we even need this any more?)
> > /profile
> > /tracks
> > /actions
> > /tokens
> > /pools
> > /conversations/CONVID
> > /tags/TAGNAME
> > /logout
> > /search?SEARCHQUERY
> >
> > ... plus API stuff, which would not change.
> >
> > I'd also like to propose making the following change to template
> > organization:
> >
> > Reorganize all the main templates under a single folder, so action_view,
> > auth_view, pools_view, profile_view, and track_view folders would go
> away.
> > We would change the name of the info_view folder to something like
> "views",
> > though this would never show up in the URL scheme, so we could stick with
> > "info_view".
> >
> > Move signup.html into the new "views" folder.
> >
> > My questions for everyone:
> >
> > Does this all sound OK?
> > Any suggestions how it could be improved or anything I'm missing that is
> a
> > reason we shouldn't do this?
> > If we do it, what release should it go in to?
> > If necessary, we can set up rewrite rules so that old bookmarks still
> work.
> > Does anyone think this would be necessary?
> >
> > If everyone is more or less OK with it, I'll create a ticket and then get
> > to
> > work on it as time allows.
> >
> > Thanks,
> > Ethan
> >
>
>
>
> --
> Best Regards,
> Vladimir Ivanov
>

Re: Proposed ESME URL redesign

[Vladimir Ivanov <le...@gmail.com>]

Hi Ethan!

Sounds reasonable for me. I have one question:

Take, for example, public page. It is defined in Boot.scala
as: Menu(Loc("public", List("info_view", "public")... and it correspondes to
'/info_view/public.html' URL.

You've proposed to change this URL to '/public'. How should it be mapped in
SiteMap:

1) Menu(Loc("public", List("public")... which correspondes to 'public.html'
template in root folder?

2) Menu(Loc("public", List("public", "some_template")... corresponding to
/public/some_template.html ?

3) Rewrite request so that when user asks for /public URL it will be
redirected to /views/public.html (where views is a single common folder for
all templates )?

Sorry if I missed something in your inital explanation.

Thanks,
Vladimir


2011/4/28 Ethan Jewett <es...@gmail.com>

> Hi all,
>
> [Note, this has been sitting in draft format for forever. So I'm just
> cut-and-pasting it and throwing it out to everyone.]
>
> I've been doing a fair amount of work on the front-end templates lately and
> I've noticed that the template and URL organization isn't currently very
> consistent. I think this has just happened over the last year or so as
> we've
> added and changed things without a view to consistency, but maybe I'm
> missing a greater organizational scheme here. If so, let me know :-)
>
> I'd like to propose making the following changes to the URL scheme:
>
> Current (mostly right, I think):
>
> / (index)
> /info_view/public
> /info_view/users
> /info_view/streams
> /info_view/contacts
> /user/USERNAME (remapped from info_view/user)
> /profile_view/edit
> /track_view/
> /action_vew/
> /auth_view/
> /pools_view/
> /conversation/CONVID  (remapped from info_view/conversation)
> /tag/TAGNAME
> /logout
> /info_view/search?SEARCHQUERY
>
> /api (original api)
> /api2 (new api)
> /twitter (twitter api)
>
>
> Proposed:
>
> / (index)
> /public
> /users
> /users/USERNAME
> /streams
> /contacts (do we even need this any more?)
> /profile
> /tracks
> /actions
> /tokens
> /pools
> /conversations/CONVID
> /tags/TAGNAME
> /logout
> /search?SEARCHQUERY
>
> ... plus API stuff, which would not change.
>
> I'd also like to propose making the following change to template
> organization:
>
> Reorganize all the main templates under a single folder, so action_view,
> auth_view, pools_view, profile_view, and track_view folders would go away.
> We would change the name of the info_view folder to something like "views",
> though this would never show up in the URL scheme, so we could stick with
> "info_view".
>
> Move signup.html into the new "views" folder.
>
> My questions for everyone:
>
> Does this all sound OK?
> Any suggestions how it could be improved or anything I'm missing that is a
> reason we shouldn't do this?
> If we do it, what release should it go in to?
> If necessary, we can set up rewrite rules so that old bookmarks still work.
> Does anyone think this would be necessary?
>
> If everyone is more or less OK with it, I'll create a ticket and then get
> to
> work on it as time allows.
>
> Thanks,
> Ethan
>



-- 
Best Regards,
Vladimir Ivanov