From yesterday we have excluded the scopes from the Seam EL content assist processor by your comments and requirement.

This was true only when we edit some component's java file and we have a scope. For all other cases (xml, xhtml, jsp and so on) we have no scope defined, so we didn't use it.

Previously Slava (because the SeamProject utility had been used to get the project variables and Slava is responsible for it) did this filtering using the scope of component. The search rules was based on context search priority (See "3.1.9.

Again, for now the scope isn't used anymore and all the project variables are used as possible proposal (the following filtering goes to the EL prefix and resolved type).

Victor > -----Original Message----- > From: Max Rydahl Andersen [mailto:max.andersen@redhat.com] > Sent: Thursday, August 09, 2007 4:22 PM > To: ruby(a)exadel.com > Cc: jbosstools-dev(a)lists.jboss.org > Subject: Re: [jbosstools-dev] Re: [Fwd: [jbosstools-commits] JBoss Tools > SVN: r2969 - > trunk/seam/plugins/org.jboss.tools.seam.core/src/org/jboss/tools/seam/in > ternal/core/el.] > > > > btw. in short, any variable is available in any place in Seam 1.2. > > In Seam 2 Gavin has started to add the concept of imports which will > become relevant in filtering of possible completions - something we need > to look into supporting down the road. > > But for now I don't understand what scope rules you are using to define > the filtering ...since there are none afaik. > > /max > >> Victor V. Rubezhny wrote: >>> Hi Max, >>> >>> 1. The scope is playing the role in completions, IMHO, due to prevent >>> usage of variables defined in scope, that is "invisible" to the >>> component as well as run-time variable "visibility" problems. >>> >>> Currently the scope is used only for the components. In other cases >>> (f.e. while editing components.xml or some jsp-/xhtml-file) the scope >>> cannot be used (this means "is not used") to filter the variables (the >>> proposals are collected regardless of the scopes). >>> >>> But for the component, IMHO, it's important to give only valid >>> proposals (the variables that are visible within the > component's scope). >> I don't follow this; what scoping rules are you using to define this ? >> >> e.g. if you have a component with default scope Conversation > then inside >> one of its methods e.g. doSomething() we have a log statement referring >> to #{someVariable} that "someVariable" is resolved at *runtime* >> completely independent of the components default scope. >> >> Meaning depending on what runtime context that method is > invoked in seam >> looks up through the current active scopes and that can be essentially >> be *all* possible scopes. >> >>> 2. I understand and agree that the sorting of proposals depending on >>> their scope is right and usefull thing. But there is no guarantee that >>> the proposals will not be re-sorted after SeamELContentAssistProcessor >>> returns them to Content Assistant. >> Why not ? Proposals has a ordering/priority flag afaik...or is that not >> true for xml completions ? >> >> /max >> >>> Victor >>> >>>> -----Original Message----- >>>> From: Max Rydahl Andersen [mailto:max.andersen@redhat.com] >>>> Sent: Thursday, August 09, 2007 1:06 AM >>>> To: jbosstools-dev(a)lists.jboss.org; Viktor Rubezhny >>>> Subject: [Fwd: [jbosstools-commits] JBoss Tools SVN: r2969 - >>>> > trunk/seam/plugins/org.jboss.tools.seam.core/src/org/jboss/tools/seam/in >>>> ternal/core/el.] >>>> >>>> >>>> Hi Victor, >>>> >>>> I just noticed this one being committed: >>>> >>>> "http://jira.jboss.com/jira/browse/JBIDE-670 xhtml code completion >>>> does not update it's list of completions >>>> >>>> Seam scope usage is fixed." >>>> >>>> and project.getVariablesByScope(scope, true); used in context of code >>>> completion...(before it was getVariablesByScope(scope);) >>>> >>>> Why is scope playing a role here in completions ? >>>> Scope can't be used to filter the list of possible matches - in the >>>> best case it can be used to *order* the list of completions. >>>> >>>> /max >>>> >>>> >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev