Gosh... I didn't realize I was so unclear. I'm sorry. Let me try again. Also, with some of Jim's comments, I think I now understand _my_ problem more clearly.
My problem is really a packaging issue, that is, in what form do I supply the underlying technology to a customer. I will be selling a site generation system. I will supply all the basics to bring up a site. A customer would follow some install instructions, set some configuration options, AND write the look-and-feel for the site. The look-and-feel represents the pages and the navigation between pages. My original idea was that I would supply a war with all the underlying business logic, velocity, maverick, database connectivity, etc. And the customer would configure it so that it looks to an external directory where he'll place his html, graphics, maverick.xml file. Jim is suggesting that I supply a "build" process which takes my "incomplete" war, adds his pages, and then creates a "real" war which is then deployed. That's not a bad idea. On the downside, it seems harder for the user to go through this build process than just pointing to a directory tree. I'm not even sure it is possible to do what I want, that is to have html content and gifs come from outside the war file... (From your explanation, I now understand shunting, which is extremely powerful. I think shunting applies to the scenario where several skins are known in advance and are all contained in a war. Languages are certainly a good example of this.) Dan At 09:24 PM 2/6/02 -0800, Jeff Schnitzer wrote: >Dan, I hate to sound daft, but even after the second round of >explanation I'm still completely confused about what you're trying to >do. Care to give it a third round? I think I would understand better >if you gave a chronology of how a single request was serviced. > > > From: jim moore [mailto:[EMAIL PROTECTED]] > > > > This does raise the question of how to set up easily configurable >skins in > > maverick though. Currently I believe it would be difficult to have > > multiple > > skins that were configurable with a single param (i.e. ><skin>skinA</skin> > > or > > <skin>skinB<skin>). This is somewhat the same problem as i18n where >you > > want > > to say, "if the user's language is english, use these templates. if > > french, > > use these other templates." Skins are similar. If the user has >selected > > skinA, use these templates, if they chose skinB, use these other > > templates. > >"Shunting" is the mechanism to do exactly this. You can specify a >"mode" attribute for multiple views with the same name, like this: > ><maverick version="2.0" default-view-type="document"> > <modules> > <shunt-factory >provider="org.infohazard.maverick.shunt.LanguageShuntFactory"/> > </modules> > <commands> > <command name="welcome"> > <controller class="org.blah.Blah"/> > <view name="success" path="en/welcome.jsp"/> > <view name="success" mode="fr" path="fr/welcome.jsp"/> > <view name="success" mode="de" path="de/welcome.jsp"/> > ... > </command> > </commands> ></maverick> > >The LanguageShuntFactory configures shunts which pick mode based on >Accept-Language. The view without a mode becomes the default. You can >also specify a mode for a global <views> block, making it easy to define >a separate file for the views for each language. Take a look at the >maverick.xml for the shunting example: > >http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mav/maverick/examples/shu >nting-jsp/WEB-INF/maverick.xml?rev=1.3&content-type=text/vnd.viewcvs-mar >kup > >It is also worthwhile to look at the Shunt interface: > >http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mav/maverick/src/java/org >/infohazard/maverick/flow/Shunt.java?rev=1.4&content-type=text/vnd.viewc >vs-markup > >and the implementation of LanguageShuntFactory (which contains >LanguageShunt as an inner class): > >http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mav/maverick/src/java/org >/infohazard/maverick/shunt/LanguageShuntFactory.java?rev=1.4&content-typ >e=text/vnd.viewcvs-markup > >Note that LanguageShunt is considerably more complicated than a >"SkinShunt" would be. Really, a SkinShunt would be nothing more than >this: > >public View getView(HttpServletRequest request) throws >NoSuitableModeException >{ > String mode = request.getSession().getAttribute("whichSkin"); > > // Look up this mode in a hashmap > return (View)this.modes.get(mode); >} > >Make sense? > >Jeff Schnitzer >[EMAIL PROTECTED] > >_______________________________________________ >Mav-user mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/mav-user _______________________________________________ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user
