Form initialization and frames

[mc...@ThoughtWorks.com]

We have a jsp called search.jsp that looks something like this

<frameset ...>
      <frame name="header" src="header.jsp" noresize scrolling="no"/>
      <frameset ...>
            <frame name="criteria" src="criteria.jsp" noresize scrolling
="no"/>
            <frame name="results" src="results.jsp" noresize scrolling
="auto"/>
      </frameset>
</frameset>

I have a CriteriaForm that I want to prepopulate some data on using an
Action whenever the user goes to this page. I also want the form stored on
the request not the session. The problem is that my forward from the Action
has to go search.jsp after it populates the form so the form tag on
criteria.jsp cannot find the form on the request. It just creates a new
instance of the form.

I don't want to put it on the session because I don't want to have to worry
about cleaning it up off the session.

This is a small section of a large app ( a few hundred jsp's ) so I have
simplified things a bit.

We think we are kind of stuck with frames because as you can probably guess
we want the results to show up below the criteria and we want to be able to
scroll the results without scrolling the criteria off the screen.

It is an existing app that we are strutsifying so changing look and feel is
not really an option.

Does anyone have a way to do this?

Thanks

2

Mike Two; Putting the tWo in Thoughrks


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Need Example code or guidance for Implementating JAAS in Struts/Web Application

["Sudhir S. Shetty" <ss...@powershare.net>]

Hi Everyone,
                      I would be very greatful if you could guide or send me
example code for implementing JAAS in a Web Application/ Struts. I am using
Weblogic 6.1 as my app server.
Thanks in advance,
regards,
Sudhir


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Form initialization and frames

[Erik Hatcher <ja...@ehatchersolutions.com>]

I have just tackled this very issue.  I did try to make my solution
extremely generalized, but I haven't decided if/when it will be ready to
contribute back.  But I will describe its architecture:

In our application we have many two-frame pages, top containing criteria,
bottom containing results.  I have a single action that I call
/<subsystem>/searchSetup.do that forwards to the two-frame JSP page. I have
a FramesetData object that is session-scoped. It encapsulates action errors,
criteria (a value object representing the form bean from the top frame,
typically), and the results (yes, results are stuffed into session, and I'll
explain why below).

The searchSetup.do action pulls action errors from request scope and puts
them into the FramesetData object, and the criteria and results, if present
in the request, are put into the FramesetData object also.  The FramesetData
object is keyed in session-scope by its action mapping path (up to the last
forward-slash) - which makes it unique for all such pages in our system.

The top-frame's form targets "_top" and its action performs the search based
on the criteria, so that all form validation errors and errors generated
from the action get put into request scope as well as the criteria and
results (these get keyed with a prefix matching the session key - but only
get stored in request scope here).

Both the top and bottom frames are .do links, and the top frame's action
fetches any drop-down boxes needing populated, fetches the criteria from the
FramesetData object and re-populates the form.  The bottom frame's action is
generalized to simply make a request scoped attribute called "results" with
the results from the FramesetData object.

Results are stored in session because I wanted to make sure any errors
generated during the creation of those results gets sent to the top frame.
The form submit button forwards back to the searchSetup.do action so both
frames get recreated when the submit button is pressed.  Our application is
not designed for heavy use, and when/if the memory eaten by the results in
session become an issue it will be addressed, but for now its working
nicely.

I'm not sure I've covered all the pieces of the "frame"work I've created,
but hopefully that is enough food for thought.  I'd be interested in hearing
how others have tackled this tricky issue.  I'm not at all a fan of frames,
but this solution made it at least workable to achieve the UI features
desired.  If there are any questions on this I'd be more than happy to
answer them.

    Erik



----- Original Message -----
From: <mc...@ThoughtWorks.com>
To: <st...@jakarta.apache.org>
Sent: Friday, December 21, 2001 7:24 PM
Subject: Form initialization and frames


> We have a jsp called search.jsp that looks something like this
>
> <frameset ...>
>       <frame name="header" src="header.jsp" noresize scrolling="no"/>
>       <frameset ...>
>             <frame name="criteria" src="criteria.jsp" noresize scrolling
> ="no"/>
>             <frame name="results" src="results.jsp" noresize scrolling
> ="auto"/>
>       </frameset>
> </frameset>
>
> I have a CriteriaForm that I want to prepopulate some data on using an
> Action whenever the user goes to this page. I also want the form stored on
> the request not the session. The problem is that my forward from the
Action
> has to go search.jsp after it populates the form so the form tag on
> criteria.jsp cannot find the form on the request. It just creates a new
> instance of the form.
>
> I don't want to put it on the session because I don't want to have to
worry
> about cleaning it up off the session.
>
> This is a small section of a large app ( a few hundred jsp's ) so I have
> simplified things a bit.
>
> We think we are kind of stuck with frames because as you can probably
guess
> we want the results to show up below the criteria and we want to be able
to
> scroll the results without scrolling the criteria off the screen.
>
> It is an existing app that we are strutsifying so changing look and feel
is
> not really an option.
>
> Does anyone have a way to do this?
>
> Thanks
>
> 2
>
> Mike Two; Putting the tWo in Thoughrks
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>