I would say you should break this project up into 2 parts, like how I did for wicket-cms.
wicket-cms and wicket-cms-example
This will create a very modular design so others can reuse wicket-cms in their own applications. You will be designing your core system as though you are a user of the system too, so you will be forced to make it as extensible/modular/componentized as possible. If everything is tightly coupled then you limit the reusability of the components. Plus its also nice to see how to integrate a product with an existing system.
Here are a few starting points:
1. Make sure the authorization class is an interface that can be implemented by others to integrate in their own system's authorization backend.
2. Keep as many components Panel-centric as possible.
For instance if you have a component that displays a list of files/content managable by a user I think the abstraction should be something like...
AbstractContentBrowserPanel
- This would display a DataTable with hooks like abstract public onContentNameClick(Content content);
ContentBrowserPanel
- This would be a default implementation of the AbstractContentBrowserPanel that implemented onContentNameClick(Content content) to something like setResponsePage(new ViewContent(content))
As you can see, now if a user wants to have a page that displays a list of content, but instead of taking them to the ViewContent page when they click on a name, they can implement AbstractContentBrowserPanel.onContentNameClick (Content content) with something like setPage(new ContentEditor(content))
3. Use as much CSS as possible for layout and design. Others can then override your classes with their own style sheet(s) to keep the layout/design consistent with their own.
The core system probably doesn't even need a custom database schema, I could be wrong, depending on the features required. But, since you are using JackRabbit to store content that eliminates the needed for a lot of custom data structures. wicket-cms-example would need a database of course. Let me give you an example how I would authorize a user to edit a piece of content:
// This would be part of wicket-cms
public interface CMSSecurity {
boolean hasPermission(Permission permission);
}
// This would be part of wicket-cms-example
public class MyCustomCMSSecurityImpl {
boolean hasPermission(Permission permission) {
boolean hasPermission = false;
// lookup user in database
User user = session().load(User.class, CustomSession.get().getUsername());
if (user.getRoles().contains(permission.getAction() + "-role") {
hasPermission = true;
}
return hasPermission;
}
}
public class ContentEditorPanel {
ContentEditorPanel(final Content content) {
Permission permission = new Permission() {
public String getAction() {
return "edit";
}
public Content getContent() {
return content;
}
};
// get CMSSecurity implementation from somewhere, like the application
if (!CMSApplication.getCMSSecurity().hasPermission(permission)) {
throw new AccessDeniedException();
}
}
}
Note: General programming suggestion for reusability. Encapsulate finer grained objects in a wrapper object, like how Permission is above. This is better than passing everything in a granular fashion, like breaking it up into Content content, String role, etc. Because now if you want to add another piece of the system to authorize against you can just add it to the Permission object without breaking the API. If you break the API, everyone that uses it will have to recode their stuff that users it.
I hope all this makes sense, its hard to explain quickly. Let me know if you have any questions.
Thanks for keeping me posted.
On 10/19/06,
Ted Roeloffzen <[EMAIL PROTECTED]> wrote:
He Joe,
Here is the first, very basic design, for the blog.
It's all very basic. i.e. There is a single class defined for the access control.
This has to be specified more, but that is something for later.
greets,
Ted2006/10/17, Joe Toth <[EMAIL PROTECTED]>:Hey Ted,
It's IRC nick: WeaZeLb0y.
How's the wicket based cms going? Will you put out some specs for the design before you implement it?
For instance:
1. What parts will be pluggable? - ie. authorization/permissions/auditing
2. What technologies will be used? - of course wicket, but will you use JCR, JPA/Hibernate, Spring, EJBs, TinyMCE
3. What features will the first iteration include?
Also, I would recommend separating the data/services from the UI. Meaning, if someone wants to create a complete different UI and use a different framework they should be able to, for example: GWT, JSF, Struts, etc.
Oddly enough, I never had to create a CMS for myself, which is one of the reasons I didn't create a fully functional wicket-cms. But, I know it'll be a requirement for a future project.
If you need any help or recommendations or anything, let me know or just ask on the list, like usual.
Thanks,
Joe
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
