@Uli
false - that makes sense. I will apply it in my next post which actually
uses this method.
@Thiago
>> I'm not sure why assigning the name "classification" Classification
suddenly makes this work ...
> I guess it works because someone told Tapestry that it is a known type.
Yes - but doesn't every Java type have a toString method? And the trivial
registration did nothing (on appearance) but associate a key with a class.
It trickie since it seems that Tapestry could call toString() on anything
without requiring this registration step. In this simplistic case,
registration didn't really tell it anything. But - given this registration
step - a few things make sense like ... before doing this, listing the
column name in the reorder clause of a t:grid was throwing an exception. So
I gotcha, registration is required to tell Tapestry about this object -
plain and simple. Then, tweak as you like by using the blocks.
>> From now on, all your questions have already been answered. ;)
:) One day - I hope to contribute BACK to Tapestry and than ... will have
arrived.
Thanks for your timely input. One last post on the way.
-Luther
On Tue, Feb 17, 2009 at 2:04 PM, Ulrich Stärk <u...@spielviel.de> wrote:
> If you want to specify a block for displaying your type, you just do the
> same as with the editor but instead you contribute it with
>
> public static void
> contributeBeanBlockSource(Configuration<BeanBlockContribution>
> configuration)
> {
> configuration.add(new BeanBlockContribution("school",
> "AppPropertyEditBlocks", "schoolViewBlock",
> false));
> }
>
> (notice the false parameter now)
>
> Cheers,
>
> Uli
>
> Luther Baker schrieb:
>
> 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
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
