You know Peter, I think we've gotten away from Struts for the most part here, and I'm not sure we should continue this discussion on this list, probably isn't appropriate... if you aren't already, could you jump on the JWP mailing list and repost this latest message there? This would have the additional benefit of getting in front of the other JWP developers' eyes, and they may have some answers I don't :)
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] On Mon, January 9, 2006 4:03 am, Pilgrim, Peter said: > >> -----Original Message----- >> From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] >> Sent: 06 January 2006 18:49 >> To: Struts Users Mailing List >> Cc: 'Struts Users Mailing List' >> Subject: RE: [OT] JavaWebParts and Struts / Ajax integration >> >> >> On Fri, January 6, 2006 1:27 pm, Pilgrim, Peter said: >> > Me too. I developing on the old Service Pack 1 of WLS. >> Production has >> > the latest SP4 and SP5 better. May be it was me, Eclipse, >> My Eclipse, >> > and combination of all. Either way I rewrite tag library definitions >> > in web.xml and my JSP by hand, just to make sure I wasn't >> going crazy! >> >> Usually its Websphere driving me nuts like that :) >> >> > Actually I forgot to saw that the JSP page itself is >> > `/asds/secured/showContactDetails.jsp' >> > where `/asds' is the context root. >> >> Hmm... the target should match whatever the mapping for the >> servlet is... >> which I *think* is just typeAheadSuggestions... I'll have to try and >> replicate what your seeing because it seems like it should be >> working. >> Does the sample webapp work as-is (after you change the TLD)? > > The sample webapp, both cookbook examples worked in WebLogic > without alteration. I just had to wrap everything in a WAR file > myself and then custom deploy to WebLogic Server using the > administration console. > >> >> > I thought of that before heading home, but I wanted to wait >> for response, >> > because what I would really need is access the `contextRoot' as >> > a variable. I could write something like this >> > >> > <target>%contextPath%/typeAheadSuggestions</target> >> >> Yeah, that definitely won't work. IIRC, *not* having a >> leading slash will >> *almost* in effect do what you want though, calculate it >> relative to the >> location of the requesting resource (which is I think what >> your seeing). >> How about this... change the servlet mapping to >> secure/typeAheadSuggestions. >> > > Yes that will work. But it will only work for pages under `secure/*', > won't it? If you want to use the same servlet under a different > page directory just for the sake of file organisation, then > we are stumped here. > > > So I think you need to modify the ajax part to > either allow keyword token substitution or specify another > target resource beginning with "/" is made context relative. > > >> > ... ( No it does not work) Sorry >> > >> > 127.0.0.1 - auth1 [06/Jan/2006:18:21:41 +0000] "GET >> > /typeAheadSuggestions?enteredText=x&assureUnique=1 >> HTTP/1.1" 404 1214 >> > 127.0.0.1 - auth1 [06/Jan/2006:18:21:44 +0000] "GET >> > /typeAheadSuggestions?enteredText=xa&assureUnique=2 >> HTTP/1.1" 404 1214 >> >> Yeah, that confirms what I said above... you will need to not have the >> leading slash, which will cause it to be calculated relative to the >> requesting resource, so if you change the servlet mapping to match it >> should work. I'm not sure that is the most convenient answer, but it >> looks like things are actually doing what they are supposed to, so it >> might be the right answer. >> >> > The ajax submission is now missing the context path completely. >> > Can you cut a release of the javawebparts to fix the bug or >> tell me where >> > I can patch it please. >> >> Give that a shot first... I don't think this is really a bug >> in AjaxTags, >> although it might be something of an enhancement (i.e., maybe add some >> attribute to the <target> element to tell how you want the URL to be >> calculated: contextRelative, resourceRelative or absolute). >> > > That would be better. Keyword sustitution might be a good thing here. > For example you can do this with these keywords > > (1) > %context% > %hostname% > %port% > %servletPath% > %requestPath% > > Or maybe allow JSF or Spring kind of interface that allows > pluggable variable resolution. E.g provide a default resolver > ``DefaultAjaxPartTargetVariableResolver'' > that does (1) that conforms to ``IAjaxPartTargetVariableResolver'' > interface but allow others to override with a plug in point. > > In some type of initialisation servlet > > AjaxParts.getInstance( request /*HttpServletRequest*/ > ).setTargetVariableResolver( new MyCustomVariableResolver() ) > > >> > How do you discern in the Servlet what field is being query? >> >> Hmm, good one, you got me! That's *definitely* an enhancement >> across-the-board, you *should* get at least the ajaxRef passed in with >> every AJAX request, and at least for the standard handlers I >> can add that. >> >> For now, what I think you can do, although I haven't tried >> it, is add a >> parameter to the target URL. So, in the config file, for >> each element, >> your target might be: >> >> <target>typeAheadSuggestions?field=1</target> >> >> ...and so on. Actually, I have a feeling that won't work... >> I don't think >> the code in the request handler currently is smart enough to see that >> there is already a query string (that's another definite enhancement). >> >> The other alternative is to take the Javascript for the >> request handler >> you are using and create your own custom handler based on it, >> adding the >> capability you need. In most cases, if you can't get what >> you want from >> the standard handlers, that's the right answer. >> >> In this case though, what your asking for is something that >> will probably >> be pretty common, so I'll definitely add that as an enhancement. > > All we simply need is to part the name of the form field as > part of the query string. > > servlet request1 : AjaxParts_type_ahead_field = firstName > servlet request2 : AjaxParts_type_ahead_field = lastName > servlet request3 : AjaxParts_type_ahead_field = department > > Then we could simply retrieve the servlet request parameter > ("AjaxParts_type_ahead_field" ) > > If we can also do the same with the DOM name of the HTML Form element that > would clinch the deal. > > servlet request1 : AjaxParts_type_ahead_form = employeeDetails > > Is there a way specify additional additional query parametes > using the existing custom tags anyway. See my ***** below: > > <html:text property="search.contact.contactName" size="22" maxlength="30" > styleClass="formtext" /><ajax:event > ajaxRef="ContactDetailsForm/enteredTextChange" > ***** paramName1="htmlForm" paramValue1="contactDetailsForm" > ***** paramName2="htmlField" paramValue2="contactName" > /><br><div id="search_contact_contactName_suggestions" style="border:1 > solid #000000;background-color:#f0f0f0;width:206px;" ></div> > > > >> >> > I had a look at the source of the page, there is a JavaScript >> > variable called `debugAjax'. Is there anywhere to switch on or off >> > via the javawebparts custom tags? I looked at <ajax:enable/>, but >> > the tag description says it an empty tag. You might want to allow >> > this feature. >> >> Yes, this was added by the new developer on the project and I already >> mentioned to him it should probably be an option. For now, >> you can simply >> throw this in the <head> of your page: >> >> <script>debugAjax=true;</script> >> >> That should do the trick. >> >> > This is where I pause for the weekend in London. *PAUSE* >> >> Sounds good, let me know how it goes on Monday and I'll help however I >> can. FYI, I am planning on cutting a new release Sunday >> night, so you may >> want to grab that first thing, just in case any of this is >> fixed by that >> (I don't think so, but just in case). >> >> Frank >> > > I downloaded the Beta2. I noticed all the jars are suffixed with the > release version e.g `_beta2'. > > > -- > Peter Pilgrim :: J2EE Software Development > Operations/IT - Credit Suisse First Boston, > Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom > Tel: +44-(0)207-883-4497 > > ============================================================================== > Please access the attached hyperlink for an important electronic > communications disclaimer: > > http://www.csfb.com/legal_terms/disclaimer_external_email.shtml > > ============================================================================== > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
