0 Replies Latest reply on Dec 11, 2007 9:12 AM by Ryan Rutan

    Dynamic Inclusion of Widgets on pages other than OverView

    Ryan Rutan

      Was wondering if it would be possible to leverage Community extended properties in conjunction with the Xwork Action name, to create a way to put widget configurations onto other page of the site.   For example, in the view-profile-blogs action, we would like to add some custom content.  A static HTML widget would work well for this, and would also help us not "own" this FTL by adding our HTML to it.

       

      My suggestion is to create a global <#if> structure that accesses a function that determines if for example the right bar should contain the default HTML, or if the content should be a string of Widgets.  In some cases, the <#if> will do an all or nothing REPLACE, or in other times an APPEND to what's already there?  This could be controlled via a property such as below, or possibly is manually limited based on the essence of certain pages.  Some pages code the <#if> as a pure REPLACE if found, other's do an APPEND if found.

       

       

       

      Some example properties I can see that might work...but am very flexible...conceptually

       

       

       

      XWORK-ACTION-NAME.LOCALE?.MAIN_BODY.widgetList.count=1

      XWORK-ACTION-NAME.LOCALE?.MAIN_BODY.widgetList.action=REPLACE

      XWORK-ACTION-NAME.LOCALE?.MAIN_BODY.widgetList.1=WidgetFrameId

      ....

      XWORK-ACTION-NAME -exact string match to the action that invoked the FTL?  Is this generic enough and a solid assumption?

      LOCALE - in the event you want to configure different widgets for different locales/languages...would default to the Default System Language

      MAIN_BODY | RIGHT_BAR - these would be configurations that reference the destination of the Widget for Display.  Preferrably, the Widget drag-drop  will add more functionality to drag-drop elsewhere on the page, so these names or the parsing logic should be such that they can be resolve to understand containers other than just MAIN/RIGHT etc...such as TOP, or BOTTOM maybe if they were to be valid positions?

       

       

       

       

      This would almost warrant the need to create an interface that decouples Widget creation from JUST the drag-drop interface on the Community Overview Page.  It may require that a reserved value be provided for CONTAINERID or FRAMEINDEX in the DB Tables...

       

       

       

      But as you can see.... this type of flexibility, would allow SpaceAdmin's the ability to customize the look/feel of their community by dropping different widgets around.  Not sure exactly how( if there should even be) to create a drop-down of "views" for the SpaceAdmin to select....but for an initial phase, I'd be happy to set the community properties manually without a UI....

       

       

       

      anyone else think this type of functionality would be good?   These are just some ramblings, but would be happy to elaborate if asked.  In general, ownership of FTL templates for trivial changes is something I am trying to avoid.