If I am happy with using an Entities toString() method ... is this safe to
say:
For DISPLAYing an Entity via its "toString" method in something like t:Grid
or t:BeanDisplay
(1) add a line to AppModule.contributeDefaultDataTypeAnalyzer and
(2) implement toString() on the entity.
/**
* Add a PropertyEditor for the <code>Classification</code> data type.
*
* @param configuration
*/
public static void
contributeDefaultDataTypeAnalyzer(MappedConfiguration<Class<?>, String>
configuration)
{
configuration.add(Classification.class, "classification");
}
@Entity
public class Classification implements Serializable, Identifiable,
Comparable<Classification>
{
....
private String name;
...
@Override
public String toString()
{
return this.name;
}
}
-Luther
On Tue, Feb 17, 2009 at 1:48 PM, Luther Baker <lutherba...@gmail.com> wrote:
> 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
>>
>>
>
