[news.eclipse.webtools.jsf] Re: Reporting problems from AbstractContextS

[Vadim Dmitriev <dmgloss@xxxxxxx>]

On Tue, 2008-03-04 at 22:11 +0000, Cameron Bateman wrote:
> Hi Vadim,
> 
> You are partially correct.  There is some dangling code there, since the 
> problems never get used.   However, it was not intended to be used to 
> report problems to the problems view.  Instead was meant to report 
> information back to the framework.
> 
> What sort of problems are you trying to report?
> 
> 
> --Cam
> 

Where to start...

I hate the idea of implementing separate symbol factory for every
variable contributing attribute. So i wrote relatively
'universal' (funny word) factory that uses so-called "restrictions" to
validate EL runtime type and extract runtime type of contributed
variable from there. For example, h:dataTable will contribute variable
of following types:
1. if EL's type is scalar object, then contributed variable will be of
type of EL
2. if EL's type is array, then contributed variable will be that array
with one array dimension removed ( SomeObject[][] if EL is
SomeObject[][][] )
3. if EL's type is List, then contributed variable will have type of the
first (and only) List type argument.

This factory requires about 6-8 lines of XML data to describe such
behavior.

Let's say there is a component with attribute A (with EL) and attribute
B (with variable name). WTP JSF component provides an easy way to
validate EL type against set of classes. While this validation is
sufficient for almost all sutiations, it has several downsides that is
crucial in current situation: it doesn't validate array types for
compatibility, for example. So I thought of making EL type validation
somewhere in my factory to gain better performance, since all the
processing will be done only once (for attribute B). Finding proper
'restriction' is a step 1 to find proper contributed variable runtime
type(type validation is done indirectly). And here comes my need to
report 'problems' from symbol factory.

Now that i think of it: throwing ELIsNotValid expection when validation
fails and returning "java.lang.Object" + "java.lang.Enum" when
everything is ok is more or less better approach, than issuing problems
for contributing attribute from symbol factory. Caching can be done as
'time-restricted' map with keys as "EL runtime type + taglib URI + tag
name"...  
Your question lead me to the answer. Thanks! :)