Thanks both of you for your explanations - if you've got a bit of patience
with me, I need to walk through my thoughts to better understand the big
picture here. Thanks in advance for your points and help - they are very
helpful.
Ok, to set the stage in a little more detail: consider a basic GRAILS or
CRUD style app where my views are List.tml, Edit.tml and Show.tml.
I've broken this up into a few posts - in this response, *I'll focus on
List.tml, t:Grid and t:BeanDisplay* -- afterwhich, I'll try to segway into a
post that leverages this information to discuss t:BeanEditForm.
In this example, I'm using Topics and Classifications. Both are simple
entities - a Topic has a @ManyToOne relationship to Classifications. Each
Topic contains exactly one Classification. Many Topics can refer to the same
Classification but again, any single Topic has exactly one Classification.
@Entity
public class Classification
{
@Id
@GeneratedValue(strategy = GenerationType.TABLE)
private Integer id;
private String name;
...
}
@Entity
public class Topic
{
@Id
@GeneratedValue(strategy = GenerationType.TABLE)
private Integer id;
@ManyToOne
private Classification classification;
...
}
Now consider List.tml:
If I use a t:Grid out of the box, I get a runtime complaint when I try to
display a Topic,
"does not contain a property named 'classification'"
I assume this is because 'Classification' is not on the list of simple types
that Tapestry currently knows about. Strings, booleans, numbers, etc. So, I
add a defaultDataTypeAnalyzer:
public static void
contributeDefaultDataTypeAnalyzer(MappedConfiguration<Class<?>, String>
configuration)
{
configuration.add(Classification.class, "classification");
}
I'm not sure why assigning the name "classification" Classification suddenly
makes this work ... but as soon as I do this, the t:Grid successfully
displays a Classification column - and populates it by invoking
Classification.toString(). Is that behavior overridable? Is it safe to say I
don't need any other moving parts for this to work this way going forward?
My next post will talk about BeanEditForm which I understand uses a
BeanModel, PropertyEditor, blocks etc - but as far as t:Grid is concerned -
is there a special way to explicitly control how Classification DISPLAY's
itself (right now it invokes Classification.toString()) ? (ie: is there a
group of classes that work together similar to t:BeanEditForm?)
In the t:BeanEditForm - one creates xhtml blocks - but it doesn't appear
necessary for t:Grid. Is that because t:Grid is only DISPLAYing the
property?
When I use t:BeanDisplay, the same thing happens, Classification.toString()
is invoked. That all sounds good and reasonable - I am just curious how, in
a DISPLAY scenario, if there is a programmatic way to override the behavior?
And, as a side note, looking for a brief explanation as to why
'contributeDefaultDataTypeAnalyzer' makes this work.
End of Part 1 :) DISPLAYing hibernate entities: t:Grid and t:BeanDisplay ...
is it simpler than t:BeanEditForm? and can I override the toString
invocation and why does contributeDefaultDataTypeAnalyzer have to happen
here?
Always happy to look at docs for this if you have any links to show.
Thanks very much - I'm off to try some of the notes for t:BeanEditForm and
I'll get back to you.
-Luther
On Tue, Feb 17, 2009 at 5:34 AM, Ulrich Stärk <u...@spielviel.de> wrote:
> Here is your overview (assuming that you want to render your list of
> schools using a select component):
>
> SelectModel
>
> This is a model of the data you want to render. This could be backed by a
> list or some other collection type (there is a type coercer from list to
> selectmodel build into tapestry which automatically converts the one into
> the other). In your case you will want to populate this model with the
> available schools.
>
> ValueEncoder
>
> As Thiago already pointed out, this is needed to convert from object to
> presentation and back.
>
> GenericSelectModel
>
> Search for it in the wiki. It's user-contributed and implements both the
> SelectModel and the ValueEncoder interfaces. In its constructor, you pass it
> the type you want to create a model/encoder for, the list of available items
> (schools in your case), the name of the id property and the name of the
> property used to display to the user (if null, toString() will be used).
>
> AppPropertyEditBlocks
>
> The name of a page where you define a block used for rendering your custom
> type (school). This name is arbitrary and can be whatever you like it to be.
> Here you wire up the select component with your model and encoder. In the
> page template you define some block whith an explicit id (e.g. schoolBlock).
>
> AppModule
>
> In your AppModule you have to make contributions to the
> DefaultDataTypeAnalyzer and the BeanBlockSource services.
>
> public static void contributeDefaultDataTypeAnalyzer(
> MappedConfiguration<Class, String> configuration)
> {
> configuration.add(School.class, "school");
> }
>
> This will assign the name school to your school type for use within
> tapestry.
>
> With
>
> public static void
> contributeBeanBlockSource(Configuration<BeanBlockContribution>
> configuration)
> {
> configuration.add(new BeanBlockContribution("school",
> "AppPropertyEditBlocks", "schoolBlock",
> true));
> }
>
> you tell Tapestry to render a property of type school with the block
> "schoolBlock" inside the AppPropertyEditBlocks page.
>
> HTH,
>
> Uli
>
> Luther Baker schrieb:
>
> Given two hibernate objects and a many-to-one relationship
>>
>> school
>> {
>> name
>> }
>>
>> student
>> {
>> firstname
>>
>> @ManyToOne
>> school
>> }
>>
>>
>> I want to pass something like this into a BeanEditForm and have the it
>> invoke school.toString() or possibly, school.getName().
>>
>> I know I can add a t:Parameter to t:BeanEditForm but it seems that I
>> should
>> be able to somehow register the School type with Tapestry and have it
>> simply
>> invoke school.toString() when required to render itself.
>>
>> I've looked at
>> http://wiki.apache.org/tapestry/Tapestry5HowToCreateAPropertyEditBlockbut
>> found it a bit confusing. At some high level, is there a brief synopsis of
>> the different players required to do this?
>>
>> PropertyEditor
>> ValueEncoder
>> DataTypeAnalyzer
>> PropertyEditContext
>> @Environmental
>> the Model ... etc.
>>
>> Now, on the other hand, is the BeanEditForm really considered just a
>> starter
>> component and is generally not used for production code? In which case, is
>> it just fine to come up with custom solutions to determine types and how
>> to
>> render them? Or is there a strong reason to go through all of this ...
>> when
>> I want to render a nested Hibernate Entity with a toString().
>>
>> Thanks,
>>
>> -Luther
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
