Summary: | API - Symbol Context Resolver needs to be pluggable | ||||||
---|---|---|---|---|---|---|---|
Product: | [WebTools] Java Server Faces | Reporter: | Cameron Bateman <cameron.bateman> | ||||
Component: | Core | Assignee: | Cameron Bateman <cameron.bateman> | ||||
Status: | RESOLVED FIXED | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | P1 | CC: | david_williams, raghunathan.srinivasan, robert_gallagher, xiaonan_jiang | ||||
Version: | 3.1 | Keywords: | api | ||||
Target Milestone: | 3.1 RC1 | Flags: | david_williams:
pmc_approved+
raghunathan.srinivasan: pmc_approved? (naci.dai) raghunathan.srinivasan: pmc_approved? (deboer) raghunathan.srinivasan: pmc_approved? (neil.hauge) raghunathan.srinivasan: pmc_approved? (kaloyan) raghunathan.srinivasan: review+ |
||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
URL: | ORACLE_P1 | ||||||
Whiteboard: | PMC_approved | ||||||
Attachments: |
|
Description
Cameron Bateman
2009-03-10 16:10:38 EDT
* Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. This is a hot-bug requested by Oracle. The fix is required to provide enahnces content assist feature in the adopter product. * Is there a work-around? If so, why do you believe the work-around is insufficient? No. Hi Cameron, Could you give more details on the problem? When will it happen? Thanks. Created attachment 134341 [details]
Adds a new non-breaking extension point that allows contributions to the SymbolContextResolverFactory
The SymbolContextResolverFactory is used by JSF framework to create a symbol resolver for resolving variables, properties and methods in EL expressions. The change allows an adopter to specify a new factory extension that can override the default resolver.
Existing behaviour is unchanged because if no extensions are found, the current default resolver is used.
Patch applied to HEAD (3.1). Do you have documentation or example on how to use the extension point and how to implement the factory class? (In reply to comment #5) > Do you have documentation or example on how to use the extension point and how > to implement the factory class? It's been introduced as a sort of provisional API in this release. I haven't documented it yet. The basic idea, is that you can use this extension point to add a new ISymbolContextResolver by contributing a IStructuredDocumentSymbolResolverFactory. When the system requests the new ISymbolContextResolver for a context, your factory will be called before the system default and the resolver it returns will be used (you can choose to return null in any context you don't support). Where this is useful is if you want change the way all EL symbols (variables, properties, methods etc.) are resolved without changing the designtime variable and property resolvers. So, for example, if you want to try to improve performance by caching symbols inside the resolver rather than recalculating each time as the default does. Alternatively, if you want to calculate variables differently in certain scenarios or even ignore the designtime variable and property resolvers in certain contexts, but still use the validation, context assist, hyperlink and hoverhelp features by injecting your own symbols. Looks like if using the defined symbolContextResolverFactory to add a new ISymbolContextResolver, the new resolver's getProperty(ISymbol, Object) method won't be called by the validation. Also, if there are more than one symbolContextResolverFactory extensions specified, only one ISymbolContextResolver can be used. Maybe should have a chain to use all the ISymbolContextResolver(s)? |