Re: PAGE Lifecycle vs COMPONENT render cycle
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
Re: PAGE Lifecycle vs COMPONENT render cycle
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
Re: PAGE Lifecycle vs COMPONENT render cycle
Your encoder shouldn't depend on a pre-fetched list. Just fetch the encoded object in your encoder. ... my encoder implements this method: public T toValue(String clientValue) So in my case, the encoder needs data from the database. I've spent cpu cycles in getModel() to pull a list of items. It seems like I should leverage that list when I hydrate the object back from it's screen representation to an actual object ... no? I guess - I could inject a dao or connection to the database into the ValueEncoder - but on first glance, that seems like overkill ... but - maybe I just need to get comfortable with it. Iv'e got the list right there. It can't have changed eh? To sum up, the main issue here is that the object I'm 'toValue'ing exists in the dbase (and in the model). The Wiki example for GenericSelectModel queries the database two times but I think it is redundant to do so. But again, if thats what the framework wants me to do - I'll work with it. I just needed to explore every option here to make sure I wasn't missing some BlockEdit event ... it seems natural when components and pages have events eh? But as natrual as I might intuit it, I do realize from your conversation that Blocks just aren't made or implemented that way. 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. My confusion here stems from my understanding that the edit block is NOT a page and you' ve mentioned a few times Your page is activatated ... and the event fires. I understand that event fires - but shouldn't it be handled by the PAGE and not the Edit Block? When a page includes a component - does the component suddenly handle that page's events? Likewise, I'm confused how the edit block (which is not a page or a component) is getting the pageAttached event. I understand it is a page event - I just don't understand why the Edit Block is handling it. Does it fire in the Page.java as well? Is there a diagram or somethign to see this? 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. Remember here, my goal right now is not to understand events per se but to get my custom select drop down working ... and it is indeed getting void pageAttached -- so that is why I must proceed down understanding lifecycle events for BlockEdit. Learning about events for pages and components is fine - but I need to know exactly how that applies to my current issue with the Edit Block. That is what I am practicing :) Thanks again, -Luther
Re: PAGE Lifecycle vs COMPONENT render cycle
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
Re: PAGE Lifecycle vs COMPONENT render cycle
Em Wed, 04 Mar 2009 16:50:21 -0300, Luther Baker lutherba...@gmail.com escreveu: ... my encoder implements this method: public T toValue(String clientValue) So in my case, the encoder needs data from the database. I've spent cpu cycles in getModel() to pull a list of items. It seems like I should leverage that list when I hydrate the object back from it's screen representation to an actual object ... no? No. toValue() is only invoked when the form is submitted. The list loading happens in another request. It is not a good idea to keep the list on memory bacause each user session would have an enormous size. By the way, you can use Hibernate cache features to deal with that instead of implementing it yourself. I guess - I could inject a dao or connection to the database into the ValueEncoder - but on first glance, that seems like overkill ... It is not. Service injection is very cheap. And tapestry-hibernate already provides a ValueEncoder for each entity class. I just need to get comfortable with it. Iv'e got the list right there. It can't have changed eh? You're doing (bad, IMHO) premature optimization, and it is the root of all evil. (I just love this quote :)). To sum up, the main issue here is that the object I'm 'toValue'ing exists in the dbase (and in the model). The Wiki example for GenericSelectModel queries the database two times but I think it is redundant to do so. Again: each ValueEncoder method is invoked in different requests and it's not a good idea to put object lists in memory (session). But again, if thats what the framework wants me to do - I'll work with it. The framework does not tell you what to do: it just encourages you to follow some proven paths, but you can choose to not follow 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
Re: PAGE Lifecycle vs COMPONENT render cycle
By the way, you can use Hibernate cache features to deal with that instead of implementing it yourself. Ahh ... I knew this ... but it is something I need to read up on. Again: each ValueEncoder method is invoked in different requests and it's not a good idea to put object lists in memory (session). Ok - I saw them both (model and encoder) retrieved at page load but I missed its invocation on submit. This approach makes sense to me then. You're doing (bad, IMHO) premature optimization, and it is the root of all evil. (I just love this quote :)). Ohhh . well thanks for the warning! There are some obvious baddies I try to avoid right away and this looked like double work - but I need to get my head around hibernate caching a bit more. The framework does not tell you what to do: it just encourages you to follow some proven paths, but you can choose to not follow them. Thanks for helping illuminate the path. Thanks, -Luther On Wed, Mar 4, 2009 at 2:00 PM, Thiago H. de Paula Figueiredo thiag...@gmail.com wrote: Em Wed, 04 Mar 2009 16:50:21 -0300, Luther Baker lutherba...@gmail.com escreveu: ... my encoder implements this method: public T toValue(String clientValue) So in my case, the encoder needs data from the database. I've spent cpu cycles in getModel() to pull a list of items. It seems like I should leverage that list when I hydrate the object back from it's screen representation to an actual object ... no? No. toValue() is only invoked when the form is submitted. The list loading happens in another request. It is not a good idea to keep the list on memory bacause each user session would have an enormous size. By the way, you can use Hibernate cache features to deal with that instead of implementing it yourself. I guess - I could inject a dao or connection to the database into the ValueEncoder - but on first glance, that seems like overkill ... It is not. Service injection is very cheap. And tapestry-hibernate already provides a ValueEncoder for each entity class. I just need to get comfortable with it. Iv'e got the list right there. It can't have changed eh? You're doing (bad, IMHO) premature optimization, and it is the root of all evil. (I just love this quote :)). To sum up, the main issue here is that the object I'm 'toValue'ing exists in the dbase (and in the model). The Wiki example for GenericSelectModel queries the database two times but I think it is redundant to do so. Again: each ValueEncoder method is invoked in different requests and it's not a good idea to put object lists in memory (session). But again, if thats what the framework wants me to do - I'll work with it. The framework does not tell you what to do: it just encourages you to follow some proven paths, but you can choose to not follow 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
PAGE Lifecycle vs COMPONENT render cycle
I created an edit block - and wired up a GenericSelectModel. All is well and fine. I populate that select model with a query from the database - so now, I'd like to move that query from getModel or getEncoder to a lifecycle method. 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 but it never gets invoked. I also tried @SetupRender but still, no invocation when I visit the page. I dug around a bit more and found the PAGE lifecycle docs: http://tapestry.apache.org/tapestry5/guide/lifecycle. At the bottom of the page appear three methods and I implemented void pageAttached() and it worked! So here are my questions. Does an edit block act like a page and not a component? And, am I missing something or is a PAGE lifecycle signficantly different than a COMPONENT lifecycle? 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 - but I wasn't ready for none of the COMPONENT lifecycle methods to trip. Am I missing something or am I safe in saying that PAGEs generally have 3 lifecycle hooks and only well-defined COMPONENTS have the setupRender ... etc *render* cycle events. Thanks, -Luther
Re: PAGE Lifecycle vs COMPONENT render cycle
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
Re: PAGE Lifecycle vs COMPONENT render cycle
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
