You can find the full source code for this website in the Seam package in the directory /examples/wiki. It is licensed under the LGPL.
| Online: | 6 Members of 8197 |
| Forum: Seam Users |
05. Oct 2008, 22:10 CET | Link |
In large enterprise applications it is important to break applications down into decoupled subsystems. To this end it is desireable to compose a seam application from a set of plugins. You could envision the following architecture:
This is the master web application which contains common horizontal features:
All these features would be part of the WAR per usual.
From here it would be nice to be able to package a subsystem in a jar and add it to the classpath of the master web application and have the subsystem merged into the master. The subsystem jar would contain the following:
Some of this is already possible:
But some of it needs a few tweaks:
public class ClasspathResourceResolver extends DefaultResourceResolver
implements ResourceResolver {
@Override
public URL resolveUrl(String resource) {
URL resourceUrl = super.resolveUrl(resource);
if (resourceUrl == null) {
if (resource.startsWith("/")) {
resource = resource.substring(1);
}
resourceUrl = Thread.currentThread().getContextClassLoader()
.getResource(resource);
}
return resourceUrl;
}
}
<context-param> <param-name>facelets.RESOURCE_RESOLVER</param-name> <param-value>net.taylor.jsf.ClasspathResourceResolver</param-value> </context-param>
Of cource all of this isn't very useful if you can't access the subsystems from the home page and menus. This can be handled by storing the menus in the database and having each subsystem register its menus on startup by listening for the @Observer(org.jboss.seam.postInitialization
) event.
Your menus facelet might look something like this:
<c:forEach items="#{menubar.menus}" var="menu">
<rich:dropDownMenu
value="#{menu.value}">
<c:forEach items="#{menu.children}" var="item">
<rich:menuItem
value="#{item.value}"
rendered="#{item.rendered}"
action="#{item.action}">
</rich:menuItem>
</c:forEach>
</rich:dropDownMenu>
</c:forEach>
Seam Wiki has a plugin concept. This posting adds a few additional ideas to help ensure that a plugin is decoupled from the master app.
John, I suggest you make this into a knowledge base article.
For the message bundle loading issue - I'm not happy with your proposed solution, but I agree it could be better. I'll try to think about a way of doing this that is consistent.
Read about how to report a bug.
I agree with you regarding the message bundle. I couldn't find a semantically correct way for additively adding elements to a collection in the components.xml file.
Not sure I like this either, but maybe turning it around the other direction, such that you define bundle components and then wire them to the resource loader component. The setter on the bundle component would add itself to the resource loader. Or maybe a create method on the bundle component would add itself to the resource loader.
Let me know if you come up with an approach you like and I'll put it together.
I'll let this topic evolve a bit and then move it to the knowledge base.
I'm much happier with this approach.
Read about how to report a bug.
I just found http://www.devproof.org/ build on wicket,spring and hibernate just like what you described ,and it's structure is managed by maven.Is there any similar thing in the seam?
I am coming for u