Objects created from link with page params

[damianharvey]

I've just noticed that if I go to a page, Seam will look at all of the page.xml's for each link on the page and instantiate any objects referenced by page params. Is this expected?

For example if I have a page with 3 links eg: index.xhtml

<s:link view="/page1.xhtml">Page 1</s:link>
<s:link view="/page2.xhtml">Page 2</s:link>
<s:link view="/page3.xhtml">Page 3</s:link>

And each page has a page.xml with a page parameter eg:page1.page.xml

<param name="id" value="#{pageOneHome.Id}"/>

Then if I visit index.xhtml and look at /debug.seam I will see that pageOneHome, pageTwoHome and pageThreeHome will all be present. I would have thought that Seam would only need to create these objects when the links were actually clicked.

In my real case it means that every menu item that I have has it's backing bean created and any Beans that are injected into the Backing Bean with create=true.

This isn't a big deal, but does make it messy trying to determine when I actually do want an object created (I'm having some dramas with resetting some objects).

Cheers,

Damian.

[pmuir]

Because s:link transparently adds any page params referenced by s:link it has to run through all possible parameters when constructing the links.

[damianharvey]

Thanks Pete, but if the object does not currently exist in the conversation, why initialize one? It can't provide a value for a link if it doesn't yet exist.

Or is this needed so that Seam can push a value into the object from the link? If that is the case then why is it just not initialized when required?

What would you advise for an application with a large-ish memory system comprised of s:link's? The destination for each link will be created right?

Cheers,

Damian.

[valbosoft]

Ok, great tip about the event observer.

I think I'll just go for the @RequestParameter route, and set the Id when initInstance() is called; in a quick test it works.

Thanks for the replies.

Cheers, Bo

[pmuir]

Damian, I see what you are saying, however there are situations where you might want the it initialized (e.g. the value is provided by a factory) - so, yes, it can provide a value if it doesn't exist yet. And the current behaviour is consistent with the rest of Seam (when you reference a value using EL it's create=true and not just a lookup).

I'm not sure of the best solution, but will think about it some more.

[delphi'sghost]

(I know this is an old-ish post, but I came across it when I had another problem, so thought I'd chime in for the next person to come across it)

It seems like the current solution is to manually add a param to the link with the param name, and set it to null. This is what the contact example does for the New Contact link.

<s:link view="/myPageWithAParam.xhtml" value="Link">
 <f:param name="myParam" value=""/>
</s:button>

This way, seam looks at the link, sees that it has a param already (albeit a blank one) and carries on its merry way without instantiating an instance of the object that would provide the param value.

I wonder whether it would be worth a JIRA issue to suggest a flag on the param tag in pages.xml so the param is only added if the object already exists.

<param name="myId" value="#{myWidget.id}" required="false"/>

In this case, Seam would not create an instance of the widget if it didn't already exist and it would make the param blank.

If required was true, then it would create an instance and get the Id.

[matt.drees]

Thanks for posting a workaround. I'll have to look into that.


I've seen other forum posts when people want to use the "injection" part of page parameters, but not the "factory/outjection" part. I think it'd be worthwhile thinking through how things could be improved to give users more fine-grained control over what page params do.


By the way, the "required" attribute is taken already. It's used to indicate the parameter is required for that page.

[damianharvey]

Cheers for the tip. I'll give it a go as well.

Is there any reason why @RequestParameter doesn't have a 'required' parameter as well?

Cheers,

Damian.