Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » JavaServer Faces » Reporting problems from AbstractContextSymbolFactory
Reporting problems from AbstractContextSymbolFactory [message #475545] Mon, 03 March 2008 10:46 Go to next message
Vadim Dmitriev is currently offline Vadim DmitrievFriend
Messages: 74
Registered: July 2009
Member
Hi.

I'm implementing yet another variable contributor factory and look for a
way to report messages to 'problems' view. 'Problems' list from
'internalCreate' method seems to be good candidate, but I followed
execution stacktrace and found something like this:
if(...)
{
List problems = new ArrayList();
>factory.create(..., problems);
}
note: method name was another, i just don't remember it for sure :)

Seems that 'problems' list is not used to add new messages to 'problems'
view. It is not used for anything useful at all. Maybe there is a way to
get current instance of IReporter? I haven't found one :(

Thanks!
Re: Reporting problems from AbstractContextSymbolFactory [message #475592 is a reply to message #475545] Tue, 04 March 2008 22:11 Go to previous messageGo to next message
Cameron Bateman is currently offline Cameron BatemanFriend
Messages: 481
Registered: July 2009
Senior Member
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
Re: Reporting problems from AbstractContextSymbolFactory [message #475593 is a reply to message #475592] Tue, 04 March 2008 23:35 Go to previous messageGo to next message
Vadim Dmitriev is currently offline Vadim DmitrievFriend
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 #475594 is a reply to message #475593] Wed, 05 March 2008 07:46 Go to previous messageGo to next message
Cameron Bateman is currently offline Cameron BatemanFriend
Messages: 481
Registered: July 2009
Senior Member
> crucial in current situation: it doesn't validate array types for
> compatibility, for example. So I thought of making EL type validation

If there a particular Java type validation problem, why don't we work to
improve the existing validator? Could provide a use case with arrays that
you think could be improved?


--Cam
Re: Reporting problems from AbstractContextSymbolFactory [message #475600 is a reply to message #475594] Mon, 10 March 2008 02:34 Go to previous message
Vadim Dmitriev is currently offline Vadim DmitrievFriend
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 #617457 is a reply to message #475545] Tue, 04 March 2008 22:11 Go to previous message
Cameron Bateman is currently offline Cameron BatemanFriend
Messages: 481
Registered: July 2009
Senior Member
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
Re: Reporting problems from AbstractContextSymbolFactory [message #617460 is a reply to message #475592] Tue, 04 March 2008 23:35 Go to previous message
Vadim Dmitriev is currently offline Vadim DmitrievFriend
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 #617461 is a reply to message #475593] Wed, 05 March 2008 07:46 Go to previous message
Cameron Bateman is currently offline Cameron BatemanFriend
Messages: 481
Registered: July 2009
Senior Member
> crucial in current situation: it doesn't validate array types for
> compatibility, for example. So I thought of making EL type validation

If there a particular Java type validation problem, why don't we work to
improve the existing validator? Could provide a use case with arrays that
you think could be improved?


--Cam
Re: Reporting problems from AbstractContextSymbolFactory [message #617480 is a reply to message #475594] Mon, 10 March 2008 02:34 Go to previous message
Vadim Dmitriev is currently offline Vadim DmitrievFriend
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
Previous Topic:Loop through the Mbeans in Session Scope
Next Topic:JSF/JSP Component Pallet is not appearing
Goto Forum:
  


Current Time: Thu Mar 28 22:23:08 GMT 2024

Powered by FUDForum. Page generated in 0.02923 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top