You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2005/04/03 20:18:31 UTC
Tapestry 4.0
The sentiment of the community seems to be that the next major release of
Tapestry (i.e., HiveMind infrastructure, Portlet support, etc.) is too
different from Tapestry 3.0 to be called "Tapestry 3.1". This release
will only be largely backwards compatible; applications that sub-class
BaseEngine or make use of custom Tapestry engine services will require some
amount of re-work. In a small number of cases, component parameters
(espcially those using direction "auto" or "custom") will not work exactly
as before.
I feel it is completely reasonable to not call this release 3.1, but to
continue to bend over backwards for backwards compatibility.
A +1 vote signals that you concur, and that the next reelease should be
numbered 4.0. This will affect the code in a very limited way: Much code has
been added with a @since 3.1 javadoc tag; this will change to @since 4.,0.
Likewise, the 3.1 numbering is in documentation, and inside some of the
specification DTDs; these will also change.
Howard M. Lewis Ship: +1
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
Re: Tapestry 4.0
Posted by Alex Ieong <xe...@gmail.com>.
Alex Ieong: +1
On Apr 4, 2005 10:09 AM, matthew c. mead <m-...@goof.com> wrote:
> +1 (nonbinding).
>
> -matt
>
>
> Geoff Longman wrote:
>
> >Geoff Longman: +1
> >
> >On Apr 3, 2005 3:22 PM, Jamie Orchard-Hays <ja...@dang.com> wrote:
> >
> >
> >>Jamie Orchard-Hays: +1
> >>
> >>On Apr 3, 2005, at 2:18 PM, Howard Lewis Ship wrote:
> >>
> >>
> >>
> >>>The sentiment of the community seems to be that the next major release
> >>>of
> >>>Tapestry (i.e., HiveMind infrastructure, Portlet support, etc.) is too
> >>>different from Tapestry 3.0 to be called "Tapestry 3.1". This release
> >>>will only be largely backwards compatible; applications that sub-class
> >>>BaseEngine or make use of custom Tapestry engine services will require
> >>>some
> >>>amount of re-work. In a small number of cases, component parameters
> >>>(espcially those using direction "auto" or "custom") will not work
> >>>exactly
> >>>as before.
> >>>
> >>>I feel it is completely reasonable to not call this release 3.1, but to
> >>>continue to bend over backwards for backwards compatibility.
> >>>
> >>>A +1 vote signals that you concur, and that the next reelease should be
> >>>numbered 4.0. This will affect the code in a very limited way: Much
> >>>code has
> >>>been added with a @since 3.1 javadoc tag; this will change to @since
> >>>4.,0.
> >>>Likewise, the 3.1 numbering is in documentation, and inside some of the
> >>>specification DTDs; these will also change.
> >>>
> >>>Howard M. Lewis Ship: +1
> >>>
> >>>--
> >>>Howard M. Lewis Ship
> >>>Independent J2EE / Open-Source Java Consultant
> >>>Creator, Jakarta Tapestry
> >>>Creator, Jakarta HiveMind
> >>>
> >>>Professional Tapestry training, mentoring, support
> >>>and project work. http://howardlewisship.com
> >>>
> >>>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >>
> >>
> >>
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
> >
>
> --
> matthew c. mead
>
> http://www.goof.com/
>
>
--
Alex Ieong, MO
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 4.0
Posted by "matthew c. mead" <m-...@goof.com>.
+1 (nonbinding).
-matt
Geoff Longman wrote:
>Geoff Longman: +1
>
>On Apr 3, 2005 3:22 PM, Jamie Orchard-Hays <ja...@dang.com> wrote:
>
>
>>Jamie Orchard-Hays: +1
>>
>>On Apr 3, 2005, at 2:18 PM, Howard Lewis Ship wrote:
>>
>>
>>
>>>The sentiment of the community seems to be that the next major release
>>>of
>>>Tapestry (i.e., HiveMind infrastructure, Portlet support, etc.) is too
>>>different from Tapestry 3.0 to be called "Tapestry 3.1". This release
>>>will only be largely backwards compatible; applications that sub-class
>>>BaseEngine or make use of custom Tapestry engine services will require
>>>some
>>>amount of re-work. In a small number of cases, component parameters
>>>(espcially those using direction "auto" or "custom") will not work
>>>exactly
>>>as before.
>>>
>>>I feel it is completely reasonable to not call this release 3.1, but to
>>>continue to bend over backwards for backwards compatibility.
>>>
>>>A +1 vote signals that you concur, and that the next reelease should be
>>>numbered 4.0. This will affect the code in a very limited way: Much
>>>code has
>>>been added with a @since 3.1 javadoc tag; this will change to @since
>>>4.,0.
>>>Likewise, the 3.1 numbering is in documentation, and inside some of the
>>>specification DTDs; these will also change.
>>>
>>>Howard M. Lewis Ship: +1
>>>
>>>--
>>>Howard M. Lewis Ship
>>>Independent J2EE / Open-Source Java Consultant
>>>Creator, Jakarta Tapestry
>>>Creator, Jakarta HiveMind
>>>
>>>Professional Tapestry training, mentoring, support
>>>and project work. http://howardlewisship.com
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>
>>
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
>
--
matthew c. mead
http://www.goof.com/
Re: Tapestry 4.0
Posted by Geoff Longman <gl...@gmail.com>.
Geoff Longman: +1
On Apr 3, 2005 3:22 PM, Jamie Orchard-Hays <ja...@dang.com> wrote:
> Jamie Orchard-Hays: +1
>
> On Apr 3, 2005, at 2:18 PM, Howard Lewis Ship wrote:
>
> > The sentiment of the community seems to be that the next major release
> > of
> > Tapestry (i.e., HiveMind infrastructure, Portlet support, etc.) is too
> > different from Tapestry 3.0 to be called "Tapestry 3.1". This release
> > will only be largely backwards compatible; applications that sub-class
> > BaseEngine or make use of custom Tapestry engine services will require
> > some
> > amount of re-work. In a small number of cases, component parameters
> > (espcially those using direction "auto" or "custom") will not work
> > exactly
> > as before.
> >
> > I feel it is completely reasonable to not call this release 3.1, but to
> > continue to bend over backwards for backwards compatibility.
> >
> > A +1 vote signals that you concur, and that the next reelease should be
> > numbered 4.0. This will affect the code in a very limited way: Much
> > code has
> > been added with a @since 3.1 javadoc tag; this will change to @since
> > 4.,0.
> > Likewise, the 3.1 numbering is in documentation, and inside some of the
> > specification DTDs; these will also change.
> >
> > Howard M. Lewis Ship: +1
> >
> > --
> > Howard M. Lewis Ship
> > Independent J2EE / Open-Source Java Consultant
> > Creator, Jakarta Tapestry
> > Creator, Jakarta HiveMind
> >
> > Professional Tapestry training, mentoring, support
> > and project work. http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 4.0
Posted by Jamie Orchard-Hays <ja...@dang.com>.
Jamie Orchard-Hays: +1
On Apr 3, 2005, at 2:18 PM, Howard Lewis Ship wrote:
> The sentiment of the community seems to be that the next major release
> of
> Tapestry (i.e., HiveMind infrastructure, Portlet support, etc.) is too
> different from Tapestry 3.0 to be called "Tapestry 3.1". This release
> will only be largely backwards compatible; applications that sub-class
> BaseEngine or make use of custom Tapestry engine services will require
> some
> amount of re-work. In a small number of cases, component parameters
> (espcially those using direction "auto" or "custom") will not work
> exactly
> as before.
>
> I feel it is completely reasonable to not call this release 3.1, but to
> continue to bend over backwards for backwards compatibility.
>
> A +1 vote signals that you concur, and that the next reelease should be
> numbered 4.0. This will affect the code in a very limited way: Much
> code has
> been added with a @since 3.1 javadoc tag; this will change to @since
> 4.,0.
> Likewise, the 3.1 numbering is in documentation, and inside some of the
> specification DTDs; these will also change.
>
> Howard M. Lewis Ship: +1
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 4.0
Posted by David Solis <ds...@gmail.com>.
David Solis: +1
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 4.0
Posted by "Brian K. Wallace" <br...@transmorphix.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
+1 non-binding
Howard Lewis Ship wrote:
| The sentiment of the community seems to be that the next major release of
| Tapestry (i.e., HiveMind infrastructure, Portlet support, etc.) is too
| different from Tapestry 3.0 to be called "Tapestry 3.1". This release
| will only be largely backwards compatible; applications that sub-class
| BaseEngine or make use of custom Tapestry engine services will require
some
| amount of re-work. In a small number of cases, component parameters
| (espcially those using direction "auto" or "custom") will not work
exactly
| as before.
|
| I feel it is completely reasonable to not call this release 3.1, but to
| continue to bend over backwards for backwards compatibility.
|
| A +1 vote signals that you concur, and that the next reelease should be
| numbered 4.0. This will affect the code in a very limited way: Much
code has
| been added with a @since 3.1 javadoc tag; this will change to @since
4.,0.
| Likewise, the 3.1 numbering is in documentation, and inside some of the
| specification DTDs; these will also change.
|
| Howard M. Lewis Ship: +1
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFCUPFZaCoPKRow/gARAvykAKC0MaORDnjRFe33tMdTb8JDGW4wmQCfeB4O
FuCb1L0xY4LG7pALSjWUyuA=
=SJa3
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 4.0
Posted by Paul Ferraro <pm...@columbia.edu>.
Paul Ferraro: +1 (binding)
Howard Lewis Ship wrote:
>The sentiment of the community seems to be that the next major release of
>Tapestry (i.e., HiveMind infrastructure, Portlet support, etc.) is too
>different from Tapestry 3.0 to be called "Tapestry 3.1". This release
>will only be largely backwards compatible; applications that sub-class
>BaseEngine or make use of custom Tapestry engine services will require some
>amount of re-work. In a small number of cases, component parameters
>(espcially those using direction "auto" or "custom") will not work exactly
>as before.
>
>I feel it is completely reasonable to not call this release 3.1, but to
>continue to bend over backwards for backwards compatibility.
>
>A +1 vote signals that you concur, and that the next reelease should be
>numbered 4.0. This will affect the code in a very limited way: Much code has
>been added with a @since 3.1 javadoc tag; this will change to @since 4.,0.
>Likewise, the 3.1 numbering is in documentation, and inside some of the
>specification DTDs; these will also change.
>
>Howard M. Lewis Ship: +1
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[RESULT] Tapestry 4.0
Posted by Howard Lewis Ship <hl...@gmail.com>.
The sentiment of the community seems to be that the next major release of
Tapestry (i.e., HiveMind infrastructure, Portlet support, etc.) is too
different from Tapestry 3.0 to be called "Tapestry 3.1". This release
will only be largely backwards compatible; applications that sub-class
BaseEngine or make use of custom Tapestry engine services will require some
amount of re-work. In a small number of cases, component parameters
(espcially those using direction "auto" or "custom") will not work exactly
as before.
I feel it is completely reasonable to not call this release 3.1, but to
continue to bend over backwards for backwards compatibility.
A +1 vote signals that you concur, and that the next reelease should be
numbered 4.0. This will affect the code in a very limited way: Much code has
been added with a @since 3.1 javadoc tag; this will change to @since 4.,0.
Likewise, the 3.1 numbering is in documentation, and inside some of the
specification DTDs; these will also change.
Binding votes:
Howard M. Lewis Ship: +1
Geoff Longman: +1
Paul Ferraro: +1
Erik Hatcher: +1
David Solis: +1
Richard Lewis Shell: +1
MindBridge: +0 (no response)
Harish Krishnaswamy: +0 (no response)
Tsveltin: +0 (no response)
Non-binding votes:
Jamie Orchard-Hays: +1
Mattew C. Mead: +1
Alex Leong: +1
Brian K. Wallace: +1
Pablo Lalloni: +1
On 4/4/05, Richard Lewis-Shell <rl...@mac.com> wrote:
>
> 3.5 or 4.0 would seem appropriate to me.
>
> So: +1
>
> Howard Lewis Ship wrote:
> > The sentiment of the community seems to be that the next major release
> of
> > Tapestry (i.e., HiveMind infrastructure, Portlet support, etc.) is too
> > different from Tapestry 3.0 to be called "Tapestry 3.1". This release
> > will only be largely backwards compatible; applications that sub-class
> > BaseEngine or make use of custom Tapestry engine services will require
> some
> > amount of re-work. In a small number of cases, component parameters
> > (espcially those using direction "auto" or "custom") will not work
> exactly
> > as before.
> >
> > I feel it is completely reasonable to not call this release 3.1, but to
> > continue to bend over backwards for backwards compatibility.
> >
> > A +1 vote signals that you concur, and that the next reelease should be
> > numbered 4.0. This will affect the code in a very limited way: Much code
> has
> > been added with a @since 3.1 javadoc tag; this will change to @since
> 4.,0.
> > Likewise, the 3.1 numbering is in documentation, and inside some of the
> > specification DTDs; these will also change.
> >
> > Howard M. Lewis Ship: +1
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
Re: Tapestry 4.0
Posted by Richard Lewis-Shell <rl...@mac.com>.
3.5 or 4.0 would seem appropriate to me.
So: +1
Howard Lewis Ship wrote:
> The sentiment of the community seems to be that the next major release of
> Tapestry (i.e., HiveMind infrastructure, Portlet support, etc.) is too
> different from Tapestry 3.0 to be called "Tapestry 3.1". This release
> will only be largely backwards compatible; applications that sub-class
> BaseEngine or make use of custom Tapestry engine services will require some
> amount of re-work. In a small number of cases, component parameters
> (espcially those using direction "auto" or "custom") will not work exactly
> as before.
>
> I feel it is completely reasonable to not call this release 3.1, but to
> continue to bend over backwards for backwards compatibility.
>
> A +1 vote signals that you concur, and that the next reelease should be
> numbered 4.0. This will affect the code in a very limited way: Much code has
> been added with a @since 3.1 javadoc tag; this will change to @since 4.,0.
> Likewise, the 3.1 numbering is in documentation, and inside some of the
> specification DTDs; these will also change.
>
> Howard M. Lewis Ship: +1
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 4.0
Posted by Pablo Lalloni <pl...@afip.gov.ar>.
Pablo Lalloni: +1
El Dom 03 Abr 2005 15:18, Howard Lewis Ship escribió:
> The sentiment of the community seems to be that the next major release of
> Tapestry (i.e., HiveMind infrastructure, Portlet support, etc.) is too
> different from Tapestry 3.0 to be called "Tapestry 3.1". This release
> will only be largely backwards compatible; applications that sub-class
> BaseEngine or make use of custom Tapestry engine services will require some
> amount of re-work. In a small number of cases, component parameters
> (espcially those using direction "auto" or "custom") will not work exactly
> as before.
>
> I feel it is completely reasonable to not call this release 3.1, but to
> continue to bend over backwards for backwards compatibility.
>
> A +1 vote signals that you concur, and that the next reelease should be
> numbered 4.0. This will affect the code in a very limited way: Much code
> has been added with a @since 3.1 javadoc tag; this will change to @since
> 4.,0. Likewise, the 3.1 numbering is in documentation, and inside some of
> the specification DTDs; these will also change.
>
> Howard M. Lewis Ship: +1
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
RE: Locked pageRecorder
Posted by Joerg Latteier <la...@online.de>.
While searching for the best way to modify persistent properties without
receiving "locked errors", I found that overriding renderComponent()
works best for me for pages as well as for components:
protected void renderComponent(IMarkupWriter writer, IRequestCycle cycle)
{
...modify persistent properties...
super.renderComponent(writer, cycle);
}
The only scenario where it does not prevent you from receiving a locked
error
is, if the page is rendered is multiple times, e.g. because a user submits a
form again before receiving the result of the first submit, or when
calling the same page from multiple browser windows/tabs simultaneously.
As far as I know this is a well-known tapestry design issue and the only way
to work around this is to avoid persistent properties.
I catch these errors with customized error pages, in other areas I hide the
form buttons using javascript after the submit and show some kind of
progress
message.
Joerg
>> -----Original Message-----
>> From: Thijs Suijten [mailto:t.suijten@semantica.nl]
>> Sent: Monday, April 04, 2005 4:47 AM
>> To: Tapestry development
>> Subject: Locked pageRecorder
>>
>>
>> I posted an issue to the users mailing list but I didnt get a
>> satisfying answer so Id like to try it here.
>>
>> I've been working with Tapestry for quit a while now. I still haven't
>> figured out why persistent page properties cannot be
>> modified during the
>> render phase. (I get a locked error)
>>
>> In my case I want to do the caching/initialization in a
>> component, this
>> cannot be done in the pageBeginRender because the
>> pageBeginRender is a
>> listener. I don't know in what order the listeners are being
>> called and
>> this causes a problem. The model is being passed to the
>> component by a
>> parameter, which is initialized in the component's-parent-page
>> pageBeginRender. Because I don't know which pageBeginRender is called
>> first I get a NullPointerException, in my case the component's
>> pageBeginRender is being called first and then the
>> component's-parent-page pageBeginRender.
>>
>> This results in not being able to do anything in the component's
>> pageBeginRender because the model is null at that point, because the
>> pageBeginRender is the last place I can set persistent page
>> properties,
>> I have a problem.
>>
>> I hope you understand my problem, english is not my native tongue so
>> explaining such a complex problem is difficult...
>>
>> Thijs Suijten - The Netherlands.
>>
>>
>> --
>> No virus found in this outgoing message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.308 / Virus Database: 266.9.1 - Release Date: 1-4-2005
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-dev-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: Locked pageRecorder
Posted by Shawn Church <sh...@boxity.com>.
Thijs,
Since this is best suited for the Tapestry users list, I am replying back
there.
First of all, in case you don't have a copy of Tapestry in Action, I would
recommend it since it explains the rewind phase as well as the listener call
order very well. For your specific situation, chapter 10 explains exactly
what it sounds like you are trying to do (see the Browser component).
Persistent page properties can be modified as long as you are not in the
rewind phase, so in pageBeginRender you should immediately return if
event.getRequestCycle().isRewinding() (see page 298 of TiA). As stated, the
pageBeginRender method "is invoked before the page's recorder is committed,
while it is still able to change persistent page properties".
I've never liked the "rewind" term very well, since it implies a
reverse-order. To me, "replay" or "re-render" or
"rebuild-my-page-state-to-match-the-form-just-submitted" makes more sense.
If a persistent page property is used to construct a form, and then the form
is submitted by a user, Tapestry must be able to reconstruct a "duplicate"
of the originally-presented form so that the newly-available input values of
the form are correctly associated with an image of the original form. So,
by the time your form listener is called, everything appears to your
application as it should.
If you need more information, it would help to know a little more about what
exactly you are trying to do. What "model" are you referring to? Is that
one of your page's persistent properties? Or is it a persistent property of
your component? In your page specification, are the bound parameters for
your component set to direction="auto" (the "direction" attribute is going
away in the next release of Tapestry).
Shawn
-----Original Message-----
From: Thijs Suijten [mailto:t.suijten@semantica.nl]
Sent: Monday, April 04, 2005 4:47 AM
To: Tapestry development
Subject: Locked pageRecorder
I posted an issue to the users mailing list but I didn’t get a
satisfying answer so I’d like to try it here.
I've been working with Tapestry for quit a while now. I still haven't
figured out why persistent page properties cannot be modified during the
render phase. (I get a locked error)
In my case I want to do the caching/initialization in a component, this
cannot be done in the pageBeginRender because the pageBeginRender is a
listener. I don't know in what order the listeners are being called and
this causes a problem. The model is being passed to the component by a
parameter, which is initialized in the component's-parent-page
pageBeginRender. Because I don't know which pageBeginRender is called
first I get a NullPointerException, in my case the component's
pageBeginRender is being called first and then the
component's-parent-page pageBeginRender.
This results in not being able to do anything in the component's
pageBeginRender because the model is null at that point, because the
pageBeginRender is the last place I can set persistent page properties,
I have a problem.
I hope you understand my problem, english is not my native tongue so
explaining such a complex problem is difficult...
Thijs Suijten - The Netherlands.
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.9.1 - Release Date: 1-4-2005
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-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
Locked pageRecorder
Posted by Thijs Suijten <t....@semantica.nl>.
I posted an issue to the users mailing list but I didn’t get a
satisfying answer so I’d like to try it here.
I've been working with Tapestry for quit a while now. I still haven't
figured out why persistent page properties cannot be modified during the
render phase. (I get a locked error)
In my case I want to do the caching/initialization in a component, this
cannot be done in the pageBeginRender because the pageBeginRender is a
listener. I don't know in what order the listeners are being called and
this causes a problem. The model is being passed to the component by a
parameter, which is initialized in the component's-parent-page
pageBeginRender. Because I don't know which pageBeginRender is called
first I get a NullPointerException, in my case the component's
pageBeginRender is being called first and then the
component's-parent-page pageBeginRender.
This results in not being able to do anything in the component's
pageBeginRender because the model is null at that point, because the
pageBeginRender is the last place I can set persistent page properties,
I have a problem.
I hope you understand my problem, english is not my native tongue so
explaining such a complex problem is difficult...
Thijs Suijten - The Netherlands.
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.9.1 - Release Date: 1-4-2005
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 4.0
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
Erik Hatcher: +1 (binding)
On Apr 3, 2005, at 2:18 PM, Howard Lewis Ship wrote:
> The sentiment of the community seems to be that the next major release
> of
> Tapestry (i.e., HiveMind infrastructure, Portlet support, etc.) is too
> different from Tapestry 3.0 to be called "Tapestry 3.1". This release
> will only be largely backwards compatible; applications that sub-class
> BaseEngine or make use of custom Tapestry engine services will require
> some
> amount of re-work. In a small number of cases, component parameters
> (espcially those using direction "auto" or "custom") will not work
> exactly
> as before.
>
> I feel it is completely reasonable to not call this release 3.1, but to
> continue to bend over backwards for backwards compatibility.
>
> A +1 vote signals that you concur, and that the next reelease should be
> numbered 4.0. This will affect the code in a very limited way: Much
> code has
> been added with a @since 3.1 javadoc tag; this will change to @since
> 4.,0.
> Likewise, the 3.1 numbering is in documentation, and inside some of the
> specification DTDs; these will also change.
>
> Howard M. Lewis Ship: +1
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org