You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Henry Chen <hc...@buzzsponge.com> on 2005/03/31 10:52:50 UTC
Multiple propertyselection: how to judge which of them is changed
So there are there propertyselections in the form. For all of them, set
"submitOnChange" to true. Then how do I know which component fire the
submit? I know that I can get the option and save it, then next time when
submit, get the value again and compare. But I don't know if this is the
right way... Any body can suggest? Thank you very much.
Henry
This electronic mail transmission contains confidential information intended
only for the person(s) named. Any use, distribution, copying or disclosure
by any other person is strictly prohibited. If you received this
transmission in error, please notify the sender by reply e-mail and then
destroy the message. Opinions, conclusions, and other information in this
message that do not relate to the official business of Peacock Nine LLC and
its subsidiaries shall be understood to be neither given nor endorsed by the
Company. When addressed to the clients of Peacock Nine, LLC and its
subsidiaries, any information contained in this e-mail is subject to the
terms and conditions in the governing client contracts and non disclosure
agreements.
Re: Multiple propertyselection: how to judge which of them is changed
Posted by Ron Piterman <mp...@vollbio.de>.
ציטוט Henry Chen:
> Use separate forms. You are right. But there is a problem. I used separate
> forms for each of the property selection. When I select in one of them, the
> rest were all "reset" to the initial as if they were not selected. How do I
> keep all their status at the same time?
I am not sure I check this: the user changes only one of them, say A,
on the next request he changes B, and A turns back to its default?
Use persistant properties to avoid that.
Another, hacky, way would be to encapsulate the status of the others In
the obejcts that correspond to the List: something like that:
List 1 values: 1A 1B 1C 1D. current status: 1B. renders to: A B C D
List 2 values: 1B 2B 3B 4B. current status: 1B. renders to: 1 2 3 4
>
> Henry
> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Ron Piterman
> Sent: Thursday, March 31, 2005 3:47 AM
> To: tapestry-user@jakarta.apache.org
> Subject: Re: Multiple propertyselection: how to judge which of them is
> changed
>
> Hi - I would have looked that, if possible, the values are integrated in the
> workflow of the page.
>
> If for example you use a combo-box as a filter for a table model, have the
> table model always use the values aso.
>
> Another thing is for example in such lists act as links. In such a case I
> would have used a separate form for each list, thus calling a different
> listener method on each list.
>
>
> ????? Henry Chen:
>
>>So there are there propertyselections in the form. For all of them,
>>set "submitOnChange" to true. Then how do I know which component fire
>>the submit? I know that I can get the option and save it, then next
>>time when submit, get the value again and compare. But I don't know if
>>this is the right way... Any body can suggest? Thank you very much.
>>
>>
>>Henry
>>
>>
>>
>>
>>
>>This electronic mail transmission contains confidential information
>>intended only for the person(s) named. Any use, distribution, copying
>>or disclosure by any other person is strictly prohibited. If you
>>received this transmission in error, please notify the sender by reply
>>e-mail and then destroy the message. Opinions, conclusions, and other
>>information in this message that do not relate to the official
>>business of Peacock Nine LLC and its subsidiaries shall be understood
>>to be neither given nor endorsed by the Company. When addressed to the
>>clients of Peacock Nine, LLC and its subsidiaries, any information
>>contained in this e-mail is subject to the terms and conditions in the
>>governing client contracts and non disclosure agreements.
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Body.addInitializationScript()
Posted by Jamie <ja...@dang.com>.
have a look at the DTD for the .script files. There is a command to
place code into the body onload event. You just include your script
compenent and the rest happens for you.
Jamie
Eric Schneider wrote:
> Hi,
>
> I'm wondering where in the request cycle it is appropriate to add some
> javascript initialization code to my Body component?
>
> Following needs to be tucked into the window.onload on every page:
>
> onLoadHandler();
>
> Also, I need this to work on pages that use Tapestry's validation
> stuff (which also makes use of window.onload). Any tips on how I
> can get this done?
>
> Thanks,
> e.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Body.addInitializationScript()
Posted by Eric Schneider <er...@centralparksoftware.com>.
Totally worked. Thank you Jamie!
e.
On Apr 1, 2005, at 5:18 PM, Jamie wrote:
> the dtd says you don't need a body tag (0 or 1)
> :
> <!ELEMENT script (include-script*, input-symbol*,
> (let | set)*, body?, initialization?)>
>
> Eric Schneider wrote:
>
>> Can I accomplish this using a Script component? Could it be as
>> simple as this?
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <!DOCTYPE script PUBLIC
>> "-//Apache Software Foundation//Tapestry Script Specification
>> 3.0//EN"
>> "http://jakarta.apache.org/tapestry/dtd/Script_3_0.dtd">
>>
>> <script>
>> <initialization>
>> onLoadHandler();
>> </initialization>
>> </script>
>>
>> Can you have a script component without a <body> defined?
>>
>> Thanks,
>> e.
>>
>> On Apr 1, 2005, at 4:48 PM, Eric Schneider wrote:
>>
>>> Hi,
>>>
>>> I'm wondering where in the request cycle it is appropriate to add
>>> some javascript initialization code to my Body component?
>>>
>>> Following needs to be tucked into the window.onload on every page:
>>>
>>> onLoadHandler();
>>>
>>> Also, I need this to work on pages that use Tapestry's validation
>>> stuff (which also makes use of window.onload). Any tips on how I
>>> can get this done?
>>>
>>> Thanks,
>>> e.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail:
>>> tapestry-user-help@jakarta.apache.org
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Body.addInitializationScript()
Posted by Jamie <ja...@dang.com>.
the dtd says you don't need a body tag (0 or 1)
:
<!ELEMENT script (include-script*, input-symbol*,
(let | set)*, body?, initialization?)>
Eric Schneider wrote:
> Can I accomplish this using a Script component? Could it be as simple
> as this?
>
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE script PUBLIC
> "-//Apache Software Foundation//Tapestry Script Specification
> 3.0//EN"
> "http://jakarta.apache.org/tapestry/dtd/Script_3_0.dtd">
>
> <script>
> <initialization>
> onLoadHandler();
> </initialization>
> </script>
>
> Can you have a script component without a <body> defined?
>
> Thanks,
> e.
>
> On Apr 1, 2005, at 4:48 PM, Eric Schneider wrote:
>
>> Hi,
>>
>> I'm wondering where in the request cycle it is appropriate to add
>> some javascript initialization code to my Body component?
>>
>> Following needs to be tucked into the window.onload on every page:
>>
>> onLoadHandler();
>>
>> Also, I need this to work on pages that use Tapestry's validation
>> stuff (which also makes use of window.onload). Any tips on how I
>> can get this done?
>>
>> Thanks,
>> e.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Body.addInitializationScript()
Posted by Eric Schneider <er...@centralparksoftware.com>.
Can I accomplish this using a Script component? Could it be as simple
as this?
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE script PUBLIC
"-//Apache Software Foundation//Tapestry Script Specification
3.0//EN"
"http://jakarta.apache.org/tapestry/dtd/Script_3_0.dtd">
<script>
<initialization>
onLoadHandler();
</initialization>
</script>
Can you have a script component without a <body> defined?
Thanks,
e.
On Apr 1, 2005, at 4:48 PM, Eric Schneider wrote:
> Hi,
>
> I'm wondering where in the request cycle it is appropriate to add some
> javascript initialization code to my Body component?
>
> Following needs to be tucked into the window.onload on every page:
>
> onLoadHandler();
>
> Also, I need this to work on pages that use Tapestry's validation
> stuff (which also makes use of window.onload). Any tips on how I
> can get this done?
>
> Thanks,
> e.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
Body.addInitializationScript()
Posted by Eric Schneider <er...@centralparksoftware.com>.
Hi,
I'm wondering where in the request cycle it is appropriate to add some
javascript initialization code to my Body component?
Following needs to be tucked into the window.onload on every page:
onLoadHandler();
Also, I need this to work on pages that use Tapestry's validation stuff
(which also makes use of window.onload). Any tips on how I can get
this done?
Thanks,
e.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Tapestry and Java 5.0
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
Had they used for (item _in_ list) then they would have introduced a
new "in" keyword and you'd have to adjust code to compile properly that
used variables and such of that name. There is a pretty strong mandate
to not introduce new keywords in new features.
Erik
On Apr 1, 2005, at 6:14 PM, Karthik Abram wrote:
>
> Generics are no better with their awful syntax. It looks like the
> typing I
> save in typecasting is more than destroyed by ugly syntax. Also, what
> is
> "for (Item a : list)"? C# scores +1 for "for (Item a in list)" and +1
> for
> event-dispatch model.
>
> -----Original Message-----
> From: sales [mailto:sales1@digiatlas.net]
> Sent: Friday, April 01, 2005 4:04 PM
> To: Tapestry users
> Subject: Re: Tapestry and Java 5.0
>
>
>
>
> Henri Dupre wrote:
>> On Apr 1, 2005 12:31 PM, Bruno Haas <gr...@laposte.net> wrote:
>>
>>
>>> * Is it a good idea at this point in time to rely on Java 5.0 ?
>>
>> I'm developping using many new Java 5 features and I'm surprised at
>> how nicely the new features integrate with existing code. I really
>> like the generics, they allow you to write a much nicer code
>> especially with collections.
>
> Thanks for reminding me to check out the list of new features. All
> good.
>
> Except for varargs - how did anyone let that awful C-programmers-sop
> concept through! How to bastardize Java in 1 easy step.
>
> dd
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Tapestry and Java 5.0
Posted by Karthik Abram <ka...@neovera.com>.
Oh and +1 for first class properties in C# instead of the javabean kludge...
-----Original Message-----
From: Karthik Abram [mailto:karthik.abram@neovera.com]
Sent: Friday, April 01, 2005 6:15 PM
To: Tapestry users
Subject: RE: Tapestry and Java 5.0
Generics are no better with their awful syntax. It looks like the typing I
save in typecasting is more than destroyed by ugly syntax. Also, what is
"for (Item a : list)"? C# scores +1 for "for (Item a in list)" and +1 for
event-dispatch model.
-----Original Message-----
From: sales [mailto:sales1@digiatlas.net]
Sent: Friday, April 01, 2005 4:04 PM
To: Tapestry users
Subject: Re: Tapestry and Java 5.0
Henri Dupre wrote:
> On Apr 1, 2005 12:31 PM, Bruno Haas <gr...@laposte.net> wrote:
>
>
>>* Is it a good idea at this point in time to rely on Java 5.0 ?
>
> I'm developping using many new Java 5 features and I'm surprised at
> how nicely the new features integrate with existing code. I really
> like the generics, they allow you to write a much nicer code
> especially with collections.
Thanks for reminding me to check out the list of new features. All good.
Except for varargs - how did anyone let that awful C-programmers-sop
concept through! How to bastardize Java in 1 easy step.
dd
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Tapestry and Java 5.0
Posted by Karthik Abram <ka...@neovera.com>.
Generics are no better with their awful syntax. It looks like the typing I
save in typecasting is more than destroyed by ugly syntax. Also, what is
"for (Item a : list)"? C# scores +1 for "for (Item a in list)" and +1 for
event-dispatch model.
-----Original Message-----
From: sales [mailto:sales1@digiatlas.net]
Sent: Friday, April 01, 2005 4:04 PM
To: Tapestry users
Subject: Re: Tapestry and Java 5.0
Henri Dupre wrote:
> On Apr 1, 2005 12:31 PM, Bruno Haas <gr...@laposte.net> wrote:
>
>
>>* Is it a good idea at this point in time to rely on Java 5.0 ?
>
> I'm developping using many new Java 5 features and I'm surprised at
> how nicely the new features integrate with existing code. I really
> like the generics, they allow you to write a much nicer code
> especially with collections.
Thanks for reminding me to check out the list of new features. All good.
Except for varargs - how did anyone let that awful C-programmers-sop
concept through! How to bastardize Java in 1 easy step.
dd
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Tapestry and Java 5.0
Posted by sales <sa...@digiatlas.net>.
Henri Dupre wrote:
> On Apr 1, 2005 12:31 PM, Bruno Haas <gr...@laposte.net> wrote:
>
>
>>* Is it a good idea at this point in time to rely on Java 5.0 ?
>
> I'm developping using many new Java 5 features and I'm surprised at
> how nicely the new features integrate with existing code. I really
> like the generics, they allow you to write a much nicer code
> especially with collections.
Thanks for reminding me to check out the list of new features. All good.
Except for varargs - how did anyone let that awful C-programmers-sop
concept through! How to bastardize Java in 1 easy step.
dd
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Tapestry and Java 5.0
Posted by Henri Dupre <he...@gmail.com>.
On Apr 1, 2005 12:31 PM, Bruno Haas <gr...@laposte.net> wrote:
> * Is it a good idea at this point in time to rely on Java 5.0 ?
I'm developping using many new Java 5 features and I'm surprised at
how nicely the new features integrate with existing code. I really
like the generics, they allow you to write a much nicer code
especially with collections.
Unless your application needs to support previous JDKs, there is no
reason not to use the new features.
Henri.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Tapestry and Java 5.0
Posted by Denis Souza <ds...@sti.com.br>.
It looks like you're executing java 5 code in a java 1.4 vm. Make sure any
tools and containers you're using (Eclipse, JBOSS, etc.) are running in a
java 5 vm.
Denis
-----Original Message-----
From: Bruno Haas [mailto:grinob.haas@laposte.net]
Sent: sexta-feira, 1 de abril de 2005 14:31
To: Tapestry users
Subject: Tapestry and Java 5.0
Hi all,
I'm trying to compile my tapestry app wit the the jdk1.5 in order to be
able to use hibernate3 ejb annotations. I'm getting the following
exception when hitting the web app. It seems that tapestry cannot load
my Home class due to a version problem.
My questions are:
* Do I have to download the tapestry source code and recompile it using
the jdk1.5 to make this work ?
* Is it a good idea at this point in time to rely on Java 5.0 ?
Thanks a lot
Bruno
java.lang.UnsupportedClassVersionError
net/sf/actirec/pages/Home (Unsupported major.minor version 49.0)
Stack Trace:
* java.lang.ClassLoader.defineClass0(Native Method)
* java.lang.ClassLoader.defineClass(ClassLoader.java:537)
*
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
*
org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLo
ader.java:1679)
*
org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.jav
a:968)
*
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.jav
a:1409)
*
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.jav
a:1289)
* java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
* java.lang.Class.forName0(Native Method)
* java.lang.Class.forName(Class.java:219)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Tapestry and Java 5.0
Posted by Bruno Haas <gr...@laposte.net>.
Hi all,
I'm trying to compile my tapestry app wit the the jdk1.5 in order to be
able to use hibernate3 ejb annotations. I'm getting the following
exception when hitting the web app. It seems that tapestry cannot load
my Home class due to a version problem.
My questions are:
* Do I have to download the tapestry source code and recompile it using
the jdk1.5 to make this work ?
* Is it a good idea at this point in time to rely on Java 5.0 ?
Thanks a lot
Bruno
java.lang.UnsupportedClassVersionError
net/sf/actirec/pages/Home (Unsupported major.minor version 49.0)
Stack Trace:
* java.lang.ClassLoader.defineClass0(Native Method)
* java.lang.ClassLoader.defineClass(ClassLoader.java:537)
* java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
* org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1679)
* org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:968)
* org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1409)
* org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1289)
* java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
* java.lang.Class.forName0(Native Method)
* java.lang.Class.forName(Class.java:219)
RE: Multiple propertyselection: how to judge which of them is changed
Posted by Henry Chen <he...@gmail.com>.
Sorry. I found the problem. I was my mistake to reset value of one of the
dropdown list. Now is works very well.
-----Original Message-----
From: news [mailto:news@sea.gmane.org] On Behalf Of Ron Piterman
Sent: Friday, April 01, 2005 2:02 AM
To: tapestry-user@jakarta.apache.org
Subject: Re: Multiple propertyselection: how to judge which of them is
changed
????? Henry Chen:
> Use separate forms. You are right. But there is a problem. I used
> separate forms for each of the property selection. When I select in
> one of them, the rest were all "reset" to the initial as if they were
> not selected. How do I keep all their status at the same time?
I am not sure I check this: the user changes only one of them, say A, on the
next request he changes B, and A turns back to its default?
Use persistant properties to avoid that.
>
> Henry
> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Ron Piterman
> Sent: Thursday, March 31, 2005 3:47 AM
> To: tapestry-user@jakarta.apache.org
> Subject: Re: Multiple propertyselection: how to judge which of them is
> changed
>
> Hi - I would have looked that, if possible, the values are integrated
> in the workflow of the page.
>
> If for example you use a combo-box as a filter for a table model, have
> the table model always use the values aso.
>
> Another thing is for example in such lists act as links. In such a
> case I would have used a separate form for each list, thus calling a
> different listener method on each list.
>
>
> ????? Henry Chen:
>
>>So there are there propertyselections in the form. For all of them,
>>set "submitOnChange" to true. Then how do I know which component fire
>>the submit? I know that I can get the option and save it, then next
>>time when submit, get the value again and compare. But I don't know if
>>this is the right way... Any body can suggest? Thank you very much.
>>
>>
>>Henry
>>
>>
>>
>>
>>
>>This electronic mail transmission contains confidential information
>>intended only for the person(s) named. Any use, distribution, copying
>>or disclosure by any other person is strictly prohibited. If you
>>received this transmission in error, please notify the sender by reply
>>e-mail and then destroy the message. Opinions, conclusions, and other
>>information in this message that do not relate to the official
>>business of Peacock Nine LLC and its subsidiaries shall be understood
>>to be neither given nor endorsed by the Company. When addressed to the
>>clients of Peacock Nine, LLC and its subsidiaries, any information
>>contained in this e-mail is subject to the terms and conditions in the
>>governing client contracts and non disclosure agreements.
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Multiple propertyselection: how to judge which of them is changed
Posted by Ron Piterman <mp...@vollbio.de>.
ציטוט Henry Chen:
> Use separate forms. You are right. But there is a problem. I used separate
> forms for each of the property selection. When I select in one of them, the
> rest were all "reset" to the initial as if they were not selected. How do I
> keep all their status at the same time?
I am not sure I check this: the user changes only one of them, say A,
on the next request he changes B, and A turns back to its default?
Use persistant properties to avoid that.
>
> Henry
> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Ron Piterman
> Sent: Thursday, March 31, 2005 3:47 AM
> To: tapestry-user@jakarta.apache.org
> Subject: Re: Multiple propertyselection: how to judge which of them is
> changed
>
> Hi - I would have looked that, if possible, the values are integrated in the
> workflow of the page.
>
> If for example you use a combo-box as a filter for a table model, have the
> table model always use the values aso.
>
> Another thing is for example in such lists act as links. In such a case I
> would have used a separate form for each list, thus calling a different
> listener method on each list.
>
>
> ????? Henry Chen:
>
>>So there are there propertyselections in the form. For all of them,
>>set "submitOnChange" to true. Then how do I know which component fire
>>the submit? I know that I can get the option and save it, then next
>>time when submit, get the value again and compare. But I don't know if
>>this is the right way... Any body can suggest? Thank you very much.
>>
>>
>>Henry
>>
>>
>>
>>
>>
>>This electronic mail transmission contains confidential information
>>intended only for the person(s) named. Any use, distribution, copying
>>or disclosure by any other person is strictly prohibited. If you
>>received this transmission in error, please notify the sender by reply
>>e-mail and then destroy the message. Opinions, conclusions, and other
>>information in this message that do not relate to the official
>>business of Peacock Nine LLC and its subsidiaries shall be understood
>>to be neither given nor endorsed by the Company. When addressed to the
>>clients of Peacock Nine, LLC and its subsidiaries, any information
>>contained in this e-mail is subject to the terms and conditions in the
>>governing client contracts and non disclosure agreements.
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Multiple propertyselection: how to judge which of them is changed
Posted by Henry Chen <he...@gmail.com>.
Use separate forms. You are right. But there is a problem. I used separate
forms for each of the property selection. When I select in one of them, the
rest were all "reset" to the initial as if they were not selected. How do I
keep all their status at the same time?
Henry
-----Original Message-----
From: news [mailto:news@sea.gmane.org] On Behalf Of Ron Piterman
Sent: Thursday, March 31, 2005 3:47 AM
To: tapestry-user@jakarta.apache.org
Subject: Re: Multiple propertyselection: how to judge which of them is
changed
Hi - I would have looked that, if possible, the values are integrated in the
workflow of the page.
If for example you use a combo-box as a filter for a table model, have the
table model always use the values aso.
Another thing is for example in such lists act as links. In such a case I
would have used a separate form for each list, thus calling a different
listener method on each list.
????? Henry Chen:
> So there are there propertyselections in the form. For all of them,
> set "submitOnChange" to true. Then how do I know which component fire
> the submit? I know that I can get the option and save it, then next
> time when submit, get the value again and compare. But I don't know if
> this is the right way... Any body can suggest? Thank you very much.
>
>
> Henry
>
>
>
>
>
> This electronic mail transmission contains confidential information
> intended only for the person(s) named. Any use, distribution, copying
> or disclosure by any other person is strictly prohibited. If you
> received this transmission in error, please notify the sender by reply
> e-mail and then destroy the message. Opinions, conclusions, and other
> information in this message that do not relate to the official
> business of Peacock Nine LLC and its subsidiaries shall be understood
> to be neither given nor endorsed by the Company. When addressed to the
> clients of Peacock Nine, LLC and its subsidiaries, any information
> contained in this e-mail is subject to the terms and conditions in the
> governing client contracts and non disclosure agreements.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Multiple propertyselection: how to judge which of them is changed
Posted by Ron Piterman <mp...@vollbio.de>.
Hi - I would have looked that, if possible, the values are integrated in
the workflow of the page.
If for example you use a combo-box as a filter for a table model, have
the table model always use the values aso.
Another thing is for example in such lists act as links. In such a case
I would have used a separate form for each list, thus calling a
different listener method on each list.
ציטוט Henry Chen:
> So there are there propertyselections in the form. For all of them, set
> "submitOnChange" to true. Then how do I know which component fire the
> submit? I know that I can get the option and save it, then next time when
> submit, get the value again and compare. But I don't know if this is the
> right way... Any body can suggest? Thank you very much.
>
>
> Henry
>
>
>
>
>
> This electronic mail transmission contains confidential information intended
> only for the person(s) named. Any use, distribution, copying or disclosure
> by any other person is strictly prohibited. If you received this
> transmission in error, please notify the sender by reply e-mail and then
> destroy the message. Opinions, conclusions, and other information in this
> message that do not relate to the official business of Peacock Nine LLC and
> its subsidiaries shall be understood to be neither given nor endorsed by the
> Company. When addressed to the clients of Peacock Nine, LLC and its
> subsidiaries, any information contained in this e-mail is subject to the
> terms and conditions in the governing client contracts and non disclosure
> agreements.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Multiple propertyselection: how to judge which of them is changed
Posted by Kent Tong <ke...@cpttm.org.mo>.
Henry Chen <henry.chen04 <at> gmail.com> writes:
> Could you explain why not? Since I already used it without problem... Is
> there any unstable issue?
I was saying that if you'd like to take the approach I
described (set a hidden field), then you can't use
submitOnChange, simply because it won't set the hidden
field.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Multiple propertyselection: how to judge which of them is changed
Posted by Henry Chen <he...@gmail.com>.
Hi Kent,
Could you explain why not? Since I already used it without problem... Is
there any unstable issue?
Thanks,
Henry
-----Original Message-----
From: news [mailto:news@sea.gmane.org] On Behalf Of Kent Tong
Sent: Thursday, March 31, 2005 7:49 PM
To: tapestry-user@jakarta.apache.org
Subject: Re: Multiple propertyselection: how to judge which of them is
changed
Henry Chen <hchen <at> buzzsponge.com> writes:
> So there are there propertyselections in the form. For all of them,
> set "submitOnChange" to true. Then how do I know which component fire
> the submit? I know that I can get the option and save it, then next
> time when submit, get the value again and compare. But I don't know if
> this is the right way... Any body can suggest? Thank you very much.
don't use submitOnchange. Attach a custom javascript function to its
onchange event and set a hidden field in that function and submit the form.
On the server side, check the value of the hidden field.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Multiple propertyselection: how to judge which of them is changed
Posted by Kent Tong <ke...@cpttm.org.mo>.
Henry Chen <hchen <at> buzzsponge.com> writes:
> So there are there propertyselections in the form. For all of them, set
> "submitOnChange" to true. Then how do I know which component fire the
> submit? I know that I can get the option and save it, then next time when
> submit, get the value again and compare. But I don't know if this is the
> right way... Any body can suggest? Thank you very much.
don't use submitOnchange. Attach a custom javascript function
to its onchange event and set a hidden field in that function
and submit the form. On the server side, check the value of
the hidden field.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org