>> > If you're using S2, you could always return the 'theme1' or 'theme2' >result in >> your action class and have the mapping for it. >> >> That's absolutely a disgusting idea, think about 10 themes, and add to >> that user installable themes... >> >> A switch() at end of each of the action methods... no way. >> > >I totally agree with you. However, I'm just giving Brian options to >assess his situation: number of themes, whether to implement another set >of library (more possible bugs, more memory usage, bigger code base, >dependency issues, etc), potential growth of his project, etc... >Personally, I don't prefer the selection of separate theme pages. I >only use 1 page for the and change the CSS and layout within that page >via include. Thus, no need for Tiles. Example, for a full layout: >header, left side bar, content in the middle, right side bar, footer. I >could then choose dynamically to whether include the left, right, or >both side bar(s) for the other variations. Using this approach may >require themes in DB backend. But it will give you the best flexibility >since there's no need to redeploy your web app just because your >client/customer want to have another theme layout with same content :) >When I look at redeployment, I see downtime. Perhaps Brian > could also look into JSP Tags too. I haven't finished my in depth look >in it but it looks very promising.
Well, my "theme" is basically different users that have systems with user defined fields, and different stuff stored in them. i.e. user1 at customer x may be sensitive data that they don't want displayed, so it needs to not be shown, while user y may have something they want displayed by the app. It's not really about layout, but about what is shown or not shown for different installations. > >> >> > Or you could just use Tiles? >> >> Hopefully it helps, although I don't know how. I have only used Struts >> 1.2.x and Tiles for it, and never did themes.. >> >> -- >> http://www.iki.fi/jarif/ >> >> Life is to you a dashing and bold adventure. > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >For additional commands, e-mail: user-h...@struts.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
