Strange rewriting behaviour

[Jeppe Nejsum Madsen]

Hi,

During addition of some new features, I found something odd:

I have two Locs that both contain a rewrite function:

Loc1: assets/edit/x -> assets/edit
Loc2: assets/x/edit -> assets/edit

What happens is that if I hit the url in Loc2, the calcTemplate of
Loc1 is called, but the snippets from Loc1 is used (I think, since
they're not the same the template doesn't render) ...

This strikes me as odd. Never mind the fact that the two scenarios
above don't make sense, is this expected behavior?

/Jeppe

[David Pollak]

Yes.  The rewrite that's associated with a Loc does the rewrite.  Then the Req that comes out the other side of the rewrite is used to determine the Loc to use.
 

/Jeppe

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

[Jeppe Nejsum Madsen]

On Wed, Mar 17, 2010 at 4:53 PM, David Pollak
<feeder.of...@gmail.com> wrote:
>
>
> On Wed, Mar 17, 2010 at 8:25 AM, Jeppe Nejsum Madsen <je...@ingolfs.dk>
> wrote:
>>
>> Hi,
>>
>> During addition of some new features, I found something odd:
>>
>> I have two Locs that both contain a rewrite function:
>>
>> Loc1: assets/edit/x -> assets/edit
>> Loc2: assets/x/edit -> assets/edit
>>
>> What happens is that if I hit the url in Loc2, the calcTemplate of
>> Loc1 is called, but the snippets from Loc1 is used (I think, since
>> they're not the same the template doesn't render) ...
>>
>> This strikes me as odd. Never mind the fact that the two scenarios
>> above don't make sense, is this expected behavior?
>
> Yes.  The rewrite that's associated with a Loc does the rewrite.  Then the
> Req that comes out the other side of the rewrite is used to determine the
> Loc to use.

Yeah, that was what I was thinking. Is there a reason why it's not an
error to add two Locs with the same link.uriList? Iirc, this is not
possible with "normal" sitemap entries....

/Jeppe

[David Pollak]

Yeah... I guess it is an error.  Wanna open a ticket on it?
 

/Jeppe

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

[Jeppe Nejsum Madsen]

On Wed, Mar 17, 2010 at 5:25 PM, David Pollak

Yep, http://www.assembla.com/spaces/liftweb/tickets/423

/Jeppe

[tbje]

Hi,
Is there still a way to make multiple menu items point to the same
page?

I used to do:
val entries =
Menu(Loc("Home", List("index"), "Home")) ::
Menu(Loc("About", List("index"), "About")) ::
Nil

This approach throws a SiteMapException after ticket 423.

Trond

[Heiko Seeberger]

This change breaks one of my production apps! I have several menu items with the same link.

Why should it be an error to have several Locs with the same link.uriList?

What can we do?

Heiko

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

--
Heiko Seeberger

Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

[Jeppe Nejsum Madsen]

On Wed, Mar 24, 2010 at 12:25 PM, Heiko Seeberger
<heiko.s...@googlemail.com> wrote:
> This change breaks one of my production apps! I have several menu items with
> the same link.
> Why should it be an error to have several Locs with the same link.uriList?

Because it is not well defined which Loc is used for e.g. access
control when the link is accessed.

/Jeppe

[Timothy Perrett]

Agreed - this is the right behaviour IMHO.

Cheers, Tim

[David Pollak]

On Wed, Mar 24, 2010 at 4:25 AM, Heiko Seeberger <heiko.s...@googlemail.com> wrote:

This change breaks one of my production apps! I have several menu items with the same link.

Why should it be an error to have several Locs with the same link.uriList?

Can you explain the use case for this?

 

What can we do?

If I understand the reason for it, I can either roll back the patch or create a mechanism for saying "Yeah... this is okay."

--

[Heiko Seeberger]

On 24 March 2010 14:03, David Pollak <feeder.of...@gmail.com> wrote:

On Wed, Mar 24, 2010 at 4:25 AM, Heiko Seeberger <heiko.s...@googlemail.com> wrote:

This change breaks one of my production apps! I have several menu items with the same link.

Why should it be an error to have several Locs with the same link.uriList?

Can you explain the use case for this?

Very simple: There are several menu items that point to the same Loc/link/template.

My client has got a complex website with a complex menu and some important links are accessible as "favorites".

 

What can we do?

If I understand the reason for it, I can either roll back the patch or create a mechanism for saying "Yeah... this is okay."

I already rolled the commit back locally, but this will only last for today. I would appreciate if you could roll back the commit until we find a solution that satisfies all needs.

Heiko

[Timothy Perrett]

Cant you just use rewriting?

Cheers, Tim

[Heiko Seeberger]

On 24 March 2010 14:36, Timothy Perrett <tim...@getintheloop.eu> wrote:

Cant you just use rewriting?

Maybe, but that seems to me any ugly fix introducing unnecessary complexity. Please consider also that there seem to be others affected by this change (see this thread) and I am pretty sure that others will be affected.

Please let's roll back and then discuss the solution for the following requirements:

1. We need to support multiple menu items to the same location

2. We need to access protect the location uniquely (if I understand the issue related to #423 correctly)

Heiko

--
Heiko Seeberger

[David Pollak]

On Wed, Mar 24, 2010 at 6:33 AM, Heiko Seeberger <heiko.s...@googlemail.com> wrote:

On 24 March 2010 14:03, David Pollak <feeder.of...@gmail.com> wrote:

On Wed, Mar 24, 2010 at 4:25 AM, Heiko Seeberger <heiko.s...@googlemail.com> wrote:

This change breaks one of my production apps! I have several menu items with the same link.

Why should it be an error to have several Locs with the same link.uriList?

Can you explain the use case for this?

Very simple: There are several menu items that point to the same Loc/link/template.

I'm looking for a use case.  I understand that you have set things up this way, but I don't understand why and without an understanding, it seems like a bad design.  So, please help me understand.

 

My client has got a complex website with a complex menu and some important links are accessible as "favorites".

Do all of these menu items have the same name?

Do all of the pages render the same or is there some mechanism on the page that determines what the real page is?

When you click on any given link that points to the same place, which menu item should be highlighted (put another way, what are your breadcrumbs)?

 

 

What can we do?

If I understand the reason for it, I can either roll back the patch or create a mechanism for saying "Yeah... this is okay."

I already rolled the commit back locally, but this will only last for today. I would appreciate if you could roll back the commit until we find a solution that satisfies all needs.

Heiko

Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

--

[David Pollak]

On Wed, Mar 24, 2010 at 6:47 AM, Heiko Seeberger <heiko.s...@googlemail.com> wrote:

On 24 March 2010 14:36, Timothy Perrett <tim...@getintheloop.eu> wrote:

Cant you just use rewriting?

Maybe, but that seems to me any ugly fix introducing unnecessary complexity. Please consider also that there seem to be others affected by this change (see this thread) and I am pretty sure that others will be affected.

Please let's roll back and then discuss the solution for the following requirements:

1. We need to support multiple menu items to the same location

I don't see this as a requirement and until I see a use case, I don't agree that this is a requirement.

 

2. We need to access protect the location uniquely (if I understand the issue related to #423 correctly)

We need to help people not have incorrectly designed menus.  It is incorrect in my opinion and Jeppe's opinion to have two different menu items pointing to the same URL.  That's the meaning of the ticket and that's what I implemented.

Thanks,

David

--

[Heiko Seeberger]

Do all of these menu items have the same name?

No, that won't work: Even before the change the name had to be unique.

 

Do all of the pages render the same or is there some mechanism on the page that determines what the real page is?

Different menu items point to the same page that renders the same.

 

When you click on any given link that points to the same place, which menu item should be highlighted (put another way, what are your breadcrumbs)?

Let me give you an example:

There are two menu items A and B with Locs a and b (the Loc names) that both point to the template x/y/z.html. When either A or B is clicked the teplate x/y/z.html is to be rendered and both A and B are "highlighted". Please know that we use our own snippets to render the very complex menu.

Heiko

[Heiko Seeberger]

Please let's roll back and then discuss the solution for the following requirements:

1. We need to support multiple menu items to the same location

I don't see this as a requirement and until I see a use case, I don't agree that this is a requirement.

 

2. We need to access protect the location uniquely (if I understand the issue related to #423 correctly)

We need to help people not have incorrectly designed menus.  It is incorrect in my opinion and Jeppe's opinion to have two different menu items pointing to the same URL.  That's the meaning of the ticket and that's what I implemented.

OK, another example: github.com

There are two "menus" pointing at github.com => The Dashboard link (menu item) in the top menu and the github logo in the upper left corner. OK the logo is not a menu item, but it makes the use case clear: Sometimes it is important to have several ways to access a certain page. In my case we have one menu item in the top menu (always visible, because the link is very important) and another menu item in a nested structure (the location where it belongs to structurally wise).

Heiko

[Jeppe Nejsum Madsen]

On Wed, Mar 24, 2010 at 4:55 PM, Heiko Seeberger
<heiko.s...@googlemail.com> wrote:
>>> Please let's roll back and then discuss the solution for the following
>>> requirements:
>>> 1. We need to support multiple menu items to the same location
>>
>> I don't see this as a requirement and until I see a use case, I don't
>> agree that this is a requirement.
>>
>>>
>>> 2. We need to access protect the location uniquely (if I understand the
>>> issue related to #423 correctly)
>>
>> We need to help people not have incorrectly designed menus.  It is
>> incorrect in my opinion and Jeppe's opinion to have two different menu items
>> pointing to the same URL.  That's the meaning of the ticket and that's what
>> I implemented.
>
> OK, another example: github.com
> There are two "menus" pointing at github.com => The Dashboard link (menu
> item) in the top menu and the github logo in the upper left corner. OK the
> logo is not a menu item, but it makes the use case clear: Sometimes it is
> important to have several ways to access a certain page. In my case we have
> one menu item in the top menu (always visible, because the link is very
> important) and another menu item in a nested structure (the location where
> it belongs to structurally wise).

I think the fundamental issue here is that Loc both defines the menu
structure and what happens on any given URL.

I agree that there are use cases for having the same URL accessible
from different places in an app. But some subset of this this is still
possible by creating an anchor tag pointing to the Loc (ie the Github
logo case). In your

But to me Loc is mostly about defining what happes on any given URL
(ie access control, what template to render, what rewriting to do
etc). Here it simply doesn't make sense to have several Locs with the
same url.

So, I think the current solution is correct, but maybe it is breaking
too much without a clear workaround (it broke my production app as
well, but both cases turned out to be errors in the menu structure!).

So what to do? I see a few options:

1) Optionally define the menu text in Menu. Then you could add the
same Loc to different menus:

val loc = Loc(...)
val entries =
Menu(loc, "Home") ::
Menu(loc, "About" ::
Nil

In fact, since you do your own menu rendering, can't you just subclass
Menu like the above and do the correct rendering?

2) Make a special cased LocAlias:

val loc = Loc(...)
val alias = LocAlias(loc, "About")
val entries =
Menu(loc) ::
Menu(alias) ::
Nil

I don't really know the inner workings of sitemap well enough to see
if there are issues with any of these solutions...and there may be
better ones.

You still end up with the problem of identifying the correct
breadcrumb to a given URL: Is it About or Home?

/Jeppe

/Jeppe

[Timothy Perrett]

So what would happen if you defined on link A a bunch of LocParam, and then on link B a different set of LocParam... how would lift know what to do?

<playing devils advocate />

Cheers, Tim

[Timothy Perrett]

Jeppe, this sounds like a great response.

Heiko, this should work for you right?

Cheers, Tim

[Heiko Seeberger]

Jeppe,

Thank you for your helpful answer!

On 24 March 2010 17:16, Jeppe Nejsum Madsen <je...@ingolfs.dk> wrote:

I think the fundamental issue here is that Loc both defines the menu

structure and what happens on any given URL.

Yep, concerns are not separated.

 

I agree that there are use cases for having the same URL accessible
from different places in an app.

Thank you.

 

But some subset of this this is still
possible by creating an anchor tag pointing to the Loc (ie the Github
logo case). In your

Sounds good! What exactly are you talking about? What's an anchor tag? Could you please give me an example?

 

But to me Loc is mostly about defining what happes on any given URL
(ie access control, what template to render, what rewriting to do
etc). Here it simply doesn't make sense to have several Locs with the
same url.

Well, it depends. Sometimes you will not define any special behavior (no LocParams at all). Then Loc is *only* about menu structure. Lift *must* support all use cases, right?

 

1) Optionally define the menu text in Menu. Then you could add the
same Loc to different menus:

val loc = Loc(...)
val entries =
    Menu(loc, "Home") ::
    Menu(loc, "About" ::
    Nil

In fact, since you do your own menu rendering, can't you just subclass
Menu like the above and do the correct rendering?

Sounds great! Separates concerns, should work.

 

2) Make a special cased LocAlias:

val loc = Loc(...)
val alias = LocAlias(loc, "About")
val entries =
    Menu(loc) ::
    Menu(alias) ::
    Nil

What's a LocAlias?

Heiko

[David Pollak]

Okay,

How about if there's an AllowDuplicationURI parameter that can be added to the Loc?  You would have to make explicit that you intend the URI to be a duplicate.  This allows you to achieve your goal at the expense of verbosity.

Thanks,

David

--

You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

--

[Jeppe Nejsum Madsen]

On Wed, Mar 24, 2010 at 5:50 PM, Heiko Seeberger
<heiko.s...@googlemail.com> wrote:

[...]

>> But some subset of this this is still
>> possible by creating an anchor tag pointing to the Loc (ie the Github
>> logo case). In your
>
> Sounds good! What exactly are you talking about? What's an anchor tag? Could
> you please give me an example?

Basically just an <a/> tag:

<lift:Menu.item name="home">About</lift:Menu.item>

will render the "home" loc somewhere with the text "About"

>> But to me Loc is mostly about defining what happes on any given URL
>> (ie access control, what template to render, what rewriting to do
>> etc). Here it simply doesn't make sense to have several Locs with the
>> same url.
>
> Well, it depends. Sometimes you will not define any special behavior (no
> LocParams at all). Then Loc is *only* about menu structure.

Well yes, but this is just a special case of the more general scenario.

> Lift *must* support all use cases, right?

I don't know :-)

>> 1) Optionally define the menu text in Menu. Then you could add the
>> same Loc to different menus:
>>
>> val loc = Loc(...)
>> val entries =
>>     Menu(loc, "Home") ::
>>     Menu(loc, "About" ::
>>     Nil
>>
>> In fact, since you do your own menu rendering, can't you just subclass
>> Menu like the above and do the correct rendering?
>
> Sounds great! Separates concerns, should work.
>
>>
>> 2) Make a special cased LocAlias:
>>
>> val loc = Loc(...)
>> val alias = LocAlias(loc, "About")
>> val entries =
>>     Menu(loc) ::
>>     Menu(alias) ::
>>     Nil
>
> What's a LocAlias?

Just a possible future Loc subclass I made up, that makes it explicit
that this Loc as actually just an alias for another Loc and it is the
other Loc that controls the LocParams.

/Jeppe

[Jeppe Nejsum Madsen]

Well, it doesn't really solve the issues of LocParams in a nice way,

What happens here:

val entries =
Menu(Loc("Home", List("index"), "Home", User.testSuperUser,
AllowDuplicationURI)) ::
Menu(Loc("About", List("index"), "About",AllowDuplicationURI)) ::
Nil

Do you have to be super user or not to see the index? Granted, it is
up the developer to make sure it makes sense. But maybe as an interim
solution until a more permanent one is found?

My LocAlias class above would make it more explicit that this Loc is
really an alias for another Loc and it is the other Loc that controls
the LocParams.

But none of the methods really solve the fundamental issue of
separating the concerns between URI mapping & menu structure.....

/Jeppe

[Heiko Seeberger]

This starts becoming a very valuable discussion!

Until we find a good solution, would it be possible to revert the commit?

Heiko

Heiko Seeberger

[David Pollak]

On Wed, Mar 24, 2010 at 11:18 AM, Heiko Seeberger <heiko.s...@googlemail.com> wrote:

This starts becoming a very valuable discussion!

Until we find a good solution, would it be possible to revert the commit?

There is a solution right now:

Menu(Loc("Foo", List("place"), "Foo")) ::
Menu(Loc("Foo2", List("placex") /* this used to be List("place") */, "Other Foo", Template(() => TemplateFinder.findAnyTemplate(List("place")) openOr NodeSeq.Empty))) ::
Nil

So, you specify a different URL for each page, but use the same template.
 

[Heiko Seeberger]

On 24 March 2010 19:47, David Pollak <feeder.of...@gmail.com> wrote:

On Wed, Mar 24, 2010 at 11:18 AM, Heiko Seeberger <heiko.s...@googlemail.com> wrote:

This starts becoming a very valuable discussion!

Until we find a good solution, would it be possible to revert the commit?

There is a solution right now:

Menu(Loc("Foo", List("place"), "Foo")) ::
Menu(Loc("Foo2", List("placex") /* this used to be List("place") */, "Other Foo", Template(() => TemplateFinder.findAnyTemplate(List("place")) openOr NodeSeq.Empty))) ::
Nil

So, you specify a different URL for each page, but use the same template.

Thank you. Looks good, will try soon.

Heiko

[Ross Mellgren]

So this change has broken our application (this is why I keep production pinned to a milestone release :-) )

Our use case is this:

We have a very large web application with a complicated menu structure. Most of the application does not use Lift.

We have one, going to be more Lift-based WARs running in the same container and integrated visually with the remainder of the app.

We use a chunk of code to read out our (non-Lift) master navigation/sitemap from its home grown XML and then create sitemap entries for it.

Our master navigation has duplicates and things.

So,

we cannot use this work around (there is no Lift templating, it's external to the Lift portion of the app)

we do have duplicates

It's unfortunate that David is on vacation, since he's a key part of this conversation, but I really wish this change were undone while we figure out something that can address it.

-Ross

[David Pollak]

On Tue, Mar 30, 2010 at 11:43 AM, Ross Mellgren <dri...@gmail.com> wrote:

So this change has broken our application (this is why I keep production pinned to a milestone release :-) )

Open a ticket for me on M4.  I'll put a flag in to disable to enforcement.
 

--

[Ross Mellgren]

On Apr 3, 2010, at 9:22 PM, David Pollak wrote:

On Tue, Mar 30, 2010 at 11:43 AM, Ross Mellgren <dri...@gmail.com> wrote:

So this change has broken our application (this is why I keep production pinned to a milestone release :-) )

Open a ticket for me on M4.  I'll put a flag in to disable to enforcement.

http://www.assembla.com/spaces/liftweb/tickets/455-ability-to-disable-unique-loc-check

Thanks.

-Ross