Hi Shannon, You're right, there is not a way to designate a specific XPath for the title yet. But I will file an RFE on your behalf.
You can modify the generated code. You are right that redeployment overwrites modifications, but here's a hint at a pattern that might be helpful if you want to tinker with customizing the generated code down the road. The generated application is designed so that almost all of the modules that are deployed are static; the only ones that change are /lib/config.xqy and /css/custom.css. Any custom styles that you add under the Appearance tab of the Application Builder are written to /css/custom.css, so it's easy to add custom styles, and of course these persist across redeployments. The key to modifying things you can't get to from the UI is /lib/config.xqy. It contains a bunch of variables that are generated based on selections you've made in the Application Builder interface. For example, $OPTIONS is an options node for the Search API, used on searches. There's and $INTRO-OPTIONS node used with the Search API to generate the browse links on the intro page. And there's one called $TRANSFORMS that has some rendering rules. (I bet if you squint closely at $TRANSFORMS, you can find that rule that applies to your title element and modify the XPath.) There are also a number of function pointers, at the bottom, that point to code blocks used to generate the output XHTML. There's a nice section at the end of the Application Builder Developer's Guide about how to use those to point to custom code in your own library. So if you decide to experiment with customization, you could make local changes to /lib/config.xqy and experiment to your heart's content, putting custom code into your own module in /lib. If you get into a bad state, just back up config.xqy and your custom code, redeploy and you'll be back where you started. The modifications are limited to one file plus your custom module, so it's pretty easy to redeploy, then selectively port the changes you want back into the application. --Colleen Whitney ________________________________________ From: [email protected] [[email protected]] On Behalf Of Shannon [[email protected]] Sent: Thursday, July 02, 2009 7:48 AM To: General Mark Logic Developer Discussion Subject: Re: [MarkLogic Dev General] Search API: Add elements to search:result node MarkLogic Server 4.1 is awesome, especially with Search API and ApplicationBuilder 1.0. I'm using AppBuilder for my next project and will have questions..... Wait--I have one already. It's about adding a New Title Item. Given the following incomplete fragment: <TEI pm:entry="2632" pm:docDesc="Dick West" pm:link-target-type="text" pm:sortkey="WH6408-43-5279 010" pm:url="4002735" pm:title="Transcripts" pm:workflow-stage="PR" pm:published-version="yes" pm:docDate="1964-08-31" pm:guideWord="some confusion about name of caller; discussed in"> <teiHeader> <fileDesc> <titleStmt> <title/> </titleStmt> <publicationStmt> <p/> </publicationStmt> <sourceDesc> <p/> </sourceDesc> </fileDesc> </teiHeader> <text> <body> <div type="transcript"> <bibl type="metadata"> <title>Conversation WH6408-43-5279</title> I would like TEI/text/body/div/bibl/title to be the item, but AppBuilder is only allowing me to select the first (empty) title element in the namespace: [cid:[email protected]] Is it possible to manipulate the program to specify which title element I want exactly? If not, please consider this an RFE. I am guessing I can modify the generated code, but since redeployment overwrites customizations, I will need to postpone the task. Thanks! On Jul 1, 2009, at 7:56 PM, David Amusin wrote: Hi Mattio, I would go with the first approach: "pass the <search:response> node off to another function and iterate through each <search:result>". The expensive part of your code will most likely be calls to the database. Although you are calling fn:doc for each item in the search results (ex: 10 calls to fn:doc if there are 10 search results), you are not doing any additional calls to cts:search, which is typically the most expensive part of your XQuery (search:search uses cts:search under the covers), so your code should not become too much slower. You might take a quick look at a generated application from the Application Builder (for example, the Oscars application) because the generated applications use the technique of calling fn:doc on each of the search results to get per-result-document metadata. David David Amusin Software Engineer Mark Logic Corporation 999 Skyway Road Suite 200 San Carlos, CA 94070 +1 650 207 2308 Cell +1 650 655 2310 Fax [email protected] www.marklogic.com<http://www.marklogic.com> This e-mail and any accompanying attachments are confidential. The information is intended solely for the use of the individual to whom it is addressed. Any review, disclosure, distribution, or use of this e-mail communication by others is strictly prohibited. If you are not the intended recipient, please notify us by returning this message to the sender and delete all copies. Thank you for your cooperation. On 7/1/09 4:17 PM, "Mattio Valentino" <[email protected]> wrote: First, I'd like to say thanks for releasing the Search API with 4.1! I'm hopeful that it can replace some of my existing code that I'm less than satisfied with. One of the first questions I have is about adding elements to <search:result>. When I return an item to the UI, I need to return some metadata as well -- title, author, etc. What's the best way to add this? One approach seemed to be to pass the <search:response> node off to another function and iterate through each <search:result>, but that optioned seemed to mean I'd be processing the same result item twice, once to process the original result and a second time to grab the metadata. A second option was cracking open search-impl.xqy where I was able to add the elements I needed after line 902 (attribute fitness {cts:fitness($result)},), but that option means it's more difficult for me to upgrade when the next release comes out, of course. Is there another option that I've missed? Can anyone recommend an approach? Thanks! Mattio _______________________________________________ General mailing list [email protected] http://xqzone.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected]<mailto:[email protected]> http://xqzone.com/mailman/listinfo/general -- Shannon Scott Shiflett, XML Programmer ROTUNDA, The University of Virginia Press PO Box 801079, Charlottesville, VA 22904-4318 USA Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903 Email: [email protected]<mailto:[email protected]> Tel: +1 434 924 4495 Web: http://rotunda.upress.virginia.edu/ _______________________________________________ General mailing list [email protected] http://xqzone.com/mailman/listinfo/general
