Julian,
Although my question was about images, I am looking for a generalized
solution that can be used with many type of files, so your "custom
component api" sounds very interesting.
Can you expand on the "custom component api"?
If you would rather continue this offline, you may email me directly.
Paul Spencer
Julian Ray wrote:
Hmmm, let see...
as many of our charts require different params, as well as some core params
to be sent, we naturally end up duplicating a lot of code in the backing
beans. Even refactoring this code into base classes did little to help. This
duplicated code has as couple of negatives: [1] its duplicated, therefore,
inefficient for many reasons, maintenance not the least among them, [2] the
URLs and servlets we create need to be on the same lifecycle which is not
necessarily the same as the JSF pages and backing beans -- we reuse the
servlet across several JSF services, and [3] as we extend the charting
functionality there is a lot of unnecessary testing and code changes which
is minimized if the backing beans work against the custom component api.
Lastly, its cleaner and much more JSF-ish :)
<professorial soap-box rant>
Typically, as in most designs, if your problem is not too complex, a simple
solution will work fine (eg servlet and URL). As the problem complexity
increases, however, more elegant solutions are necessary hence the custom
component. Indeed we started with backing bean URLs then migrated to a
custom component during the course of several code refactoring phases - a
pattern we repeated for JasperReports and other functionality as well.
To address Cagatay's comments:
[1] A phase listener would probably be preferable to a servlet and I intend
to migrate (or at least benchmark) a phase listener to replace our servlet.
However, often when beginning with a new technology staying within the
bounds of our experience at, least initially, can be beneficial, especially
when using an agile approach to development where speed of development and
delivered functionality are driving forces. Basically, if you know how to
code servlets and are comfortable coding servlets, use a servlet and when it
all works migrate to something better but get it to work first.
[2] I have not yet tried the JSF-Chart Creator in JSF-COMP although I have
heard good things about it and fully intend to take a look. However, this
goes back to my initial rant and if JSF-COMP does everything you need (at
least for now) why not use it -- it was not available when we started our
current build cycle :).
</professorial soap-box rant>
-----Original Message-----
From: Paul Spencer [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 29, 2006 9:51 AM
To: MyFaces Discussion
Subject: Re: How to displayi an images generated by a managed bean?
Julian,
Can you expand on this?
One more note, While this approach works well found that it is more
convienient to create a custom component to provide the JSF interface
as we use charts on a large number of our pages and it fits the MVC
model better to let the JSF fuly control the format and display of the
greaphic.
Your responses have been very helpful.
Paul Spencer
