You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Jim O'Callaghan <ji...@peritussolutions.com> on 2010/06/16 15:11:13 UTC
Custom Edit Block
I'm trying to put together an edit / display block for an entity (Entity B)
where for simplification the entity contains an id and a desc field
- in an edit scenario I want the rendered output to have a hidden field
for the id and an input field for the desc field, so that upon submission I
can use the id to update an existing entity using the desc field
- in a display scenario I just need to display a readonly text field for
the desc
I want to be able to use this block system-wide in bean edit forms and bean
displays where the form is being rendered for Entity A which contains a 1:1
Entity B.
I'm looking at the example at
http://tapestry.apache.org/tapestry5/guide/beaneditform.html but drawing a
bit of a blank on how some tml to render my hidden id field and my text desc
field for edit, and my text desc field only for display fits in with the
code. Can anyone point to a more comprehensive online example or let me
know if what I am doing is something achievable? I'm not sure if Google
just isn't cooperating today or I am being stupid ...
Regards,
Jim.
RE: Custom Edit Block
Posted by Jim O'Callaghan <jc...@yahoo.co.uk>.
Thanks Christophe I'll have a look in that direction.
Regards,
Jim.
-----Original Message-----
From: Christophe Cordenier [mailto:christophe.cordenier@gmail.com]
Sent: 16 June 2010 17:20
To: Tapestry users
Subject: Re: Custom Edit Block
...some more hints
Block resolution is made in this order :
1. Using the property id
2. Using its data Type
DataType is defined by the natural type of the property or with @DataType
annotation
BeanBlockSource is the entry point for block lookup, this latter uses
BeanBlockOverrideSource to access to overriden block definition.
2010/6/16 Christophe Cordenier <ch...@gmail.com>
> Hi
>
> Maybe you should have a look at the BeanBlockOverrideSource service.
>
> 2010/6/16 Jim O'Callaghan <jc...@yahoo.co.uk>
>
> Thanks for the reply Uli. I see how I can do this on a case by case basis
>> but what I was hoping for was to contribute a block / renderer /
validator
>> /
>> translator that were all associated with entities of type Entity B, and
>> then
>> wherever they were included an entity being rendered using a BEF / Bean
>> Display, the relevant block would automatically be rendered - is this
>> approach possible? Having to manually supply <t:parameter ... for every
>> page would not be a very attractive option.
>>
>> Regards,
>> Jim.
>>
>> -----Original Message-----
>> From: Ulrich Stärk [mailto:uli@spielviel.de]
>> Sent: 16 June 2010 14:28
>> To: Tapestry users
>> Subject: Re: Custom Edit Block
>>
>> You will want to apply the NonVisual annotation to your id field and use
>> the
>> BeanDisplay component
>> for displaying the contents in your display scenario. I'm not sure right
>> now
>> whether the NonVisual
>> annotation will make the BeanEditForm render a hidden input field
>> though...
>> If it doesn't you have
>> to something like
>>
>> <t:beaneditform object="entity">
>> <t:parameter name="id">
>> <t:hidden t:id="id" value="entity.id"/>
>> </t:parameter>
>> </t:beaneditform>
>>
>> as described on the page you were referring to.
>>
>> HTH,
>>
>> Uli
>>
>> On 16.06.2010 15:11, Jim O'Callaghan wrote:
>> > I'm trying to put together an edit / display block for an entity
(Entity
>> B)
>> > where for simplification the entity contains an id and a desc field
>> >
>> > - in an edit scenario I want the rendered output to have a hidden
>> field
>> > for the id and an input field for the desc field, so that upon
>> submission
>> I
>> > can use the id to update an existing entity using the desc field
>> >
>> > - in a display scenario I just need to display a readonly text
field
>> for
>> > the desc
>> >
>> >
>> >
>> > I want to be able to use this block system-wide in bean edit forms and
>> bean
>> > displays where the form is being rendered for Entity A which contains a
>> 1:1
>> > Entity B.
>> >
>> >
>> >
>> > I'm looking at the example at
>> > http://tapestry.apache.org/tapestry5/guide/beaneditform.html but
>> drawing a
>> > bit of a blank on how some tml to render my hidden id field and my text
>> desc
>> > field for edit, and my text desc field only for display fits in with
the
>> > code. Can anyone point to a more comprehensive online example or let
me
>> > know if what I am doing is something achievable? I'm not sure if
Google
>> > just isn't cooperating today or I am being stupid ...
>> >
>> >
>> >
>> > Regards,
>> >
>> > Jim.
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> --
> Regards,
> Christophe Cordenier.
>
> Developer of wooki @wookicentral.com
>
--
Regards,
Christophe Cordenier.
Developer of wooki @wookicentral.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Custom Edit Block
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Wed, 16 Jun 2010 16:18:12 -0300, Jim O'Callaghan
<jc...@yahoo.co.uk> wrote:
> Thiago, given that approach, where an entity with structure (Long id,
> String desc) is being translated, would you mind suggesting the best
> approach to access the id of my entity <not the field id or tapestry id>
> from within the parseClient method of the relevant translator?
I would attempt to use the Environmental service to do that.
> even putting something in a threadlocal, but if there is a better /
> safer way I would be interested to hear it, or to hear if this approach
> is not suitable for my use case. Getting the client value (the entity's
> desc field) back in parseClient is working correctly, but if I don’t
> have the existing entity id my persistence layer assigns a new one.
Why don't you create a single form field component that edits this entity
class, put all this logic there and then use it inside your edition block?
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: Custom Edit Block
Posted by Jim O'Callaghan <jc...@yahoo.co.uk>.
Thanks Thiago I'll look into it further - you've clarified it a lot. When I was talking about storing an object in the component I meant some state I could store that would persist through the render --> user input --> post so I could access it afterward and reassign my values to the original entity, but what you've suggested is more along the lines of what I was hoping to achieve originally - a separate hidden key field rendered alongside the input field - thanks.
Regards,
Jim.
-----Original Message-----
From: Thiago H. de Paula Figueiredo [mailto:thiagohp@gmail.com]
Sent: 17 June 2010 12:53
To: Tapestry users
Subject: Re: Custom Edit Block
On Wed, 16 Jun 2010 18:24:50 -0300, Jim O'Callaghan
<jc...@yahoo.co.uk> wrote:
> Thiago,
Hi!
> Thanks for your helpful advice, as usual. Before I junk what I've done
> and get stuck in again, would you mind telling me if I can use this
> approach to:
All you did until now is in the right direction (DataTypeAnalyzer,
BeanBlockSource contributions, etc). You just need to create a form field
component that has one TextField for the description and a hidden field
for the id.
> - store an entity in the newly created form field component
I'm not following you.
> - get the component to render a subset of attributes I want from the
> entity
BeanModel manipulation solves that.
> - on form submission take what parameter(s) I want from the POST and
> assign it/them to the relevant attribute of the entity within the
> component
Subclassing AbstractField, you'll need to implement the
processSubmission(String elementName) method. That's the hook for doing
what you're describing.
> - have Tapestry automagically use this component upon coming across an
> attribute of entity type xyz (similar to how the datefield component is
> used by default) in the beaneditform / bean display
You already implemented that: just use it in your entity edition block.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informa��o Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Custom Edit Block
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Wed, 16 Jun 2010 18:24:50 -0300, Jim O'Callaghan
<jc...@yahoo.co.uk> wrote:
> Thiago,
Hi!
> Thanks for your helpful advice, as usual. Before I junk what I've done
> and get stuck in again, would you mind telling me if I can use this
> approach to:
All you did until now is in the right direction (DataTypeAnalyzer,
BeanBlockSource contributions, etc). You just need to create a form field
component that has one TextField for the description and a hidden field
for the id.
> - store an entity in the newly created form field component
I'm not following you.
> - get the component to render a subset of attributes I want from the
> entity
BeanModel manipulation solves that.
> - on form submission take what parameter(s) I want from the POST and
> assign it/them to the relevant attribute of the entity within the
> component
Subclassing AbstractField, you'll need to implement the
processSubmission(String elementName) method. That's the hook for doing
what you're describing.
> - have Tapestry automagically use this component upon coming across an
> attribute of entity type xyz (similar to how the datefield component is
> used by default) in the beaneditform / bean display
You already implemented that: just use it in your entity edition block.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: Custom Edit Block
Posted by Jim O'Callaghan <jc...@yahoo.co.uk>.
Thiago,
Thanks for your helpful advice, as usual. Before I junk what I've done and get stuck in again, would you mind telling me if I can use this approach to:
- store an entity in the newly created form field component
- get the component to render a subset of attributes I want from the entity
- on form submission take what parameter(s) I want from the POST and assign it/them to the relevant attribute of the entity within the component
- have Tapestry automagically use this component upon coming across an attribute of entity type xyz (similar to how the datefield component is used by default) in the beaneditform / bean display
I'm probably labouring a simple query here, but I'm finding getting a working result a hard fought battle to get a small number of lines of relevant code working.
Thanks,
Jim.
-----Original Message-----
From: Thiago H. de Paula Figueiredo [mailto:thiagohp@gmail.com]
Sent: 16 June 2010 21:14
To: Tapestry users
Subject: Re: Custom Edit Block
On Wed, 16 Jun 2010 17:05:29 -0300, Jim O'Callaghan
<jc...@yahoo.co.uk> wrote:
> ... in the translator, is there some way I can get access to the
> relevant entity? I thought all I had access to was the clientValue,
> which in the case of say a numeric format / address etc.
That's correct. A translator is something that just makes the string <->
value translation for text fields. You should really create a form field
component (AbstractField subclass), so you don't even need a translator
for it.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informa��o Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Custom Edit Block
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Wed, 16 Jun 2010 17:05:29 -0300, Jim O'Callaghan
<jc...@yahoo.co.uk> wrote:
> ... in the translator, is there some way I can get access to the
> relevant entity? I thought all I had access to was the clientValue,
> which in the case of say a numeric format / address etc.
That's correct. A translator is something that just makes the string <->
value translation for text fields. You should really create a form field
component (AbstractField subclass), so you don't even need a translator
for it.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: Custom Edit Block
Posted by Jim O'Callaghan <jc...@yahoo.co.uk>.
Kalle,
Thanks for the response. I am using Hibernate, but I'm not sure I follow you - in:
public EntityB parseClient(Field field, String clientValue, String message) throws ValidationException {
.
.
.
}
... in the translator, is there some way I can get access to the relevant entity? I thought all I had access to was the clientValue, which in the case of say a numeric format / address etc. I could create the target object as new from the clientValue String and return it, but that wouldn't work for my use case, where the clientValue is just a part of the entity I want to return. Am I missing something obvious?
Regards,
Jim.
-----Original Message-----
From: Kalle Korhonen [mailto:kalle.o.korhonen@gmail.com]
Sent: 16 June 2010 20:35
To: Tapestry users
Subject: Re: Custom Edit Block
On Wed, Jun 16, 2010 at 12:18 PM, Jim O'Callaghan <jc...@yahoo.co.uk> wrote:
> Thiago, given that approach, where an entity with structure (Long id, String desc) is being translated, would you mind suggesting the best approach to access the id of my entity <not the field id or tapestry id> from within the parseClient method of the relevant translator? �I had a look through the 5.1.0.5 sources and nothing jumped out. �I was thinking of putting a method on the translator to set a local var (to hold the id) and setting it from the AppPropertyEditBlocks getXXXTranslator, or even putting something in a threadlocal, but if there is a better / safer way I would be interested to hear it, or to hear if this approach is not suitable for my use case. �Getting the client value (the entity's desc field) back in parseClient is working correctly, but if I don�t have the existing entity id my persistence layer assigns a new one.
>
Are you using Hibernate? If so:
ClassMetadata metadata = sessionFactory.getClassMetadata(entity.getClass());
Serializable identifier = metadata.getIdentifier(entity, EntityMode.POJO);
(From Tynamo's SeedEntityImpl)
Kalle
> -----Original Message-----
> From: Thiago H. de Paula Figueiredo [mailto:thiagohp@gmail.com]
> Sent: 16 June 2010 19:09
> To: Tapestry users
> Subject: Re: Custom Edit Block
>
> On Wed, 16 Jun 2010 14:52:55 -0300, Christophe Cordenier
> <ch...@gmail.com> wrote:
>
>> Another elegant way is maybe to decorate the BeanModelSource to detect
>> entities and set a special datatype in case of 'id' property. Anyway i
>> dind't make the test.
>
> I still prefer the DataTypeAnalyzer route. That's the normal, expected
> path.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and instructor
> Owner, Ars Machina Tecnologia da Informa??o Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Custom Edit Block
Posted by Kalle Korhonen <ka...@gmail.com>.
On Wed, Jun 16, 2010 at 12:18 PM, Jim O'Callaghan <jc...@yahoo.co.uk> wrote:
> Thiago, given that approach, where an entity with structure (Long id, String desc) is being translated, would you mind suggesting the best approach to access the id of my entity <not the field id or tapestry id> from within the parseClient method of the relevant translator? I had a look through the 5.1.0.5 sources and nothing jumped out. I was thinking of putting a method on the translator to set a local var (to hold the id) and setting it from the AppPropertyEditBlocks getXXXTranslator, or even putting something in a threadlocal, but if there is a better / safer way I would be interested to hear it, or to hear if this approach is not suitable for my use case. Getting the client value (the entity's desc field) back in parseClient is working correctly, but if I don’t have the existing entity id my persistence layer assigns a new one.
>
Are you using Hibernate? If so:
ClassMetadata metadata = sessionFactory.getClassMetadata(entity.getClass());
Serializable identifier = metadata.getIdentifier(entity, EntityMode.POJO);
(From Tynamo's SeedEntityImpl)
Kalle
> -----Original Message-----
> From: Thiago H. de Paula Figueiredo [mailto:thiagohp@gmail.com]
> Sent: 16 June 2010 19:09
> To: Tapestry users
> Subject: Re: Custom Edit Block
>
> On Wed, 16 Jun 2010 14:52:55 -0300, Christophe Cordenier
> <ch...@gmail.com> wrote:
>
>> Another elegant way is maybe to decorate the BeanModelSource to detect
>> entities and set a special datatype in case of 'id' property. Anyway i
>> dind't make the test.
>
> I still prefer the DataTypeAnalyzer route. That's the normal, expected
> path.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and instructor
> Owner, Ars Machina Tecnologia da Informa��o Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: Custom Edit Block
Posted by Jim O'Callaghan <jc...@yahoo.co.uk>.
Christophe, Thiago, Thanks for the suggestions. As luck would have it I ended up contributing a DataTypeAnalyzer and a block to the BeanBlockSource.
Thiago, given that approach, where an entity with structure (Long id, String desc) is being translated, would you mind suggesting the best approach to access the id of my entity <not the field id or tapestry id> from within the parseClient method of the relevant translator? I had a look through the 5.1.0.5 sources and nothing jumped out. I was thinking of putting a method on the translator to set a local var (to hold the id) and setting it from the AppPropertyEditBlocks getXXXTranslator, or even putting something in a threadlocal, but if there is a better / safer way I would be interested to hear it, or to hear if this approach is not suitable for my use case. Getting the client value (the entity's desc field) back in parseClient is working correctly, but if I don’t have the existing entity id my persistence layer assigns a new one.
Thanks,
Jim.
-----Original Message-----
From: Thiago H. de Paula Figueiredo [mailto:thiagohp@gmail.com]
Sent: 16 June 2010 19:09
To: Tapestry users
Subject: Re: Custom Edit Block
On Wed, 16 Jun 2010 14:52:55 -0300, Christophe Cordenier
<ch...@gmail.com> wrote:
> Another elegant way is maybe to decorate the BeanModelSource to detect
> entities and set a special datatype in case of 'id' property. Anyway i
> dind't make the test.
I still prefer the DataTypeAnalyzer route. That's the normal, expected
path.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informa��o Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Custom Edit Block
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Wed, 16 Jun 2010 14:52:55 -0300, Christophe Cordenier
<ch...@gmail.com> wrote:
> Another elegant way is maybe to decorate the BeanModelSource to detect
> entities and set a special datatype in case of 'id' property. Anyway i
> dind't make the test.
I still prefer the DataTypeAnalyzer route. That's the normal, expected
path.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Custom Edit Block
Posted by Christophe Cordenier <ch...@gmail.com>.
Another elegant way is maybe to decorate the BeanModelSource to detect
entities and set a special datatype in case of 'id' property. Anyway i
dind't make the test.
2010/6/16 Thiago H. de Paula Figueiredo <th...@gmail.com>
> On Wed, 16 Jun 2010 13:19:44 -0300, Christophe Cordenier <
> christophe.cordenier@gmail.com> wrote:
>
> ...some more hints
>>
>> Block resolution is made in this order :
>>
>> 1. Using the property id
>> 2. Using its data Type
>>
>> DataType is defined by the natural type of the property or with @DataType
>> annotation
>>
>
> The data type is defined by the DataTypeAnalyzer service. It uses an
> ordered configuration of DataTypeAnalyzers. You should implement one or
> contribute to the DefaultDataTypeAnalyzer service (useful when the object ->
> data type mapping is made by object type only).
>
> Then you'll need to contribute your blocks to the BeanBlockSource service.
>
> The Tapestry sources are a good source (ha!) of examples of the above.
> Start taking a look at TapestryModule.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Regards,
Christophe Cordenier.
Developer of wooki @wookicentral.com
Re: Custom Edit Block
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Wed, 16 Jun 2010 13:19:44 -0300, Christophe Cordenier
<ch...@gmail.com> wrote:
> ...some more hints
>
> Block resolution is made in this order :
>
> 1. Using the property id
> 2. Using its data Type
>
> DataType is defined by the natural type of the property or with @DataType
> annotation
The data type is defined by the DataTypeAnalyzer service. It uses an
ordered configuration of DataTypeAnalyzers. You should implement one or
contribute to the DefaultDataTypeAnalyzer service (useful when the object
-> data type mapping is made by object type only).
Then you'll need to contribute your blocks to the BeanBlockSource service.
The Tapestry sources are a good source (ha!) of examples of the above.
Start taking a look at TapestryModule.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Custom Edit Block
Posted by Christophe Cordenier <ch...@gmail.com>.
...some more hints
Block resolution is made in this order :
1. Using the property id
2. Using its data Type
DataType is defined by the natural type of the property or with @DataType
annotation
BeanBlockSource is the entry point for block lookup, this latter uses
BeanBlockOverrideSource to access to overriden block definition.
2010/6/16 Christophe Cordenier <ch...@gmail.com>
> Hi
>
> Maybe you should have a look at the BeanBlockOverrideSource service.
>
> 2010/6/16 Jim O'Callaghan <jc...@yahoo.co.uk>
>
> Thanks for the reply Uli. I see how I can do this on a case by case basis
>> but what I was hoping for was to contribute a block / renderer / validator
>> /
>> translator that were all associated with entities of type Entity B, and
>> then
>> wherever they were included an entity being rendered using a BEF / Bean
>> Display, the relevant block would automatically be rendered - is this
>> approach possible? Having to manually supply <t:parameter ... for every
>> page would not be a very attractive option.
>>
>> Regards,
>> Jim.
>>
>> -----Original Message-----
>> From: Ulrich Stärk [mailto:uli@spielviel.de]
>> Sent: 16 June 2010 14:28
>> To: Tapestry users
>> Subject: Re: Custom Edit Block
>>
>> You will want to apply the NonVisual annotation to your id field and use
>> the
>> BeanDisplay component
>> for displaying the contents in your display scenario. I'm not sure right
>> now
>> whether the NonVisual
>> annotation will make the BeanEditForm render a hidden input field
>> though...
>> If it doesn't you have
>> to something like
>>
>> <t:beaneditform object="entity">
>> <t:parameter name="id">
>> <t:hidden t:id="id" value="entity.id"/>
>> </t:parameter>
>> </t:beaneditform>
>>
>> as described on the page you were referring to.
>>
>> HTH,
>>
>> Uli
>>
>> On 16.06.2010 15:11, Jim O'Callaghan wrote:
>> > I'm trying to put together an edit / display block for an entity (Entity
>> B)
>> > where for simplification the entity contains an id and a desc field
>> >
>> > - in an edit scenario I want the rendered output to have a hidden
>> field
>> > for the id and an input field for the desc field, so that upon
>> submission
>> I
>> > can use the id to update an existing entity using the desc field
>> >
>> > - in a display scenario I just need to display a readonly text field
>> for
>> > the desc
>> >
>> >
>> >
>> > I want to be able to use this block system-wide in bean edit forms and
>> bean
>> > displays where the form is being rendered for Entity A which contains a
>> 1:1
>> > Entity B.
>> >
>> >
>> >
>> > I'm looking at the example at
>> > http://tapestry.apache.org/tapestry5/guide/beaneditform.html but
>> drawing a
>> > bit of a blank on how some tml to render my hidden id field and my text
>> desc
>> > field for edit, and my text desc field only for display fits in with the
>> > code. Can anyone point to a more comprehensive online example or let me
>> > know if what I am doing is something achievable? I'm not sure if Google
>> > just isn't cooperating today or I am being stupid ...
>> >
>> >
>> >
>> > Regards,
>> >
>> > Jim.
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> --
> Regards,
> Christophe Cordenier.
>
> Developer of wooki @wookicentral.com
>
--
Regards,
Christophe Cordenier.
Developer of wooki @wookicentral.com
Re: Custom Edit Block
Posted by Christophe Cordenier <ch...@gmail.com>.
Hi
Maybe you should have a look at the BeanBlockOverrideSource service.
2010/6/16 Jim O'Callaghan <jc...@yahoo.co.uk>
> Thanks for the reply Uli. I see how I can do this on a case by case basis
> but what I was hoping for was to contribute a block / renderer / validator
> /
> translator that were all associated with entities of type Entity B, and
> then
> wherever they were included an entity being rendered using a BEF / Bean
> Display, the relevant block would automatically be rendered - is this
> approach possible? Having to manually supply <t:parameter ... for every
> page would not be a very attractive option.
>
> Regards,
> Jim.
>
> -----Original Message-----
> From: Ulrich Stärk [mailto:uli@spielviel.de]
> Sent: 16 June 2010 14:28
> To: Tapestry users
> Subject: Re: Custom Edit Block
>
> You will want to apply the NonVisual annotation to your id field and use
> the
> BeanDisplay component
> for displaying the contents in your display scenario. I'm not sure right
> now
> whether the NonVisual
> annotation will make the BeanEditForm render a hidden input field though...
> If it doesn't you have
> to something like
>
> <t:beaneditform object="entity">
> <t:parameter name="id">
> <t:hidden t:id="id" value="entity.id"/>
> </t:parameter>
> </t:beaneditform>
>
> as described on the page you were referring to.
>
> HTH,
>
> Uli
>
> On 16.06.2010 15:11, Jim O'Callaghan wrote:
> > I'm trying to put together an edit / display block for an entity (Entity
> B)
> > where for simplification the entity contains an id and a desc field
> >
> > - in an edit scenario I want the rendered output to have a hidden
> field
> > for the id and an input field for the desc field, so that upon submission
> I
> > can use the id to update an existing entity using the desc field
> >
> > - in a display scenario I just need to display a readonly text field
> for
> > the desc
> >
> >
> >
> > I want to be able to use this block system-wide in bean edit forms and
> bean
> > displays where the form is being rendered for Entity A which contains a
> 1:1
> > Entity B.
> >
> >
> >
> > I'm looking at the example at
> > http://tapestry.apache.org/tapestry5/guide/beaneditform.html but drawing
> a
> > bit of a blank on how some tml to render my hidden id field and my text
> desc
> > field for edit, and my text desc field only for display fits in with the
> > code. Can anyone point to a more comprehensive online example or let me
> > know if what I am doing is something achievable? I'm not sure if Google
> > just isn't cooperating today or I am being stupid ...
> >
> >
> >
> > Regards,
> >
> > Jim.
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Regards,
Christophe Cordenier.
Developer of wooki @wookicentral.com
RE: Custom Edit Block
Posted by Jim O'Callaghan <jc...@yahoo.co.uk>.
Thanks for the reply Uli. I see how I can do this on a case by case basis
but what I was hoping for was to contribute a block / renderer / validator /
translator that were all associated with entities of type Entity B, and then
wherever they were included an entity being rendered using a BEF / Bean
Display, the relevant block would automatically be rendered - is this
approach possible? Having to manually supply <t:parameter ... for every
page would not be a very attractive option.
Regards,
Jim.
-----Original Message-----
From: Ulrich Stärk [mailto:uli@spielviel.de]
Sent: 16 June 2010 14:28
To: Tapestry users
Subject: Re: Custom Edit Block
You will want to apply the NonVisual annotation to your id field and use the
BeanDisplay component
for displaying the contents in your display scenario. I'm not sure right now
whether the NonVisual
annotation will make the BeanEditForm render a hidden input field though...
If it doesn't you have
to something like
<t:beaneditform object="entity">
<t:parameter name="id">
<t:hidden t:id="id" value="entity.id"/>
</t:parameter>
</t:beaneditform>
as described on the page you were referring to.
HTH,
Uli
On 16.06.2010 15:11, Jim O'Callaghan wrote:
> I'm trying to put together an edit / display block for an entity (Entity
B)
> where for simplification the entity contains an id and a desc field
>
> - in an edit scenario I want the rendered output to have a hidden
field
> for the id and an input field for the desc field, so that upon submission
I
> can use the id to update an existing entity using the desc field
>
> - in a display scenario I just need to display a readonly text field
for
> the desc
>
>
>
> I want to be able to use this block system-wide in bean edit forms and
bean
> displays where the form is being rendered for Entity A which contains a
1:1
> Entity B.
>
>
>
> I'm looking at the example at
> http://tapestry.apache.org/tapestry5/guide/beaneditform.html but drawing a
> bit of a blank on how some tml to render my hidden id field and my text
desc
> field for edit, and my text desc field only for display fits in with the
> code. Can anyone point to a more comprehensive online example or let me
> know if what I am doing is something achievable? I'm not sure if Google
> just isn't cooperating today or I am being stupid ...
>
>
>
> Regards,
>
> Jim.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Custom Edit Block
Posted by Ulrich Stärk <ul...@spielviel.de>.
You will want to apply the NonVisual annotation to your id field and use the BeanDisplay component
for displaying the contents in your display scenario. I'm not sure right now whether the NonVisual
annotation will make the BeanEditForm render a hidden input field though... If it doesn't you have
to something like
<t:beaneditform object="entity">
<t:parameter name="id">
<t:hidden t:id="id" value="entity.id"/>
</t:parameter>
</t:beaneditform>
as described on the page you were referring to.
HTH,
Uli
On 16.06.2010 15:11, Jim O'Callaghan wrote:
> I'm trying to put together an edit / display block for an entity (Entity B)
> where for simplification the entity contains an id and a desc field
>
> - in an edit scenario I want the rendered output to have a hidden field
> for the id and an input field for the desc field, so that upon submission I
> can use the id to update an existing entity using the desc field
>
> - in a display scenario I just need to display a readonly text field for
> the desc
>
>
>
> I want to be able to use this block system-wide in bean edit forms and bean
> displays where the form is being rendered for Entity A which contains a 1:1
> Entity B.
>
>
>
> I'm looking at the example at
> http://tapestry.apache.org/tapestry5/guide/beaneditform.html but drawing a
> bit of a blank on how some tml to render my hidden id field and my text desc
> field for edit, and my text desc field only for display fits in with the
> code. Can anyone point to a more comprehensive online example or let me
> know if what I am doing is something achievable? I'm not sure if Google
> just isn't cooperating today or I am being stupid ...
>
>
>
> Regards,
>
> Jim.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org