Balaji Saranathan wrote:
Hi,
I'm trying to understand JSF application development by creating a
Contacts Management page. I have the list of contacts in a XML format -
each contact represented by a ContactBean, incidentally the backing bean.
Does it make good sense to separate the event handling methods of the
backing bean to a more meaningful say, ContactsHandler class and leave
the ContactBean with just the getters and setters. I read one good thing
about JSF is to tie the action methods on the properties of the beans in
the backing bean class. Does such a thing in this case - having all the
Yes most JSF patterns follow the way of tying the model and controllers
together, it is easier to understand that way (and easier for keeping
track of objects and also easier for the tool builders), the by the
books approach would be however to have separate controller and model
and in the long run also cleaner to maintain, but you have another bunch
of artefacts more if you do it that way.
updating methods, summary results etc, add any performance overhead?
Also, how would I handle such a Bean - at the session level or the
request level?
I would not worry about the performance overhead too much in this case.
You try to think to soon and in the wrong parts about performance.
First of all you are in a web centric context, and you have to access data.
What happens is, that you send a request over a medium latency line
(which the internet is), you access the database, the database accesses
the disk sends the data back and over the line, and the browser has to
render all that stuff.
adding a log(n) complexity which ram only access, by moving the
controller into IOC to all this latency stuff with things, which are
accessed every few minutes on one users side best, does not really make
that much difference. There are areas which have a much bigger impact on
performance (like hitting the database, or in your case, if the xml file
is bigger, which method you use to parse the file)
how your algorithms generally are etc...
So go the way you like and you feel generally save with, I�d say.
I for instance skipped IOCing the controller and connected the model
and the controller together via plain old delegation.
The access to this follows following scheme:
#{backingbean.delegate.property}
That way I still have a separate logic, but I did not have to IOC it
(which I didnt like to do in that case) and I can generated eposed
delegate methods on the fly via Eclipse, if I need it.
