-Eric
Jacob Farber wrote:
Hi Eric, Jacob from Fluid here. My initial thought is this is possible.Best case scenario would be that the JSR spec can be neatly tied into the core FSS data. Worst case, the JSR to FSS mapping would be in a separate css file which would be an extension of the FSS core. Either one means very little transitioning or learning curve would be required.JacobOn Thu, Jan 8, 2009 at 3:03 PM, Eric Dalquist <[email protected] <mailto:[email protected]>> wrote:I think the FSS approach sounds like a good one. At this point I think you're taking the right approach with evaluating some options out there an just picking one, until someone picks something the current mess of 'whatever looks best for that portlet' will continue. One thing I would like to see is if we can figure out how to point the JSR defined CSS classes (as poorly defined as they are) to some FSS classes and then document that, it would hopefully help for those portlets that do use those CSS classes. -Eric Gary Thompson wrote: On behalf of Unicon's Cooperative Support [1] subscribers, Unicon is in the process of designing and building a new Portlet Administration portlet [2] to replace the current Channel Manager functionality, based on UP-2047 [3]. This particular portlet will be core uPortal functionality. In developing the user interface screens of the portlet, we have reached the point of needing to make choices on markup and CSS structure. == The Problem == There is no standard for markup or CSS for developing portlets for uPortal. Yet markup and CSS must be developed. In lack of a standard, everyone does what is best in their own eyes. == The Goal == Set a standard for markup/CSS for portlet development for uPortal that: * Builds on existing best practices * Leverages the collaboration of many disciplines and practitioners * Does not put the burden of creation, education, documentation, and maintenance solely on the uPortal community * Yet allows the uPortal community to participate in defining and maintaining the standard Resulting in: * More rapid and efficient development of portlets * Higher quality and cohesion of portlets in uPortal * Improved user experience == The Evaluation == Unicon evaluated these three options for a markup/CSS standard: JSR-168/286 [4], Yahoo YUI [5], and Fluid Skinning System (FSS) [6]. Arguments for JSR-168/286 * The current standard for portlets in uPortal Arguments against JSR-168/286 * Lacks context * Does not use best practices * Insufficient specification to develop robust portlets * Ambiguous and poor documentation * No layout specification * No widgets or components * No code or application samples * No beneficial integration with jQuery or Fluid components already used by uPortal * Difficult to affect change Arguments for YUI * Incredibly robust and has been widely adopted and tested * Has a very active community * Provides markup generation tools allowing for faster front-end development * Provides many stable widgets and common components * Supports YUI's A-grade browsers * Well-developed, high-quality documentation with over 290 functional code examples Arguments against YUI * Based on a Yahoo-centric model (e.g., abstract class naming conventions specific to Yahoo: yui-g, yui-u, yui-b). * Closed source and governed by Yahoo, where participation and ability to affect change is limited * No beneficial integration with jQuery or Fluid components already used by uPortal Arguments for Fluid Skinning System (FSS) * Sufficient specification and developer documentation with enough detail to enable a UI professional to create different layouts ranging in complexity within 30 minutes of reviewing the documentation * Coding style and class naming convention is easily understood and meaningful * Provides flexible and multiple column layouts * Provides several excellent components and a growing library * Supports linearization, the super-simplification of the layout of elements on a page for offering alternatives for accessibility and devices (e.g., mobile) * Supports FF 2.x, FF 3.x, IE 6.x, IE 7.x, Safari 3.1 and Opera 9.5 * Active, open-source community already connected to the uPortal community, where participation is welcome and change responsive * Beneficial integration with jQuery and Fluid components already used by uPortal * Produces fully-accessible results and is forward-thinking on accessibility Arguments against Fluid Skinning System (FSS) * Relatively young and has not been widely adopted or tested * Does not offer as many widgets or common components as YUI == The Proposal == Adopt the Fluid Skinning System (FSS) as the standard for portlet markup/CSS development in uPortal. I welcome thoughts and votes. Gary --------------------- References [1] http://www.unicon.net/support/cooperative [2] http://www.ja-sig.org/wiki/x/BwBPAQ [3] http://www.ja-sig.org/issues/browse/UP-2047 [4] http://jcp.org/aboutJava/communityprocess/final/jsr168/index.html [5] http://developer.yahoo.com/yui/ [6] http://wiki.fluidproject.org/x/96M7 -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue
smime.p7s
Description: S/MIME Cryptographic Signature
