Resend ---------- Forwarded message ---------- From: Mats Norén <[EMAIL PROTECTED]> Date: Aug 15, 2007 1:38 PM Subject: Re: Ideas for a Wicket Based Cms To: users@wicket.apache.org
Hi, I played a little with an idea of a CMS with Wicket a while ago. Due to lack of time (as usual) I never got that far. This is some old notes I made at the time. Maybe it will give you some ideas. CMS === Key points: - nice urls - reuse of dynamic components in different pages - extend ordinary wicket panels and add configuration in db for maxium reuse - navigation separated from page hierarchy - mix static components with dynamic components from db Concepts ======= NavigationItem ============== A NavigationItem has a reference to a Page. A NavigationItem can have a parent NavigationItem(except the root nav.item) A NavigationItem can have a collection of child NavigationItem:s. Page ==== A page consists of 1 or more Areas. Area ==== An area contains 1 or more Components. Component ========= A Component can be any wicket panel that implements the ICmsComponent. ICmsComponent is used to obtain an editor for the component. Rendercycle ========= Resolving a page ============ The CMS uses a custom PageFactory (CmsPageFactory) that looks for the marker interface CmsMarkerPage. By using the IndexedUrlParameterCodingStrategy all pages under the mount "/cms" triggers the custom PageFactory. CmsPageFactory is injected with a ContentDAO responsible for loading a NavigationItem based on the hierarchial structure of the remaining part of the url after the initial "/cms". For example if the url is "/cms/nav1/nav2/test.html" a lookup for the NavigationItem with the path "nav1/nav2/test.html" is made. The NavigationItem has a reference to a Page in db. The db-table contains the the Class-name and id of the page along with some other params. The id and path are added to the PageParameters. The resolvedClass and the resolved PageParameters is delegated to the original PageFactory in wicket. Constructing the page ================ Each page in the Cms extends CmsBasePage. CmsBasePage is responsible for loading a page-entity from db. Different types of pages, 3 column layout, 2 column etc is created by extending CmsBasePage. A special ListView called ContentView is added for each Area. The ContentView iterates each Component in the area in sort order. A lookup for a matching Wicket-component based on componentId, className, modelId is made. Each component is responsible for initializing it's model based on the modelId. A thin wrapper layer that instantiates the correct wicket-component based on the modelId is all that is needed to use any wicket component as a CMS-component. Component ideas so far (very sketchy, mostly as proof of concepts): -album -article * -calendar (displays a google calendar) * -comment -delicious -image * -linklist -map (openlayers) -navmenu -person.ldap -pressitem -rating -rss (displays a rss-feed) * - wikiarticle (using radeox) * /regards Mats On 8/14/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > two extra points: > > *) think about bookmarkability/ nice URLs. > *) try to make the user-facing side (so the result of what people did > with the CMS/ anything that can be accessed without logging in) > stateless if you can. > > Eelco > > > On 8/14/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > 1) It will use Jackrabbit to store CMS-related data > > > 2) To create a page, the administrator starts by selecting a layout, and > > > then select the appropriate panels to fill the layout. The configuration > > > can > > > be stored in an OODB like db40. The page are virtual, but the CMS will use > > > reflection to create the page when the user accesses it. > > > 3) The administrator can set any page as the default homepage. > > > 4) Different panels that can be assigned by the administrator for each > > > page, > > > like > > > a) Velocity Panel for writing blog-like contents; > > > b) Menu Panel for user-built menus; > > > c) User sign-in panel > > > d) Events calendar panel that uses joda-time library etc > > > 5) Administrator can set the user roles to each page for acess content > > > 6) Integrating a workflow engine for publishing. > > > > Yeah, that sounds pretty good to me. Keep us informed! > > > > Eelco > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
