webwork-user

[Webwork-user] Mozilla

[Maurice C . P. <Ma...@Vi...>]

I was trying out the new 0.3 release this morning using a nightly Mozilla build on Linux and hit a little snag.  The Helloworld view didn't render in the browser, instead the raw HTML was displayed.  Since I was using a recent nightly build this will probably impact NS 6.0.  This change to the Dispatcher fixed the problem:

Index: Dispatcher.java
===================================================================
RCS file: /cvsroot/webwork/webwork/src/main/webwork/servlets/Dispatcher.java,v
retrieving revision 1.2
diff -u -r1.2 Dispatcher.java
--- Dispatcher.java	2000/11/28 15:27:39	1.2
+++ Dispatcher.java	2000/11/28 20:11:58
@@ -157,6 +157,9 @@
    public void service(HttpServletRequest request, HttpServletResponse response)
       throws ServletException
    {
+
+      response.setContentType("text/html"); 
+	  
       if (debug)
       {
          Enumeration enum = request.getAttributeNames();

I think that this will be OK as long as only HTML the desired output from the Dispatcher.

Later,

Maurice

Re: [Webwork-user] Mozilla

[Rickard <ri...@te...>]

Hi!

"Maurice C . Parker" wrote:
>     public void service(HttpServletRequest request, HttpServletResponse response)
>        throws ServletException
>     {
> +
> +      response.setContentType("text/html");
> +
>        if (debug)
>        {
>           Enumeration enum = request.getAttributeNames();
> 
> I think that this will be OK as long as only HTML the desired output from the Dispatcher.

Yeah, I can see the problem and why the above fixes it... hm.. but it is
not good in the long run, since it should be possible to create XML,
WML, PDF, whatever.. the text/html is a good default, but it should be
overridable. 

I was thinking something like:
Foo.action -> text/html as type
Foo.wml.action -> text/wml as type
Foo.plain.action -> text/plain as type
etc.

Does this seem reasonable? It is a bit more computation to do on each
call though (check extensions), but at least it is "future compliant" so
WebWork can support multiple output MIME-types.

/Rickard

-- 
Rickard Öberg

Email: ri...@te...
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com

[Webwork-user] Session interaction

[Rickard O. <ri...@te...>]

Hey

Re: servlet agnostic session interaction. I think I have an interesting
solution to this.

Let's introduce an interface SessionAware, which contains the method
public void setSession(java.util.Map session);

When the action is created it is tested for SessionAware, and if the action
implements it, it is called. However, since we want to keep the action
servlet agnostic, it will get a Map and not the real Session. This Map will
be a proxy object that simply converts the Map calls to Session calls.

This way it should still be possible to run all actions without a servlet
environment, for example in automatic testing (e.g. regression tests), and
it should also be possible to reuse them in a Swing GUI, in which case the
session is simply a HashMap or similar.

What do you think? Some of the methods in Session are not available in Map,
but I figured it is "good enough" and one can always get to those extra
methods by using ServletAware.

Is this nirvana yet?

regards,
  Rickard

Re: [Webwork-user] Session interaction

[Maurice C . P. <Ma...@Vi...>]

* Rickard Oberg (ri...@te...) wrote:
> Hey
> 
> Re: servlet agnostic session interaction. I think I have an interesting
> solution to this.
> 
> Let's introduce an interface SessionAware, which contains the method
> public void setSession(java.util.Map session);
> 
> When the action is created it is tested for SessionAware, and if the action
> implements it, it is called. However, since we want to keep the action
> servlet agnostic, it will get a Map and not the real Session. This Map will
> be a proxy object that simply converts the Map calls to Session calls.

Very elegant.

> 
> This way it should still be possible to run all actions without a servlet
> environment, for example in automatic testing (e.g. regression tests), and
> it should also be possible to reuse them in a Swing GUI, in which case the
> session is simply a HashMap or similar.

True.  The concept of a session is not particular to HTTP programming.

> 
> What do you think? Some of the methods in Session are not available in Map,
> but I figured it is "good enough" and one can always get to those extra
> methods by using ServletAware.

More than "good enough".  If you need the other methods you are probably 
worried about more than just maintaining state and should be using ServletAware.

> 
> Is this nirvana yet?

Yes!


Later,

Maurice