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
