Re: [Webwork-user] Need Clarification on Workflow

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

Hi!

Tim White wrote:
> Log In: Provide username and password to access application.
> 
> <webwork> Not sure how this fits in.

I think there will have to be a ServletAware action that sets a cookie
or something in the session.

Maybe one could do a tag that extracts result data into a session. That
will allow things to be servlet agnostic.

I.e. Login.action:
setUserName(..)
setPassword(..)
execute() -> loggedin.jsp
loggedin.jsp:
<webwork:session name="username"><webwork:property
name="username"/></webwork:session>
i.e. extract username from Login action and place in session under name
"username". This will keep the action from having to know anything about
servlets.

This part is not complete yet, so any suggestions are welcome.

> Search For People: Provide a search string and receive a list of People.
> 
> <webwork> Form Bean that takes a search string as a parameter, finds
> appropriate beans, and puts them in a Collection attribute.  The JSP
> iterates over the collection and prints the list.  I could go direct SQL
> here for performance, I suppose.

Yes, pretty straightforward. In EBS I have made this as two beans: first
a form bean which contains all form fields, and does nothing on
execute(). On "submit" another action is called which subclasses the
form bean (so that it has the right fields) and which does validation
and then SQL execution (if all is well). If validation fails it outputs
the first forms .JSP, which shows the form with the fields and the error
messages. If validation is ok I show a JSP with the form and its values,
plus a result table. See find.* and find/*.jsp in EBS for examples.
Heck, the view.* and view/*.jsp also work this way come to think of it.

> Edit Person: Click on a Person from the search list and edit that
> Person's info.
> 
> <webwork> Form Bean that takes a PersonId as a parameter, looks up the
> right Entity Bean, and attaches it to an attribute.  The JSP then pulls
> out the attributes into an edit form.

Yup:
setPersonId(..)
execute(): get entity info -> showperson.jsp
getPerson(): return info 
In showperson:
<webwork:property name="person">
  Name: <webwork:property name="name"/>
  Age: <webwork:property name="age"/>
</webwork>
or:
  Name: <webwork:property name="person:name"/>
  Age: <webwork:property name="person:age"/>
Which is the same thing.

> Save Person: Submit changes to a person made on the edit form.
> 
> <webwork> I couldn't find a good example of this in EBS.  Only the
> fields that were changed should be changed on the Entity Bean.
> Validiation and error checking has to occur.  So I have a Form Bean that
> takes each and every attribute of the person as parameters (setters for
> each).  Rather than individual attributes, each setter sets an attribute
> of a PersonData attribute.  

Note that your form bean can simply subclass PersonData in this case.

> Then Person.setData is called with the data
> object.  Voila, the data is changed.  The problem is, if not all the
> parameters are specified, the data class ends up nulling those fields
> from the Entity Bean. :(  I'd like to avoid brute-force listing each
> parameter and comparing it.

You want the form to be initially filled with the PersonData, yes?

Hmmm... here is the best solution I think:
you should have two actions. Action one has getData(), and retrieves the
PersonData on execute(). It returns "personform.jsp" from execute(),
which extracts person info from the data from getData(). Now you will
see the current info for the selected person. When you click submit you
call another action which subclasses the first one. One execute it first
calls super.execute() so that the original PersonData is retrieved. Now
you can simply call set on the getData() object, and then do
Person.setData(getData()). Return "personform.jsp" and it will again
show the current data, but now it reflects the new data.

Makes sense?

> I'm worried that I should be using a stateful session bean, or some
> other method to hold onto the Person Entity Bean here, rather than
> looking it up over and over.  

I think it is ok to look it up over and over.

> But since I don't have direct access to
> the ServletContext, or some other stateful repository with the basic
> webwork model, I'm wondering how this could be accomplished.  I'm sure
> I'm missing something...

You always have access to everything if you use the ServletAware
interface. Then you will get the request and response which you can use
for whatever purposes. Subclass ServletAwareActionSupport for this. For
most uses this will not be required though.

> For example, if an error occurs, I have to look the bean up again to
> print the error and go back to the edit screen.

This can easily be done without any servlet info. Look at the HelloWorld
example in WebWork, which does this!

/Rickard

-- 
Rickard Öberg

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