Stefan Evans wrote:Right so you have multiple pages returned and included in your project.
How do you decide which JSP page (out of the numerous available) to invoke?
How is this different from knowing which module to invoke?
Stefan Evans wrote:Ok then. Lets assume that you would generate a new jsp page. You now have a page for each module.
How would you then decide which page to invoke?
Stefan Evans wrote:I still maintain that editing JSP pages at runtime is a bad idea.
In the example you gave, the only customisation you wanted to make was the name of the bean in session to access the data for.
And you don't need to do it at all.
You asked the question: "How does the bean know which data to take from session?"'
Your answer was: "He doesn't."
My answer to that question would be: You tell it.
Presumably your backing bean should only reference/work with one specific module at a time.
You say you can have multiple instances of module, so I would keep a Collection of them in session - probably as a map in fact.
You then retrieve the correct module you want to work with from the session map, set it on your backing bean, and display the page.
By decoupling the page from your data storage, you can reuse that same JSP template page for all of your module data, and avoid having to generate files at runtime.
Tim Holloway wrote:Dependency Injection is nothing more than a process where beans are wired together from outside rather than requiring the beans to reach out and find stuff (which requires them to have explicit logic coded into them).
For actual database testing, you might want to look at dbUnit. You can create a JSF webapp, and you can definitely inject objects to be tested into it, but that may be overkill for you.
Guy deLyonesse wrote:
Vladislav Simovic wrote:
Can you elaborate more on this, I am not familiar with this tehnique?
Prettymuch any decent JSF book explains it.![]()
Dieter Quickfend wrote:Why not use Dependency Injection in the backing bean? That's pretty much what they mean by Inversion of Control, you know.
Dieter Quickfend wrote:
where certainI18nString is a property in your backing bean containing your internationalized string.