<div dir="ltr">Hello Vikas,<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 15, 2018 at 11:13 AM, Vikas Mahato <span dir="ltr"><<a href="mailto:vikasmahato0@gmail.com" target="_blank">vikasmahato0@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Hi all,<br><br></div>I looked into how to make UNO components for calc and referred to Solver.idl and XSolver.idl in  offapi module for more understanding.<br><br></div>I am thinking of moving the existing implementation of dataproviders and datatransformations (located at sc/source/ui/dataproviders) to two UNO components.<br></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>Please don't. The internal ones are the canonical data providers and I would like to keep them as it is much easier to design APIs and debug general problems through internal API code. The UNO API will allow extensions to add additional data providers and data transformations. In the end you will notice that you will map some of the UNO API code to internal code anyway and your internal code will help you shape the API.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><br></div>This would mean creating 4 new files in offapi/com/sun/star/sheet namely <br><br>ExternalDataProvider.idl<br></div>XExternalDataProvider.idl<br></div>DataTransformations.idl<br></div>XDataTransformations.idl<br></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>That sounds about right.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div><br></div>ExternalDataProvider will host the following methods:<br></div>1. void Import()<br></div>2. OUString& GetURL()<br><font size="2">3. <span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap" id="m_5365546525660892206gmail-docs-internal-guid-b8f9775a-630f-406e-c110-e496a7b6ed54">map<OUString, OUString> getDataSourcesForURL(const OUString& rURL)</span><br>4. <span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap" id="m_5365546525660892206gmail-docs-internal-guid-2e0ef070-630f-c0a8-210a-b8466178345f">unique_ptr<SvStream> FetchStreamFromURL(const OUString&, OStringBuffer& rBuffer)</span></font></div></div></div></div></div></div></blockquote><div><br></div><div><br></div><div>Note that in UNO API we can not use most of the C++ classes. unique_ptr needs no equivalent anyway as all UNO API objects are reference counted (uno::Reference, rtl::Reference). Finding a good replacement for map<OUString, OUString> will be more challenging and might require using something along the lines of uno::Sequence<some string pair type>.</div><div><br></div><div>I'm not sure if we need the Import function in the API. Keep in mind that the importing is completely handled by the internal code and should not be started by an extension. I suppose it will be enough for the actual uno object implementation to have an object which provides all the necessary methods.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><br><br><br></div>DataTransformation will host all the methods defined in datatransformation.hxx<br><br></div>I want to convert the existing implementations to UNO so that external application developers can make use of the functionality as well. <br></div></div></div></div></blockquote><div><br></div><div>As mentioned, we should have the UNO API as layer on top of the internal API. At least in Calc (and Charts) we have made bad experiences in the past with pure UNO API features.</div><div><br></div><div>Regards,</div><div>Markus<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><br></div>Looking for suggestions and feedback.<br><br></div>Kind Regards,<br></div>Vikas Mahato<br></div>
<br>______________________________<wbr>_________________<br>
LibreOffice mailing list<br>
<a href="mailto:LibreOffice@lists.freedesktop.org">LibreOffice@lists.freedesktop.<wbr>org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/libreoffice" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/libreoffice</a><br>
<br></blockquote></div><br></div></div>