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 <[email protected]> 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 <[email protected]>
>
>> 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 <[email protected]
>> >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 <[email protected]>
>> >
>> > > 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
>

Reply via email to