Using Grid and org.joda.time.DateTime

[Martin Reurings]

Hi everybody,

I've been using T5 quite a while now but only recently started making
serious use of the Grid and BeanEditor (finally giving way to my
misgivings concerning some of the html-output in favor of development
speed). But, now that I've started using Grid I ran into something I
can't quite grasp. I have a Pojo with a reasonable set of getters and
setters, however, Grid only accepts 'public Long getId()' to be a
property, while 'public DateTime getDateCreated()' is ignored?!?

I wouldn't mind as much if it were just one field, but since we use
'org.joda.time.DateTime' a lot in our project I figured I'd be better of
figuring out what's going on and solve it now, rather than later... Any
ideas what might be going on? Any links / concepts I should start
looking at / googling for, to solve this elegantly?

Oh, and before I forget, this is how I declared my grid:
    @Component(id = "pojos", parameters =
{"source=ucw.pojos","row=pojo","add=dateCreated"})
    private Grid _pojosComponent;

Where ucw.pojos is returning a List of Pojo's and for testing purposes I
was storing the pojo in a property so I could test if I was able to
generate output of the dateCreated even though the Grid was ignoring it,
which turned out successful:
<p:dateCreatedCell>
  ${pojo.dateCreated}
</p:dateCreatedCell>

Cheers,

 Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Ulrich Stärk]

That's because Tapestry doesn't know how to display org.joda.time.DateTime. Provide a block that
knows how to display a DateTime on some page and contribute that block to the BeanBlockSouce service
(see [1] for an example).

Uli

[1] http://tapestry.apache.org/tapestry5.1/guide/beaneditform.html

Am 04.11.2009 14:20 schrieb Martin Reurings:

> Hi everybody,
>
> I've been using T5 quite a while now but only recently started making
> serious use of the Grid and BeanEditor (finally giving way to my
> misgivings concerning some of the html-output in favor of development
> speed). But, now that I've started using Grid I ran into something I
> can't quite grasp. I have a Pojo with a reasonable set of getters and
> setters, however, Grid only accepts 'public Long getId()' to be a
> property, while 'public DateTime getDateCreated()' is ignored?!?
>
> I wouldn't mind as much if it were just one field, but since we use
> 'org.joda.time.DateTime' a lot in our project I figured I'd be better of
> figuring out what's going on and solve it now, rather than later... Any
> ideas what might be going on? Any links / concepts I should start
> looking at / googling for, to solve this elegantly?
>
> Oh, and before I forget, this is how I declared my grid:
>    @Component(id = "pojos", parameters =
> {"source=ucw.pojos","row=pojo","add=dateCreated"})
>    private Grid _pojosComponent;
>
> Where ucw.pojos is returning a List of Pojo's and for testing purposes I
> was storing the pojo in a property so I could test if I was able to
> generate output of the dateCreated even though the Grid was ignoring it,
> which turned out successful:
> <p:dateCreatedCell>
>  ${pojo.dateCreated}
> </p:dateCreatedCell>
>
> Cheers,
>
> Martin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Ulrich Stärk]

I just noticed that the page I referred to is missing some things:

If you just want to display (output) a property, inject the PropertyOutputContext environmental
service instead of the PropertyEditContext. Also you might want to put your block on a page called
AppPropertyDisplayBlocks instead of AppPropertyEditBlocks (in the end this doesn't matter since you
can configure that in your contribution to the BeanBlockSource service). Acquiring the actual value
of your property is then done with (DateTime) context.getPropertyValue().

Uli

Am 04.11.2009 14:36 schrieb Ulrich Stärk:

> That's because Tapestry doesn't know how to display
> org.joda.time.DateTime. Provide a block that knows how to display a
> DateTime on some page and contribute that block to the BeanBlockSouce
> service (see [1] for an example).
>
> Uli
>
> [1] http://tapestry.apache.org/tapestry5.1/guide/beaneditform.html
>
> Am 04.11.2009 14:20 schrieb Martin Reurings:
>> Hi everybody,
>>
>> I've been using T5 quite a while now but only recently started making
>> serious use of the Grid and BeanEditor (finally giving way to my
>> misgivings concerning some of the html-output in favor of development
>> speed). But, now that I've started using Grid I ran into something I
>> can't quite grasp. I have a Pojo with a reasonable set of getters and
>> setters, however, Grid only accepts 'public Long getId()' to be a
>> property, while 'public DateTime getDateCreated()' is ignored?!?
>>
>> I wouldn't mind as much if it were just one field, but since we use
>> 'org.joda.time.DateTime' a lot in our project I figured I'd be better
>> of figuring out what's going on and solve it now, rather than later...
>> Any ideas what might be going on? Any links / concepts I should start
>> looking at / googling for, to solve this elegantly?
>>
>> Oh, and before I forget, this is how I declared my grid:
>>    @Component(id = "pojos", parameters =
>> {"source=ucw.pojos","row=pojo","add=dateCreated"})
>>    private Grid _pojosComponent;
>>
>> Where ucw.pojos is returning a List of Pojo's and for testing purposes
>> I was storing the pojo in a property so I could test if I was able to
>> generate output of the dateCreated even though the Grid was ignoring
>> it, which turned out successful:
>> <p:dateCreatedCell>
>>  ${pojo.dateCreated}
>> </p:dateCreatedCell>
>>
>> Cheers,
>>
>> Martin
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Martin Reurings]

Hi Uli,

Thank you for the detailed info and extra clarifications :) I've
constantly been using the Tapestry Core, Component Reference to get my
information. Although that seems to be detailed, it isn't necessarily
complete... I'll be sure to check the websites' guide section more
closely in the future before posting to the users list :) Even so, it
appears asking here has already gained me an edge, I may have had to
struggle along before I figured out the PropertyOutputContext vs.
PropertyEditContext differences...

Cheers,

 Martin

Ulrich Stärk wrote:

> I just noticed that the page I referred to is missing some things:
>
> If you just want to display (output) a property, inject the
> PropertyOutputContext environmental service instead of the
> PropertyEditContext. Also you might want to put your block on a page
> called AppPropertyDisplayBlocks instead of AppPropertyEditBlocks (in
> the end this doesn't matter since you can configure that in your
> contribution to the BeanBlockSource service). Acquiring the actual
> value of your property is then done with (DateTime)
> context.getPropertyValue().
>
> Uli
>
> Am 04.11.2009 14:36 schrieb Ulrich Stärk:
>> That's because Tapestry doesn't know how to display
>> org.joda.time.DateTime. Provide a block that knows how to display a
>> DateTime on some page and contribute that block to the BeanBlockSouce
>> service (see [1] for an example).
>>
>> Uli
>>
>> [1] http://tapestry.apache.org/tapestry5.1/guide/beaneditform.html
>>
>> Am 04.11.2009 14:20 schrieb Martin Reurings:
>>> Hi everybody,
>>>
>>> I've been using T5 quite a while now but only recently started
>>> making serious use of the Grid and BeanEditor (finally giving way to
>>> my misgivings concerning some of the html-output in favor of
>>> development speed). But, now that I've started using Grid I ran into
>>> something I can't quite grasp. I have a Pojo with a reasonable set
>>> of getters and setters, however, Grid only accepts 'public Long
>>> getId()' to be a property, while 'public DateTime getDateCreated()'
>>> is ignored?!?
>>>
>>> I wouldn't mind as much if it were just one field, but since we use
>>> 'org.joda.time.DateTime' a lot in our project I figured I'd be
>>> better of figuring out what's going on and solve it now, rather than
>>> later... Any ideas what might be going on? Any links / concepts I
>>> should start looking at / googling for, to solve this elegantly?
>>>
>>> Oh, and before I forget, this is how I declared my grid:
>>>    @Component(id = "pojos", parameters =
>>> {"source=ucw.pojos","row=pojo","add=dateCreated"})
>>>    private Grid _pojosComponent;
>>>
>>> Where ucw.pojos is returning a List of Pojo's and for testing
>>> purposes I was storing the pojo in a property so I could test if I
>>> was able to generate output of the dateCreated even though the Grid
>>> was ignoring it, which turned out successful:
>>> <p:dateCreatedCell>
>>>  ${pojo.dateCreated}
>>> </p:dateCreatedCell>
>>>
>>> Cheers,
>>>
>>> Martin
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Martin Reurings]

Hi Uli and/or anybody else reading this,

Could you help me some more? I ran into an unexpected problem :) There
is a known editor-block for Joda DateTime, however, there is no known
view-block?!? When I added the following:
    /**
     * This method is used to add aditional editors / views to the Grid
and BeanEditor components.
     * @param configuration
     */
    @SuppressWarnings("unchecked")
    public static void
contributeDefaultDataTypeAnalyzer(MappedConfiguration<Class, String>
configuration)
    {
      configuration.add(DateTime.class, "jodaTime");
    }
    public static void
contributeBeanBlockSource(Configuration<BeanBlockContribution>
configuration)
    {
      configuration.add(new BeanBlockContribution("jodatime",
"AppPropertyViewBlocks", "jodatime", false));
    }

And the appropriate stuff in AppPropertyViewBlocks.java and .tml I was
able to view the DateTime properties on my Pojo, yay! However, this came
with an unexpected side-effect, another Pojo which contained a DateTime
field is using a BeanEditor, which was able to generate an editor for
the DateTime field and is now throwing 'Unable to locate a block to edit
property 'dateAccountCreated' (with data type 'jodaTime')' :( Any
thoughts on how I can add the viewer without killing the editor?

Cheers,

 Martin

Ulrich Stärk wrote:

> I just noticed that the page I referred to is missing some things:
>
> If you just want to display (output) a property, inject the
> PropertyOutputContext environmental service instead of the
> PropertyEditContext. Also you might want to put your block on a page
> called AppPropertyDisplayBlocks instead of AppPropertyEditBlocks (in
> the end this doesn't matter since you can configure that in your
> contribution to the BeanBlockSource service). Acquiring the actual
> value of your property is then done with (DateTime)
> context.getPropertyValue().
>
> Uli
>
> Am 04.11.2009 14:36 schrieb Ulrich Stärk:
>> That's because Tapestry doesn't know how to display
>> org.joda.time.DateTime. Provide a block that knows how to display a
>> DateTime on some page and contribute that block to the BeanBlockSouce
>> service (see [1] for an example).
>>
>> Uli
>>
>> [1] http://tapestry.apache.org/tapestry5.1/guide/beaneditform.html
>>
>> Am 04.11.2009 14:20 schrieb Martin Reurings:
>>> Hi everybody,
>>>
>>> I've been using T5 quite a while now but only recently started
>>> making serious use of the Grid and BeanEditor (finally giving way to
>>> my misgivings concerning some of the html-output in favor of
>>> development speed). But, now that I've started using Grid I ran into
>>> something I can't quite grasp. I have a Pojo with a reasonable set
>>> of getters and setters, however, Grid only accepts 'public Long
>>> getId()' to be a property, while 'public DateTime getDateCreated()'
>>> is ignored?!?
>>>
>>> I wouldn't mind as much if it were just one field, but since we use
>>> 'org.joda.time.DateTime' a lot in our project I figured I'd be
>>> better of figuring out what's going on and solve it now, rather than
>>> later... Any ideas what might be going on? Any links / concepts I
>>> should start looking at / googling for, to solve this elegantly?
>>>
>>> Oh, and before I forget, this is how I declared my grid:
>>>    @Component(id = "pojos", parameters =
>>> {"source=ucw.pojos","row=pojo","add=dateCreated"})
>>>    private Grid _pojosComponent;
>>>
>>> Where ucw.pojos is returning a List of Pojo's and for testing
>>> purposes I was storing the pojo in a property so I could test if I
>>> was able to generate output of the dateCreated even though the Grid
>>> was ignoring it, which turned out successful:
>>> <p:dateCreatedCell>
>>>  ${pojo.dateCreated}
>>> </p:dateCreatedCell>
>>>
>>> Cheers,
>>>
>>> Martin
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Thiago H. de Paula Figueiredo]

You could use a DataTypeAnalyzer instead of a DefaultDataTypeAnalyzer.  
This way, you have more control.

Em Wed, 04 Nov 2009 14:08:08 -0200, Martin Reurings <martin@...>  
escreveu:

> Hi Uli and/or anybody else reading this,
>
> Could you help me some more? I ran into an unexpected problem :) There  
> is a known editor-block for Joda DateTime, however, there is no known  
> view-block?!? When I added the following:
>     /**
>      * This method is used to add aditional editors / views to the Grid  
> and BeanEditor components.
>      * @param configuration
>      */
>     @SuppressWarnings("unchecked")
>     public static void  
> contributeDefaultDataTypeAnalyzer(MappedConfiguration<Class, String>  
> configuration)
>     {
>       configuration.add(DateTime.class, "jodaTime");
>     }
>     public static void  
> contributeBeanBlockSource(Configuration<BeanBlockContribution>  
> configuration)
>     {
>       configuration.add(new BeanBlockContribution("jodatime",  
> "AppPropertyViewBlocks", "jodatime", false));
>     }
>
> And the appropriate stuff in AppPropertyViewBlocks.java and .tml I was  
> able to view the DateTime properties on my Pojo, yay! However, this came  
> with an unexpected side-effect, another Pojo which contained a DateTime  
> field is using a BeanEditor, which was able to generate an editor for  
> the DateTime field and is now throwing 'Unable to locate a block to edit  
> property 'dateAccountCreated' (with data type 'jodaTime')' :( Any  
> thoughts on how I can add the viewer without killing the editor?
>
> Cheers,
>
>  Martin
>
> Ulrich Stärk wrote:
>> I just noticed that the page I referred to is missing some things:
>>
>> If you just want to display (output) a property, inject the  
>> PropertyOutputContext environmental service instead of the  
>> PropertyEditContext. Also you might want to put your block on a page  
>> called AppPropertyDisplayBlocks instead of AppPropertyEditBlocks (in  
>> the end this doesn't matter since you can configure that in your  
>> contribution to the BeanBlockSource service). Acquiring the actual  
>> value of your property is then done with (DateTime)  
>> context.getPropertyValue().
>>
>> Uli
>>
>> Am 04.11.2009 14:36 schrieb Ulrich Stärk:
>>> That's because Tapestry doesn't know how to display  
>>> org.joda.time.DateTime. Provide a block that knows how to display a  
>>> DateTime on some page and contribute that block to the BeanBlockSouce  
>>> service (see [1] for an example).
>>>
>>> Uli
>>>
>>> [1] http://tapestry.apache.org/tapestry5.1/guide/beaneditform.html
>>>
>>> Am 04.11.2009 14:20 schrieb Martin Reurings:
>>>> Hi everybody,
>>>>
>>>> I've been using T5 quite a while now but only recently started making  
>>>> serious use of the Grid and BeanEditor (finally giving way to my  
>>>> misgivings concerning some of the html-output in favor of development  
>>>> speed). But, now that I've started using Grid I ran into something I  
>>>> can't quite grasp. I have a Pojo with a reasonable set of getters and  
>>>> setters, however, Grid only accepts 'public Long getId()' to be a  
>>>> property, while 'public DateTime getDateCreated()' is ignored?!?
>>>>
>>>> I wouldn't mind as much if it were just one field, but since we use  
>>>> 'org.joda.time.DateTime' a lot in our project I figured I'd be better  
>>>> of figuring out what's going on and solve it now, rather than  
>>>> later... Any ideas what might be going on? Any links / concepts I  
>>>> should start looking at / googling for, to solve this elegantly?
>>>>
>>>> Oh, and before I forget, this is how I declared my grid:
>>>>    @Component(id = "pojos", parameters =  
>>>> {"source=ucw.pojos","row=pojo","add=dateCreated"})
>>>>    private Grid _pojosComponent;
>>>>
>>>> Where ucw.pojos is returning a List of Pojo's and for testing  
>>>> purposes I was storing the pojo in a property so I could test if I  
>>>> was able to generate output of the dateCreated even though the Grid  
>>>> was ignoring it, which turned out successful:
>>>> <p:dateCreatedCell>
>>>>  ${pojo.dateCreated}
>>>> </p:dateCreatedCell>
>>>>
>>>> Cheers,
>>>>
>>>> Martin
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da  
Informação Ltda.
Consultor, desenvolvedor e instrutor em Java, Tapestry e Hibernate
Coordenador e professor da Especialização em Engenharia de Software com  
Ênfase em Java da Faculdade Pitágoras
http://www.arsmachina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Martin Reurings]

Using those two classnames as a reference I still can't figure out how I
could possibly assert the control I need. Honestly, I am somewhat
surprised with how hard this seems to be :( There's an editor available
and I'm providing a BeanBlock that is _not_ an editor, why are those two
in conflict, when they clearly should not be?

Lately I've found that when I ran into problem with T5 it was because I
was making things harder than they needed to be, but this time I don't
see how I can make it more simple :(

Thiago H. de Paula Figueiredo wrote:

> You could use a DataTypeAnalyzer instead of a DefaultDataTypeAnalyzer.
> This way, you have more control.
>
> Em Wed, 04 Nov 2009 14:08:08 -0200, Martin Reurings
> <martin@...> escreveu:
>
>> Hi Uli and/or anybody else reading this,
>>
>> Could you help me some more? I ran into an unexpected problem :)
>> There is a known editor-block for Joda DateTime, however, there is no
>> known view-block?!? When I added the following:
>>     /**
>>      * This method is used to add aditional editors / views to the
>> Grid and BeanEditor components.
>>      * @param configuration
>>      */
>>     @SuppressWarnings("unchecked")
>>     public static void
>> contributeDefaultDataTypeAnalyzer(MappedConfiguration<Class, String>
>> configuration)
>>     {
>>       configuration.add(DateTime.class, "jodaTime");
>>     }
>>     public static void
>> contributeBeanBlockSource(Configuration<BeanBlockContribution>
>> configuration)
>>     {
>>       configuration.add(new BeanBlockContribution("jodatime",
>> "AppPropertyViewBlocks", "jodatime", false));
>>     }
>>
>> And the appropriate stuff in AppPropertyViewBlocks.java and .tml I
>> was able to view the DateTime properties on my Pojo, yay! However,
>> this came with an unexpected side-effect, another Pojo which
>> contained a DateTime field is using a BeanEditor, which was able to
>> generate an editor for the DateTime field and is now throwing 'Unable
>> to locate a block to edit property 'dateAccountCreated' (with data
>> type 'jodaTime')' :( Any thoughts on how I can add the viewer without
>> killing the editor?
>>
>> Cheers,
>>
>>  Martin
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Thiago H. de Paula Figueiredo]

Em Wed, 04 Nov 2009 15:00:38 -0200, Martin Reurings <martin@...>  
escreveu:

> Using those two classnames as a reference I still can't figure out how I  
> could possibly assert the control I need.

I agree that my answer wasn't as clear as it should.

> Honestly, I am somewhat surprised with how hard this seems to be :(

It isn't. :)

> There's an editor available and I'm providing a BeanBlock that is _not_  
> an editor, why are those two in conflict, when they clearly should not  
> be?

Contributing a DefaultDataTypeAnalyzer, you create a type. Tapestry  
expects you provide both editing and viewing blocks. In your case, you  
just need to add a line in contributeBeanBlockSource to inform Tapestry  
what editor it should use for jodaTime. I don't know what editor block  
Tapestry was using before, but I guess it's 'date'. So please try adding  
the following line to your contributebeanBlockSource() method and then  
post the result:

configuration.add(new BeanBlockContribution("jodatime",  
"PropertyEditBlocks", "jodatime", true));

--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da  
Informação Ltda.
http://www.arsmachina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Martin Reurings]

>
>> Using those two classnames as a reference I still can't figure out
>> how I could possibly assert the control I need.
>
> I agree that my answer wasn't as clear as it should.

The basic problem with explaining something that is clear as day to you
lies in finding out what the other doesn't yet understand :)

>> There's an editor available and I'm providing a BeanBlock that is
>> _not_ an editor, why are those two in conflict, when they clearly
>> should not be?
>
> Contributing a DefaultDataTypeAnalyzer, you create a type. Tapestry
> expects you provide both editing and viewing blocks. In your case, you
> just need to add a line in contributeBeanBlockSource to inform
> Tapestry what editor it should use for jodaTime. I don't know what
> editor block Tapestry was using before, but I guess it's 'date'. So
> please try adding the following line to your
> contributebeanBlockSource() method and then post the result:
>
> configuration.add(new BeanBlockContribution("jodatime",
> "PropertyEditBlocks", "jodatime", true));
>

I ended up using:
      configuration.add(new BeanBlockContribution("jodatime",
"PropertyEditBlocks", "date", true));

But I had to add coercion to and from DateTime to Date (Not really that
hard to do...), which leads me to suspect that perhaps somebody changed
the property on the account pojo from normal Date to DateTime without
telling me... Anyways, lessons learned, thank you very much for your
patience!

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Thiago H. de Paula Figueiredo]

Em Wed, 04 Nov 2009 21:18:24 -0200, Martin Reurings <martin@...>  
escreveu:

> The basic problem with explaining something that is clear as day to you  
> lies in finding out what the other doesn't yet understand :)

You're absolutely right. :)

> But I had to add coercion to and from DateTime to Date (Not really that  
> hard to do...),

You're right again. :) Implement a Coercion<Date, DateTime> and contribute  
it to the TypeCorcer service.

> which leads me to suspect that perhaps somebody changed the property on  
> the account pojo from normal Date to DateTime without telling me...

That's what I would guess, as DateTime is not a Date subclass and Tapestry  
itself doesn't provide any coercion from or to JodaTime types.

> Anyways, lessons learned, thank you very much for your patience!

You're welcome!

--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da  
Informação Ltda.
http://www.arsmachina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...