Eugeny, the questions are still open :)

1. Max, I agree with you about el plug-ins. First I took that el is core and rreferences is ui presentation, but now I can see that el plug-in has both core/ui, that's not right.

2. common.resref is just a copy of References to Resources dialog that  actually also  mix of core and ui classes. I'm not sure for now who except VPE can also use it for now but it seems provides a way to map runtime paths to resources to development path. Relation between res.ref and jst.web is bad but it really dosent' matter for now because there is one bug feature 'RichFaces VPE Feature' with all plug-ins in it, that's why we have no compilation problems. To fix it right way we should separate resource links mapping core from ui. Each client of resref core can have its own ui to edit that mappings because type of mapped resources can be different. In case of VPE it is CSS, TLD, '/' web root and '.' current directory. For other clients it could be something else.

I'm not sure we should do right away, I'd just move classes back to VPE or to plug-in that has VPE name space hence to vpe.resref.

3. Now resre and EL settings are stored in IResource Persistent Property that's why QName("", <some dotted name>) is used everywhere. http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/resInt_properties.htm
which has only 2K max size, so the setting could be moved to regular preferences in .settings hidden folder.

4. I'd add one more 'Page level' may be not now but later.

5. EL preferences editing strategy should be developed. It includes preferences pages UI for Workspace, Project, Folder or File. Now we have only Global preferences.

6. el.core should public and internal packages and be testable in core mode.

Denis.

Max Rydahl Andersen wrote: 
Hi Denis,

  
I'd not say it is good.

First of all I cannot see any reason to put it in common. El is
related 
to Java Server Pages (${}) and JSF (#{}).
    

  
But what is major purpose of new plug-ins? It is providing replacement
for EL expressions to possible values. It should allow to show page in
VPE as close to run-time as possible. That functionality is related
only to VPE and that means there is no reason to move those plug-ins in 
nether to common component nor to any other. VPE component is a right
place for it, especially org.jboss.tools.vpe plugin.
    

Not true.

EL is used in non-JSF scenarios too. e.g. Seam configuration files.
I asked Eugene to split out the specific EL replacement setup to be able
to use this in non-VPE scenarios.

I objected because it seems that this resulted in two plugins which dependency
list is the opposite of what I would expect since I still do not see why EL
resolving has a dependency to something related to resource references. Just because
there are some ui components in there the EL ui uses does not make it right.

In my pov the only parts that would need "extracting" is the EL core and ui and
those could make it into org.jboss.tools.common.el.core and org.jboss.tools.common.el.ui
and at least be independent plugins which does this basic and simple task of providing
configuration for the global, project and folder level EL variables and have a simple core
api for resolving a variable in a given context.

Then if VPE needs to convert these into resource references that should be done in VPE.

/max

  
 
Thanks
Denis

Eugene Stherbin wrote:
    
Max Rydahl Andersen пишет:
      
good, but why does the EL variable substitution require resource 
references ? Why are there VPE packages in it ?
Why put it in separate packages when there is still these hard 
dependencies ?

/max

----- "Eugene Stherbin" <estherbin@exadel.com> wrote:

 
        
Hi,

The org.jboss.tools.common.rreferences bundle renamed to the 
org.jboss.tools.common.resref in svn.

-- 
Best Ragards,
 
Eugene Stherbin
Exadel Inc.
Mob. phone: +375 (29) 705-52-59
E-mail: estherbin@exadel.com

_______________________________________________
jbosstools-dev mailing list
jbosstools-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
    
          
  
        
1.org.jboss.tools.common.resref bundle contains of base classes.
      
These 
    
classes has all necessary functionality for save/read properties,
      
show 
    
popups, display table with Add/Edit/Delete functionality and e.t.c.
      
org.jboss.tools.common.el - contains of 4 classes  that extends base
      
functionality and add functionality required for Global El/Vpe El.

2. Because classes in VPE package required only  for VPE.

3. See point 1. It separated to two bundles because bundles has 
difference logical functionality and if we will want add new similar
      
functionality only extends from  org.jboss.tools.common.resref
      
bundle.