struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marco Schwarz <marco.schw...@cioppino.net>
Subject Re: <s:textfield /> Beginner question
Date Mon, 14 Nov 2011 19:47:40 GMT
I remember I'm new with Struts2 ;-)

Why do I use Struts2/Tiles/openJPA?

openJPA: to work with database entities
tiles: to work with layouts
struts2: the action concept and the posibility to make mapping between
html and the object in my action.

example:

model:
class Person() {
  private int id;
  private String name;
  public String getName() { return name; }
  public int getId() { return id; }
  public void setName(String name) { this.name = name; }
  publci void setId(int id) { this.id = id; }
}

action:
PersonAction extends {

  private Person person;

  @override
  public String execute throws Execption {

    //read Person 1 from DB
    person = em.find(1, Person.class);

    return SUCCESS;

  }

}

html:
<s:textfield name="person.id" label="id" />
<s:textfield name="person.name" label="name" />

When I must read the request, why do I use Struts2... Servlet do the same.

Thanks
Marco




On Mon, Nov 14, 2011 at 3:58 PM, Edward W. Rouse <erouse@comsquared.com> wrote:
> You could always store it in the session and read it from there.
>
>> -----Original Message-----
>> From: Marco Schwarz [mailto:marco.schwarz@cioppino.net]
>> Sent: Saturday, November 12, 2011 1:57 PM
>> To: Struts Users Mailing List; jlmagc@gmail.com
>> Subject: Re: <s:textfield /> Beginner question
>>
>> You are right, but the user must see the fields and I need the object
>> with all properties for call (JPA) persist method. what's the best
>> practice for this use case
>>
>> I have one object and many roles ....  any role can change a different
>> field ... Do I create a class for any roles?
>>
>> Idea?
>>
>> Thanks
>> Marco
>>
>>
>> On Sat, Nov 12, 2011 at 7:31 PM,  <jlmagc@gmail.com> wrote:
>> > The use of hidden fields to avoid the user changing those fields is a
>> security risk. You are still getting all the fields from the client's
>> side, so the user or somebody else (through a man-in-the-middle
>> atytack) are still able to change the value of those fields.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message