I haven't heard much in the way of a reponse on
this proposal so I guess I'll be on my own.... In either case, I would
like to make one more addendum to what I'm proposing in case anyone is
interested.
There are times I've found when the presentation
(input mapping) is not cut and dry. For instance, consider these
URLS:
Besides all being bill payment sites, the
commonality between them is that they are all run on the same servers at
Paytrust and all use the same underlying business logic (servlets)! I
architected the presentation (JSP) to vary depending on the partner we are
currently serving up in the request. I would like to see this type of
metaphore extended to the action servlet. So, during the pre_rendering
notification, I can for instance, tell the action servlet specifically what JSP
file to use. The mappings are not fine-grain enough. In the case
above, they all are mapped to DemoLogin. The real / physical JSP that gets
loaded is determined by the request.
The hierarchy of the JSPs look like
this:
baseJSPdir { contains all of the default
JSPs that have templates to define simple variation such as color, headers, etc.
}
|
-paytrust
{ contains a set of overriding JSPs going
by the same name which are unique to the site }
-<cobrandX>
{ ditto (see above)
}
Any takers? Its been quite successful for me
up to now and would require minimal changes to struts...
Thanks,
Jeff
|
- Proposal Jeff Trent
- Re: Proposal Ted Husted
- Re: need solution Rajasekhar Bodduluri
- Re: Proposal Taylor Cowan
- Re: Proposal Jeff Trent
- RE: Proposal Dan - Blue Lotus Software
- Re: Proposal Jeff Trent
- RE: Proposal Dan - Blue Lotus Software
- Re: Proposal Jeff Trent
- Re: Proposal Jeff Trent
- Re: Proposal Ted Husted
- Re: Proposal Jeff Trent
- Re: Proposal Ted Husted
- Re: Proposal Taylor Cowan
- Re: Proposal Craig R. McClanahan
- RE: Proposal Dan - Blue Lotus Software
- Re: Proposal Taylor Cowan
- RE: Proposal Craig R. McClanahan
- RE: Proposal Dan - Blue Lotus Software
- Re: Proposal Craig R. McClanahan