[JAVASERVERFACES_SPEC_PUBLIC-970] Plugin System Created: 14/Apr/11  Updated: 06/Jan/12  Resolved: 20/Nov/11

Status: Closed
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: lamine_ba Assignee: Ed Burns
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_large importance_medium


 Description   

core system to build a multi-templating system and more...



 Comments   
Comment by lamine_ba [ 15/Apr/11 ]

Broadly speaking, this feature is a starting point to set the building blocks that will help us move towards a standard application framework.What would you say if a plugin was a book? that it has an id, a name, a description, an author...?

Plugin.java

public abstract class Plugin  {

    protected String id;
    protected String name="";
    protected String description="";
    protected String creationDate="";
    protected String version="1.0";
    protected String license="";
    protected String author="";
    protected String authorEmail="";
    protected String authorUrl="";
    protected Resource metadata;
    protected Folder folder;
	
    public Resource getResource(String name) {
		
	return folder.getDocument(name);
		
    }

    public void download(OutputStream out) throws IOException {
		
	folder.zip(out);
   }
   ..................................................
}

Without reading its metadata, How one could know that 'Secrets of the Rockstar Programmers' is written by Ed burns? And if that metadata wasn't loaded at first to create a view of that book, how one could read it?

PluginLoader.java

public interface PluginLoader<T extends Plugin> {   
    public T load(Resource metadata) throws Exception;
}

And who can manage my books? PluginManager! Did you hear my call? My plugins are stored in a folder and they are waiting to be loaded...

PluginManager.java

public abstract class PluginManager<T extends Plugin> implements ResourceResolver {

    protected  final List<T>    plugins=new ArrayList<T>();
    protected  PluginLoader<T>  loader;
    protected  Folder folder;
    protected  EventHandler handler;

    public void load() throws Exception {     
     ........
    }

    public T load(Resource metadata) throws Exception{     
            return loader.load(metadata);
    }
    
    public Resource getResource(String name) {
		
	   return folder.getDocument(name);
		
     }

    public void add(T plugin) {
            ......
    }

    public void remove(T plugin)  {
            ......
    }

    public void download(T plugin,OutputStream out) throws IOException { 
            ......
    }

    public void downloadAll(OutputStream out) throws IOException { 
            folder.zip(out);
    }

}

And from this little thing, a multi-templating system is born.

Template.java

public class Template extends Plugin {
}

TemplateManager.java

@Manage(folder="templates",metadata="template.xml")
public class TemplateManager extends PluginManager<Template> {
}

you can read more about this feature there http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-971

Comment by kito75 [ 20/Apr/11 ]

Related issues:

Make flows reusable http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-730
Support for modular, reusable, fragments of a web application http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-532
Simplify external view loading requirements http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-809

Comment by smsajid [ 05/Jan/12 ]

Is this issue fixed?
I just hope we are not building a deprecated feature? Plugin or module system is part of Java 8. We should leverage that feature and build upon and not develop a conflicting and repeating solution. Yes, JSF2.2 will be part of JavaEE7 which is based on JavaSE7 and JavaSE7 does not have modules yet. But why build a feature that has to be removed in the next release. I think we should delay the plugin feature to JSF2.3 (maybe?) that will be part of JavaEE8.

Comment by lamine_ba [ 06/Jan/12 ]

Hello smsajid.

First of all, Thank you very much for your comment and let me reassure you that this issue has not been fixed. Now to clarify something : Modularity in the language does not mean that JSF will become automatically a modular framework. Using the module system of Java 8, How one can package his css, his images, his js, his composite components, his views, the navigation logic into a reusable unit and plug it into any JSF application? Yes with Java 8, we will be able to plug reusable units of business logic but nothing more. So it means that JSF needs to have its own "Virtual" module system to manage and discover its own artifacts.

The real reason why I have closed this issue is that : The JSF plugin and module system we need is just an aggregation of the two issues below....

1) Make flows reusable
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-730

2) Support for modular, reusable, fragments of a web application
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-532

Generated at Wed Aug 05 00:35:24 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.