Thiago,
You are like superman on this forum.
Thanks for spending so much time here ... I for one don't know what I'd do
without these discussions.
I know it is a tangent but I've posted to other groups like the Grails
nabble group and NEVER EVER get any responses. A framework is worthless to
me if I can't quickly get into a feedback loop of sorts when I run into
problem. Keeping this forum so active has a lot of intangible benefits for
Tapestry world domination and I just thought it'd be worth saying.
Keep up the good work and thanks again for all the time you spend here.
-Luther
On Wed, Mar 4, 2009 at 12:27 PM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:
> Em Wed, 04 Mar 2009 13:52:22 -0300, Luther Baker <lutherba...@gmail.com>
> escreveu:
>
> If Block Edit isn't a page and it isn't a component ... is there a
>> predictable way to initialize it each time it is requested?
>> In my case, I have a Hibernate entity ... with a reference @ManyToOne - to
>> another entity. It is this child entity that has an edit block associated
>> with it. When I go to EDIT the parent entity, I need to load all possible
>> children entities into a select drop down and pick from them.
>>
>
> Forget about events in this case.
> Do it the easy way: you have to pass a SelectModel to the Select component
> though the model parameter.
> Something like:
>
> <select t:type="Select" t:model="entityModel" ...>
>
> Just do your initialization inside the getEntityModel() method:
>
> SelectModel getEntityModel() {
> // fetch children entities
> // populate SelectModel
> return selectModel;
> }
>
> Therefore, I need to refresh that edit block drop down each time it
>> displays. Since I registered this block with the App Module - I don't
>> explicitly reference it in the actual page displaying the BeanEditForm.
>> Does that make sense? The BeanEditForm is instantiating the edit block
>> behind the scenes.
>>
>
> You're right. You don't need to use a lifecycle event to refresh the Select
> component because the model is requested everytime it (Select) is rendered.
>
> So, I separated them - so I literally have a getModel and a getEncoder.
>> Now, if I can't depend on events with this app block - I could put the query
>> in one of these two - and I can see one hit before the other - but is that
>> order guaranteed?
>>
>
> Your encoder shouldn't depend on a pre-fetched list. Just fetch the encoded
> object in your encoder.
>
> On that note, pageAttached is currently firing in my EditBlock.java class.
>>
>
> It is expected. Your page is activated when BeanEditForm gets a component
> from it.
>
> Were you implying (in an early post) that I should depend on that in all
>> cases?
>>
>
> I don't even know what you mean here, but the answer is no. :)
> That I'm just lucky here? I didn't quite understand this comment:
>
> since literally, void pageAttached() is declared and implemented in the
>> BlockEdit.java - and not literally the page. "declared it inside a page"
>> confuses me.
>>
>
> BlockEdit is a page that is not used as a regular page. Regular pages are
> requested though HTTP. BlockEdit is used just to declare blocks.
>
> Again: stop understanding lifecycle events in BlockEdit for a while and try
> to learn them on regular pages and components.
>
>
> --
> 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
>
>
