Re: Getting article aid (giving or not givingpubid) via the title

In article <mailman.290.1063103277.9998.xaraya_knowledge-base-n5IRV0TL0hwRxVAL8JNkPw@public.gmane.org>, Xaraya Knowledge Base <[email protected]> wrote:
>...
>SQLXML is very interesting and simple to use. It transforms SQL results
>(from queries of every type stored in a template) in valid XML, and is
>executed/returned via a normal HTTP call with parameters.
>In the future a more standard SOAP interface will be interesting, but I
>don't know it very well.
>The complete system runs very well, and it's very stable.
>...
>In every case, thanks for your reply.
>If you are interested in SQLXML, Sablotron etc, here I am: feel free to
>contact me, even at my personal email
>[email protected]

Could be interesting to put it in the repository, at least in the tests/
directory, until someone can pick it up and turn it into a new generic
access method for Xaraya :-)

If it's not too much trouble, could you create a feature request at
bugs.xaraya.com, with an attachment containing the code + some
basic docs ?

>> 2) about retrieving an article by title
>>
>> I'm not sure why you could have the title available but not the aid.
>> After all, even with syndication, you can retrieve the aid from the
>> URL if necessary.
>
>This is the point. XML results came from another data source, completely
>decoupled.
>If I have to interface, for example, a product name
>("PIPPO PC SERVER")
>with an article, how to connect the name ("PIPPO PC SERVER") with an AID?
>My hope:
>1) with the title (+pubid)
>Your response:
>2) with a search
>
>Another problem is about a simple help module that I want to develop.
>In a Xaraya user function call I always have the follwing variables:
>Module
>Function
>(other vars)
>If I want to build a generic article Hook capable of retrieving an article
>(Topic Help) for every Xaraya function, I have to join articles using these
>variables. No AID. ;-)
>...
The search function exists, which is why I recommended it as a first
approach. Now if there is a valid case for retrieving an article by exactly
matching a specific field (and both you & Jason seem to say there is),
then we can easily add that as part of the standard articles API as well.

Any preferences regarding input parameters & output formats ? Please
put them in a feature request too, so we can keep track of it :-)

Mike.