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. 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. So, in the Java class associated with my edit block, I provide the model, I provide the encoder ... and I want to query for the latest list of enties. The Wiki example implements by the encoder and the model in the GenericSelectModel ... and then provides "values" as the model and encoder. If "getValues" queries the database and provides both the model and the encoder -- it gets invoked 2 times (the t:Select model and encoder parameters). 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? If so - maybe I could compensate by checking a flag in either method and loading the list as necessary - but all that seems like a hack. It seems that my edit block needs a prepare event of some sort, and then the getModel and getEncoder methods are not burdened with also deciding if the data is present. Whoa - hope that wasn't too hard to follow. Please remember, I'm learning more about Tapestry all the time - so please erase all this and set me straight with the 'right' way. I seem to be going down a rabbit hole here if events don't apply to app blocks. On that note, pageAttached is currently firing in my EditBlock.java class. Were you implying (in an early post) that I should depend on that in all cases? That I'm just lucky here? I didn't quite understand this comment: > A block is not a page nor a component. @PageAttached just worked because you declared it inside a page. since literally, void pageAttached() is declared and implemented in the BlockEdit.java - and not literally the page. "declared it inside a page" confuses me. Does that long explanation make sense? I really appreciate all of your time and input. Sorry for the long, belabored windedness :) Thanks, -Luther On Tue, Mar 3, 2009 at 10:42 PM, Luther Baker <lutherba...@gmail.com> wrote: > > Writing blocks for BeanEditForm/BeanEditor is a very confusing place to > learn about them. ;) > > Yes -- necessity *is* the mother of invention :) > > Thanks for the explanation regarding blocks - I'm off to try some > experiments now. > > Thanks again T. > > -Luther > > > > > On Tue, Mar 3, 2009 at 9:15 PM, Thiago H. de Paula Figueiredo < > thiag...@gmail.com> wrote: > >> Em Wed, 04 Mar 2009 00:00:28 -0300, Luther Baker <lutherba...@gmail.com> >> escreveu: >> >> I took a look and found this page on COMPONENT rendering: >>> http://tapestry.apache.org/tapestry5/guide/rendering.html and I tried >>> the >>> literal method >>> void setupRender >>> >> >> In which class have you declared this method? If it was the page where you >> put your edit and view blocks (let's call it BlocksPage), it wouldn't work, >> as BlocksPage is never rendered (never requested), just blocks and >> components declared inside it are. BlocksPage just exists because all >> Tapestry blocks needs to be declared inside some page. >> >> Does an edit block act like a page and not a component? >>> >> >> A block is not a page nor a component. @PageAttached just worked because >> you declared it inside a page. >> >> And, am I missing something or is a PAGE lifecycle signficantly different >>> than a COMPONENT lifecycle? >>> >> >> A page is a component. It has the component lifecycle plus some events of >> its own. >> >> I had read and made the assumptions that PAGEs >>> were actually COMPONENTs themselves and because they are special maybe I >>> could see a PAGE having *additional* lifecycle methods - >>> >> >> This is absolutely correct. >> >> but I wasn't ready for none of the COMPONENT lifecycle methods to trip. >>> >> >> Again: a page used just to provide blocks does not react to component >> lifecycle events because it is not being rendered (it was not requested), >> just one of its blocks. >> >> I strongly suggest you to learn about events in Tapestry using writing >> very normal page (one that really renders HTML) and writing a simple >> component. Writing blocks for BeanEditForm/BeanEditor is a very confusing >> place to learn about them. ;) >> >> -- >> 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 >> >> >
