Jacob Orshalick

Author
+ Follow
since Mar 30, 2009
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jacob Orshalick

And I'm glad you liked the post, hope it helps out
11 years ago
The @Factory basically allows you to initialize a context variable on request. Take a look at the Seam reference docs to learn more about this.

@BypassInterceptors allows you to avoid interception when a method on a Seam component is invoked. This is really a performance tuning technique for those values that need to be retrieved from a Seam component, but are only available by calling on that Seam component.

When to access a value through a component vs. initializing it as a context variable is really situational. I tend to initialize context variables for values that I access frequently.
11 years ago

There's just no way from keeping Seam in calling the variables more than once, right?



It is actually JSF that does this when rendering the response, not Seam. If you are accessing the variables as #{myBackingBean.customerComboBox} then yes, it is likely the get method will be invoked more than once during page rendering. The @BypassInterceptors annotation allows you to avoid the overhead of interception by Seam when the get method is invoked by JSF.

I think I have made the invocation of the class variables in the backing bean only once already by instantiating them in the init block with the @Init annotation.



Yes, the init block will initialize the class variables only once, but that init method will be invoked every time the component is created. This means that if your component is scoped to EVENT, it would be invoked every time the page is loaded. If it is scoped to the conversation, every time the conversation is started and so on... In other words, depending on the scenario, the DB access in the init block could still be the performance bottleneck. Caching could certainly help if that is the case.
11 years ago
Then I guess it would be a really good contribution Have you posted a JIRA for this?
11 years ago
Basically when a page belongs to a long-running conversation (LRC), a conversation identifier (cid) is sent as part of the response when the page is rendered. When you leave that page and navigate around the application or even to another site, you can use the back-button to return to the page. When you then click a link or button on the page, the cid is sent back with the form allowing Seam to identify the conversation associated with the page. The request is then processed within the context of the conversation.

How this works is described in-depth with diagrams and discussion in chapter 8 of the book. I hope that helps.
11 years ago
Basically you don't need an extra UI layer when using Seam. You can bind JSF components directly to POJOs or EJBs which inject the EntityManager directly to perform DB operations. This avoids an extra UI layer and you can avoid the addition of DAOs. This may not be feasible in all cases, but can greatly simplify your application.
11 years ago
If you get a chance to pick up the book, there are a number of illustrations in chapter 8, 9, and 10 describing conversation scope in-depth (from basic conversations, to concurrent conversations, and nest conversations). The process scope is also discussed in-depth in chapter 24.
11 years ago
If the list of elements in the combo-box changes rarely (e.g. mostly reference data), you could try caching the queries using the second-level cache of your ORM provider. After the initial load this will speed up subsequent loads of the data dramatically as the data will simply be pulled from cache in-memory. ORM second-level caching is discussed in the multi-layer caching chapter as well
11 years ago
Thanks, it was a blast! Congratulations to the winners and thank you to all who participated.
11 years ago
Have you tried the command: seam generate-ui? It generates an application from existing JPA/EJB3 entities placed into the src/model folder. seam-gen can help you to get started quickly, but there are certainly going to be specific scenarios that are not addressed that will have to be customized by the developer.
11 years ago
Odd... I suppose you could try surrounding the data table with an a4j: outputPanel and give it a unique id. You could then specify the id of the outputPanel in the reRender attribute of the a4j:commandLink. This would at least give you an idea of whether the data table is the culprit or if there is some other issue going on in your form.
11 years ago
When introducing a concept that is not specific to JSF it is covered in a more conceptual matter. For example, when discussing conversations and persistence context management, we demonstrate through diagrams and discussions that apply regardless of what presentation layer you happen to be using. Once you get into the more detailed discussions you will find that the code examples are implemented using JSF, but many of the APIs remain the same regardless of your presentation layer so should be easily translated.

There are certainly discussions in the book that are specific to JSF, but that comes with the territory as one of the original goals of Seam was to resolve the issues associated with using JSF
11 years ago
Yes, you can definitely do this with richfaces through the reRender attribute. If you are using a4j:commandLink specify the id of the data table in the reRender attribute. Also make sure that the action you are invoking from the a4j:commandLink returns void as you are returning to the same page.
11 years ago

example, users logged into windows desktop can seamlessly access seam apps without login



I have actually been working through this with JBoss Negotiation and Kerberos authentication. The UserPrincipal gets initialized in the web context by JBoss Negotiation and you can use this principal to auto-login the user with a custom authenticator. Your authenticator can also use the user information to retrieve the roles associated with the user or if you are using Seam 2.1 by providing a role identity store. You can also provide an identity store for fallback authentication (e.g. through LDAP or some other means) should the Kerberos authentication fail.
11 years ago

Are there any plans for adding things like HibernateSearch templates or some other classes to help reduce the boiler plate code and provide a great way to see what Seam is doing and how best to leverage it?



This is definitely a good idea and would be a great place for you to contribute ;) I would certainly like to see this added for my own use.
11 years ago