Whoa - stepping through a Tapestry request cycle, now that is alot of
dynamic code! It was a bit difficult to follow all that jit thread-specific
object creation ... especially since things were happening in placed I
didn't have breakcpoints ... but eventually, I think I got what I needed.
Basically, I built a translator for the t:TextField and added it to the
AppModule via contributeTranslatorSource.
Then, I changed the DISPLAY block Java code to use a Property*Output*Context
whilst the EDIT block code uses the Property*Edit*Context and whalah - it
seems to work.
I didn't have to mess with ValueEncoders or BeanModels at all - but I've not
implemented the SelectModel yet. That is tomorrow.
I do have one more question, my translator extends AbstractTranslator and
therefore must implement parseClient. My question is ... is it normal to
@Inject daos or hibernate services into something like a Translator? I'm not
sure how else to hydrate my Entity in the parseClient method ... but that
sounds like I'm adding alot of weight to that Translator. Is that normal? If
not, is there a better approach for that?
Thanks,
-Luther
On Tue, Feb 17, 2009 at 5:57 PM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:
> Em Tue, 17 Feb 2009 20:25:49 -0300, Luther Baker <lutherba...@gmail.com>
> escreveu:
>
> I had to strip a few parameters out and print literals for now. My next
>> question ... is how to get MY data into that class.
>>
>
> That's why @Environmental private PropertyEditContext context is there. ;)
> It is the bridge that takes you to the edited value.
>
> @Property
>> @Component(parameters =
>> { "value=context.propertyValue" })
>>
>
> Ah - (#1) I thought this was going to work - since only one or the other
>> block would be used at any given time. Since we are using the same java
>> class for either / or block ... it strikes me that I can't reuse t:id.
>>
>
> It doesn't matter if you use a component or not, they should have unique
> t:id's. If they're not unique, they aren't ids. ;) Don't forget that this is
> an ordinary page.
>
> Does the corresponding Java class somehow discriminate and use my same
>> classification property object but with multiple ids? I think I'm
>> confusing
>> things - partly because I have little component writing experience.
>>
>
> When you inject a component in a page, you have to tell Tapestry what is
> its t:id. The name of the field is one way to do it. The other ones is
> @Component(id="someId").
>
> but I'm not sure what to do to get that working. What is a 'translator'
>> and how do I write one ... and attach it to the context? And ... are those
>> appropriate questions?
>>
>
> Instead of trial and error, grap Tapestry's source code and read the
> PropertyEditBlocks class. It is where the Tapestry-provided blocks are
> declared. They should give you some hints. Use it as a starting point.
>
> but that didn't turn out so well. "Could not convert '
>> context.propertyValue.name' into a component parameter binding
>>
>
> The return value of PropertyEditContext.getPropertyValue() is Object. By
> the way, it is exactly the property you're trying to edit, so there's no
> need to reference property names here.
>
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
