Re: Custom class persistent objects are not persistent

Fri, 22 Jul 2005 10:33:06 -0700

Robert is correct for what I am trying to do and here is a simple example that you can try and see if you get the same problem (my custom class objects not being persistent) that I have. You can just copy and paste into the respective files. 

Testing.page
--------------------

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE page-specification
   PUBLIC "-//Apache Software Foundation//Tapestry Specification 3.0//EN"
   "http://jakarta.apache.org/tapestry/dtd/Tapestry_3_0.dtd";>

<page-specification class="org.richi.Testing">
<property-specification name="myValue" persistent="yes" type="org.richi.VString" initial-value="initialVString"/> <property-specification name="myValue1" persistent="yes" type="java.lang.String" initial-value="initialString"/> 
 <component id="form" type="Form">
 </component>
 <component id="inputValue" type="TextField">
   <binding name="value" expression="myValue.value"/>
 </component>
 <component id="inputValue1" type="TextField">
   <binding name="value" expression="myValue1"/>
 </component>
 <component id="actionSubmit" type="Submit">
 </component>
</page-specification>


Testing.html
-------------------
<html>
<head>
 <title>Testing</title>
 <meta name="GENERATOR" content="Quanta Plus">
 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body jwcid="$content$">
<div align="left"><h3>Testing</h3>
<form jwcid="form">
   <input jwcid="inputValue" type="text"/>
   <input jwcid="inputValue1" type="text"/>
   <input jwcid="actionSubmit" type="submit"/>
</form>
</div>
</body>
</html>



org/richi/Testing.java
--------------------------------

package org.richi;

public abstract class Testing extends BasePage {
 public VString getInitialVString() {
   return new VString("Default VString");
 }
 public String getInitialString() {
   return new String("Default String");
 }
}



org/richi/VString.java
--------------------------------

public class VString implements Serializable {
 String value = null;
 public VString() {}
 public VString(String str) {
   setValue(str);
 }
 public void setValue(String str) {
   value = new String(str);
 }
 public String getValue() {
   return value;
 }
}
Now if you submit the form after entered some text to the textfields and hit the "refresh" button on your browser, you will notice that the first textfield will reset to "Default VString " while the second one doesn't (i.e. the first one doesn't persist and the second one does). The only difference between these two textfields is that the first one is binded to an object type VString (a complex object composed of a String) and the second one is a simple object type String. Notice also that in the *.java implementation of the page, I don't mention the abstract getters nor setters as I don't need them; I use the properties only in the *.page file. So why is this? Am I missing something? I know the problem can be solve by just using a String directly, but imagine that I have a much more complex class to represent a database record and would like to access its members from a form. 

Thank you for your help.

Richard



From: Robert Zeigler <[EMAIL PROTECTED]>
Reply-To: "Tapestry users" <[email protected]>
To: Tapestry users <[email protected]>
Subject: Re: Custom class persistent objects are not persistent
Date: Thu, 21 Jul 2005 23:34:36 -0500

Patrick Casey wrote:
>    His problem is that his properties are not persisting, neh? So he
> needs to implement some form of persistence. If he doesn't, some of his
> properties may "hang around" in the page because they're never
> re-initialized, but then you're basically racing the garbage collector (and 
> any other user who might check out the same page).
>
>    So far as I know, if you're not actively persisting your properties
> (setting and using the persist flag for example), then the fact that a
> property stays set between interactions with the client is nothing more than > an artifact of a development environment where you're the only one using a > given page instance. In production, where somebody else may check out that > page instance and set its concrete properties, you can't count on things you 
> "set" in the page object still being there the next time you happen to
> request it.
>
>    For that matter, you might not even get back the same page object
> instance, all Tapestry guarantees is that if you ask for a "Login" page you 
> get an instance of that page class. It doesn't guarantee that a given
> session gets the *same* instance back time after tim.
>


All of that is very true.  Sorry for the confusion, perhaps my original
e-mail was unclear.  An example would probably be
better...
Given the following .page file:

<page-specification class="MyPage">
<property-specification name="myValue" persistent="yes" type="VString"
initial-value="new VString('default')"/>

<component id="inputValue" type="TextField">
   <binding name="value" expression="myValue.value"/>
</component>
</page-specification>

This java class is perfectly acceptable:
.java:
public class MyPage extends BasePage
}

So is:
public abstract class MyPage extends BasePage
    public abstract VString getMyValue();
    public void setMyValue(VString val);
}

As is:
public class MyPage extends BasePage {
   public VString getMyVal() {
      return (VString) getProperty("myValue");
   }
   public void setMyVal(VString val) [
      setProperty("myValue",val);
   }
}

What is /not/ valid, as you pointed out, is doing:

public class MyPage extends BasePage {
   private VString myValue;
}
And then accessing myValue. Also invalid, as you well know:
public class MyPage extends BasePage {
   private VString myValue;
   public VString getMyValue() {
      return myValue;
   }
   public void setMyValue(VString val) {
      myValue = val;
   }
}

The way I understood Richard's e-mail was that he was /not/ accessing
the myValue property from his java code, period.  (Quoted text: '...I
only make use of "myValue" property from within the .page file...')  And
if he is not accessing it, there is no need whatsoever to define
abstract accessors.

Hope that clears up any confusion caused by my earlier response.

Robert

>    --- Pat
>
>
>>-----Original Message-----
>>From: Robert Zeigler [mailto:[EMAIL PROTECTED]
>>Sent: Thursday, July 21, 2005 8:46 PM
>>To: Tapestry users
>>Subject: Re: Custom class persistent objects are not persistent
>>
>>Richard is right. He doesn't need the abstract accessors. In fact, he
>>doesn't need anything in the .java/.class file for his properties.
>>As he pointed out, he's only using the properties in the .page file. As
>>long as there is no need to access the property in your java code,
>>there's no need to define the abstract accessors.
>>
>>That said, I'm using 3.0.3, and  have no problems at all with persistent
>>properties.
>>
>>Perhaps you could show us a bit more of your .page file? A look at the
>>.java wouldn't hurt, either.
>>
>>Robert
>>Patrick Casey wrote:
>>
>>>    For better or for worse, Tapestry "prefers" to deal with abstract
>>>properties to it can auto-magically enhance your page class. Just as you 
>>>propose, an abstract property is a property for which you have abstract
>>>getters and setters, but not implementation.
>>>
>>>    For those cases where you need to implement concrete properties,
>>>you're left with two alternatives:
>>>
>>>    1) Roll your own persistence layer (my preferred approach).
>>>    2) Use  Tapestry.fireObservedChange(<Page>, <Property>) in the
>>>setter for each concrete property (do a search through the doc for
>>
>>details)
>>
>>>to manually force persistence. Note though that I think this approach is 
>>>deprecated in 4.0.
>>>
>>>    --- Pat
>>>
>>>    PS No, I don't like this particular implementation either, but it is
>>>what it is.
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Richard V. [mailto:[EMAIL PROTECTED]
>>>>Sent: Thursday, July 21, 2005 7:54 PM
>>>>To: [email protected]
>>>>Subject: RE: Custom class persistent objects are not persistent
>>>>
>>>>What do you mean by abstract properties? Do you mean to define the
>>>>javabeans
>>>>functions as abstracts in the page class? Something like:
>>>>
>>>>public abstract String getMyValue(); public abstract void
>>>>setMyValue(String
>>>>value);
>>>>
>>>>But these functions are related to accessing the properties in the page 
>>>>class implementation declared from the .page file. I only make use of
>>>>"myValue" property from within the .page file, so I don't need those
>>>>abstract functions from above.
>>>>
>>>>Richard
>>>>
>>>>
>>>>
>>>>
>>>>>From: "Patrick Casey" <[EMAIL PROTECTED]>
>>>>>Reply-To: "Tapestry users" <[email protected]>
>>>>>To: "'Tapestry users'" <[email protected]>
>>>>>Subject: RE: Custom class persistent objects are not persistent
>>>>>Date: Thu, 21 Jul 2005 18:56:55 -0700
>>>>>
>>>>>
>>>>>    If memory serves, the "persistent=yes" tag only works on abstract
>>>>>properties. Concrete properties like you use are going to require you
>>>>>persist them yourself.
>>>>>
>>>>>    --- Pat
>>>>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Richard V. [mailto:[EMAIL PROTECTED]
>>>>>>Sent: Thursday, July 21, 2005 6:48 PM
>>>>>>To: [email protected]
>>>>>>Subject: Custom class persistent objects are not persistent
>>>>>>
>>>>>>Hello everyone,
>>>>>>
>>>>>>I have a problem with Tapestry 3.0.3 in regard to persistent
>>>>
>>>>properties
>>>>
>>>>
>>>>>in
>>>>>
>>>>>
>>>>>>a
>>>>>>page. I noticed that for java simple class objects such as String,
>>>>>>Integer,
>>>>>>Boolean, etc. used as persistent properties in a page behave as
>>>>>
>>>>>expected;
>>>>>
>>>>>
>>>>>>i.e. they are part of the http session. However, this does not seem to 
>>>>>>hold
>>>>>>if you use complex classes (i.e. created by composition of other
>>>>
>>>>simple
>>>>
>>>>
>>>>>>classes). For example the following class:
>>>>>>
>>>>>>public class VString implements Serializable {
>>>>>> String value = null;
>>>>>>
>>>>>> public VString() {}
>>>>>> public VString(String str) {
>>>>>>   setValue(str);
>>>>>> }
>>>>>> public void setValue(String str) {
>>>>>>   value = new String(str);
>>>>>> }
>>>>>> public String getValue() {
>>>>>>   return value;
>>>>>> }
>>>>>>}
>>>>>>
>>>>>>
>>>>>>And to use it in a page, I will define the following:
>>>>>>
>>>>>><property-specification name="myValue" persistent="yes" type="VString" 
>>>>>>initial-value="new VString('default')"/>
>>>>>>
>>>>>><component id="inputValue" type="TextField">
>>>>>>   <binding name="value" expression="myValue.value"/>
>>>>>></component>
>>>>>>
>>>>>>The property myValue will not persist and resets to "default" on the
>>>>>
>>>>>next
>>>>>
>>>>>
>>>>>>refresh of the page. However, it will stay if you change the type from 
>>>>>>VString to String.
>>>>>>So, my question would be: is this normal behavior from Tapestry or am 
>>>>
>>>>I
>>>>
>>>>
>>>>>>missing something to get this work?
>>>>>>
>>>>>>Many thanks in advanced.
>>>>>>
>>>>>>Richard
>>>>>>
>>>>>>
>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>>>For additional commands, e-mail: [EMAIL PROTECTED] 
>>>>>
>>>>>
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>>For additional commands, e-mail: [EMAIL PROTECTED] 
>>>>>
>>>>
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to