I wanted to do something where a just created the properties for each club based on the URL and pass resources and a directory to the jsp pages. I think in my case it would be best on the server to have just one set of pages running even if there is a bit more overhead processing the pages. This would save on ram usage, which I could then use for caching of pages to increase the speed of the site.
Also this way I can seperate the content/configuration (which I would store in a directory stucture for all the clubs) from the logic which would be a struts application. This was the type of thing that I was doing before except that previously I was passing a clubID in the URL. This is no longer an option because every club needs to be accessabe from just a standard URL without a query string. I also need to integrate this with some parts from an existing PHP site which I'm sure is going to add some complexity to the site. And I don't want to have to erase and rebuild 50 sites everytime I need to fix a little problem. Which with my client happens several times a day. Thanks for the help. mike On Tue, 2002-05-14 at 06:38, [EMAIL PROTECTED] wrote: > > > > You're not reading this wrong. I'm advocating creating 50 webapps (and 50 > war files) if you have 50 sites. > > But I've always felt that disk space and server memory are cheap compared > to developer time. CPU requirements would likely be the same with either > approach. > > Don't run from ghosts - that is, don't spend a lot of effort programming > around hardware limitations that don't exist or that can be eliminated by a > few hundred dollars in parts. Developer time is the critical resource - not > hardware. > > I believe that this approach (driving the site customization at build-time > versus run-time) will give you a simpler codebase that's likely to be > eaiser (i.e. faster) to develop. > > However, if you want to drive the customization at run-time, you could do > so with a similar approach: > > - Still drive every thing that is site-specific from properties. > - Create a cache of Properties objects (or ResourceBundles) in a Hashmap > that gets loaded at start-up (and potentially allow for dynamic reload > without restarting the server). These Properties objects would contain all > site-specific values. > - To build the View (i.e. jsp) for each request retrieve the Properties > object containing the propery values for that site based on some lookup > driven by the url/uri requested. > - You could create a <SetSiteProperties> tag that attached the Properties > object to the Request with some known attribute name - this type of > behavior occurs throughout Struts so you could find examples somewhere in > the code. > - Then the html output is customized by the Properties. > > Gosh - now that I look at this, it doesn't look that hard either.... > > What do you think? > > > > > > Mike Karl <[EMAIL PROTECTED]> on 05/13/2002 07:07:07 PM > > Please respond to "Struts Users Mailing List" > <[EMAIL PROTECTED]> > > To: Struts Users Mailing List <[EMAIL PROTECTED]> > cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) > Subject: Re: Multiple sites using one struts application. > > > Would this then build me an application for each site? So it would copy > the files over for each site. I don't know that this is viable because > I have 50 or so sites that would be running on one server. What I would > like is just one set of files running at a time and not 50 so that I > could save on server resources. Or am I reading this wrong. > > thanks > mike > > > On Mon, 2002-05-13 at 15:31, [EMAIL PROTECTED] wrote: > > > > > > > > > > I believe this is a build/deploy question as much as a Struts question. > But > > here goes: > > > > 1. Drive virtually everything from your application.properties file. All > > these properties are available to your Action classes. For example, > define > > the path to your images directory there, the club name, the jdbc url, > etc.) > > > > 2. Create each site as it's own web app - but keep everything in a SINGLE > > SOURCE CONTROL REPOSITORY version. You will create specific sites ONLY AT > > BUILD TIME. Again - only one version exists in source control. Call this > > The Template. > > > > This is critical. No site-specific code or properties get checked in > > with The Template. Everything is driven from the application.properties > > file. > > > > 3. Define the values in this application.properties file using "tokens", > > not actual values. For example: > > > > in The Template application.properties for Struts: > > > > club.name=CLUB_NAME > > path.to.images=IMAGE_PATH > > site.jdbc.url=JDBC_URL > > > > - etc. - > > > > 4. Then, for each actual site, create a seperate "properties" file > > containing the specific values for that site. For example: > > > > in "club1.properties" > > > > club.name=Fred's Club > > path.to.images=/fredimages/images > > site.jdbc.url="jdbc:oracle:thin:@123.45.67.89:1521:orcl" > > > > - etc. - > > > > 5. At build time, use Ant's "<replace>" target to replace the "tokens" in > > the struts application.properties file with the site-specific values from > > the site-specific properties files. That is: > > > > > > <replace > > file="path/to/struts/application.properties" > > propertyFile="path/to/specific/club.properties" > > > <replacefilter > > token="CLUB_NAME" > > property="club.name"/> > > <replacefilter > > token="IMAGE_PATH" > > property="path.to.images"/> > > <replacefilter > > token="JDBC_URL" > > property="site.jdbc.url"/> > > </replace> > > > > > > See details on the Ant <replace> tag at: > http://jakarta.apache.org/ant/manual/CoreTasks/replace.html > > > > 6. Create a different ant target to build each site. And maybe a > "build-all" to build all the sites. > > > > There's a bit of work here getting things organized. But this will > allow you to generate sites from The Template as a build/configuration > process > > - not as a development issue. > > > > Summary: > > > > 1. Drive EVERYTHING site specific from the application.properties file > > 2. Use tokens in the application.properties file instead of actual > values > > 3. Create the actual sites at build/deploy time using Ant and the > <replace> target. > > > > This will work! > > > > > > FWIW - > > Kevin > > > > > > > > > > > > Mike Karl <[EMAIL PROTECTED]> on 05/13/2002 04:51:36 PM > > > > Please respond to "Struts Users Mailing List" > > <[EMAIL PROTECTED]> > > > > To: [EMAIL PROTECTED] > > cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) > > Subject: Multiple sites using one struts application. > > > > > > Hello, > > I'm building a site for a group of clubs. All the sites will have the > > same set of pages and actions. > > > > For instance: > > > > http://clubsites/club1/index.jsp > > http://clubsites/club2/index.jsp > > http://clubsites/club3/index.jsp > > http://anothersite/club4/index.jsp > > > > All of these sites would basically be the same in terms of layout and > > functionality except that the would have different images. They may > > also connect to seperate database. How can I set up a site like this so > > that I can use the same pages for all of the clubs but pass different > > configurations so that I can render the pages with their own images. > > > > thanks > > mike > > > > > > > > -- > > To unsubscribe, e-mail: < > > mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: < > > mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > --------------------------------------------------------------------------- > > This e-mail message (including attachments, if any) is intended for the > use > > of the individual or entity to which it is addressed and may contain > > information that is privileged, proprietary , confidential and exempt > from > > disclosure. If you are not the intended recipient, you are notified that > > any dissemination, distribution or copying of this communication is > > strictly prohibited. If you have received this communication in error, > > please notify the sender and erase this e-mail message immediately. > > > --------------------------------------------------------------------------- > > > > > > -- > > To unsubscribe, e-mail: < > mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: < > mailto:[EMAIL PROTECTED]> > -- > Mike Karl > > Montana Connect > 851 Bridger Dr. > Bozeman, MT 59715 > (406) 556-1800 > > [EMAIL PROTECTED] > > -- > To unsubscribe, e-mail: < > mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: < > mailto:[EMAIL PROTECTED]> > > > > > > > > --------------------------------------------------------------------------- > This e-mail message (including attachments, if any) is intended for the use > of the individual or entity to which it is addressed and may contain > information that is privileged, proprietary , confidential and exempt from > disclosure. If you are not the intended recipient, you are notified that > any dissemination, distribution or copying of this communication is > strictly prohibited. If you have received this communication in error, > please notify the sender and erase this e-mail message immediately. > --------------------------------------------------------------------------- > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- Mike Karl Montana Connect 851 Bridger Dr. Bozeman, MT 59715 (406) 556-1800 [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
