Easiest way to skin on Apache is dojotoolkit WidgetSkin components http://dojo.jot.com/WikiHome/WidgetSkinning
The 'beauty' of using Dojo Skin widgets is you can wrap dojo controls within Struts 2.x taglibs (which are callable from jsp) http://struts.apache.org/2.0.11.1/index.html A more difficult to implement but vastly performance driven option is to use DWR BTW: The sole developer and technoevangelist for DWR is Joe Walker http://getahead.org/dwr/ Finally Scriptaculous integration under Appfuse BTW: The sole developer and technoevangelist for Appfuse is Matt Raible http://raibledesigns.com/rd/entry/script_aculo_us_vs_dojo HTH Martin ----- Original Message ----- From: "Andy Clark" <[EMAIL PROTECTED]> To: <users@tomcat.apache.org> Sent: Monday, April 21, 2008 2:43 PM Subject: Re: Bending Jasper to My Will > Pid wrote: > > Andy Clark wrote: > >> I want Jasper to look for JSP and Tag files in a > >> specific location (e.g. based on a request param); > >> and then fall back to a default location if the > >> file is not found. This would be extremely useful > >> for skinning a webapp. > > > > Cascading Style Sheets are an even more useful, > > practical and easier to implement solution for > > skinning a webapp. > > > > Failing that, programmatically customising the HTML > > output of a common set of tag files would be easier. > > CSS and DHTML only applies to the client-side and > does not allow server-side customizations. We need > to go beyond simple color changes or even changing > the HTML layout; we need to be able to override any > or all tags and JSP files in parallel. In other > words, multiple versions of the code is deployed and > we want to control which application code to use > based on the user's settings. > > Our application allows users to host multiple domains > and different user levels, each of which can have a > different skin. And we currently allow simple changes > to color, etc via CSS. But if the skin author wants to > change the functionality or layout, they must modify > the base JSP files/tags. Which means that *all* of > the skins see the changes. Not what we want. > > For our customers, it is important to be able to > brand each skin independently and even control which > features are exposed via the interface. And we have > no way of knowing all the different ways in which the > customer wants to modify the application. And... they > should be able to do all of this without modifying > the web.xml file. > > So what I would like to be able to do (transparently > from the user) is to, on a request-by-request basis, > determine which tags/JSP files to use based on that > user's skin preference. For example, if the user's > skin is set to "Foo", then I want to look for tag and > JSP file overrides in the skins/Foo/ directory and > use those; if I don't find them there, I want to > fallback and use the tags/JSP files in the default > directory. > > I'll use a more precise example. Say that I have the > following files in my webapp: > > WEB-INF/tags/view.tag > WEB-INF/tags/button.tag > skins/Foo/tags/view.tag > skins/Bar/tags/button.tag > > with these contents: > > <%-- file: WEB-INF/tags/view.tag --%> > <h1>Hello World</h1> > <my:button text='Click Me' /> > > <%-- file: WEB-INF/tags/button.tag --%> > <%@ attribute name='text' required='true' %> > <button>${text}</button> > > <%-- file: skins/Foo/tags/view.tag --%> > <h1>Welcome to Clicky McClicker's Clicktastic Emporium</h1> > <my:button text='Clickity Click' /> > > <%-- file: skins/Bar/tags/button.tag --%> > <%@ attribute name='text' required='true' %> > <a href='#'>${text}</a> > > If there are three users whose skin preference is > set to <undefined>, Foo, and Bar, respectively, then > the interface they see is completely different when > the JSP they hit uses <my:view /> in the page. > > User 1 sees: > > <h1>Hello World</h1> > <button>Click Me</button> > > User 2 sees: > > <h1>Welcome to Clicky McClicker's Clicktastic Emporium</h1> > <button>Clickity Click</button> > > User 3 sees: > > <h1>Hello World</h1> > <a href='#'>Click Me</a> > > In essence, I need to control Jasper internally to > do two things: > > 1) resolve all requests for tag/JSP files at the > requested location to look for the same file in > the user's skin directory; and > > 2) failing to find the file in the first location, > try again at the default location. > > I hope this sheds some more light on what I need to > do. And I really hope there are some Jasper experts > on the list that can point me in the right direction > (even if it means patching the Jasper source). > > > Customising a web app by implementing different sets > > of tag files seems like the hardest possible route. > > True, but it's what I need to do. Unless there's some > other JSP trick that I'm missing... > > -AndyC > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
