GET parameters

[lavoir]

Hello

I been going over Seam and will definatetly try it out. I was pleasantly surprised with all the example applications provided.

But as always, questions come to mind given the type of applications I had to build over the years.

1- Alot of the applications I have built in the past relied on dynamic URLs to get content indexed. In a pure business app scenario, our users need the ability to send specific URLs pointing to specific POs, reports, etc

With my last JSF protoype, I used UrlRewriteFilter to remap the URLS and its method invocation to set the GET parameters to a session bean.

What would be the correct way to handle this with Seam?


2- Another hurdle I faced while developing with JSF was having to jump though hoops to dynamically add components to views based on data.
For example, creating views based on metadata or simply adding an unknown number additional property checkboxes.
Any thoughts on handling this with Seam?

Ren

[gavin.king]

Ugh, I should get Jacob or someone to answer these questions, since they are really JSF-specific stuff. I would guess that whatever is the correct solution in plain JSF is also the correct solution in Seam. Seam doesn't try to replace JSF as the UI component model.

[hookomjj]

"lavoir" wrote:
1- Alot of the applications I have built in the past relied on dynamic URLs to get content indexed. In a pure business app scenario, our users need the ability to send specific URLs pointing to specific POs, reports, etc

With my last JSF protoype, I used UrlRewriteFilter to remap the URLS and its method invocation to set the GET parameters to a session bean.

What would be the correct way to handle this with Seam?

JSF doesn't have a front controller as you are trying to create. What people do is specify a managed bean with pre-defined parameters in EL such as <property-value>#{param.id}</property-value> so when the bean is used within the page, the data would be set for invocation/use.

Soon Seam will support EL injection via annotations, but JSF, in general, doesn't enforce the procedures based off of URL as you've found out. Really, you have to look at where JSF and other component frameworks are going, where a single view (URL) may be used for long running conversations where relying on the request parameters isn't going to work. Your example though is very practical, it's just not easy to solve in JSF in a procedural manner.

"lavoir" wrote:
2- Another hurdle I faced while developing with JSF was having to jump though hoops to dynamically add components to views based on data.
For example, creating views based on metadata or simply adding an unknown number additional property checkboxes.
Any thoughts on handling this with Seam?

That would be out of Seam's realm and would be better represented with custom UIComponents, or document fragments. I've been tossing around the idea of generating CRUD content based on an EJB 3's metadata, but from a customization standpoint, it's not something that's easily re-usable for everyone.

[lavoir]

"hookomjj" wrote:

JSF doesn't have a front controller as you are trying to create. What people do is specify a managed bean with pre-defined parameters in EL such as <property-value>#{param.id}</property-value> so when the bean is used within the page, the data would be set for invocation/use.

Soon Seam will support EL injection via annotations, but JSF, in general, doesn't enforce the procedures based off of URL as you've found out. Really, you have to look at where JSF and other component frameworks are going, where a single view (URL) may be used for long running conversations where relying on the request parameters isn't going to work. Your example though is very practical, it's just not easy to solve in JSF in a procedural manner.

I guess what threw me off was the mention of not storing data on the httpsession.

"hookomjj" wrote:

That would be out of Seam's realm and would be better represented with custom UIComponents, or document fragments. I've been tossing around the idea of generating CRUD content based on an EJB 3's metadata, but from a customization standpoint, it's not something that's easily re-usable for everyone.

Again, when the docs mentionned managing state, for some reason, I thought view state, wich is what I had problems with adding components dynamically.

Guess, I should of wrapped my head in the code a bit longuer before posting, but thanks for clearing this up.

I guess it could even be possible to use Sun's java studio creator with a bit of setup efforts.

[hookomjj]

"lavoir" wrote:

I guess what threw me off was the mention of not storing data on the httpsession.

Again, when the docs mentionned managing state, for some reason, I thought view state, wich is what I had problems with adding components dynamically.

Guess, I should of wrapped my head in the code a bit longuer before posting, but thanks for clearing this up.

I guess it could even be possible to use Sun's java studio creator with a bit of setup efforts.

Seam does have a conversation state that matches the view state... so a request and post back, generally, but it can continue until you invoke an action that ends the conversation.

[lavoir]

"hookomjj" wrote:

JSF doesn't have a front controller as you are trying to create. What people do is specify a managed bean with pre-defined parameters in EL such as <property-value>#{param.id}</property-value> so when the bean is used within the page, the data would be set for invocation/use.

I been thinking about this particular case and how it would fit into Seam.

What I would assume is that a managed bean is defined in faces-config that accept the parameters, inject the parameters into an action bean that has an init method being called with @create that would load the data required by the page.

In fact, I assume that if your application entry page requires data from multiple entities, you would have an action class for the page that contains a method with the @create annotation that initializes the entities used on the page?

[gavin.king]

What I would assume is that a managed bean is defined in faces-config that accept the parameters

Is this possible in JSF? I thought it was not.

[lavoir]

What I would assume is that a managed bean is defined in faces-config that accept the parameters

Is this possible in JSF? I thought it was not.

Derek Yang Shen illustrated the concept in his article:
http://www.javaworld.com/javaworld/jw-07-2004/jw-0719-jsf.html

He demonstrates two ways, one of them is the following:

<managed-bean>
 <description>
 Backing bean that contains product information.
 </description>
 <managed-bean-name>productBean</managed-bean-name>
 <managed-bean-class>catalog.view.bean.ProductBean</managed-bean-class>
 <managed-bean-scope>request</managed-bean-scope>
 <managed-property>
 <property-name>id</property-name>
 <value>#{param.productId}</value>
 </managed-property>
 <managed-property>
 <property-name>serviceLocator</property-name>
 <value>#{serviceLocatorBean}</value>
 </managed-property>
 </managed-bean>

The second way, wich is wrapped in a convenience method in FacesUtils:

(String)FacesContext.getCurrentInstance().getExternalContext().getRequestParameterMap().get(name);

[lavoir]

Just checked out some of my old Sun JSF Studio Creator test code to see how I had done it.

 javax.servlet.http.HttpServletRequest req =
 (javax.servlet.http.HttpServletRequest) getExternalContext().getRequest();

 String keywordValue = req.getParameter("keyword");

[gavin.king]

We plan to support EL expressions in @In(...). There is an existing feature request in JIRA.

[lavoir]

We plan to support EL expressions in @In(...). There is an existing feature request in JIRA.

Yes hookomjj mentionned that and I m looking forward to it :)