You might be able to use the Shunting facility of the Maverick MVC
framework (http://mav.sourceforge.net) to accomplish your goal.
Shunting allows different views to be automatically chosen based on
characteristics of the request; the stock example chooses between
different language views based on the Accept-Language header.

It would be easy to write a simple custom Shunt that makes decisions
based on the Referer header.  I'm not quite sure I understand exactly
what you are trying to do, but I would be surprised if Maverick cannot
accommodate it.

Jeff Schnitzer
[EMAIL PROTECTED]

> -----Original Message-----
> From: ���� �������� [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, April 09, 2002 8:30 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [Advanced Servlets] Design Patterns
> 
> CG> Hi all.
> CG>         I'm using the MVC pattern for my current projects. In it,
my
> servlet
> CG> is using a Front Controller type design pattern, finding out who
> requested
> CG> it (by using the REFERER header) and processing it before finding
out
> what
> CG> the requested was (by using request.getServletPath()). It then
> determine the
> CG> navigation for the buttons on the next page using XML bindings
into a
> CG> javabean.
> CG>         This works fine for simple systems that have a fixed flow,
but
> when
> CG> I added a href style click and jump navigation system. It starts
to
> cause a
> CG> bit of problems. Not in the point and click itself but when you
link
> in from
> CG> a separate browser window using the point and click system as well
as
> when
> CG> there is a redirection to an error page. (using error page
definitions
> in
> CG> web.xml).
> CG>         Is there a better way to do the navigation? Can someone
> recommend a
> CG> design pattern that works better than the Front Controller? Or
maybe
> show a
> CG> better example of how Front Controller can be used better? (The
> petstore
> CG> example is too simple to be of any use here). It works fine now
but
> it's
> CG> starting to look like it could be a problem for someone
maintaining it
> in
> CG> the future (yea i actually want to make it easy for someone else
to
> maintain
> ;>>) Something like what Struts does with the action forms is good but
> Struts
> CG> is way too much overhead for something that should be pretty
simple.
> 
> 
> try this http://www.brainopolis.com/theseus/index.html
> 
> 
> CG>         The main issue is that this servlet should be "plug and
> playable"
> CG> into future systems with minimal changes. To do this currently, I
am
> just
> CG> maintaining a separate XML config file for the 2 projects. I want
to
> keep
> CG> the ease of that but have a cleaner controller servlet.
> CG> -Tim
> 
> --
> Best regards,
>  Yuriy
> 
>
________________________________________________________________________
__
> _
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff SERVLET-INTEREST".
> 
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources:
http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html

___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".

Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html

Reply via email to