JSF tools M5 - EL Syntax checking [message #471496] |
Mon, 20 March 2006 04:36  |
Eclipse User |
|
|
|
At first - many thanks for this release, new features are impressive !
Here is one missfeature, that I found when switch my existing project to
it: EL Syntax checking not works for following cases:
1. Variable introduced by <x:yyy var="myvariable">
For example:
<f:loadBundle basename="resources.MessageBundles" var="bundle" />
<h:outputLabel value="#{bundle.prompt}" />
Syntax checking says: bundle cannot be resolved
Or:
<h:dataTable ... var="row" >
....
....
<h:outputText value="#{row.columnname}" />
Syntax checking says: row cannot be resolved
2. Managed bean property or method is in parent class
Example:
<h:commandLink action="#{myBean.backAction}" />
Syntax checking says: backAction is cannot be resolved as a property of
the bean myBean
backAction is method declared in ParentBean (class MyBean extends
ParentBean).
Bye,
Lumir Vanek
|
|
|
|
|
|
|
|
Re: JSF tools M5 - EL Syntax checking [message #471503 is a reply to message #471501] |
Tue, 21 March 2006 01:34  |
Eclipse User |
|
|
|
Hi!
>> In other words, beside "create bean" this will be a "associate class".
>
> Can you elaborate a little more on "associate class"? Are you
> suggesting that the user would be able to have a referenced-bean-like
> mechanism that is stored outside the faces-config that would allow them
> to say: "use this class for content-assist, validation etc."?
Yes, this association should not influence any config file. Just to help
the code assist.
You NEVER EVER can handle all cases automatically. Think of custom
components - sure its a common standard to use "var=" to define a local
scoped variable, but its not always easy - say, often its not even
possible - to determine the class behind this var automatically.
Its even hard to detect the class for a dataTable as the values= points
to a DataModel or a simple List - you need a datasample to get in touch
with the class.
My suggestion also allows us to associate a class to the el-string if a
bean is set from the application directly into the request/session map.
There might be no configuration, not even a component - just a bean
somewhere laying around.
This is why I thought about such a association feature.
Wherever you store this mapping, I think the key should be something
like "filename/el-reference-name=className".
I think, this will be a killer feature.
Ciao,
Mario
|
|
|
Re: JSF tools M5 - EL Syntax checking [message #596611 is a reply to message #471496] |
Mon, 20 March 2006 06:20  |
Eclipse User |
|
|
|
On 3/20/2006 4:36 AM, Lumir Vanek wrote:
> At first - many thanks for this release, new features are impressive !
>
> Here is one missfeature, that I found when switch my existing project to
> it: EL Syntax checking not works for following cases:
[good cases snipped]
Another common one would be when the the first part of the expression
is a keyword for a custom Variable Resolver and not a managed bean.
Also the trailing parts of the expression do not have to be properties
of a bean - it all depends on what PropertyResolver is registered
and what it does with the properties.
|
|
|
Re: JSF tools M5 - EL Syntax checking [message #596619 is a reply to message #471497] |
Mon, 20 March 2006 12:04  |
Eclipse User |
|
|
|
Hi!
>> Here is one missfeature, that I found when switch my existing project to
>> it: EL Syntax checking not works for following cases:
> Another common one would be when the the first part of the expression
> is a keyword for a custom Variable Resolver and not a managed bean.
Yes, and I dont see how this can be solved by an IDE automatically.
Though, it would be great if we can associate a class to "unknown beans".
This association is only to help the ide to provide a code-assist and
should not be inserted in any faces-config.xml.
In other words, beside "create bean" this will be a "associate class".
WDYT?
Mario
|
|
|
Re: JSF tools M5 - EL Syntax checking [message #596629 is a reply to message #471496] |
Mon, 20 March 2006 13:56  |
Eclipse User |
|
|
|
Hi Lumir,
Thanks for taking the time to look at this. I will be addressing these
cases in the coming weeks.
Also please feel free to launch bugzilla bugs when you find these issues.
That way, you can track changes and resolutions by way of Bugzilla e-mail
alerts.
Regards,
Cameron
|
|
|
Re: JSF tools M5 - EL Syntax checking [message #596637 is a reply to message #471497] |
Mon, 20 March 2006 14:01  |
Eclipse User |
|
|
|
Hi Yury,
You make an excellent point. For this milestone we were trying to demo
some features we'd like to expose to the user, so it's not complete yet.
Please continue to raise these issues though; your input is greatly
appreciated.
--Cam
Yury Kats wrote:
> Another common one would be when the the first part of the expression
> is a keyword for a custom Variable Resolver and not a managed bean.
> Also the trailing parts of the expression do not have to be properties
> of a bean - it all depends on what PropertyResolver is registered
> and what it does with the properties.
|
|
|
Re: JSF tools M5 - EL Syntax checking [message #596644 is a reply to message #471498] |
Mon, 20 March 2006 14:04  |
Eclipse User |
|
|
|
Mario Ivankovits wrote:
> In other words, beside "create bean" this will be a "associate class".
Can you elaborate a little more on "associate class"? Are you suggesting
that the user would be able to have a referenced-bean-like mechanism that
is stored outside the faces-config that would allow them to say: "use this
class for content-assist, validation etc."?
--Cam
|
|
|
Re: JSF tools M5 - EL Syntax checking [message #596659 is a reply to message #471501] |
Tue, 21 March 2006 01:34  |
Eclipse User |
|
|
|
Hi!
>> In other words, beside "create bean" this will be a "associate class".
>
> Can you elaborate a little more on "associate class"? Are you
> suggesting that the user would be able to have a referenced-bean-like
> mechanism that is stored outside the faces-config that would allow them
> to say: "use this class for content-assist, validation etc."?
Yes, this association should not influence any config file. Just to help
the code assist.
You NEVER EVER can handle all cases automatically. Think of custom
components - sure its a common standard to use "var=" to define a local
scoped variable, but its not always easy - say, often its not even
possible - to determine the class behind this var automatically.
Its even hard to detect the class for a dataTable as the values= points
to a DataModel or a simple List - you need a datasample to get in touch
with the class.
My suggestion also allows us to associate a class to the el-string if a
bean is set from the application directly into the request/session map.
There might be no configuration, not even a component - just a bean
somewhere laying around.
This is why I thought about such a association feature.
Wherever you store this mapping, I think the key should be something
like "filename/el-reference-name=className".
I think, this will be a killer feature.
Ciao,
Mario
|
|
|
Powered by
FUDForum. Page generated in 0.09634 seconds