Home » Eclipse Projects » JavaServer Faces » Reporting problems from AbstractContextSymbolFactory
| |
Re: Reporting problems from AbstractContextSymbolFactory [message #475593 is a reply to message #475592] |
Tue, 04 March 2008 23:35 |
Vadim Dmitriev Messages: 74 Registered: July 2009 |
Member |
|
|
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! :)
|
|
| |
Re: Reporting problems from AbstractContextSymbolFactory [message #475600 is a reply to message #475594] |
Mon, 10 March 2008 02:34 |
Vadim Dmitriev Messages: 74 Registered: July 2009 |
Member |
|
|
Several cases, that can be improved:
I. Array case:
Let's take the following class declaration as starting point:
class ExtendedArrayElement extends ArrayElement{ ... }
1. Current type comparator compare non-simple-class signatures only as
Strings. I.e. A can be assigned to B if A = "[[[ArrayElement" and B =
"[[[ArrayElement" (signatures strings equals). And not if A =
"[[[ExtendedArrayElement", which is technically not correct.
2. There is one special case for arrays, which is not covered either: if
A = "[[[Ljava.lang.Object", then it can be assigned to B =
"[Ljava.lang.Object;", which TypeComparator reports as wrong.
II. Parametrized types case:
With parametrized types there are some complicated cases, all of which
drill to resolving type parameters and substituting them with actual
types.
My guess parametrized types comparison should be done it three steps
(checking if A can be assigned to B):
1. check if A extends or implements B. If it does, then extract type
parameters of A
2. Substitute type parameters variables with actual types
3. Check base types and types arguments one-by-one for compatibility.
For example:
class StringMap< N > extends HashMap< String, N > {...}
If we need to check compatibility of A = StringMap<Integer> with B =
Map< String, Number >, then we must:
1. Find if A extends or implements B (in this case StringMap implements
Map)
2. Substitute StringMap's interface Map type parameters with actual
types: Map< K = String, V = N = Integer >
3. Check if Map< String, Integer > (interface of type A with resolved
type parameters) can be assigned to B = Map<String, Number>. In this
case - it can be assigned.
I haven't gave it much thought, though implemented this logic already.
If you are somehow interested - check "SignatureComparator" class in my
attachment here [1].
[1] - https://bugs.eclipse.org/bugs/show_bug.cgi?id=219160
|
|
| |
Re: Reporting problems from AbstractContextSymbolFactory [message #617460 is a reply to message #475592] |
Tue, 04 March 2008 23:35 |
Vadim Dmitriev Messages: 74 Registered: July 2009 |
Member |
|
|
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! :)
|
|
| |
Re: Reporting problems from AbstractContextSymbolFactory [message #617480 is a reply to message #475594] |
Mon, 10 March 2008 02:34 |
Vadim Dmitriev Messages: 74 Registered: July 2009 |
Member |
|
|
Several cases, that can be improved:
I. Array case:
Let's take the following class declaration as starting point:
class ExtendedArrayElement extends ArrayElement{ ... }
1. Current type comparator compare non-simple-class signatures only as
Strings. I.e. A can be assigned to B if A = "[[[ArrayElement" and B =
"[[[ArrayElement" (signatures strings equals). And not if A =
"[[[ExtendedArrayElement", which is technically not correct.
2. There is one special case for arrays, which is not covered either: if
A = "[[[Ljava.lang.Object", then it can be assigned to B =
"[Ljava.lang.Object;", which TypeComparator reports as wrong.
II. Parametrized types case:
With parametrized types there are some complicated cases, all of which
drill to resolving type parameters and substituting them with actual
types.
My guess parametrized types comparison should be done it three steps
(checking if A can be assigned to B):
1. check if A extends or implements B. If it does, then extract type
parameters of A
2. Substitute type parameters variables with actual types
3. Check base types and types arguments one-by-one for compatibility.
For example:
class StringMap< N > extends HashMap< String, N > {...}
If we need to check compatibility of A = StringMap<Integer> with B =
Map< String, Number >, then we must:
1. Find if A extends or implements B (in this case StringMap implements
Map)
2. Substitute StringMap's interface Map type parameters with actual
types: Map< K = String, V = N = Integer >
3. Check if Map< String, Integer > (interface of type A with resolved
type parameters) can be assigned to B = Map<String, Number>. In this
case - it can be assigned.
I haven't gave it much thought, though implemented this logic already.
If you are somehow interested - check "SignatureComparator" class in my
attachment here [1].
[1] - https://bugs.eclipse.org/bugs/show_bug.cgi?id=219160
|
|
|
Goto Forum:
Current Time: Tue Sep 24 12:10:44 GMT 2024
Powered by FUDForum. Page generated in 0.04599 seconds
|