Re: Select does not submit form on change
Em Tue, 08 Dec 2009 22:33:40 -0200, Vangel V. Ajanovski
escreveu:
But, the bad thing is that here Thiago's solution does not help - with
it I get an Event.observe is not a function
And now it does not work even in IE.
This is a Prototype function, documented here:
http://www.prototypejs.org/api/event/observe. If Prototype wasn't added
automatically by some Tapestry component, you can easily add it by
annotating your page class or component with
@IncludeJavaScriptLibrary("${tapestry.scriptaculous}/prototype.js").
--
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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Select does not submit form on change
I removed the submit button and it works indeed. Thank you for the answer. -- View this message in context: http://old.nabble.com/Select-does-not-submit-form-on-change-tp26687467p26703632.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Select does not submit form on change
On 09.12.2009 01:33, Vangel V. Ajanovski wrote: > > But, the bad thing is that here Thiago's solution does not help - with > it I get an > Event.observe is not a function > And now it does not work even in IE. > > Now I am replying to myself ;) Of course it doesn't work - prototype is not automatically bundled with such a simple page - will have to do that manually. smime.p7s Description: S/MIME Cryptographic Signature
Re: Select does not submit form on change
Sorry, but there might be some problem with the mailing list, my message was considered as a SPAM and first the text was removed from the message, and the next time I got info that it was considered as SPAM. I am sending the message again. On 08.12.2009 02:47, Mite wrote: > I have written this code so far: > > > labelField="literal:courseId" onChange="form.submit();"/> > > > This issue is not really a problem of Tapestry, this is a Javascript browser implementation problem. In my code sample this works in IE 8, and it does not work in Firefox 3.6 or Opera 10 Take the submit button out, and it will work with no problem. So, What exactly happens in for example Firefox is that when you add a Submit button, the Submit() function is overriden with the Submit button and it becomes a property. Now the form.submit is not the function for submitting any more, but in fact now it is the submit button itself. I think that I never ever had a need to use a button and a list for submitting at the same time, so I never saw this as a problem. But, the bad thing is that here Thiago's solution does not help - with it I get an Event.observe is not a function And now it does not work even in IE. smime.p7s Description: S/MIME Cryptographic Signature
Re: Select does not submit form on change
smime.p7s Description: S/MIME Cryptographic Signature
Re: t5 handling events by components, event handling sequence
Why don't you want to pass the page's context to the tab component? Isn't the
content of the tabs dependent on the value of the page's context?
On 09/12/2009, at 4:46 AM, kamiseq wrote:
> ok one more thing, my tabs are working great but let examine such a usecase
>
> 1)I have user page with a grid of a user list
> 2)when user is selected I rerender the page with context specified by grid
> element
> 3)my url then is something like myapp/user/1 and the tab control is
> displayed with 3 tabs (for example)
> 4)when I click a tab event is triggered to component and then it redirects
> back to the page to rerender its context and here where the problem occurs
> cos the link is incorrect and the initial selection is lost
>
> I figured out something like in tab component
>
> @Inject
> private PageRenderLinkSource pagerender;
> @Inject
> private ComponentResources resources;
>
> @OnEvent(component = "tabSelect")
> Object onTabActivated(String panelId) {
>this.activeTabInfo = new TabInfo(panelId);
> *return
> pagerender.createPageRenderLinkWithContext(this.resources.getPage().getClass(),
> ??);*
> }
>
> and if I replace "??" with the initial context value (let say "1" everything
> works fine - the question is where to get the initial page's context from.
>
> maybe I can aquire it as well from ComponentResources as it seams that
> framework knows about it
> [INFO] AppModule.TimingFilter Request time: 3 ms
> 127.0.0.1 - - [08/gru/2009:17:15:06 +]
> "GET*/myapp/user/index.tabnavigation.tabselect/tabVersions HTTP/1.1"
> *302 0 *"http://localhost:8080/myapp/user/1";
> ..
> *127.0.0.1 - - [08/gru/2009:17:15:06 +]* "GET /myapp/user
> HTTP/1.1"*200 1954
> * "http://localhost:8080/myapp/user/1"*
>
> the page's Long onPasivate() doesn't help so I am a bit stuck here, and I
> dont want to pass page's context value to tab component
>
> pozdrawiam
> Paweł Kamiński
>
> kami...@gmail.com
> pkaminski@gmail.com
> __
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Best practice for initializing page to default context
Yes, I agree with that Norman. That's sort of what I implied when I said that I "always link to pages with initial context already set" - i.e. the reverse works better - re-initialize the page if a specific context is set. That's one way, what Howard suggests is another (identify page internal links) and third is to differentiate between an event and a render request. And of course, you can get it done by setting various semi-persistent (flash etc). flags etc. Kalle On Tue, Dec 8, 2009 at 11:43 AM, Norman Franke wrote: > I implemented a somewhat similar approach for search using an even more > basic approach. Most of my search fields are @Persisted, but I still needed > a way to know when to reset the search dialog. I ended up creating a new > context parameter, consisting of the string "reset". Every time I wanted to > create a blank search page, I'd send the reset parameter which would set all > of the @Persist-ed properties to null. (Using the context parameter to the > pagelink, one could even make that a custom component: NewSearch or > something.) Otherwise, it would use the values as-is. This allowed someone > to click on a result to get more details, but then come back with everything > as it was. Rather simple, but effective in my case. > > Norman Franke > Answering Service for Directors, Inc. > www.myasd.com > > > > On Dec 8, 2009, at 1:59 PM, Howard Lewis Ship wrote: > >> I've had to solve this problem for one of my clients as well and I >> think it's something that should go into the framework. The approach >> I took was to identify self-referential links (page render links that >> are to the same page they originate from) using an additional query >> parameter. This allows Tapestry to differentiate between requests that >> start on a new page vs. those that continue on the page. Tapestry can >> then fire a notification on components to perform initialization (on >> page render requests without the query parameter). >> >> This would be a new lifecycle method, like pageAttached() or >> pageLoaded(). I'm still working on the right terminology, for Widen >> it is "initialized", as in method pageInitialized(). >> >> On Mon, Dec 7, 2009 at 10:22 PM, Kalle Korhonen >> wrote: >>> >>> Most things in T5 are delightfully simple, but I find this >>> surprisingly difficult: how to best initialize a page to default >>> context (and redirect to it). Imagine you have a search & result page. >>> If I access the page without any context I want all records to be >>> displayed. In onActivate() without parameters I set the context to >>> *all* and return this to redirect, then I query the database in >>> setupRender() to initialize the data for the grid. However, sorting >>> the grid will also cause a call to onActivate() without parameters, >>> resetting my data to the default context. The parameter-less call to >>> onActivate() would be harmless if I didn't do a redirect from >>> onActivate() but then I cannot set the default context and redirect. >>> In setupRender() I could decide whether redirect is needed or not but >>> at that time, I'm already committed to rendering the request. >>> >>> Because events cause a parameterless onActivate() call, I tend to >>> reserve onActivate() for possible component/event initialization needs >>> only and always link to pages with initial context already set. I also >>> find it roughly impossible to use overloaded versions of onActivate() >>> and subsequently, if my page has multiple entry points, I typically >>> resort to implementing it in a single onActivate(EventContext >>> eventContext) operation containing a big if-else clause. Since the >>> activation context is anyway sent with an event request (as in >>> ?t:ac=mycontext), rather than using the encoded context for rendering, >>> wouldn't it be just simpler if that context was used for activating >>> the page for the event request and the following redirect for >>> rendering would just use whatever context onPassivate() returns? What >>> do others think, how do you handle this? >>> >>> Kalle >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >>> >> >> >> >> -- >> Howard M. Lewis Ship >> >> Creator of Apache Tapestry >> >> The source for Tapestry training, mentoring and support. Contact me to >> learn how I can get you up and productive in Tapestry fast! >> >> (971) 678-5210 >> http://howardlewisship.com >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> > > - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Lock contention in PerthreadManagerImpl
I've put some comments into the issue itself. On Tue, Dec 8, 2009 at 1:48 PM, Massimo Lusetti wrote: > On Tue, Dec 8, 2009 at 4:03 PM, Howard Lewis Ship wrote: > >> Unfortunately, ThreadLocal.get()/remove() was buggy and not thread >> safe in JDK 1.5. > > Do you actually mean 'is' not 'was' ? > > Couldn't this be (re)written without using syncronized blocks? > -- > Massimo > http://meridio.blogspot.com > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Lock contention in PerthreadManagerImpl
On Tue, Dec 8, 2009 at 4:03 PM, Howard Lewis Ship wrote: > Unfortunately, ThreadLocal.get()/remove() was buggy and not thread > safe in JDK 1.5. Do you actually mean 'is' not 'was' ? Couldn't this be (re)written without using syncronized blocks? -- Massimo http://meridio.blogspot.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Exception accessing T5 Registry from other servlet
On Mon, Dec 7, 2009 at 5:58 PM, Howard Lewis Ship wrote: > > I've been planning to add a simpler alternative to > SessionStateObjects, an annotation that simply says "store this value > in the session with this explicit key", to make coordinating a T5 app > with a legacy app simpler. > It's already there ;) http://tapestry.formos.com/nightly/tapestry5/apidocs/org/apache/tapestry5/annotations/SessionAttribute.html -- Best regards, Igor Drobiazko http://tapestry5.de/blog
Re: Best practice for initializing page to default context
I implemented a somewhat similar approach for search using an even more basic approach. Most of my search fields are @Persisted, but I still needed a way to know when to reset the search dialog. I ended up creating a new context parameter, consisting of the string "reset". Every time I wanted to create a blank search page, I'd send the reset parameter which would set all of the @Persist-ed properties to null. (Using the context parameter to the pagelink, one could even make that a custom component: NewSearch or something.) Otherwise, it would use the values as-is. This allowed someone to click on a result to get more details, but then come back with everything as it was. Rather simple, but effective in my case. Norman Franke Answering Service for Directors, Inc. www.myasd.com On Dec 8, 2009, at 1:59 PM, Howard Lewis Ship wrote: I've had to solve this problem for one of my clients as well and I think it's something that should go into the framework. The approach I took was to identify self-referential links (page render links that are to the same page they originate from) using an additional query parameter. This allows Tapestry to differentiate between requests that start on a new page vs. those that continue on the page. Tapestry can then fire a notification on components to perform initialization (on page render requests without the query parameter). This would be a new lifecycle method, like pageAttached() or pageLoaded(). I'm still working on the right terminology, for Widen it is "initialized", as in method pageInitialized(). On Mon, Dec 7, 2009 at 10:22 PM, Kalle Korhonen wrote: Most things in T5 are delightfully simple, but I find this surprisingly difficult: how to best initialize a page to default context (and redirect to it). Imagine you have a search & result page. If I access the page without any context I want all records to be displayed. In onActivate() without parameters I set the context to *all* and return this to redirect, then I query the database in setupRender() to initialize the data for the grid. However, sorting the grid will also cause a call to onActivate() without parameters, resetting my data to the default context. The parameter-less call to onActivate() would be harmless if I didn't do a redirect from onActivate() but then I cannot set the default context and redirect. In setupRender() I could decide whether redirect is needed or not but at that time, I'm already committed to rendering the request. Because events cause a parameterless onActivate() call, I tend to reserve onActivate() for possible component/event initialization needs only and always link to pages with initial context already set. I also find it roughly impossible to use overloaded versions of onActivate() and subsequently, if my page has multiple entry points, I typically resort to implementing it in a single onActivate(EventContext eventContext) operation containing a big if-else clause. Since the activation context is anyway sent with an event request (as in ?t:ac=mycontext), rather than using the encoded context for rendering, wouldn't it be just simpler if that context was used for activating the page for the event request and the following redirect for rendering would just use whatever context onPassivate() returns? What do others think, how do you handle this? Kalle - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Best practice for initializing page to default context
On Tue, Dec 8, 2009 at 10:59 AM, Howard Lewis Ship wrote: > I've had to solve this problem for one of my clients as well and I > think it's something that should go into the framework. The approach > I took was to identify self-referential links (page render links that > are to the same page they originate from) using an additional query > parameter. This allows Tapestry to differentiate between requests that > start on a new page vs. those that continue on the page. Tapestry can > then fire a notification on components to perform initialization (on > page render requests without the query parameter). > This would be a new lifecycle method, like pageAttached() or > pageLoaded(). I'm still working on the right terminology, for Widen > it is "initialized", as in method pageInitialized(). Thank you Howard, that would excellent. Until it's in the framework, obviously you can get it done one way or another but framework support would make things easier and more consistent. I'd hate to come up with something that is half-there as an optional module if you are already working on solving it at the core framework level. Sounds like there's no issue open on it (?) - if not, I'll open one. Kalle > On Mon, Dec 7, 2009 at 10:22 PM, Kalle Korhonen > wrote: >> Most things in T5 are delightfully simple, but I find this >> surprisingly difficult: how to best initialize a page to default >> context (and redirect to it). Imagine you have a search & result page. >> If I access the page without any context I want all records to be >> displayed. In onActivate() without parameters I set the context to >> *all* and return this to redirect, then I query the database in >> setupRender() to initialize the data for the grid. However, sorting >> the grid will also cause a call to onActivate() without parameters, >> resetting my data to the default context. The parameter-less call to >> onActivate() would be harmless if I didn't do a redirect from >> onActivate() but then I cannot set the default context and redirect. >> In setupRender() I could decide whether redirect is needed or not but >> at that time, I'm already committed to rendering the request. >> >> Because events cause a parameterless onActivate() call, I tend to >> reserve onActivate() for possible component/event initialization needs >> only and always link to pages with initial context already set. I also >> find it roughly impossible to use overloaded versions of onActivate() >> and subsequently, if my page has multiple entry points, I typically >> resort to implementing it in a single onActivate(EventContext >> eventContext) operation containing a big if-else clause. Since the >> activation context is anyway sent with an event request (as in >> ?t:ac=mycontext), rather than using the encoded context for rendering, >> wouldn't it be just simpler if that context was used for activating >> the page for the event request and the following redirect for >> rendering would just use whatever context onPassivate() returns? What >> do others think, how do you handle this? >> >> Kalle >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Best practice for initializing page to default context
I've had to solve this problem for one of my clients as well and I think it's something that should go into the framework. The approach I took was to identify self-referential links (page render links that are to the same page they originate from) using an additional query parameter. This allows Tapestry to differentiate between requests that start on a new page vs. those that continue on the page. Tapestry can then fire a notification on components to perform initialization (on page render requests without the query parameter). This would be a new lifecycle method, like pageAttached() or pageLoaded(). I'm still working on the right terminology, for Widen it is "initialized", as in method pageInitialized(). On Mon, Dec 7, 2009 at 10:22 PM, Kalle Korhonen wrote: > Most things in T5 are delightfully simple, but I find this > surprisingly difficult: how to best initialize a page to default > context (and redirect to it). Imagine you have a search & result page. > If I access the page without any context I want all records to be > displayed. In onActivate() without parameters I set the context to > *all* and return this to redirect, then I query the database in > setupRender() to initialize the data for the grid. However, sorting > the grid will also cause a call to onActivate() without parameters, > resetting my data to the default context. The parameter-less call to > onActivate() would be harmless if I didn't do a redirect from > onActivate() but then I cannot set the default context and redirect. > In setupRender() I could decide whether redirect is needed or not but > at that time, I'm already committed to rendering the request. > > Because events cause a parameterless onActivate() call, I tend to > reserve onActivate() for possible component/event initialization needs > only and always link to pages with initial context already set. I also > find it roughly impossible to use overloaded versions of onActivate() > and subsequently, if my page has multiple entry points, I typically > resort to implementing it in a single onActivate(EventContext > eventContext) operation containing a big if-else clause. Since the > activation context is anyway sent with an event request (as in > ?t:ac=mycontext), rather than using the encoded context for rendering, > wouldn't it be just simpler if that context was used for activating > the page for the event request and the following redirect for > rendering would just use whatever context onPassivate() returns? What > do others think, how do you handle this? > > Kalle > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Best practice for initializing page to default context
Em Tue, 08 Dec 2009 16:23:37 -0200, ningdh escreveu: Hi, Thiago Hi! What Kalle and I concern is the onActivate must come first before onPassivate, so if page A links to page B, A must set the context of B first, right? In this case, onActivate() is not invoked, so A must invoke one or more methods in the B instance that set the fields that contain B's context. The activate event is only triggered when a page instance is attached to an incoming request. That's why onActivate() in A isn't invoked before onPassivate(). If B has multiple param, I can't think of a good way in general onActivate way. In this scenario (one page redirects to other), onActivate() isn't invoked automatically by Tapestry. Of course, B can invoke it explicitly. And of course we can use createPageLink method with context, but the problem of onActivate is that params must be in strict order. We must be careful on the order and make sure everything goes well. There was a very interesting discussion about using name/values pairs in the activation context some time ago: http://old.nabble.com/T5%3A-Passing-named-structured-type-params-in-URLs--to23453229s302.html#a23453229 Some different approachs are described. -- 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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Best practice for initializing page to default context
Hi, Thiago - Original Message - From: "Thiago H. de Paula Figueiredo" To: "Tapestry users" Sent: Wednesday, December 09, 2009 2:09 AM Subject: Re: Best practice for initializing page to default context > Em Tue, 08 Dec 2009 15:49:15 -0200, Kalle Korhonen > escreveu: > >> DH's approach looks interesting, but maybe a bit involving with field >> names encoded to the url. Thiago, I know it's the recommended approach >> but I'm just saying it doesn't strike me as the ideal approach. > > The ideal solution always depends on the specific problem and, of course, > depends on the taste of the developer. :) > >> That sounds like "I don't understand and don't want to hear about it" > > Please read what I wrote, not what you think I was thinking. ;) > >> - why bother responding if that's the case? Now I'm not sure if it's >> worth my time to write more details or sample code to describe what I >> mean if you are not interested in explaining or exploring how to do it >> better. > > I answered that, AFAIK, Tapestry always use onPassivate() when rendering > an URL for a given page. You said that it wasn't always the case. I wanted > to explore your problem, but I couldn't understand your description of it. > What Kalle and I concern is the onActivate must come first before onPassivate, so if page A links to page B, A must set the context of B first, right? If B has multiple param, I can't think of a good way in general onActivate way. And of course we can use createPageLink method with context, but the problem of onActivate is that params must be in strict order. We must be careful on the order and make sure everything goes well. Too hard for me. > -- > 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-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
Re: Best practice for initializing page to default context
On Tue, Dec 8, 2009 at 10:02 AM, ningdh wrote:
> I can't think of a better way not to involve the field name encoded.
Yes, I understand why you did it.
> And if you don't like the field name exposed, you can also customize the
> param name by setting the annotation value, such as
> @PageActivationUnit("cat")
Oh, that's cool, didn't read your source that carefully... thanks for
that btw. I need to ponder about this a bit - I'd like to find a good,
generic pattern to follow.
Kalle
> - Original Message -
> From: "Kalle Korhonen"
> To: "Tapestry users"
> Sent: Wednesday, December 09, 2009 1:49 AM
> Subject: Re: Best practice for initializing page to default context
>
>
>> On Tue, Dec 8, 2009 at 3:39 AM, Thiago H. de Paula Figueiredo
>> wrote:
>>> Em Tue, 08 Dec 2009 04:22:58 -0200, Kalle Korhonen
>>> escreveu:
and subsequently, if my page has multiple entry points, I typically
resort to implementing it in a single onActivate(EventContext
eventContext) operation containing a big if-else clause.
>>> That's the recommended way when you have a variable number of activation
>>> context parameters.
>>
>> DH's approach looks interesting, but maybe a bit involving with field
>> names encoded to the url. Thiago, I know it's the recommended approach
>> but I'm just saying it doesn't strike me as the ideal approach.
>>
Since the activation context is anyway sent with an event request (as in
?t:ac=mycontext), rather than using the encoded context for rendering,
wouldn't it be just simpler if that context was used for activating
the page for the event request and the following redirect for
rendering would just use whatever context onPassivate() returns?
>>> The activation context is always what onPassivate() returns. I don't
>>> understand what is the problem here.
>>
>> That sounds like "I don't understand and don't want to hear about it"
>> - why bother responding if that's the case? Now I'm not sure if it's
>> worth my time to write more details or sample code to describe what I
>> mean if you are not interested in explaining or exploring how to do it
>> better.
>>
>> Kalle
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Best practice for initializing page to default context
Em Tue, 08 Dec 2009 15:49:15 -0200, Kalle Korhonen escreveu: DH's approach looks interesting, but maybe a bit involving with field names encoded to the url. Thiago, I know it's the recommended approach but I'm just saying it doesn't strike me as the ideal approach. The ideal solution always depends on the specific problem and, of course, depends on the taste of the developer. :) That sounds like "I don't understand and don't want to hear about it" Please read what I wrote, not what you think I was thinking. ;) - why bother responding if that's the case? Now I'm not sure if it's worth my time to write more details or sample code to describe what I mean if you are not interested in explaining or exploring how to do it better. I answered that, AFAIK, Tapestry always use onPassivate() when rendering an URL for a given page. You said that it wasn't always the case. I wanted to explore your problem, but I couldn't understand your description of it. -- 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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Best practice for initializing page to default context
I can't think of a better way not to involve the field name encoded.
And if you don't like the field name exposed, you can also customize the param
name by setting the annotation value, such as
@PageActivationUnit("cat")
private Category category;
Then the url is like /searchpage/cat-VALUE
I like this style a lot and use heavily in my multiple projects.
DH
- Original Message -
From: "Kalle Korhonen"
To: "Tapestry users"
Sent: Wednesday, December 09, 2009 1:49 AM
Subject: Re: Best practice for initializing page to default context
> On Tue, Dec 8, 2009 at 3:39 AM, Thiago H. de Paula Figueiredo
> wrote:
>> Em Tue, 08 Dec 2009 04:22:58 -0200, Kalle Korhonen
>> escreveu:
>>> and subsequently, if my page has multiple entry points, I typically
>>> resort to implementing it in a single onActivate(EventContext
>>> eventContext) operation containing a big if-else clause.
>> That's the recommended way when you have a variable number of activation
>> context parameters.
>
> DH's approach looks interesting, but maybe a bit involving with field
> names encoded to the url. Thiago, I know it's the recommended approach
> but I'm just saying it doesn't strike me as the ideal approach.
>
>>> Since the activation context is anyway sent with an event request (as in
>>> ?t:ac=mycontext), rather than using the encoded context for rendering,
>>> wouldn't it be just simpler if that context was used for activating
>>> the page for the event request and the following redirect for
>>> rendering would just use whatever context onPassivate() returns?
>> The activation context is always what onPassivate() returns. I don't
>> understand what is the problem here.
>
> That sounds like "I don't understand and don't want to hear about it"
> - why bother responding if that's the case? Now I'm not sure if it's
> worth my time to write more details or sample code to describe what I
> mean if you are not interested in explaining or exploring how to do it
> better.
>
> Kalle
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
Re: Best practice for initializing page to default context
On Tue, Dec 8, 2009 at 3:39 AM, Thiago H. de Paula Figueiredo wrote: > Em Tue, 08 Dec 2009 04:22:58 -0200, Kalle Korhonen > escreveu: >> and subsequently, if my page has multiple entry points, I typically >> resort to implementing it in a single onActivate(EventContext >> eventContext) operation containing a big if-else clause. > That's the recommended way when you have a variable number of activation > context parameters. DH's approach looks interesting, but maybe a bit involving with field names encoded to the url. Thiago, I know it's the recommended approach but I'm just saying it doesn't strike me as the ideal approach. >> Since the activation context is anyway sent with an event request (as in >> ?t:ac=mycontext), rather than using the encoded context for rendering, >> wouldn't it be just simpler if that context was used for activating >> the page for the event request and the following redirect for >> rendering would just use whatever context onPassivate() returns? > The activation context is always what onPassivate() returns. I don't > understand what is the problem here. That sounds like "I don't understand and don't want to hear about it" - why bother responding if that's the case? Now I'm not sure if it's worth my time to write more details or sample code to describe what I mean if you are not interested in explaining or exploring how to do it better. Kalle - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: t5 handling events by components, event handling sequence
ok one more thing, my tabs are working great but let examine such a usecase
1)I have user page with a grid of a user list
2)when user is selected I rerender the page with context specified by grid
element
3)my url then is something like myapp/user/1 and the tab control is
displayed with 3 tabs (for example)
4)when I click a tab event is triggered to component and then it redirects
back to the page to rerender its context and here where the problem occurs
cos the link is incorrect and the initial selection is lost
I figured out something like in tab component
@Inject
private PageRenderLinkSource pagerender;
@Inject
private ComponentResources resources;
@OnEvent(component = "tabSelect")
Object onTabActivated(String panelId) {
this.activeTabInfo = new TabInfo(panelId);
*return
pagerender.createPageRenderLinkWithContext(this.resources.getPage().getClass(),
??);*
}
and if I replace "??" with the initial context value (let say "1" everything
works fine - the question is where to get the initial page's context from.
maybe I can aquire it as well from ComponentResources as it seams that
framework knows about it
[INFO] AppModule.TimingFilter Request time: 3 ms
127.0.0.1 - - [08/gru/2009:17:15:06 +]
"GET*/myapp/user/index.tabnavigation.tabselect/tabVersions HTTP/1.1"
*302 0 *"http://localhost:8080/myapp/user/1";
..
*127.0.0.1 - - [08/gru/2009:17:15:06 +]* "GET /myapp/user
HTTP/1.1"*200 1954
* "http://localhost:8080/myapp/user/1"*
the page's Long onPasivate() doesn't help so I am a bit stuck here, and I
dont want to pass page's context value to tab component
pozdrawiam
Paweł Kamiński
kami...@gmail.com
pkaminski@gmail.com
__
Re: Select does not submit form on change
At last. This way works. This is the second time you get me out of the mud. :) Thank you -- View this message in context: http://old.nabble.com/Select-does-not-submit-form-on-change-tp26687467p26697258.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Select does not submit form on change
I will be more specific then.
What you need to do is:
- Use Firefox and Firebug (or some other request monitoring tool) to see
what happens when you select something in your select. Is any event trigered
in the browser. Is something sent to the server?
- Check on the server side if the page class is at all contacted. Set a
breakpoint in your onActivate method or something similar.
On Tue, Dec 8, 2009 at 12:18 PM, Mite wrote:
>
> No, I just have the function:
>
> void onSubmit() {
>System.out.println("Value changed!");
> }
>
> labelField="literal:courseId" onChange="this.form.submit();"/>
>
> which prints to console when a submit is made, but it does not print
> anything when I change the value.
>
>
> Are you using some debug tool to verify if a request is sent to the server?
> Like firebug in firefox? Are you getting a javascript error when you select
> something?
>
>
> --
> View this message in context:
> http://old.nabble.com/Select-does-not-submit-form-on-change-tp26687467p26692303.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
Re: Lock contention in PerthreadManagerImpl
On Tue, Dec 8, 2009 at 5:08 AM, Olle Hallin wrote:
> Hi!
>
> We are load testing our new high volume site before soft launch, and we have
> noticed that we have two sources of severe lock contention.
> Of 300 threads, in average 165 are waiting for one of these two locks.
>
> One is in ZipFile (caused by �...@incudejavascriptlibrary("classpath:..."))
> and
> the other is in
> org.apache.tapestry5.ioc.internal.services.PerthreadManagerImpl
>
> The ZipFile bottleneck is harmless, since we will use a CDN in production.
> The second one is harder to work-around, since it is caused by
> RequestGlobals.storeServletRequestResponse().
>
> I have browsed PerthreadManagerImpl.java, and have found two cases where a
> lock on "this" is requested.
>
> In both cases the lock is requested before accessing a ThreadLocal
> (ThreadLocal.get() and ThreadLocal.remove()).
> Since ThreadLocal is thread-safe, external locking is uneeded.
>
Unfortunately, ThreadLocal.get()/remove() was buggy and not thread
safe in JDK 1.5.
> Shall I file a JIRA issue, or have I missed something?
>
> We use T5 5.1.0.5
>
> Olle Hallin
> Senior Java Developer and Architect
> olle.hal...@crisp.se
> www.crisp.se
> http://www.linkedin.com/in/ollehallin
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Best practice for initializing page to default context
Of course, but since I am not very good at javassit, my implementation may be
ugly and a bit long. Anyone please consummate it.
Like PageActivationContext, I introduce an PageActivationUnitWorker.
The key part is to collect the param fields and add the param map to page class
in runtime. onActivate and onPassivate would use this map to set value or
retrieve value.
1. For annotation:
@Target(FIELD)
@Documented
@Retention(RUNTIME)
public @interface PageActivationUnit {
String value() default "";
}
2. For worker:
public class PageActivationUnitWorker implements ComponentClassTransformWorker {
private TypeCoercer _typeCoercer;
public PageActivationUnitWorker(TypeCoercer typeCoercer) {
this._typeCoercer = typeCoercer;
}
public void transform(ClassTransformation transformation,
MutableComponentModel model) {
List fieldNames =
transformation.findFieldsWithAnnotation(PageActivationUnit.class);
if (fieldNames != null && fieldNames.size() > 0) {
Map fieldParamMap = new HashMap();
for (String fieldName : fieldNames) {
PageActivationUnit annotation = transformation.getFieldAnnotation(fieldName,
PageActivationUnit.class);
fieldParamMap.put(fieldName, getParameterName(fieldName,
annotation.value()));
}
String typeCoercer = transformation.addInjectedField(TypeCoercer.class,
"typeCoercer", _typeCoercer);
TransformMethodSignature activate
= new TransformMethodSignature(Modifier.PROTECTED | Modifier.FINAL,
"boolean",
"onActivate",
new String[]
{EventContext.class.getName()}, null);
TransformMethodSignature passivate
= new TransformMethodSignature(Modifier.PROTECTED |
Modifier.FINAL, "java.lang.Object[]",
"onPassivate",
null, null);
BodyBuilder activeBuilder = new BodyBuilder().begin();
activeBuilder.addln("java.util.Map keyValueMap = new java.util.HashMap();");
activeBuilder.add("for (int i = 0; i < $1.getCount(); i++)");
activeBuilder.begin();
activeBuilder.addln("String []keyValue = ((String)$1.get(String.class,
i)).split(\"-\");");
activeBuilder.addln("String key = keyValue[0];");
activeBuilder.addln("String value = (keyValue.length > 1) ? keyValue[1] :
null;");
activeBuilder.addln("keyValueMap.put(key, value);");
activeBuilder.end();
// end for
for (int i = 0, size = fieldNames.size(); i < size; i++) {
String fieldName = fieldNames.get(i);
String fieldType = transformation.getFieldType(fieldName);
activeBuilder.addln("String fieldValue=(String)keyValueMap.get(\"%s\");",
fieldParamMap.get(fieldName));
activeBuilder.addln("if (fieldValue != null) {");
activeBuilder.addln("%s=(%s)%s.coerce(fieldValue, Class.forName(\"%s\"));",
fieldName, fieldType, typeCoercer, fieldType);
activeBuilder.addln("}");
}
activeBuilder.addln("return true;");
// end method body
activeBuilder.end();
BodyBuilder deactiveBuilder = new BodyBuilder().begin();
for (int i = 0, size = fieldNames.size(); i < size; i++) {
String fieldName = fieldNames.get(i);
if (i == size - 1) {
deactiveBuilder.add("\"%s-\" + (%s != null ? (String)%s.coerce(%s,
String.class) : \"\")", fieldParamMap.get(fieldName), fieldName, typeCoercer,
fieldName);
} else {
deactiveBuilder.add("\"%s-\" + (%s != null ? (String)%s.coerce(%s,
String.class) : \"\"),", fieldParamMap.get(fieldName), fieldName, typeCoercer,
fieldName);
}
}
deactiveBuilder.end();
transformation.addTransformedMethod(activate, activeBuilder.toString());
transformation.addTransformedMethod(passivate, "return new Object[]" +
deactiveBuilder.toString() + ";");
}
}
private String getParameterName(String fieldName, String annotatedName)
{
if (InternalUtils.isNonBlank(annotatedName)) return annotatedName;
return InternalUtils.stripMemberName(fieldName);
}
}
3. In app module
public static void contributeComponentClassTransformWorker(
OrderedConfiguration configuration,
TypeCoercer typeCoercer) {
configuration.add("PageActivationUnit", new
PageActivationUnitWorker(typeCoercer), "before:OnEvent");
}
That's all.
One disadvantage is that you can't use primitive type for param field, so use
Integer instead of int.
DH
http://www.gaonline.com.cn
- Original Message -
From: "Inge Solvoll"
To: "Tapestry users"
Sent: Tuesday, December 08, 2009 4:14 PM
Subject: Re: Best practice for initializing page to default context
> Would it be possible for you to share that code with us? I don't necessarily
> want to use that approach, but it would be very helpful to see how you
> implemented it.
>
> Inge
>
> On Tue, Dec 8, 2009 at 9:10 AM, DH wrote:
>
>> Once I found it difficult too, and I never used EventContext because I
>> think it is not better than multiple on
Re: Lock contention in PerthreadManagerImpl
JIRA https://issues.apache.org/jira/browse/TAP5-945 created Olle Hallin Senior Java Developer and Architect olle.hal...@crisp.se www.crisp.se http://www.linkedin.com/in/ollehallin 2009/12/8 Thiago H. de Paula Figueiredo > Em Tue, 08 Dec 2009 11:08:38 -0200, Olle Hallin > escreveu: > > Hi! >> > > Hi! > > > Shall I file a JIRA issue, or have I missed something? >> > > I'm no expert at concurrency, but please post it so the committers with the > required knowledge can take a look at it. ;) > > -- > 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-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
Re: Lock contention in PerthreadManagerImpl
Em Tue, 08 Dec 2009 11:08:38 -0200, Olle Hallin escreveu: Hi! Hi! Shall I file a JIRA issue, or have I missed something? I'm no expert at concurrency, but please post it so the committers with the required knowledge can take a look at it. ;) -- 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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Lock contention in PerthreadManagerImpl
Hi!
We are load testing our new high volume site before soft launch, and we have
noticed that we have two sources of severe lock contention.
Of 300 threads, in average 165 are waiting for one of these two locks.
One is in ZipFile (caused by @IncudeJavaScriptLibrary("classpath:...")) and
the other is in
org.apache.tapestry5.ioc.internal.services.PerthreadManagerImpl
The ZipFile bottleneck is harmless, since we will use a CDN in production.
The second one is harder to work-around, since it is caused by
RequestGlobals.storeServletRequestResponse().
I have browsed PerthreadManagerImpl.java, and have found two cases where a
lock on "this" is requested.
In both cases the lock is requested before accessing a ThreadLocal
(ThreadLocal.get() and ThreadLocal.remove()).
Since ThreadLocal is thread-safe, external locking is uneeded.
Shall I file a JIRA issue, or have I missed something?
We use T5 5.1.0.5
Olle Hallin
Senior Java Developer and Architect
olle.hal...@crisp.se
www.crisp.se
http://www.linkedin.com/in/ollehallin
Re: t5 handling events by components, event handling sequence
yep I am just after huge argument with my firend about tapestry and wishes vs reality :) now I understand and it makes some sense although I try to avoid @persist as much as possible and the main problem here is to define how user must use the page and interact with it and what if session expires / he/she redirects to another page and comes back to the first one. I need to think about those at first place thanks for help pozdrawiam Paweł Kamiński kami...@gmail.com pkaminski@gmail.com __
Re: page name generating
Em Tue, 08 Dec 2009 08:40:34 -0200, Jan Jirout escreveu: Hi, Hi! I think that both problems are related to "name stripping", but I don't know how to add new rules to this process. It seems to me, that "URL rewriting" doesn't help at all. URL rewriting is definitely the best solution to both your problems. Using it, you have total control about your URLs. The "I woud like to use page names as ArticlePage and UserPage but in tml file use refference to them as 'user' and 'article'" could be solved by decorating or advising the ComponentSource and changing the parameter of the getPage() method. I suggest you to not do that, as one of the beauties of Tapestry is exactly that the page class, the template and how you reference the page are all the same. -- 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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Best practice for initializing page to default context
Em Tue, 08 Dec 2009 04:22:58 -0200, Kalle Korhonen escreveu: and subsequently, if my page has multiple entry points, I typically resort to implementing it in a single onActivate(EventContext eventContext) operation containing a big if-else clause. That's the recommended way when you have a variable number of activation context parameters. Since the activation context is anyway sent with an event request (as in ?t:ac=mycontext), rather than using the encoded context for rendering, wouldn't it be just simpler if that context was used for activating the page for the event request and the following redirect for rendering would just use whatever context onPassivate() returns? The activation context is always what onPassivate() returns. I don't understand what is the problem here. -- 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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: t5 handling events by components, event handling sequence
Em Mon, 07 Dec 2009 21:38:17 -0200, kamiseq escreveu:
hi,
Hi!
I ve wrote simple component that renders link and handles event
triggered by
the link then it sets some value and should render that value.
the problem is that I get the value but then the value is lost as
tapestry redirects to a page that holds the component
why is so and how can design my component to fix that. Of course I can
annotate the value field as @Persist-ent but I really would like to avoid
session as much as possible.
You cannot avoid the session in this case, as Tapestry uses
redirect-after-post. You can use @Persist("flash"): the value will be
removed from the session after it is read the first time.
--
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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Select does not submit form on change
Em Tue, 08 Dec 2009 09:18:59 -0200, Mite escreveu:
No, I just have the function:
void onSubmit() {
System.out.println("Value changed!");
}
Try using onSuccess() instead of onSubmit().
By the way, instead of relying on onchange="", use Prototype events:
Event.observe('select', 'change', function() { $('form').submit(); } );
--
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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Select does not submit form on change
No, I just have the function:
void onSubmit() {
System.out.println("Value changed!");
}
which prints to console when a submit is made, but it does not print
anything when I change the value.
Are you using some debug tool to verify if a request is sent to the server?
Like firebug in firefox? Are you getting a javascript error when you select
something?
--
View this message in context:
http://old.nabble.com/Select-does-not-submit-form-on-change-tp26687467p26692303.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Select does not submit form on change
You're not giving us very much information to work with here... Are you using some debug tool to verify if a request is sent to the server? Like firebug in firefox? Are you getting a javascript error when you select something? On Tue, Dec 8, 2009 at 11:58 AM, Mite wrote: > > Thank you for the reply. > It does not make any difference. Still the same result. > > This is really bad. Trying to get to work an event on a select for a whole > day. > It is so much easier with .NET or only JavaScript and HTML. > > > > Try > > this.form.submit() > > -- > View this message in context: > http://old.nabble.com/Select-does-not-submit-form-on-change-tp26687467p26692063.html > Sent from the Tapestry - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
RE: Select does not submit form on change
The only way I got this to work was via Javascript called from the select to do the submit. -Original Message- From: Mite [mailto:mitemeis...@gmail.com] Sent: 08 December 2009 10:58 To: users@tapestry.apache.org Subject: Re: Select does not submit form on change Thank you for the reply. It does not make any difference. Still the same result. This is really bad. Trying to get to work an event on a select for a whole day. It is so much easier with .NET or only JavaScript and HTML. Try this.form.submit() -- View this message in context: http://old.nabble.com/Select-does-not-submit-form-on-change-tp26687467p2 6692063.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Select does not submit form on change
Thank you for the reply. It does not make any difference. Still the same result. This is really bad. Trying to get to work an event on a select for a whole day. It is so much easier with .NET or only JavaScript and HTML. Try this.form.submit() -- View this message in context: http://old.nabble.com/Select-does-not-submit-form-on-change-tp26687467p26692063.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
page name generating
Hi, I have two probably related problems. 1) I have business object Article and User and also I have package com.myapp.pages. Inside this package are placed pages Article and User. Both of them works and contains with business object Article and User. It lead to state when I have to fully specify business object package name. I woud like to use page names as ArticlePage and UserPage but in tml file use refference to them as "user" and "article" 2) I have page class files like createNewUser.java and template createNewUser.tml. When I access this page URL is "createnewnser" but I would like to see URL "create-new-user". I think that both problems are related to "name stripping", but I don't know how to add new rules to this process. It seems to me, that "URL rewriting" doesn't help at all. thanks for help Jan - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Cross field validation in a component
Hello * I have a component DateSelector which must be in a form. DateSelector contains 3 Select components. My question is, how can I perform cross-field validation in DateSelector? As far as I see, there is no event which the component gets which I can use to perform this task. DateSelector gets the 3 VALIDATE events from the 3 embedded Select components but what I need is an event which will be sent to DateSelector after the 3 VALIDATE events, because not till then the 3 values from the 3 embedded Select components are set. So, what I need in my component is a kind of VALIDATE_FORM and also a SUCCESS event (in order to set the resulting value from the 3 values). Does anybody know, how a component can get those kind of events? Thanks Klaus -- View this message in context: http://old.nabble.com/Cross-field-validation-in-a-component-tp26690823p26690823.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: t5 handling events by components, event handling sequence
Ok, but how can I command the component to render actionLink as a link to the page that contains the component or how could I redirect from component to the page in generic way(Could I pass any reference of the page as component's parameter? and then use public method on that page?)? any way to intercept the component event?? the big trouble is that component logic is processed first and then tapestry redirect and renders the page, it should bubble from component to page without redirecting. pozdrawiam Paweł Kamiński kami...@gmail.com pkaminski@gmail.com __
Re: Best practice for initializing page to default context
Of course, but since I am not very good at javassit, my implementation may be
ugly and a bit long. Anyone please consummate it.
Like PageActivationContext, I introduce an PageActivationUnitWorker.
The key part is to collect the param fields and add the param map to page class
in runtime. onActivate and onPassivate would use this map to set value or
retrieve value.
1. For annotation:
@Target(FIELD)
@Documented
@Retention(RUNTIME)
public @interface PageActivationUnit {
String value() default "";
}
2. For worker:
public class PageActivationUnitWorker implements ComponentClassTransformWorker {
private TypeCoercer _typeCoercer;
public PageActivationUnitWorker(TypeCoercer typeCoercer) {
this._typeCoercer = typeCoercer;
}
public void transform(ClassTransformation transformation,
MutableComponentModel model) {
List fieldNames =
transformation.findFieldsWithAnnotation(PageActivationUnit.class);
if (fieldNames != null && fieldNames.size() > 0) {
Map fieldParamMap = new HashMap();
for (String fieldName : fieldNames) {
PageActivationUnit annotation = transformation.getFieldAnnotation(fieldName,
PageActivationUnit.class);
fieldParamMap.put(fieldName, getParameterName(fieldName,
annotation.value()));
}
String typeCoercer = transformation.addInjectedField(TypeCoercer.class,
"typeCoercer", _typeCoercer);
TransformMethodSignature activate
= new TransformMethodSignature(Modifier.PROTECTED | Modifier.FINAL,
"boolean",
"onActivate",
new String[]
{EventContext.class.getName()}, null);
TransformMethodSignature passivate
= new TransformMethodSignature(Modifier.PROTECTED |
Modifier.FINAL, "java.lang.Object[]",
"onPassivate",
null, null);
BodyBuilder activeBuilder = new BodyBuilder().begin();
activeBuilder.addln("java.util.Map keyValueMap = new java.util.HashMap();");
activeBuilder.add("for (int i = 0; i < $1.getCount(); i++)");
activeBuilder.begin();
activeBuilder.addln("String []keyValue = ((String)$1.get(String.class,
i)).split(\"-\");");
activeBuilder.addln("String key = keyValue[0];");
activeBuilder.addln("String value = (keyValue.length > 1) ? keyValue[1] :
null;");
activeBuilder.addln("keyValueMap.put(key, value);");
activeBuilder.end();
// end for
for (int i = 0, size = fieldNames.size(); i < size; i++) {
String fieldName = fieldNames.get(i);
String fieldType = transformation.getFieldType(fieldName);
activeBuilder.addln("String fieldValue=(String)keyValueMap.get(\"%s\");",
fieldParamMap.get(fieldName));
activeBuilder.addln("if (fieldValue != null) {");
activeBuilder.addln("%s=(%s)%s.coerce(fieldValue, Class.forName(\"%s\"));",
fieldName, fieldType, typeCoercer, fieldType);
activeBuilder.addln("}");
}
activeBuilder.addln("return true;");
// end method body
activeBuilder.end();
BodyBuilder deactiveBuilder = new BodyBuilder().begin();
for (int i = 0, size = fieldNames.size(); i < size; i++) {
String fieldName = fieldNames.get(i);
if (i == size - 1) {
deactiveBuilder.add("\"%s-\" + (%s != null ? (String)%s.coerce(%s,
String.class) : \"\")", fieldParamMap.get(fieldName), fieldName, typeCoercer,
fieldName);
} else {
deactiveBuilder.add("\"%s-\" + (%s != null ? (String)%s.coerce(%s,
String.class) : \"\"),", fieldParamMap.get(fieldName), fieldName, typeCoercer,
fieldName);
}
}
deactiveBuilder.end();
transformation.addTransformedMethod(activate, activeBuilder.toString());
transformation.addTransformedMethod(passivate, "return new Object[]" +
deactiveBuilder.toString() + ";");
}
}
private String getParameterName(String fieldName, String annotatedName)
{
if (InternalUtils.isNonBlank(annotatedName)) return annotatedName;
return InternalUtils.stripMemberName(fieldName);
}
}
3. In app module
public static void contributeComponentClassTransformWorker(
OrderedConfiguration configuration,
TypeCoercer typeCoercer) {
configuration.add("PageActivationUnit", new
PageActivationUnitWorker(typeCoercer), "before:OnEvent");
}
That's all.
One disadvantage is that you can't use primitive type for param field, so use
Integer instead of int.
DH
http://www.gaonline.com.cn
- Original Message -
From: "Inge Solvoll"
To: "Tapestry users"
Sent: Tuesday, December 08, 2009 4:14 PM
Subject: Re: Best practice for initializing page to default context
> Would it be possible for you to share that code with us? I don't necessarily
> want to use that approach, but it would be very helpful to see how you
> implemented it.
>
> Inge
>
> On Tue, Dec 8, 2009 at 9:10 AM, DH wrote:
>
>> Once I found it difficult too, and I never used EventContext because I
>> think it is not better than multiple on
Re: Best practice for initializing page to default context
Would it be possible for you to share that code with us? I don't necessarily want to use that approach, but it would be very helpful to see how you implemented it. Inge On Tue, Dec 8, 2009 at 9:10 AM, DH wrote: > Once I found it difficult too, and I never used EventContext because I > think it is not better than multiple onActivate. > > Finally I wrote my own PageActivationContext called PageActivationUnit, the > difference is that PageActivationContext only can occur once, but > PageActivationUnit can be used in multiple fields. > > For example, a product search page, it has params like > category,keyword,pagesize,pageno,brand and so on. If using > PageActivationUnit, the java would be like: > > @PageActivationUnit > private Category category; > > @PageActivationUnit > private String keyword; > > @PageActivationUnit > private Integer pagesize; > > @PageActivationUnit > private Integer pageNo; > > @PageActivationUnit > private Brand brand; > > PageActivationUnit will handle all the activate and passivate event for me, > and the url requested would be like > '/searchpage/category-value/keyword-value/pagesize-10/pageNo-2/brand-value'. > Yes, I encode the field name in the url and its value in a pair. > Another advantage is if later another param 'orderBy' is added, I don't > have to change any code at all. > > DH > http://www.gaonline.com.cn > > - Original Message - > From: "Kalle Korhonen" > To: "Tapestry users" > Sent: Tuesday, December 08, 2009 2:22 PM > Subject: Best practice for initializing page to default context > > > > Most things in T5 are delightfully simple, but I find this > > surprisingly difficult: how to best initialize a page to default > > context (and redirect to it). Imagine you have a search & result page. > > If I access the page without any context I want all records to be > > displayed. In onActivate() without parameters I set the context to > > *all* and return this to redirect, then I query the database in > > setupRender() to initialize the data for the grid. However, sorting > > the grid will also cause a call to onActivate() without parameters, > > resetting my data to the default context. The parameter-less call to > > onActivate() would be harmless if I didn't do a redirect from > > onActivate() but then I cannot set the default context and redirect. > > In setupRender() I could decide whether redirect is needed or not but > > at that time, I'm already committed to rendering the request. > > > > Because events cause a parameterless onActivate() call, I tend to > > reserve onActivate() for possible component/event initialization needs > > only and always link to pages with initial context already set. I also > > find it roughly impossible to use overloaded versions of onActivate() > > and subsequently, if my page has multiple entry points, I typically > > resort to implementing it in a single onActivate(EventContext > > eventContext) operation containing a big if-else clause. Since the > > activation context is anyway sent with an event request (as in > > ?t:ac=mycontext), rather than using the encoded context for rendering, > > wouldn't it be just simpler if that context was used for activating > > the page for the event request and the following redirect for > > rendering would just use whatever context onPassivate() returns? What > > do others think, how do you handle this? > > > > Kalle > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > For additional commands, e-mail: users-h...@tapestry.apache.org > > > > >
Re: Best practice for initializing page to default context
Once I found it difficult too, and I never used EventContext because I think it is not better than multiple onActivate. Finally I wrote my own PageActivationContext called PageActivationUnit, the difference is that PageActivationContext only can occur once, but PageActivationUnit can be used in multiple fields. For example, a product search page, it has params like category,keyword,pagesize,pageno,brand and so on. If using PageActivationUnit, the java would be like: @PageActivationUnit private Category category; @PageActivationUnit private String keyword; @PageActivationUnit private Integer pagesize; @PageActivationUnit private Integer pageNo; @PageActivationUnit private Brand brand; PageActivationUnit will handle all the activate and passivate event for me, and the url requested would be like '/searchpage/category-value/keyword-value/pagesize-10/pageNo-2/brand-value'. Yes, I encode the field name in the url and its value in a pair. Another advantage is if later another param 'orderBy' is added, I don't have to change any code at all. DH http://www.gaonline.com.cn - Original Message - From: "Kalle Korhonen" To: "Tapestry users" Sent: Tuesday, December 08, 2009 2:22 PM Subject: Best practice for initializing page to default context > Most things in T5 are delightfully simple, but I find this > surprisingly difficult: how to best initialize a page to default > context (and redirect to it). Imagine you have a search & result page. > If I access the page without any context I want all records to be > displayed. In onActivate() without parameters I set the context to > *all* and return this to redirect, then I query the database in > setupRender() to initialize the data for the grid. However, sorting > the grid will also cause a call to onActivate() without parameters, > resetting my data to the default context. The parameter-less call to > onActivate() would be harmless if I didn't do a redirect from > onActivate() but then I cannot set the default context and redirect. > In setupRender() I could decide whether redirect is needed or not but > at that time, I'm already committed to rendering the request. > > Because events cause a parameterless onActivate() call, I tend to > reserve onActivate() for possible component/event initialization needs > only and always link to pages with initial context already set. I also > find it roughly impossible to use overloaded versions of onActivate() > and subsequently, if my page has multiple entry points, I typically > resort to implementing it in a single onActivate(EventContext > eventContext) operation containing a big if-else clause. Since the > activation context is anyway sent with an event request (as in > ?t:ac=mycontext), rather than using the encoded context for rendering, > wouldn't it be just simpler if that context was used for activating > the page for the event request and the following redirect for > rendering would just use whatever context onPassivate() returns? What > do others think, how do you handle this? > > Kalle > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
