On Oct 23, 2008, at 10:12 AM, Shane Bryzak wrote: It should be in the view, on the link. I can't see any way that trying to put this in pages.xml makes sense. Note that we already support this to some degree with <f:param name="whatever" value="" />. It's very tedious to put this on every link, especially when you have multiple page parameters, so having an easier way to set this on each particular link would be great.

On 23 Oct 2008, at 21:20, Dan Allen wrote: As Christian said, <f:param name="whatever" /> is probably the wrong syntax for this, as it implies you are adding a parameter, not removing it. Maybe we need an <s:suppressPageParameter name="foo" /> instead. I think we are agreed, a global turn-off on s:link is the best approach (if we want to do a global switch at all...). I suggest we call it suppressPageParameters="true".

On 24 Oct 2008, at 12:48, Christian Bauer wrote: I like this.

On 24 Oct 2008, at 20:10, Dan Allen wrote: Thanks :-) Actually it is possible to differentiate between the two in JSF (nothing to do with facelets). if (parameter.getValueExpression("value") == null) { // The markup was <f:param name="foo"/> } else if (parameter.getValue() == null) { / // The markup was <f:param name="foo" value="#{null}"/> } Christian, did you mean it this way around? To me, this syntax would create a link that only had the *foo* parameter (that's the way you described it to me on IM): <s:link view="one.xhtml" pageParameters="override"> <f:param name="foo"/> </s:link> and this only a bar parameter: <s:link view="one.xhtml" pageParameters="override"> <f:param name="bar"/> </s:link> So, specifying override requires you to specify any parameters you want to propagate on the link. Specifying a param without the value will cause the default value to be used from pages.xml, or you can specify a value. So in my scheme, this would propagate both foo and bar, with foo using it's default value. Under my scheme we don't need "ignore" , you would use: <s:link view="one.xhtml" pageParameters="override"> <f:param name="foo"/> </s:link> Encode isn't right, as that (to me) refers to encoding the parameter strings. This is really the same as <s:link view="one.xhtml" pageParameters="override"> <f:param name="foo" value="#{binding.other}" /> </s:link> I'm really not sure that the no-value-attribute is correct, so I think we should change it to your original suggestion Christian - that it causes a parameter to be propagated with the value got from pages.xml. I think as this is a new minor feature we can break it.

I don't want to disrupt the larger context of this thread, but <f:param name="whatever"/> and <f:param name="whatever" value="#{null}"/> are indistinguishable from the perspective of the Facelets tag handler. Both are interpreted as a null value. Thus, there is no way to enforce one or the other. Obviously, the second one is clearer and more semantically correct. This is one of those cases when Facelets is overly casual. -Dan -- Dan Allen Software consultant | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction NOTE: While I make a strong effort to keep up with my email on a daily basis, personal or other work matters can sometimes keep me away from my email. If you contact me, but don't hear back for more than a week, it is very likely that I am excessively backlogged or the message was caught in the spam filters. Please don't hesitate to resend a message if you feel that it did not reach my attention.

On Thu, Oct 23, 2008 at 11:12 AM, Shane Bryzak <shane.bryzak(a)jboss.com&gt; wrote: I completely agree that this is a problem...one that is significantly prominent in seam-gen projects because we put all those s:link tags in the menu bar. The s:link tag has other uses besides page parameters, yet currently there is no way to have one without the other. We need to give the user a way to severe the coupling. Putting a flag in the page descriptor makes no sense. The whole idea of the page parameter is that you don't have to worry about propagating the value. How does the page descriptor know when you need it and when you don't? This is a view/navigation concern. I have long said that we need a switch on the Seam command components (s:link and s:button) that turn off the appending of page parameters to the URL. When choosing an attribute name, let's try to keep the amount of typing to a minimum. Since it is likely to be used often, I would rather not have to type out a sentence. Here are some suggestions: <s:link ... pageParams="false"/> or <s:link ... pageParams="ignore"/> <s:link ... pageParameters="false"/> or <s:link ... pageParameters="ignore"/> <s:link ... encodePageParams="false"/> I don't like the idea of a negated switch (e.g., suppressPageParams). Then, in a conditional, you end up with suppressPageParams="false", which is a double negative. A value of "override" seems odd to me since overriding should always be possible. I guess if this is the default value, then you would only ever see it written out in a EL conditional. But it is misleading. I would prefer the switch to be true/false or true/ignore. In general, I see this as an issue of significance. For one, page parameters are causing components to be created when the developer may not want them to, so it's a performance thing. Second, it's makes developers annoyed with the Seam command components because they make it difficult to shake off a particular parameter when it isn't wanted. If we do add this attribute to the Seam command components, we need to also add it to the redirect directive in the page descriptor. -Dan -- Dan Allen Software consultant | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction NOTE: While I make a strong effort to keep up with my email on a daily basis, personal or other work matters can sometimes keep me away from my email. If you contact me, but don't hear back for more than a week, it is very likely that I am excessively backlogged or the message was caught in the spam filters. Please don't hesitate to resend a message if you feel that it did not reach my attention.