webwork-user — WebWork users mailing list

Re: [Webwork-user] Re: SessionAware

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

Hi!

Tim White wrote:
> 
> Will having a Map available in the generic session solve the
> username/password issues?

Hm.. not quite following. Can you expand? What is the issue?

/Rickard

-- 
Rickard Öberg

Email: ri...@jb...

Re: [Webwork-user] Calling methods from views

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

Hey

"Maurice C . Parker" wrote:
> Yesterday during my work on porting Jive to a portal style framework I ran into an issue where there was data that I needed pull into one of my views from an existing Jive object.
> 
> The problem is that the data wasn't accessible via an accessor, but only by calling a method.  This is what I needed to call:
> 
> public String getProperty(String s);
> 
> Would the ability to call methods from within views break Webworks pull model or would it be undesireable for view programmers to call methods?
> 
> Thoughts?

This is not directly supported, but there is a workaround. The property
names, or the subparts of them anyway, can refer to three things:
* getX() methods
* If current result is a java.util.Map, then call get(X) instead
* If current result is a java.util.ResourceBundle, then call
getObject(X) instead

So, it would be possible to do what you want right now by hiding it
behind a Map. 

public Map getProperties()
{
  return new AbstractMap()
  {
    public Set entrySet()
    {
      ... get properties into a Set and return it
    }
  }
}

Then you can refer to it by doing "properties:foo", which will be
equivalent to getProperties().get("foo").

If you do this, please send me the complete code (if that's ok I mean)
so I can add this as an example. As you're probably beginning to see the
magic of WebWork is not in it's API, but in the design and
implementation patterns that one can use. This is one such important
pattern.

regards,
  Rickard

-- 
Rickard Öberg

Email: ri...@jb...

Re: (forw) Re: [Webwork-user] Mozilla

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

Hey

"Maurice C . Parker" wrote:
> > 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.
> >
> This is good thinking.  So would it use the same actions?  It would be real cool to be able to run in different modes or skins using the same actions and you would just have different views selected from views.properties.

Note that you can get skins with just one views.properties. See the
HelloWorld example that is in WebWork. The names in views.properties
*are relative*, so if you do:
/myapp/fancy/MyAction.action
and views.properties contains
MyAction.result=myaction.jsp
Then you will get
/myapp/fancy/myaction.jsp
as result. However, if you instead do:
/myapp/simple/MyAction.action
then you will see
/myapp/simply/myaction.jsp
without having to change anything in views.properties. See the
HelloWorld example for more details.

> If this is the case, it might be clearer to put the new extension on the end of the action instead of right after the class name.

Well, the dispatcher is invoked based on the extension, so it needs to
be ".action". What we put before that is up to us though, hence the
above scheme.

/Rickard

-- 
Rickard Öberg

Email: ri...@jb...

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

[Webwork-user] Re: SessionAware

[Tim W. <tl...@us...>]

Will having a Map available in the generic session solve the
username/password issues?

Thanks,

Tim

[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

[Webwork-user] Calling methods from views

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

All,

Yesterday during my work on porting Jive to a portal style framework I ran into an issue where there was data that I needed pull into one of my views from an existing Jive object.

The problem is that the data wasn't accessible via an accessor, but only by calling a method.  This is what I needed to call:


public String getProperty(String s);


Would the ability to call methods from within views break Webworks pull model or would it be undesireable for view programmers to call methods?

Thoughts?

Maurice

Re: [Webwork-user] Need Clarification on Workflow

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

* Rickard Öberg (ri...@te...) wrote:
> 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.
> 

For me the Holy Grail would be to write an entire web application without ever needing to code a ServletAware action.  With the excellent tags and introspection provided by Webwork, I am seeing the light at the end of the tunnel.

I don't know about using tags to set the session variables and cookies.  Doesn't that violate the MVC framework somewhat?  The view would now be responsible for helping to maintain state.

I would prefer a config file that let's Dispatcher know when an action needs a little help from with it's statefulness.  Here's one possibility:

<dispatcher>
  <statehelper name="dClickPrivacyViolator" type="cookie">
      <action name="CheckForGambler" field="sitesVisited"/>
      <action name="CheckForPornSurfer" field="sitesVisited"/>
  </statehelper>
  <statehelper name="authorization" type="session">
      <action name="Login" field="authToken"/>
      <action name="CheckPermissions" field="authToken"/>
      <action name="Logout" field="authToken"/>
  </statehelper>
</dispatcher>

This way the person writing the views doesn't have to worry about statefulness, it just looks like magic to them and the person writing the actions has control over the state of thier actions without touching the servlet stuff.

Later,

Maurice

(forw) Re: [Webwork-user] Mozilla

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

* Rickard Öberg (ri...@te...) wrote:
> Hi!
> 
> > 
> > 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.
> 
This is good thinking.  So would it use the same actions?  It would be real cool to be able to run in different modes or skins using the same actions and you would just have different views selected from views.properties.

If this is the case, it might be clearer to put the new extension on the end of the action instead of right after the class name.

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] 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

[Webwork-user] WebWork 0.3 released

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

All,

I just uploaded WebWork 0.3 to CVS and the WebWork homepage (.zip).

This is partly a rewrite and partly more functionality. The name parsing
functionality is now in one place so that all tags behave the same (i.e.
the code that figures out that the name "foo:bar:xyzzy" could translate
into the calls "getFoo().get("bar").getXyzzy()".

On the functionality side I have added a tag "equals" which can be used
to compare values and conditionally do stuff. There are two examples
that uses this tag.

But I think the most interesting additions are the new examples. They
show some nifty patterns on how to use WebWork.

For example, there is now a select.jsp that one can include in ones
JSP's and which will render a <SELECT> box in a form. It takes a couple
of parameters so that one can control what should be in the listing, and
how it should determine what option is selected. 

Here's the example. select.jsp looks like this:
<SELECT NAME="<%=request.getParameter("name")%>">
<webwork:iterator name="$list">
<OPTION NAME="<webwork:property/>" <webwork:equals
value="$value">SELECTED</webwork:equals>><webwork:property/></OPTION>
</webwork:iterator>
</SELECT>
---
So, it has three parameters: name, list, and value. "name" holds the
name of the select box. "list" holds the name of the property which
should be used to fill the list box. I.e. if you have a method
"Collection getOptions()" then "list" should be set to "options".
"value" holds the property that holds the currently selected option. The
"list" and "value" properties does not have to be in the same action.
This is cool because you can have one action that does a listing of, for
example, people, and use it with a bunch of actions that render forms
where one can select a person. 

To complete the example here is the form JSP that includes it:
<FORM ACTION="FormTest.action">
<jsp:include page="AgeList.action?result=select.jsp" flush="true">
  <jsp:param name="name" value="age"/>
  <jsp:param name="list" value="ages"/>
  <jsp:param name="value" value="age"/>
</jsp:include>

<INPUT TYPE=submit VALUE="Update">
</FORM>

This is invoked by calling "FormTest.action". FormTest has methods
getAge/setAge, and AgeList has a method "getAges" that returns a list of
strings with valid options. So, by the above reasoning, you could in
this case reuse the AgeList action in several JSP forms.

You can easily make more generic components such as this which take
input parameters to render themselves.

With regard to iterators, they now work without having to specify a
property name. This is useful to traverse, for example, String[][]
objects. Let's say your action has a getArray() that returns a
String[][] object. Then you can iterate over it by doing:

<TABLE>
<webwork:iterator name="array">
  <TR>
  <webwork:iterator>
  <TD><webwork:property/>
  </webwork:iterator>
  </TR>
</webwork:iterator>
</TABLE>

This will print a table with the 2D arrays strings as cells.

Another very important upgrade was to allow forms to have values that
goes to several beans. The way it works is that your action must call
Dispatcher.setParameters() with your custom object, which will perform
the same thing it does on the action before calling execute(). There is
an example available that shows how to use this (MultiForm.java).

I have not yet updated EBS to use these new features, but will do so
shortly. 

The easiest way to see this in action is to deploy webwork.war, and surf
to "/webwork". There are now links to all the examples so that you can
easily try them all out.

Have fun! And let me know what you think about this release, and if you
think it is heading in the right direction.

regards,
  Rickard

-- 
Rickard Öberg

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

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

[Webwork-user] Need Clarification on Workflow

[Tim W. <tl...@us...>]

OK.  I'm grasping the framework pretty well now, but there are a few
things I'm still unsure on.

I'm going to walk through my app model, and match webwork to it.  Let me
know where I go astray.

Log In: Provide username and password to access application.

<webwork> Not sure how this fits in.

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.

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.

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.  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.

For the dependent objects (accounts, etc.) I'm thinking separate frames
and Form Beans.

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.  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...

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.

What do you think?

Thanks,

Tim White

Re: [Webwork-user] Setting Property of a Property

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

Hi!

Tim White wrote:
> Right, and of course I do need to both Person and Account, and some
> others. :)

Bugger...

> Hmmm.  Some of the entity beans have quite a few fields, and I'm still
> worried about having yet another set of getters and setters in a another
> object for the same data.  One thing to note, based on some fooling
> around I was doing, you can only pass in String parameters as far as I
> can tell to be automatically set.  This prevents you from using a Data
> class where some items are Integers etc.

This is incorrect. PropertyEditors are used. PropertyEditors for all
primitive types are available by default, and you can install your own
or create BeanInfo objects to have more control (I prefer BeanInfo
objects, especially since I generate them with a custom doclet..).

> There has to be some way of leveraging existing objects for this - this
> is Java after all. :)

Indeed, and fear not, it is there :-) Try making a setFoo(int x) method.
Also look in the dispatcher code (setParameters) for details.

> Here are some thoughts:
> 
> What are you doing with "extra" parameters passed in on the form submit
> right now?  Are they being discarded?  

yes, due to the "action pulls what it needs" philosophy. If you want to
use more of the parameters, simply define more setX() methods.

> If so, perhaps they could instead
> be placed in a collection that lived in ActionSupport.  A method of that
> collection could map it's contents to the getters and setters of a
> target object in the subclass, hopefully doing String-to-datatype
> conversions if needed.

Well, you can always bypass this whole servlet-agnostic thing and
implement ServletAware. This will give you the servlet request, from
which you can get the parameters.

> Or, if the extra parameters are still living in the ServletContext, you
> could provide a method in ActionSupport to pull them out and assign them
> to an object within the form bean.

As above, this is already available :-) Either implement ServletAware,
or subclass ServletAwareActionSupport. This "backdoor" ensures that one
can always get the whole shebang if necessary, although I prefer the
servlet-agnostic Action-style as much as possible (keeps them clean and
simple, and also makes it possible to reuse in Swing UI, and makes it
easier to do automatic testing outside of servlet environment!).

regards,
  Rickard

-- 
Rickard Öberg

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

Re: [Webwork-user] Setting Property of a Property

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

On second thought...

> > But I can't seem to set the property of a property in an action the same
> > way.
> >
> > I'd prefer not to define getters and setters for all my data object's
> > fields again in the action class, since I have a lovely PersonData class
> > generated by EJBDoclet that already has all those getters and setters.
> >
> > I'd like to make the name of an HTML Form field currentPerson:lastName
> > and have webwork set the lastName field of the PersonData attribute of
> > the PersonEdit class.
> >
> > Is this possible?  I can't seem to get it to work - I have debug turned
> > on, and the Dispatcher doesn't appear to be recognizing the : fields in
> > setParameters.
> >
> > Any thoughts?
>
> Wow, that is a great idea! :-) Why didn't I think of that... add this to
the
> task tracker on the site.
>
> Or can anyone think of semantical problems with it? Off the top of my head
> it seems very cool, but I might be missing something...

There are problems with this. This is what we are talking about:
?foo:bar=xyzzy should result in action.getFoo().setBar("xyzzy");

The first problem is a coding one. The action dispatcher currently sets
parameters in a "pull" way: it gets the actions BeanInfo and for all setX
found it calls it with the corresponding value from parameters. I.e. we go
from action to parameter. With the : notation on parameters it would have to
be the other way round, i.e. parameters are "pushed" into the action. This
is bad because sometimes only a subset of the parameters should be set (if
actions are used in a hierarchical way), and it is also more computationally
expensive since the dispatcher would have to list the parameters and for
each parameter do a linear search of the bean properties to find the right
one. The complexity would be O(N^2) instead of O(N), which is bad.

Another problem is that it would change the semantics of how actions are
used somewhat. Currently the flow is
1) call setters
2) call execute
3) call getters
With the : notation this would change to
1) call setters, and possibly get and set on return value of get
2) call execute
3) call getters
which I'm not quite happy with.

What do you think?

There is also a workaround for what you want to do: let the action subclass
your PersonData. This is actually how most of the actions work in EBS: the
base class is a barebones JavaBean with get/set, and whose execute method
does nothing, and they are then subclassed with actions that only implement
execute and additional get methods for result data.

Is this ok for you? The only drawback with this that I can think of is if
your form include both PersonData and AccountData, because your action can't
subclass both at the same time.

/Rickard

Re: [Webwork-user] Setting Property of a Property

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

Hi!


> But I can't seem to set the property of a property in an action the same
> way.
>
> I'd prefer not to define getters and setters for all my data object's
> fields again in the action class, since I have a lovely PersonData class
> generated by EJBDoclet that already has all those getters and setters.
>
> I'd like to make the name of an HTML Form field currentPerson:lastName
> and have webwork set the lastName field of the PersonData attribute of
> the PersonEdit class.
>
> Is this possible?  I can't seem to get it to work - I have debug turned
> on, and the Dispatcher doesn't appear to be recognizing the : fields in
> setParameters.
>
> Any thoughts?

Wow, that is a great idea! :-) Why didn't I think of that... add this to the
task tracker on the site.

Or can anyone think of semantical problems with it? Off the top of my head
it seems very cool, but I might be missing something...

regards,
  Rickard

[Webwork-user] Setting Property of a Property

[Tim W. <tl...@us...>]

Well, I can get the property of a property by separating them with :,
that's very cool.

But I can't seem to set the property of a property in an action the same
way.

I'd prefer not to define getters and setters for all my data object's
fields again in the action class, since I have a lovely PersonData class
generated by EJBDoclet that already has all those getters and setters.

I'd like to make the name of an HTML Form field currentPerson:lastName
and have webwork set the lastName field of the PersonData attribute of
the PersonEdit class.

Is this possible?  I can't seem to get it to work - I have debug turned
on, and the Dispatcher doesn't appear to be recognizing the : fields in
setParameters.

Any thoughts?

Thanks,

Tim

[Webwork-user] build.sh

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

Rickard,

A small change to the build.sh for Linux was needed to get the CVS version of Webwork to compile:

The version I got to work now looks like this:



#! /bin/sh
 
# $Id: build.sh,v 1.2 2000/11/22 08:30:46 rickardoberg Exp $
  
TARGET_CLASSPATH=../../lib/ant.jar:\
../../lib/parser.jar:\
../../lib/jaxp.jar
   
if [ "$JAVA_HOME" != "" ] ; then
   TARGET_CLASSPATH=$TARGET_CLASSPATH:$JAVA_HOME/lib/tools.jar
else
   echo "Error: The JAVA_HOME environment variable is not set."
fi
	    
java -classpath $TARGET_CLASSPATH org.apache.tools.ant.Main $*   

[Webwork-user] Test

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

Test

-- 
Rickard Öberg

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

[Webwork-user] Test

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

Test

-- 
Rickard Öberg

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