Changeset 13949
- Timestamp:
- 2007-02-27T09:39:17+13:00 (17 years ago)
- Location:
- trunk/gsdl-documentation/manuals/xml-source/es
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/gsdl-documentation/manuals/xml-source/es/Develop_es.xml
r13781 r13949 132 132 <CodeLine>xcopy /s d:\collect\dlpeople\* import</CodeLine> 133 133 <Text id="42">En el directorio <i>etc</i> de la colección hay un archivo denominado <i>collect.cfg</i>. Ãbralo con el editor de texto que prefiera; uno básico pero que es fácil de conseguir se llama <i>edit</i>. El resultado deberÃa parecerse a la Figura <CrossRef target="Figure" ref="collection_configuration_file_created_by_mkcol"/>, que muestra el archivo de configuración de la colección creado mediante el comando <i>perl âS mkcol.pl â[email protected] dlpeople</i>.</Text> 134 <Text id="43">Ahora puede âimportarâ la colección. Se trata del proceso por el que se traen los documentos al sistema Greenstone, normalizando el formato de los documentos, el modo en que se especifican los metadatos y la estructura de los archivos en que se almacenan los documentos. Teclee <i>perl âS import.pl</i> en el indicador para obtener una lista de todas las opciones del programa de importación. Para simplificar, limÃtese al comando básico</Text>134 <Text id="43">Ahora ya está listo para "importar" la colección. Este es el proceso que integra los documentos en el sistema Greenstone, estandarizando el formato de documento, la forma de especificar los metadatos, y la estructura de ficheros en la que se almacenan los documentos. Escriba <i>perl -S import.pl</i> en el indicador para obtener una lista de todas las opciones del programa de importación. La opción -<i>remove old</i> se usa para asegurarse de que primero se borran todos los documentos importados previamente.</Text> 135 135 <CodeLine>perl âS import.pl dlpeople</CodeLine> 136 136 <Text id="44">No se preocupe por el texto que desfila rápidamente en la pantalla: es sólo un informe de la progresión de la importación. Tenga en cuenta que importar esta colección lleva unos cinco minutos en una computadora de 1 GHz y, por consiguiente, más tiempo en máquinas más lentas. Obsérvese que no es necesario encontrarse en los directorios <i>collect</i> o <i>dlpeople</i> cuando se selecciona este comando, porque ya se ha introducido la variable GSDLHOME y el programa Greenstone puede encontrar todos los archivos necesarios.</Text> … … 254 254 <Text id="94">El directorio <i>index</i> de la antigua colección se sustituye tecleando <i>rd /s index</i>, luego <i>ren building index</i> seguido de <i>mkdir building</i>, o utilizando el administrador de archivos gráficos.</Text> 255 255 </th> 256 <th> </th>257 256 <th> 258 257 <Text id="95">El directorio <i>index</i> de la antigua colección se sustituye tecleando <i>rm âr index/</i> * luego <i>mv building/* index</i></Text> … … 1687 1686 <TableContent> 1688 1687 <tr> 1689 <th width="@width"/>1690 <th width="@width"/>1688 <th/> 1689 <th/> 1691 1690 <th> 1692 1691 <Text id="408"><b>Objetivo</b></Text> … … 1717 1716 </tr> 1718 1717 <tr> 1718 <th width="60"/> 1719 1719 <th> 1720 1720 <Text id="416"><i>RecPlug</i></Text> … … 1731 1731 </tr> 1732 1732 <tr> 1733 <th width="60"/> 1733 1734 <th> 1734 1735 <Text id="420"><i>GAPlug</i></Text> … … 1745 1746 </tr> 1746 1747 <tr> 1748 <th width="60"/> 1747 1749 <th> 1748 1750 <Text id="424"><i>TEXTPlug</i></Text> … … 1759 1761 </tr> 1760 1762 <tr> 1763 <th width="60"/> 1761 1764 <th> 1762 1765 <Text id="428"><i>HTMLPlug</i></Text> … … 1773 1776 </tr> 1774 1777 <tr> 1778 <th width="60"/> 1775 1779 <th> 1776 1780 <Text id="432"><i>WordPlug</i></Text> … … 1787 1791 </tr> 1788 1792 <tr> 1793 <th width="60"/> 1789 1794 <th> 1790 1795 <Text id="436"><i>PDFPlug</i></Text> … … 1801 1806 </tr> 1802 1807 <tr> 1808 <th width="60"/> 1803 1809 <th> 1804 1810 <Text id="440"><i>PSPlug</i></Text> … … 1815 1821 </tr> 1816 1822 <tr> 1823 <th width="60"/> 1817 1824 <th> 1818 1825 <Text id="444"><i>EMAILPlug</i></Text> … … 1829 1836 </tr> 1830 1837 <tr> 1838 <th width="60"/> 1831 1839 <th> 1832 1840 <Text id="448"><i>BibTexPlug</i></Text> … … 1843 1851 </tr> 1844 1852 <tr> 1853 <th width="60"/> 1845 1854 <th> 1846 1855 <Text id="452"><i>ReferPlug</i></Text> … … 1857 1866 </tr> 1858 1867 <tr> 1868 <th width="60"/> 1859 1869 <th> 1860 1870 <Text id="456"><i>SRCPlug</i></Text> … … 1871 1881 </tr> 1872 1882 <tr> 1883 <th width="60"/> 1873 1884 <th> 1874 1885 <Text id="460"><i>ImagePlug</i></Text> … … 1885 1896 </tr> 1886 1897 <tr> 1898 <th width="60"/> 1887 1899 <th> 1888 1900 <Text id="464"><i>SplitPlug</i></Text> … … 1899 1911 </tr> 1900 1912 <tr> 1913 <th width="60"/> 1901 1914 <th> 1902 1915 <Text id="468"><i>FOXPlug</i></Text> … … 1913 1926 </tr> 1914 1927 <tr> 1928 <th width="60"/> 1915 1929 <th> 1916 1930 <Text id="472"><i>ZIPPlug</i></Text> … … 1944 1958 </tr> 1945 1959 <tr> 1960 <th width="60"/> 1946 1961 <th> 1947 1962 <Text id="481"><i>GBPlug</i></Text> … … 1958 1973 </tr> 1959 1974 <tr> 1975 <th width="60"/> 1960 1976 <th> 1961 1977 <Text id="485"><i>TCCPlug</i></Text> … … 2188 2204 <Figure id="xml_format"> 2189 2205 <Title> 2190 <Text id="546">Formato XML: </Text>2206 <Text id="546">Formato XML: (a) Definición de Tipo de Documento (DTD); (b) Ejemplo de archivo de metadatos</Text> 2191 2207 <SubTitle> 2192 <Text id="547"> a) Definición de Tipo de Documento (DTD);</Text>2208 <Text id="547">(a)</Text> 2193 2209 </SubTitle> 2194 2210 </Title> … … 2207 2223 <Text id="548"/> 2208 2224 <SubTitle> 2209 <Text id="549"> b) Ejemplo de archivo de metadatos</Text>2225 <Text id="549">(b)</Text> 2210 2226 </SubTitle> 2211 2227 </Title> … … 2291 2307 <File width="605" height="280" url="images/Dev_Fig_12.png"/> 2292 2308 </Figure> 2293 <Text id="569">Un clasificador más simple, llamado <i>List</i>, que se muestra en la Figura <CrossRef target="Figure" ref="list_classifier"/>, crea una lista clasificada de un elemento de metadato determinado y lo presenta sin ninguna subsección alfabética . Un ejemplo es el metadato <i>cómo</i> de la colección de demostración, que es generado por la lÃnea <i>classify List âmetadata Howto</i> en el archivo de configuración de la colección. Otro clasificador general es <i>DateList</i>, ilustrado en la Figura <CrossRef target="Figure" ref="datelist_classifier"/>, que genera una lista de selección de intervalos de fechas. (El clasificador <i>DateList</i> se utiliza también en la colección âArchivos de Greenstoneâ.)</Text>2309 <Text id="569">Un clasificador más simple, llamado <i>List</i>, que se muestra en la Figura <CrossRef target="Figure" ref="list_classifier"/>, crea una lista clasificada de un elemento de metadato determinado y lo presenta sin ninguna subsección alfabética<FootnoteRef id="3"/>. Un ejemplo es el metadato <i>cómo</i> de la colección de demostración, que es generado por la lÃnea <i>classify List âmetadata Howto</i> en el archivo de configuración de la colección. Otro clasificador general es <i>DateList</i>, ilustrado en la Figura <CrossRef target="Figure" ref="datelist_classifier"/>, que genera una lista de selección de intervalos de fechas. (El clasificador <i>DateList</i> se utiliza también en la colección âArchivos de Greenstoneâ.)</Text> 2294 2310 <Figure id="datelist_classifier"> 2295 2311 <Title> … … 2313 2329 <TableContent> 2314 2330 <tr> 2331 <th width="132"/> 2315 2332 <th> 2316 2333 <Text id="576"><b>Argumento</b></Text> … … 2324 2341 <Text id="578"><i>Hierarchy</i></Text> 2325 2342 </th> 2343 <th width="92"/> 2326 2344 <th> 2327 2345 <Text id="579">Clasificación jerárquica</Text> … … 2364 2382 <Text id="588">List</Text> 2365 2383 </th> 2384 <th width="92"/> 2366 2385 <th> 2367 2386 <Text id="589">Lista alfabética de los documentos</Text> … … 2388 2407 <Text id="594"><i>SectionList</i></Text> 2389 2408 </th> 2409 <th width="92"/> 2390 2410 <th> 2391 2411 <Text id="595">Lista de las secciones en los documentos</Text> … … 2396 2416 <Text id="596"><i>AZList</i></Text> 2397 2417 </th> 2418 <th width="92"/> 2398 2419 <th> 2399 2420 <Text id="597">Lista de documentos dividida por intervalos alfabéticos</Text> … … 2420 2441 <Text id="602"><i>AZSectionList</i></Text> 2421 2442 </th> 2443 <th width="92"/> 2422 2444 <th> 2423 2445 <Text id="603">Como <i>AZList</i> pero incluye cada sección del documento</Text> … … 2428 2450 <Text id="604"><i>DateList</i></Text> 2429 2451 </th> 2452 <th width="92"/> 2430 2453 <th> 2431 2454 <Text id="605">Similar a <i>AZList</i> pero ordenada por fechas</Text> … … 2660 2683 <Text id="664">Después de la palabra clave <i>format</i> hay otra palabra clave en dos partes, de las que sólo una es obligatoria. La primera parte identifica la lista a la que se aplica el formato. La lista que se obtiene mediante una búsqueda se llama <i>Search</i> (búsqueda), mientras que las listas generadas por clasificadores se denominan <i>CL1, CL2, CL3</i>, etc., para el primer, segundo, tercer, etc., clasificador especificado en el archivo <i>collect.cfg</i>. La segunda parte de la palabra clave se refiere a la porción de la lista a la que se aplica el formateo, esto es, <i>Hlist</i> (para una lista horizontal, como el selector A-Z en un nodo <i>AZList</i>), <i>Vlist</i> (para una lista vertical, como la lista de tÃtulos en un nodo <i>AZList</i>) o <i>DateList</i>. Por ejemplo:</Text> 2661 2684 <Indented> 2662 <Text id="665"><i>format CL4Vlist ...</i>              Âse aplica a todos los VLists de CL4</Text>2685 <Text id="665"><i>format CL4Vlist ...</i> se aplica a todos los VLists de CL4</Text> 2663 2686 </Indented> 2664 2687 <Indented> 2665 <Text id="666"><i>format CL2Hlist ...</i>              Âse aplica a todos los HListsde CL2</Text>2688 <Text id="666"><i>format CL2Hlist ...</i> se aplica a todos los HListsde CL2</Text> 2666 2689 </Indented> 2667 2690 <Indented> 2668 <Text id="667"><i>format CL1DateList ...</i>       Âse aplica a todos los DateListsde CL1</Text>2691 <Text id="667"><i>format CL1DateList ...</i> se aplica a todos los DateListsde CL1</Text> 2669 2692 </Indented> 2670 2693 <Indented> 2671 <Text id="668"><i>format SearchVList ...</i>        Âse aplica a la lista de resultados de búsqueda</Text>2694 <Text id="668"><i>format SearchVList ...</i> se aplica a la lista de resultados de búsqueda</Text> 2672 2695 </Indented> 2673 2696 <Indented> 2674 <Text id="669"><i>format CL3 ...</i>                      Âse aplica a todos los nodos de CL3, a menos que se especifique lo contrario</Text>2697 <Text id="669"><i>format CL3 ...</i> se aplica a todos los nodos de CL3, a menos que se especifique lo contrario</Text> 2675 2698 </Indented> 2676 2699 <Indented> 2677 <Text id="670"><i>format Vlist ...</i>                     Âse aplica a todos los Vlistsde todos los clasificadores, a menos que se especifique lo contrario</Text>2700 <Text id="670"><i>format Vlist ...</i> se aplica a todos los Vlistsde todos los clasificadores, a menos que se especifique lo contrario</Text> 2678 2701 </Indented> 2679 2702 <Text id="671">En los ejemplos de la figura 16, las comillas (â...â) representan las especificaciones de formato HTML que controlan la información y su presentación, tal como aparecen en las páginas Web que muestran el clasificador. Al igual que las especificaciones HTML, cualquier metadato puede aparecer entre corchetes: su valor se interpola en el lugar indicado. Asimismo, cualquiera de los elementos del Cuadro <CrossRef target="Table" ref="the_format_options"/> puede aparecer en las cadenas de formato. La sintaxis de las cadenas incluye también una instrucción condicional que se ilustra en un ejemplo más adelante.</Text> … … 2878 2901 </th> 2879 2902 <th> 2880 <Text id="730"><i>www.tuwien.ac.at/~prikryl/ wget.html</i></Text>2903 <Text id="730"><i>www.tuwien.ac.at/~prikryl/ wget.html</i></Text> 2881 2904 </th> 2882 2905 </tr> … … 2955 2978 </th> 2956 2979 <th> 2957 <Text id="751"><i>www.ra.informatik.uni-stuttgart.de/ ~gosho/pdftohtml</i></Text>2980 <Text id="751"><i>www.ra.informatik.uni-stuttgart.de/ ~gosho/pdftohtml</i></Text> 2958 2981 </th> 2959 2982 </tr> … … 3074 3097 </Bullet> 3075 3098 <Bullet> 3076 <Text id="792">activando la función <i>filter( 3099 <Text id="792">activando la función <i>filter()</i> mediante el protocolo nulo.</Text> 3077 3100 </Bullet> 3078 3101 </BulletList> … … 3096 3119 <Text id="799">El texto de origen de la colección Gutenberg consiste en un extenso archivo por cada libro. Durante la creación de la colección, dichos archivos se dividen en páginas separadas cada 200 lÃneas aproximadamente, y las informaciones importantes de cada página se guardan en los Ãndices y en la base de datos de informaciones de la colección. En la parte superior de la Figura <CrossRef target="Figure" ref="the_golf_course_mystery"/> se indica que este libro tiene 104 páginas electrónicas, y justo debajo aparece el principio de la primera página: el nombre de la persona que introdujo el texto, el tÃtulo, el autor y el principio de un Ãndice (dicho Ãndice forma parte del texto de origen del Proyecto Gutenberg y no ha sido generado por Greenstone). En la parte superior izquierda se ven los botones que controlan la presentación del documento: una sola página o la totalidad del documento, si se resalta o no el término de la consulta, y si se muestra o no el libro en su propia ventana, separado de la actividad principal de búsqueda y consulta. En la parte superior derecha hay un asistente de consulta que proporciona acceso directo a cualquier página del libro: basta con escribir el número de la página y pulsar el botón âir a la páginaâ. Asimismo, se pueden consultar las páginas anteriores y posteriores haciendo clic en los iconos de flecha situados de cada lado del dispositivo de selección de página.</Text> 3097 3120 <Text id="800">La operación de recuperación de documentos, <i>documentaction</i>, se especifica mediante la configuración <i>a=d</i> y requiere varios argumentos suplementarios. Lo más importante es el documento por recuperar: éste se define mediante la variable <i>d</i>. En la Figura <CrossRef target="Figure" ref="the_golf_course_mystery"/> su valor es <i>d=HASH51e598821ed6cbbdf0942b.1</i> para recuperar la primera página del documento cuyo identificador es <i>HASH51e598821ed6cbbdf0942b</i>, y que en términos más convencionales se conoce como <i>The Golf Course Mystery</i>. Hay otras variables mediante las cuales se determina si el término de búsqueda ha de resaltarse o no ( <i>hl</i>) y qué página del libro se debe mostrar ( <i>gt</i>). Estas variables complementan las opciones propuestas por los botones de la página Web representados en la Figura <CrossRef target="Figure" ref="the_golf_course_mystery"/> y antes mencionados. Se utilizan los valores por defecto cuando se omite cualquiera de estas variables.</Text> 3098 <Text id="801">Esta acción sigue un procedimiento similar a <i>queryaction</i> : examen de los argumentos CGI, acceso al servidor de colección mediante el protocolo y utilización del resultado para generar una página Web. Las opciones relativas al documento se descodifican a partir de los argumentos CGI y se guardan en el objeto para operaciones ulteriores. Para recuperar el documento desde el servidor de colección, sólo se necesita el identificador de documento para efectuar la llamada de protocolo <i>get_document( 3121 <Text id="801">Esta acción sigue un procedimiento similar a <i>queryaction</i> : examen de los argumentos CGI, acceso al servidor de colección mediante el protocolo y utilización del resultado para generar una página Web. Las opciones relativas al documento se descodifican a partir de los argumentos CGI y se guardan en el objeto para operaciones ulteriores. Para recuperar el documento desde el servidor de colección, sólo se necesita el identificador de documento para efectuar la llamada de protocolo <i>get_document()</i>. Una vez enviado el documento, queda por hacer un trabajo considerable de formateo. Para ello, el código de <i>documentaction</i> accede a los argumentos almacenados y utiliza los objetos Formato y Lenguaje de macros.</Text> 3099 3122 </Content> 3100 3123 </Subsection> … … 3284 3307 <Text id="841">Unicode necesita dos bytes para almacenar cada carácter. En la Figura <CrossRef target="Figure" ref="the_text_t_api"/> se muestran las caracterÃsticas principales de la interfaz para programas de aplicación (API, esto es, <i>Application Program Interface</i>) de <i>text_t</i>. El requisito de los dos bytes se cumple utilizando el tipo estándar C++ <i>short</i>, que se define como un número entero de dos bytes. El principal tipo de datos del objeto <i>text_t</i> es una matriz dinámica de <i>unsigned</i><i>shorts</i> elaborada mediante la declaración STL <i>vector<unsigned short></i> y que recibe el nombre abreviado de <i>usvector</i>.</Text> 3285 3308 <Text id="842">Las funciones de creación (lÃneas 10-12) admiten explÃcitamente tres formas de inicialización: creación sin parámetros, que genera una cadena Unicode vacÃa; creación con un parámetro entero, que genera una versión de texto Unicode con el valor numérico proporcionado; y creación con un parámetro <i>char*</i>, que trata el argumento como una cadena C++ terminada en cero y genera una versión Unicode del mismo.</Text> 3286 <Text id="843">A continuación, la mayor parte del código (lÃneas 17-28) se ocupa de mantener un contenedor de tipo vector STL: <i>begin( )</i>, <i>end( )</i>, <i>push_back( )</i>, <i>empty()</i>, etc. Permite asimismo borrar y concatenar cadenas, asà como convertir un número entero en una cadena de texto Unicode y remitir el correspondiente valor entero a un texto que representa un número.</Text>3309 <Text id="843">A continuación, la mayor parte del código (lÃneas 17-28) se ocupa de mantener un contenedor de tipo vector STL: <i>begin()</i>, <i>end()</i>, <i>push_back()</i>, <i>empty()</i>, etc. Permite asimismo borrar y concatenar cadenas, asà como convertir un número entero en una cadena de texto Unicode y remitir el correspondiente valor entero a un texto que representa un número.</Text> 3287 3310 <Figure id="overloaded_operators_to_text_t" class="withLineNumber"> 3288 3311 <Title> … … 3328 3351 </th> 3329 3352 <th width="450"> 3330 <Text id="850">Funciones de lectura y escritura de archivos de configuración. Por ejemplo, la función <i>read_cfg_line( 3353 <Text id="850">Funciones de lectura y escritura de archivos de configuración. Por ejemplo, la función <i>read_cfg_line()</i> (leer archivo de configuración) toma como argumentos el flujo de entrada y la matriz <i>text_tarray</i> (abreviación de <i>vector<text_t></i>) para rellenar con los datos leÃdos.</Text> 3331 3354 </th> 3332 3355 </tr> … … 3344 3367 </th> 3345 3368 <th width="450"> 3346 <Text id="854">Auxiliar para funciones de gestión de archivos independientes del sistema operativo. Por ejemplo, <i>filename_cat( 3369 <Text id="854">Auxiliar para funciones de gestión de archivos independientes del sistema operativo. Por ejemplo, <i>filename_cat()</i> admite hasta seis argumentos <i>text_t</i> y devuelve un <i>text_t</i> que es el resultado de concatenar los elementos utilizando el separador de directorio adecuado para el sistema operativo en cuestión.</Text> 3347 3370 </th> 3348 3371 </tr> … … 3360 3383 </th> 3361 3384 <th width="450"> 3362 <Text id="858">Función de apoyo para fechas y horas. Por ejemplo, <i>time2text( 3385 <Text id="858">Función de apoyo para fechas y horas. Por ejemplo, <i>time2text()</i> toma la hora de la computadora, expresada como el número de segundos transcurridos desde el 1º de enero de 1970, y la convierte en el formato AAAA/MM/DD hh:mm:ss, que devuelve como tipo <i>text_t</i>.</Text> 3363 3386 </th> 3364 3387 </tr> … … 3438 3461 <CodeLine>};</CodeLine> 3439 3462 </Figure> 3440 <Text id="871">En la Figura <CrossRef target="Figure" ref="search_base_class_api"/> se muestra el API de la clase de base para el objeto de búsqueda de la Figura <CrossRef target="Figure" ref="greenstone_runtime_system"/>. Define dos funciones miembro virtuales: <i>search( )</i> y <i>docTargetDocument()</i>. Tal como indica el <i>=0</i> que sigue la declaración de argumento, se trata de funciones puras, lo que significa que una clase que hereda este objeto debe implementar ambas funciones (de otro modo el compilador se quejará).</Text>3463 <Text id="871">En la Figura <CrossRef target="Figure" ref="search_base_class_api"/> se muestra el API de la clase de base para el objeto de búsqueda de la Figura <CrossRef target="Figure" ref="greenstone_runtime_system"/>. Define dos funciones miembro virtuales: <i>search()</i> y <i>docTargetDocument()</i>. Tal como indica el <i>=0</i> que sigue la declaración de argumento, se trata de funciones puras, lo que significa que una clase que hereda este objeto debe implementar ambas funciones (de otro modo el compilador se quejará).</Text> 3441 3464 <Text id="872">La clase incluye asimismo dos campos de datos protegidos: <i>collectdir</i> y <i>cache</i>. Cuando se instancia un objeto de búsqueda para una colección particular, se utiliza el campo <i>collectdir</i> para determinar dónde está guardada esa colección (y, lo que es más importante, sus archivos de Ãndice) en el sistema de archivos. El campo <i>cache</i> retiene el resultado de una consulta. Se utiliza para acelerar el tratamiento de consultas ulteriores que repiten la primera (y sus parámetros). Puede parecer improbable que se efectúen consultas idénticas, pero de hecho esto ocurre con bastante frecuencia. El protocolo de Greenstone es sin estado. A fin de generar una página de resultados como la de la Figura <CrossRef target="Figure" ref="searching_gutenberg_for_darcy"/>, pero con los resultados 11-20 de la misma consulta, se transmite de nuevo la búsqueda especificando, en este caso, que se presente la serie de documentos 11-20. El campo <i>cache</i> acelera esta operación, puesto que se comprueba que la búsqueda ya ha sido ejecutada y los resultados se sacan directamente de este campo.</Text> 3442 3465 <Text id="873">Ambos campos de datos son aplicables a todos los objetos heredados que implementan un mecanismo de búsqueda. Por ello aparecen en la clase de base y se declaran dentro de una sección protegida de la clase, a fin de que las clases heredadas puedan acceder directamente a ellos.</Text> … … 3473 3496 <CodeLine>void mgq_stemword (unsigned char *word);</CodeLine> 3474 3497 </Figure> 3475 <Text id="877">MG se utiliza por lo general de manera interactiva tecleando las instrucciones desde la lÃnea de comandos, y un modo de implementar <i>mgsearchclass</i> serÃa activando la llamada <i>system( 3476 <Text id="878">Para proporcionar parámetros a MG, se usa <i>mgq_ask( 3498 <Text id="877">MG se utiliza por lo general de manera interactiva tecleando las instrucciones desde la lÃnea de comandos, y un modo de implementar <i>mgsearchclass</i> serÃa activando la llamada <i>system()</i> de la biblioteca C dentro del objeto para ejecutar los comandos MG apropiados. Sin embargo, un método más eficaz consiste en intervenir directamente en el código de MG utilizando las llamadas de función. Aunque esto requiere un mayor conocimiento del código de MG, una gran parte de la complejidad puede ocultarse tras una nueva API que pasará a ser el punto de contacto para el objeto <i>mgsearchclass</i>. Ãsta es la función del archivo <i>colserver/mgq.c</i>, cuya API se muestra en la Figura <CrossRef target="Figure" ref="api_for_direct_access_to_mg"/>.</Text> 3499 <Text id="878">Para proporcionar parámetros a MG, se usa <i>mgq_ask()</i>, que admite opciones de texto en un formato idéntico al que se usa en la lÃnea de comandos, como por ejemplo:</Text> 3477 3500 <CodeLine>mgq_ask(â.set casefold offâ);</CodeLine> 3478 <Text id="879">Se utiliza asimismo para activar una consulta. Se accede a los resultados mediante la función <i>mgq_results</i>, que adopta como cuarto parámetro un puntero dirigido hacia una función. Ello proporciona un modo flexible de convertir la información devuelta en estructuras de datos de MG en el formato que requiere <i>mgsearchclass</i>. Las operaciones como <i>mgq_numdocs( )</i>, <i>mgq_numterms( )</i> y <i>mgq_docsretrieved()</i> también devuelven información, pero prescritas de manera más precisa. Las dos últimas contribuyen a la función de truncamiento.</Text>3501 <Text id="879">Se utiliza asimismo para activar una consulta. Se accede a los resultados mediante la función <i>mgq_results</i>, que adopta como cuarto parámetro un puntero dirigido hacia una función. Ello proporciona un modo flexible de convertir la información devuelta en estructuras de datos de MG en el formato que requiere <i>mgsearchclass</i>. Las operaciones como <i>mgq_numdocs()</i>, <i>mgq_numterms()</i> y <i>mgq_docsretrieved()</i> también devuelven información, pero prescritas de manera más precisa. Las dos últimas contribuyen a la función de truncamiento.</Text> 3479 3502 </Content> 3480 3503 </Subsection> … … 3514 3537 <CodeLine>}; </CodeLine> 3515 3538 </Figure> 3516 <Text id="882">La función del objeto Fuente (<i>Source</i>) de la Figura <CrossRef target="Figure" ref="greenstone_runtime_system"/> es acceder a los metadatos y al texto del documento; la API de su clase de base se muestra en la Figura <CrossRef target="Figure" ref="source_base_class_api"/>. Una función miembro se asigna a cada tarea: las funciones <i>get_metadata( )</i> y <i>get_document( )</i>, respectivamente. Ambas se declaran <i>virtual</i>, por lo que la versión suministrada por una implementación particular de la clase de base se activa durante la ejecución. Una versión heredada de este objeto utiliza GDBM para implementar <i>get_metadata( )</i> y MG para implementar <i>get_document()</i> : a continuación explicaremos en detalle esta versión.</Text>3517 <Text id="883">Las otras funciones miembro que aparecen en la Figura <CrossRef target="Figure" ref="source_base_class_api"/> son <i>configure( )</i>, <i>init( )</i> y <i>translate_OID()</i>. Las dos primeras se relacionan con el proceso de inicialización que se explica en la Sección <CrossRef target="Section" ref="initialisation"/>.</Text>3518 <Text id="884">La otra, <i>translate_OID( 3539 <Text id="882">La función del objeto Fuente (<i>Source</i>) de la Figura <CrossRef target="Figure" ref="greenstone_runtime_system"/> es acceder a los metadatos y al texto del documento; la API de su clase de base se muestra en la Figura <CrossRef target="Figure" ref="source_base_class_api"/>. Una función miembro se asigna a cada tarea: las funciones <i>get_metadata()</i> y <i>get_document()</i>, respectivamente. Ambas se declaran <i>virtual</i>, por lo que la versión suministrada por una implementación particular de la clase de base se activa durante la ejecución. Una versión heredada de este objeto utiliza GDBM para implementar <i>get_metadata()</i> y MG para implementar <i>get_document()</i> : a continuación explicaremos en detalle esta versión.</Text> 3540 <Text id="883">Las otras funciones miembro que aparecen en la Figura <CrossRef target="Figure" ref="source_base_class_api"/> son <i>configure()</i>, <i>init()</i> y <i>translate_OID()</i>. Las dos primeras se relacionan con el proceso de inicialización que se explica en la Sección <CrossRef target="Section" ref="initialisation"/>.</Text> 3541 <Text id="884">La otra, <i>translate_OID()</i>, maneja la sintaxis para expresar los identificadores de documento. En la Figura <CrossRef target="Figure" ref="the_golf_course_mystery"/> vimos que el número de una página podÃa anexarse a un identificador de documento para recuperar únicamente esa página. Esto era posible porque, al crearse la colección, las páginas se almacenaban como âseccionesâ. Si se agrega â.1â a un OID, se recupera la primera sección del documento correspondiente. Las secciones pueden subdividirse y para acceder a ellas es preciso concatenar números de secciones separados por puntos.</Text> 3519 3542 <Text id="885">Además de los números jerárquicos de secciones, la sintaxis del identificador de documento admite una forma de acceso relativo. En el caso de la sección en uso de un documento, se puede acceder al <i>primer hijo</i> anexando <i>.fc (first child)</i>, al <i>último niño</i> anexando <i>.lc (last child)</i>, al <i>padre</i> anexando <i>.pr (parent)</i>, al <i>hermano</i><i>siguiente</i> anexando <i>.ns</i><i>(next sibling)</i> y al <i>hermano anterior</i> anexando <i>.ps (previous sibling)</i>.</Text> 3520 3543 <Text id="886">La función <i>translate_OID</i> utiliza los parámetros <i>OIDin</i> y <i>OIDout</i> para retener la fuente y el resultado de la conversión. Incluye otros dos parámetros: <i>err</i> y <i>logout</i>. Ãstos comunican cualquier estado de error que se pueda producir durante la operación de traducción, y determina dónde enviar la información de registro ( <i>logging information</i>). Como veremos en la Sección <CrossRef target="Section" ref="protocol"/>, estos parámetros dependen estrechamente del protocolo.</Text> … … 3611 3634 <CodeLine>};</CodeLine> 3612 3635 </Figure> 3613 <Text id="897">El objeto que reúne MG y GDBM para efectuar una implementación de <i>sourceclass</i> se denomina <i>mggdbmsourceclass</i>. En la Figura <CrossRef target="Figure" ref="api_for_mg_and_gdbm_based_version_of_sourceclass"/> se presenta su API. Las dos nuevas funciones miembro <i>set_gdbmptr( )</i> y <i>set_mgsearchptr( )</i> almacenan punteros dirigidos hacia sus respectivos objetos, de modo que las implementaciones de <i>get_metadata( )</i> y <i>get_document()</i> puedan acceder a las herramientas apropiadas para llevar a cabo su tarea.</Text>3636 <Text id="897">El objeto que reúne MG y GDBM para efectuar una implementación de <i>sourceclass</i> se denomina <i>mggdbmsourceclass</i>. En la Figura <CrossRef target="Figure" ref="api_for_mg_and_gdbm_based_version_of_sourceclass"/> se presenta su API. Las dos nuevas funciones miembro <i>set_gdbmptr()</i> y <i>set_mgsearchptr()</i> almacenan punteros dirigidos hacia sus respectivos objetos, de modo que las implementaciones de <i>get_metadata()</i> y <i>get_document()</i> puedan acceder a las herramientas apropiadas para llevar a cabo su tarea.</Text> 3614 3637 </Content> 3615 3638 </Part> … … 3661 3684 </BulletList> 3662 3685 <Text id="904"><i>mggdbsourceclass</i> es otra clase que incluye estos tres campos de datos.</Text> 3663 <Text id="905">El proceso de inicialización utiliza las funciones miembro <i>configure( )</i> e <i>init( )</i> (que ya vimos en la función <i>sourceclass</i>). El propio objeto se alinea estrechamente con la porción de filtro que le corresponde en el protocolo; las funciones <i>get_filteroptions( )</i> y <i>filter()</i>, en particular, coinciden exactamente.</Text>3686 <Text id="905">El proceso de inicialización utiliza las funciones miembro <i>configure()</i> e <i>init()</i> (que ya vimos en la función <i>sourceclass</i>). El propio objeto se alinea estrechamente con la porción de filtro que le corresponde en el protocolo; las funciones <i>get_filteroptions()</i> y <i>filter()</i>, en particular, coinciden exactamente.</Text> 3664 3687 <Figure id="how_a_filter_option_is_stored"> 3665 3688 <Title> … … 3803 3826 </th> 3804 3827 <th width="420"> 3805 <Text id="931">Interfaz funcional para el paquete MG. Sus principales funciones son <i>mg_ask( )</i> y <i>mg_results()</i>.</Text>3828 <Text id="931">Interfaz funcional para el paquete MG. Sus principales funciones son <i>mg_ask()</i> y <i>mg_results()</i>.</Text> 3806 3829 </th> 3807 3830 </tr> … … 3923 3946 <tr> 3924 3947 <th width="132"> 3925 <Text id="952"><i>get_protocol_name( 3948 <Text id="952"><i>get_protocol_name()</i></Text> 3926 3949 </th> 3927 3950 <th width="397"> … … 3931 3954 <tr> 3932 3955 <th width="132"> 3933 <Text id="954"><i>get_collection_list( 3956 <Text id="954"><i>get_collection_list()</i></Text> 3934 3957 </th> 3935 3958 <th width="397"> … … 3939 3962 <tr> 3940 3963 <th width="132"> 3941 <Text id="956"><i>has_collection( 3964 <Text id="956"><i>has_collection()</i></Text> 3942 3965 </th> 3943 3966 <th width="397"> … … 3947 3970 <tr> 3948 3971 <th width="132"> 3949 <Text id="958"><i>ping( 3972 <Text id="958"><i>ping()</i></Text> 3950 3973 </th> 3951 3974 <th width="397"> 3952 <Text id="959">ReenvÃa el valor <i>true (verdadero)</i> si se ha logrado establecer una conexión con la colección nombrada. En el caso del protocolo nulo, la implementación es idéntica a la de <i>has_collection( 3953 </th> 3954 </tr> 3955 <tr> 3956 <th width="132"> 3957 <Text id="960"><i>get_collectinfo( 3975 <Text id="959">ReenvÃa el valor <i>true (verdadero)</i> si se ha logrado establecer una conexión con la colección nombrada. En el caso del protocolo nulo, la implementación es idéntica a la de <i>has_collection()</i>.</Text> 3976 </th> 3977 </tr> 3978 <tr> 3979 <th width="132"> 3980 <Text id="960"><i>get_collectinfo()</i></Text> 3958 3981 </th> 3959 3982 <th width="397"> … … 3963 3986 <tr> 3964 3987 <th width="132"> 3965 <Text id="962"><i>get_filterinfo( 3988 <Text id="962"><i>get_filterinfo()</i></Text> 3966 3989 </th> 3967 3990 <th width="397"> … … 3971 3994 <tr> 3972 3995 <th width="132"> 3973 <Text id="964"><i>get_filteroptions( 3996 <Text id="964"><i>get_filteroptions()</i></Text> 3974 3997 </th> 3975 3998 <th width="397"> … … 3979 4002 <tr> 3980 4003 <th width="132"> 3981 <Text id="966"><i>filter( 4004 <Text id="966"><i>filter()</i></Text> 3982 4005 </th> 3983 4006 <th width="397"> … … 3987 4010 <tr> 3988 4011 <th width="132"> 3989 <Text id="968"><i>get_document( 4012 <Text id="968"><i>get_document()</i></Text> 3990 4013 </th> 3991 4014 <th width="397"> … … 3995 4018 </TableContent> 3996 4019 </Table> 3997 <Text id="970">En el Cuadro <CrossRef target="Table" ref="list_of_protocol_calls"/> se presenta una lista de las llamadas de función al protocolo, y un resumen de cada una de ellas. Los ejemplos de la Sección <CrossRef target="Section" ref="how_the_conceptual_framework_fits_together"/> ilustran la mayorÃa de esas llamadas. Las funciones no mencionadas anteriormente son <i>has_collection( )</i>, <i>ping( )</i>, <i>get_protocol_name( )</i> y <i>get_filteroptions()</i>. Las dos primeras responden afirmativa o negativamente a las preguntas â¿existe la colección en este servidor?â y â¿se encuentra en funcionamiento?â, respectivamente. La finalidad de las otras dos es admitir protocolos múltiples en una arquitectura repartida en diferentes computadoras, y no sólo el ejecutable individual basado en el protocolo nulo que se menciona aquÃ. Una de ellas detecta qué protocolo se encuentra en uso. La otra permite que un recepcionista consulte al servidor de una colección para averiguar qué opciones admite, a fin de configurarse dinámicamente y sacar el máximo provecho de los servicios ofrecidos por un servidor particular.</Text>4020 <Text id="970">En el Cuadro <CrossRef target="Table" ref="list_of_protocol_calls"/> se presenta una lista de las llamadas de función al protocolo, y un resumen de cada una de ellas. Los ejemplos de la Sección <CrossRef target="Section" ref="how_the_conceptual_framework_fits_together"/> ilustran la mayorÃa de esas llamadas. Las funciones no mencionadas anteriormente son <i>has_collection()</i>, <i>ping()</i>, <i>get_protocol_name()</i> y <i>get_filteroptions()</i>. Las dos primeras responden afirmativa o negativamente a las preguntas â¿existe la colección en este servidor?â y â¿se encuentra en funcionamiento?â, respectivamente. La finalidad de las otras dos es admitir protocolos múltiples en una arquitectura repartida en diferentes computadoras, y no sólo el ejecutable individual basado en el protocolo nulo que se menciona aquÃ. Una de ellas detecta qué protocolo se encuentra en uso. La otra permite que un recepcionista consulte al servidor de una colección para averiguar qué opciones admite, a fin de configurarse dinámicamente y sacar el máximo provecho de los servicios ofrecidos por un servidor particular.</Text> 3998 4021 <Figure id="null_protocol_api"> 3999 4022 <Title> … … 4033 4056 <Text id="972">En la Figura <CrossRef target="Figure" ref="null_protocol_api"/> se muestra la API para el protocolo nulo. Se han omitido los comentarios y determinados detalles de nivel inferior (véase el archivo fuente <i>recpt/nullproto.h</i> para obtener más información al respecto).</Text> 4034 4057 <Text id="973">Este protocolo hereda de la clase de base <i>recptproto</i>. Se utiliza la herencia virtual a fin de poder admitir fácilmente más de un tipo de protocolo âincluso protocolos aún no concebidosâ en el resto del código fuente. Ello es posible porque el objeto de clase de base <i>recptproto</i> se utiliza a lo largo de todo el código fuente, excepto en el punto de creación, donde especificamos la variedad concreta de protocolo que deseamos utilizar que, en este caso, es el protocolo nulo.</Text> 4035 <Text id="974">Con la excepción de <i>get_protocol_name( 4036 <Text id="975">La mayorÃa de las funciones toman el nombre de la colección como argumento. Tres de las funciones miembro, <i>get_filteroptions( )</i>, <i>filter( )</i> y <i>get_document()</i> siguen el esquema de proporcionar un parámetro de consulta y de recibir los resultados en un parámetro de respuesta Response.</Text>4058 <Text id="974">Con la excepción de <i>get_protocol_name()</i>, que no toma parámetros y devuelve el nombre del protocolo como una cadena de texto codificada en Unicode, todas las funciones de protocolo incluyen un parámetro de error y un flujo de salida como argumentos finales. El parámetro de error registra cualquier error que se produce durante la ejecución de la llamada de protocolo y la secuencia de salida se utiliza a efectos de registro ( <i>logging</i>). Las funciones son del tipo <i>void</i>, esto es, no reenvÃan explÃcitamente la información en su instrucción final, sino que reenvÃan datos a través de parámetros designados como el parámetro de error antes mencionado. En algunos lenguajes de programación, estos subprogramas se definirÃan como âprocedimientosâ en vez de âfuncionesâ, pero C++ no establece ninguna distinción sintáctica.</Text> 4059 <Text id="975">La mayorÃa de las funciones toman el nombre de la colección como argumento. Tres de las funciones miembro, <i>get_filteroptions()</i>, <i>filter()</i> y <i>get_document()</i> siguen el esquema de proporcionar un parámetro de consulta y de recibir los resultados en un parámetro de respuesta Response.</Text> 4037 4060 </Content> 4038 4061 </Section> … … 4168 4191 <Text id="1005">Para cada argumento CGI, el constructor debe especificar su nombre corto (lÃneas 2 y 10), que es el nombre de la variable CGI propiamente dicha; un nombre largo (lÃneas 3 y 11) que se utiliza para proporcionar una descripción más elocuente de la acción; si representa un valor de carácter simple o múltiple (lÃneas 4 y 12); un posible valor por defecto (lÃneas 5 y 13); lo que ocurre cuando se proporcionan varios valores por defecto (lÃneas 6 y 14) (ya que pueden introducirse valores por defecto en los archivos de configuración); y si es preciso preservar o no el valor al final de esta acción (lÃneas 7 y 15).</Text> 4169 4192 <Text id="1006">Puesto que está integrada en el código, se pueden generar automáticamente páginas Web que detallan esta información. La acción <i>statusaction</i> produce esta información, que puede visualizarse introduciendo la dirección URL de la página de administración de Greenstone.</Text> 4170 <Text id="1007">Las doce acciones heredadas se construyen en <i>main( 4193 <Text id="1007">Las doce acciones heredadas se construyen en <i>main()</i>, la función de alto nivel del ejecutable <i>library</i>, cuya definición figura en el archivo <i>recpt/librarymain.cpp</i>. Es aquà también donde se forma el objeto Recepcionista (definido en <i>recpt/receptionist.cpp</i>). La responsabilidad de todas las acciones recae en el objeto de recepcionista, que las trata manteniendo, como un campo de datos, una matriz asociativa de la clase base Acción, indizada por nombres de acción.</Text> 4171 4194 <Figure id="action_base_class_api"> 4172 4195 <Title> … … 4216 4239 <CodeLine>};</CodeLine> 4217 4240 </Figure> 4218 <Text id="1009">En la Figura <CrossRef target="Figure" ref="action_base_class_api"/> se muestra la API de la clase base Acción. Cuando se ejecuta una acción, el objeto Recepcionista activa diversas funciones, empezando por <i>check_cgiarsgs( )</i>. La mayorÃa de estas funciones contribuyen a verificar, configurar y definir valores y macros, mientras que <i>do_action()</i> genera efectivamente la página resultante. Si un objeto heredado particular no dispone de una definición para una función miembro determinada, pasa a la definición de la clase base que implementa un comportamiento por defecto apropiado.</Text>4241 <Text id="1009">En la Figura <CrossRef target="Figure" ref="action_base_class_api"/> se muestra la API de la clase base Acción. Cuando se ejecuta una acción, el objeto Recepcionista activa diversas funciones, empezando por <i>check_cgiarsgs()</i>. La mayorÃa de estas funciones contribuyen a verificar, configurar y definir valores y macros, mientras que <i>do_action()</i> genera efectivamente la página resultante. Si un objeto heredado particular no dispone de una definición para una función miembro determinada, pasa a la definición de la clase base que implementa un comportamiento por defecto apropiado.</Text> 4219 4242 <Text id="1010">La explicación de las funciones miembro es la siguiente:</Text> 4220 4243 <BulletList> 4221 4244 <Bullet> 4222 <Text id="1011"><i>get_action_name( 4245 <Text id="1011"><i>get_action_name()</i> devuelve el valor del argumento CGI <i>a</i> que especifica esta acción. El nombre deberÃa ser corto pero puede incluir más de un carácter.</Text> 4223 4246 </Bullet> 4224 4247 <Bullet> 4225 <Text id="1012"><i>check_cgiargs( )</i> es llamada antes que <i>get_cgihead_info( )</i>, <i>define_external_macros( )</i> y <i>do_action()</i>. En caso de error aparece un mensaje escrito en <i>logout</i> ; si el error es importante, la función devuelve el valor <i>false</i> (falso) y no genera ningún contenido de página.</Text>4248 <Text id="1012"><i>check_cgiargs()</i> es llamada antes que <i>get_cgihead_info()</i>, <i>define_external_macros()</i> y <i>do_action()</i>. En caso de error aparece un mensaje escrito en <i>logout</i> ; si el error es importante, la función devuelve el valor <i>false</i> (falso) y no genera ningún contenido de página.</Text> 4226 4249 </Bullet> 4227 4250 <Bullet> 4228 <Text id="1013"><i>check_external_cgiargs( )</i> se activa después de <i>check_cgiargs()</i> para todas las acciones. Su uso se limita a invalidar otros comportamientos por defecto, como por ejemplo, mostrar una página de conexión cuando la página solicitada requiere una autenticación.</Text>4251 <Text id="1013"><i>check_external_cgiargs()</i> se activa después de <i>check_cgiargs()</i> para todas las acciones. Su uso se limita a invalidar otros comportamientos por defecto, como por ejemplo, mostrar una página de conexión cuando la página solicitada requiere una autenticación.</Text> 4229 4252 </Bullet> 4230 4253 <Bullet> 4231 <Text id="1014"><i>get_cgihead_info( 4254 <Text id="1014"><i>get_cgihead_info()</i> establece la información del encabezado CGI. Si <i>response</i> tiene el valor de <i>location</i>, entonces <i>response_data</i> contiene la dirección de redirección. Si <i>response</i> equivale a <i>content</i>, entonces <i>response_data</i> contiene el tipo de contenido.</Text> 4232 4255 </Bullet> 4233 4256 <Bullet> 4234 <Text id="1015"><i>uses_display( 4257 <Text id="1015"><i>uses_display()</i> devuelve <i>true</i> ( <i>verdadero)</i> si se necesita <i>displayclass</i> para mostrar el contenido de la página (comportamiento por defecto).</Text> 4235 4258 </Bullet> 4236 4259 <Bullet> 4237 <Text id="1016"><i>define_internal_macros( 4260 <Text id="1016"><i>define_internal_macros()</i> define todas las macros relacionadas con las páginas generadas por esta acción.</Text> 4238 4261 </Bullet> 4239 4262 <Bullet> 4240 <Text id="1017"><i>define_external_macros( 4263 <Text id="1017"><i>define_external_macros()</i> define todas las macros que podrÃan ser utilizadas por otras acciones para producir páginas.</Text> 4241 4264 </Bullet> 4242 4265 <Bullet> 4243 <Text id="1018"><i>do_action( 4266 <Text id="1018"><i>do_action()</i> genera la página resultante, normalmente en un flujo a través del objeto Lenguaje de macros <i>display</i> y el objeto de conversión de salida <i>textout</i>. ReenvÃa el valor <i>false</i> si un error ha impedido que la acción produzca un resultado.</Text> 4244 4267 </Bullet> 4245 4268 </BulletList> 4246 <Text id="1019">Situado en el principio de la definición de clase, <i>argsinfo</i> es el campo de datos protegidos (utilizado en el extracto de código que se muestra en la Figura <CrossRef target="Figure" ref="using_the_cgiargsinfoclass_from_pageactioncpp"/>) que almacena la información de argumento CGI especificada en una función constructora de acción heredada. El otro campo de datos, <i>gsdlhome</i>, registra <i>GSDLHOME</i> para facilitar el acceso<FootnoteRef id=" 3"/>. El objeto incluye asimismo las funciones <i>configure( )</i> e <i>init()</i> a efectos de inicialización.</Text>4269 <Text id="1019">Situado en el principio de la definición de clase, <i>argsinfo</i> es el campo de datos protegidos (utilizado en el extracto de código que se muestra en la Figura <CrossRef target="Figure" ref="using_the_cgiargsinfoclass_from_pageactioncpp"/>) que almacena la información de argumento CGI especificada en una función constructora de acción heredada. El otro campo de datos, <i>gsdlhome</i>, registra <i>GSDLHOME</i> para facilitar el acceso<FootnoteRef id="4"/>. El objeto incluye asimismo las funciones <i>configure()</i> e <i>init()</i> a efectos de inicialización.</Text> 4247 4270 </Content> 4248 4271 </Subsection> … … 4365 4388 <CodeLine>};</CodeLine> 4366 4389 </Figure> 4367 <Text id="1037">El objeto principal de apoyo al lenguaje de macros es <i>displayclass</i>, definido en <i>lib/display.h</i>. Sus funciones miembro públicas aparecen en la Figura <CrossRef target="Figure" ref="displayclass_api"/>. La clase lee los archivos de macros especificados utilizando <i>loaddefaultmacros( )</i> y guarda en una sección protegida de la clase (que no se muestra) el tipo de la estructura de datos que se muestra en la Figura <CrossRef target="Figure" ref="data_structures_representing_the_default_macros"/>. Es posible asimismo que el sistema de ejecución cree macros utilizando <i>setmacro( )</i> (en el último ejemplo de la Sección <CrossRef target="Section" ref="how_the_conceptual_framework_fits_together"/>, <i>pageaction</i> establece que _ <i>homeextra</i> _ sea el cuadro generado dinámicamente para las colecciones disponibles que utilizan esta función). Todo ello con la ayuda de un conjunto de matrices asociativas semejantes a las que se utilizan para representar los archivos de macros (no es idéntico porque el primero no requiere la capa âparámetroâ). En <i>displayclass</i>, las macros que se leen desde el archivo se denominan <i>macros por defecto</i>. Las macros locales que se especifican a través de <i>setmacro()</i> se denominan <i>macros en curso</i>, y son borradas de la memoria tras generarse la página.</Text>4368 <Text id="1038">Cuando se va a generar una página, se llama primero <i>openpage( 4390 <Text id="1037">El objeto principal de apoyo al lenguaje de macros es <i>displayclass</i>, definido en <i>lib/display.h</i>. Sus funciones miembro públicas aparecen en la Figura <CrossRef target="Figure" ref="displayclass_api"/>. La clase lee los archivos de macros especificados utilizando <i>loaddefaultmacros()</i> y guarda en una sección protegida de la clase (que no se muestra) el tipo de la estructura de datos que se muestra en la Figura <CrossRef target="Figure" ref="data_structures_representing_the_default_macros"/>. Es posible asimismo que el sistema de ejecución cree macros utilizando <i>setmacro()</i> (en el último ejemplo de la Sección <CrossRef target="Section" ref="how_the_conceptual_framework_fits_together"/>, <i>pageaction</i> establece que _ <i>homeextra</i> _ sea el cuadro generado dinámicamente para las colecciones disponibles que utilizan esta función). Todo ello con la ayuda de un conjunto de matrices asociativas semejantes a las que se utilizan para representar los archivos de macros (no es idéntico porque el primero no requiere la capa âparámetroâ). En <i>displayclass</i>, las macros que se leen desde el archivo se denominan <i>macros por defecto</i>. Las macros locales que se especifican a través de <i>setmacro()</i> se denominan <i>macros en curso</i>, y son borradas de la memoria tras generarse la página.</Text> 4391 <Text id="1038">Cuando se va a generar una página, se llama primero <i>openpage()</i> para comunicar las configuraciones en curso de los parámetros de la página en cuestión ( <i>l=en</i>, etc.). A continuación, el texto y las macros fluyen a través de la clase â normalmente desde una <i>actionclass</i> â utilizando el código:</Text> 4369 4392 <CodeLine>cout << text_t2ascii << display << â_unamacro_â</CodeLine> 4370 4393 <CodeLine>                               << â_otramacro_â;</CodeLine> 4371 <Text id="1039">El resultado es que las macros se amplÃan siguiendo las configuraciones de los parámetros de la página. En caso necesario, estas configuraciones pueden modificarse durante el proceso mediante una acción que utiliza <i>setpageparams( 4394 <Text id="1039">El resultado es que las macros se amplÃan siguiendo las configuraciones de los parámetros de la página. En caso necesario, estas configuraciones pueden modificarse durante el proceso mediante una acción que utiliza <i>setpageparams()</i>. Las demás funciones miembro públicas proporcionan el apoyo de nivel inferior.</Text> 4372 4395 </Content> 4373 4396 </Subsection> … … 4467 4490 <Text id="1066">Función de apoyo que hace todo lo necesario para generar una página utilizando el protocolo CGI. El acceso se hace mediante la función:</Text> 4468 4491 <CodeLine>void cgiwrapper (receptionist &recpt,</CodeLine> 4469 <CodeLine> text_t collection);</CodeLine> 4470 </th> 4471 </tr> 4472 <tr> 4473 <th width="140"> 4492 <CodeLine>text_t collection);</CodeLine> 4474 4493 <Text id="1067">que es la única función declarada en el archivo de encabezados. Todo el resto del archivo <i>.cpp</i> tiene un alcance léxico de carácter local en el archivo (utilizando la palabra clave C++ <i>static</i>). Si se utiliza la función para una colección particular, entonces se debe introducir <i>collection</i>, o si no la cadena vacÃa ââ. El código incluye apoyo para Fast-CGI.</Text> 4475 4494 </th> … … 4734 4753 </Title> 4735 4754 <Content> 4736 <Text id="1131">En Greenstone, la inicialización es una operación compleja que trata archivos de configuración y asigna valores por defecto a los campos de datos. Además de las funciones de herencia y de creación, los objetos centrales definen las funciones <i>init( )</i> y <i>configure()</i> para contribuir a normalizar la tarea. Aun asÃ, el orden de ejecución puede ser difÃcil de seguir. En esta sección se explica lo que sucede.</Text>4755 <Text id="1131">En Greenstone, la inicialización es una operación compleja que trata archivos de configuración y asigna valores por defecto a los campos de datos. Además de las funciones de herencia y de creación, los objetos centrales definen las funciones <i>init()</i> y <i>configure()</i> para contribuir a normalizar la tarea. Aun asÃ, el orden de ejecución puede ser difÃcil de seguir. En esta sección se explica lo que sucede.</Text> 4737 4756 <Text id="1132">Greenstone utiliza varios archivos de configuración con diferentes fines, pero todos respetan la misma sintaxis. A menos que una lÃnea empiece por el sÃmbolo â#â o sólo contenga espacios en blanco, la primera palabra define un término clave y las demás representan una configuración particular de dicho término clave.</Text> 4738 <Text id="1133">Las lÃneas de los archivos de configuración se transmiten de una en una a la función <i>configure( )</i> y contienen dos argumentos: el término clave y una matriz de las palabras restantes. Basándose en el término clave, una versión particular de <i>configure( )</i> determina si la información es de interés, y si es asà la guarda. Por ejemplo, <i>collectserver</i> (que corresponde al objeto Colección de la Figura <CrossRef target="Figure" ref="greenstone_runtime_system"/>) trata las instrucciones de formato del archivo de configuración de una colección. Cuando la función <i>configure()</i> recibe el término clave <i>format</i>, se activa una instrucción <i>if</i> que guarda en el objeto una copia del segundo argumento de la función.</Text>4739 <Text id="1134">Tras tratar el término clave y antes de que concluya la función, algunas versiones de <i>configure( )</i> transmiten los datos a las funciones <i>configure( )</i> de otros objetos. El objeto Recepcionista activa la función <i>configure( )</i> de los objetos Acciones, Protocolos y Consulta. El objeto Protocolo nulo activa la función <i>configure()</i> de cada objeto Colección; el objeto Colección activa los objetos Filtro y Fuente.</Text>4740 <Text id="1135">En C++, los campos de datos se inicializan normalmente mediante la función de creación del objeto. Sin embargo, en Greenstone algunas inicializaciones dependen de los valores leÃdos en los archivos de configuración, por ello es preciso proceder a una segunda tanda de inicializaciones. Esta es la finalidad de las funciones miembro <i>init( )</i>, y en algunos casos requiere posteriores llamadas de la función <i>configure()</i>.</Text>4757 <Text id="1133">Las lÃneas de los archivos de configuración se transmiten de una en una a la función <i>configure()</i> y contienen dos argumentos: el término clave y una matriz de las palabras restantes. Basándose en el término clave, una versión particular de <i>configure()</i> determina si la información es de interés, y si es asà la guarda. Por ejemplo, <i>collectserver</i> (que corresponde al objeto Colección de la Figura <CrossRef target="Figure" ref="greenstone_runtime_system"/>) trata las instrucciones de formato del archivo de configuración de una colección. Cuando la función <i>configure()</i> recibe el término clave <i>format</i>, se activa una instrucción <i>if</i> que guarda en el objeto una copia del segundo argumento de la función.</Text> 4758 <Text id="1134">Tras tratar el término clave y antes de que concluya la función, algunas versiones de <i>configure()</i> transmiten los datos a las funciones <i>configure()</i> de otros objetos. El objeto Recepcionista activa la función <i>configure()</i> de los objetos Acciones, Protocolos y Consulta. El objeto Protocolo nulo activa la función <i>configure()</i> de cada objeto Colección; el objeto Colección activa los objetos Filtro y Fuente.</Text> 4759 <Text id="1135">En C++, los campos de datos se inicializan normalmente mediante la función de creación del objeto. Sin embargo, en Greenstone algunas inicializaciones dependen de los valores leÃdos en los archivos de configuración, por ello es preciso proceder a una segunda tanda de inicializaciones. Esta es la finalidad de las funciones miembro <i>init()</i>, y en algunos casos requiere posteriores llamadas de la función <i>configure()</i>.</Text> 4741 4760 <Figure id="initialising_greenstone_using_the_null_protocol"> 4742 4761 <Title> … … 4827 4846 <CodeLine>End.</CodeLine> 4828 4847 </Figure> 4829 <Text id="1137">En la Figura <CrossRef target="Figure" ref="initialising_greenstone_using_the_null_protocol"/> se presentan los mensajes de diagnóstico generados por una versión de Greenstone configurada para resaltar el proceso de inicialización. El programa arranca con la función <i>main( )</i> del archivo <i>recpt/librarymain.cpp</i>. Crea un objeto Recepcionista y un objeto Protocolo nulo, luego recorre el archivo <i>gsdlsite.cfg</i> (ubicado en el mismo directorio que el ejecutable <i>library</i>) en busca de <i>gsdlhome</i> y guarda su valor en una variable. Para cada colección en lÃnea âlista establecida leyendo los directorios de <i>GSDLHOME/collect</i> â el programa crea un objeto de colección mediante el objeto Protocolo nulo, que contiene objetos Filtro, Búsqueda y Fuente, asà como algunas llamadas cableadas a <i>configure()</i>.</Text>4830 <Text id="1138">A continuación, la función <i>main( )</i> agrega el objeto Protocolo nulo al recepcionista, que mantiene una matriz de clase de base de protocolos en un campo de datos protegidos, y luego activa varios convertidores. La función <i>main( )</i> crea todos los objetos Acción y Consulta que se utilizan en el ejecutable y los incorpora al recepcionista. La función concluye al activar la función <i>cgiwrapper()</i> ubicada en <i>cgiwrapper.cpp</i>, que efectúa a su vez un número importante de inicializaciones de objetos.</Text>4831 <Text id="1139">La función <i>cgiwrapper( )</i> comprende tres partes: configuración, inicialización y generación de página. En primer lugar, se efectúan algunas llamadas cableadas a la función <i>configure()</i>, luego se lee el archivo <i>gsdlsite.cfg</i> y se aplica <i>configure</i> a cada lÃnea. Lo mismo ocurre con el archivo <i>etc/main.cfg</i>.</Text>4832 <Text id="1140">La segunda fase de <i>cgiwrapper( )</i> activa <i>init( )</i>. El objeto Recepcionista sólo hace una llamada a su función <i>init( )</i>, pero esta acción invoca las funciones <i>init( )</i> de los diferentes objetos que contiene. Primero una llamada cableada a <i>configure( )</i> para instalar <i>collectdir</i>, y luego se leen los archivos de macros. Se activa la función <i>init( )</i> de cada acción. Lo mismo ocurre con cada protocolo almacenado en el recepcionista, pero en el sistema que se describe aquà sólo se almacena el protocolo nulo. La activación de la función <i>init( )</i> de este objeto suscita otras configuraciones: en cada colección del protocolo nulo se leen y se tratan los archivos especÃficos de la colección <i>build.cfg</i> y <i>collect.cfg</i>, y cada lÃnea activa la función <i>configure()</i>.</Text>4833 <Text id="1141">La fase final de <i>cgiwrapper( 4848 <Text id="1137">En la Figura <CrossRef target="Figure" ref="initialising_greenstone_using_the_null_protocol"/> se presentan los mensajes de diagnóstico generados por una versión de Greenstone configurada para resaltar el proceso de inicialización. El programa arranca con la función <i>main()</i> del archivo <i>recpt/librarymain.cpp</i>. Crea un objeto Recepcionista y un objeto Protocolo nulo, luego recorre el archivo <i>gsdlsite.cfg</i> (ubicado en el mismo directorio que el ejecutable <i>library</i>) en busca de <i>gsdlhome</i> y guarda su valor en una variable. Para cada colección en lÃnea âlista establecida leyendo los directorios de <i>GSDLHOME/collect</i> â el programa crea un objeto de colección mediante el objeto Protocolo nulo, que contiene objetos Filtro, Búsqueda y Fuente, asà como algunas llamadas cableadas a <i>configure()</i>.</Text> 4849 <Text id="1138">A continuación, la función <i>main()</i> agrega el objeto Protocolo nulo al recepcionista, que mantiene una matriz de clase de base de protocolos en un campo de datos protegidos, y luego activa varios convertidores. La función <i>main()</i> crea todos los objetos Acción y Consulta que se utilizan en el ejecutable y los incorpora al recepcionista. La función concluye al activar la función <i>cgiwrapper()</i> ubicada en <i>cgiwrapper.cpp</i>, que efectúa a su vez un número importante de inicializaciones de objetos.</Text> 4850 <Text id="1139">La función <i>cgiwrapper()</i> comprende tres partes: configuración, inicialización y generación de página. En primer lugar, se efectúan algunas llamadas cableadas a la función <i>configure()</i>, luego se lee el archivo <i>gsdlsite.cfg</i> y se aplica <i>configure</i> a cada lÃnea. Lo mismo ocurre con el archivo <i>etc/main.cfg</i>.</Text> 4851 <Text id="1140">La segunda fase de <i>cgiwrapper()</i> activa <i>init()</i>. El objeto Recepcionista sólo hace una llamada a su función <i>init()</i>, pero esta acción invoca las funciones <i>init()</i> de los diferentes objetos que contiene. Primero una llamada cableada a <i>configure()</i> para instalar <i>collectdir</i>, y luego se leen los archivos de macros. Se activa la función <i>init()</i> de cada acción. Lo mismo ocurre con cada protocolo almacenado en el recepcionista, pero en el sistema que se describe aquà sólo se almacena el protocolo nulo. La activación de la función <i>init()</i> de este objeto suscita otras configuraciones: en cada colección del protocolo nulo se leen y se tratan los archivos especÃficos de la colección <i>build.cfg</i> y <i>collect.cfg</i>, y cada lÃnea activa la función <i>configure()</i>.</Text> 4852 <Text id="1141">La fase final de <i>cgiwrapper()</i> consiste en analizar los argumentos CGI y luego activar la acción adecuada. Ambas acciones se efectúan con la asistencia del objeto Recepcionista.</Text> 4834 4853 <Text id="1142">Los códigos de configuración, inicialización y generación de páginas están separados porque Greenstone está concebido para funcionar como servidor (con Fast-CGI, el protocolo CORBA, o la versión Biblioteca Local de Windows). En ese modo de funcionamiento, el código de configuración y de inicialización sólo se ejecuta una vez, y luego el programa permanece en memoria y genera numerosas páginas Web en respuesta a las consultas de los usuarios sin necesidad de volverse a inicializar.</Text> 4835 4854 </Content> … … 5164 5183 <CodeLine>}</CodeLine> 5165 5184 </Figure> 5166 <Text id="1219">En la Figura <CrossRef target="Figure" ref="programming_a_list_of_integers_using_stl"/> se muestra un programa equivalente que utiliza STL. Ya no es necesario definir una estructura de datos adecuada en el código, sino que basta con la directiva #include <list> de la lÃnea 2 que contiene la plantilla para la lista definida en STL. El objeto se denomina âclase Contenedorâ ya que cuando se declara una variable de este tipo se especifica también el tipo que se desea que almacene. En la lÃnea 19 se elabora una lista de números enteros con la instrucción list<int> vals;. Se pueden agregar elementos al objeto mediante la función miembro <i>push_back ( 5167 <Text id="1220">Las lÃneas 6-12 efectúan el trabajo principal. Sigue habiendo dos inicializaciones y un bucle <i>while</i>, pero por lo demás la nueva sintaxis tiene poco en común con la antigua. En esta nueva forma de tratamiento es fundamental una variable de tipo <i>iterator</i> (lÃnea 7). Numerosas clases STL incluyen tipos <i>iterator</i> para ofrecer una manera uniforme de recorrer una secuencia de objetos de contenedor. El primer elemento se devuelve con <i>begin( )</i> y el elemento que sigue al último elemento se devuelve con <i>end()</i>. Se pasa al elemento siguiente mediante la operación de incremento ++, que es sobrecargada por la clase <i>iterator</i> para implementar esta tarea, y se accede al valor almacenado mediante una operación de derreferenciación ( <i>*curr</i> en la lÃnea 10) también sobrecargada.</Text>5185 <Text id="1219">En la Figura <CrossRef target="Figure" ref="programming_a_list_of_integers_using_stl"/> se muestra un programa equivalente que utiliza STL. Ya no es necesario definir una estructura de datos adecuada en el código, sino que basta con la directiva #include <list> de la lÃnea 2 que contiene la plantilla para la lista definida en STL. El objeto se denomina âclase Contenedorâ ya que cuando se declara una variable de este tipo se especifica también el tipo que se desea que almacene. En la lÃnea 19 se elabora una lista de números enteros con la instrucción list<int> vals;. Se pueden agregar elementos al objeto mediante la función miembro <i>push_back ()</i>, como se hace en las lÃneas 20-21.</Text> 5186 <Text id="1220">Las lÃneas 6-12 efectúan el trabajo principal. Sigue habiendo dos inicializaciones y un bucle <i>while</i>, pero por lo demás la nueva sintaxis tiene poco en común con la antigua. En esta nueva forma de tratamiento es fundamental una variable de tipo <i>iterator</i> (lÃnea 7). Numerosas clases STL incluyen tipos <i>iterator</i> para ofrecer una manera uniforme de recorrer una secuencia de objetos de contenedor. El primer elemento se devuelve con <i>begin()</i> y el elemento que sigue al último elemento se devuelve con <i>end()</i>. Se pasa al elemento siguiente mediante la operación de incremento ++, que es sobrecargada por la clase <i>iterator</i> para implementar esta tarea, y se accede al valor almacenado mediante una operación de derreferenciación ( <i>*curr</i> en la lÃnea 10) también sobrecargada.</Text> 5168 5187 <Text id="1221">La implementación STL de este programa es un poco más concisa que el código convencional (25 lÃneas, en lugar de 31). Las ventajas son más importantes en proyectos más voluminosos, ya que el objeto <i>list</i> de STL tiene un potencial mayor de lo que muestra el ejemplo. Este objeto incluye, por ejemplo, una lista doblemente enlazada que admite diversas formas de inserción y supresión. Se requerirÃan tareas de programación suplementarias para integrar estas funciones en la versión de lista de números enteros básica.</Text> 5169 <Text id="1222">Obsérvese que el parámetro <i>total_int_list</i> de la Figura <CrossRef target="Figure" ref="programming_a_list_of_integers_using_stl"/> se ha implementado como puntero para que corresponda con el puntero utilizado en <i>total_int_list</i> de la Figura <CrossRef target="Figure" ref="programming_a_list_of_integers"/>. En STL, suele ser más natural (y preferible) utilizar referencias en lugar de punteros. Asà pues, el parámetro se convierte en <i>list<int>& head</i>, y sus funciones miembro se activan con la sintaxis <i>head.begin( 5188 <Text id="1222">Obsérvese que el parámetro <i>total_int_list</i> de la Figura <CrossRef target="Figure" ref="programming_a_list_of_integers_using_stl"/> se ha implementado como puntero para que corresponda con el puntero utilizado en <i>total_int_list</i> de la Figura <CrossRef target="Figure" ref="programming_a_list_of_integers"/>. En STL, suele ser más natural (y preferible) utilizar referencias en lugar de punteros. Asà pues, el parámetro se convierte en <i>list<int>& head</i>, y sus funciones miembro se activan con la sintaxis <i>head.begin();</i> y asà sucesivamente.</Text> 5170 5189 </Content> 5171 5190 </Section> … … 5208 5227 </Figure> 5209 5228 <Text id="1226">En STL, las matrices asociativas se constituyen mediante el objeto <i>map</i> (correspondencia). En la Figura <CrossRef target="Figure" ref="using_associative_arrays_in_stl"/> se presenta un ejemplo un tanto artificial que almacena la edad de tres personas (Alicia, Pedro y Maria) en una matriz asociativa indizada con sus nombres (lÃneas 19-22). El problema es escribir una función que calcule la edad total de todas las personas presentes, sin saber ni cuántas ni quiénes son. Por supuesto, se podrÃa resolver este problema con una matriz clásica de números enteros indizados numéricamente. Este ejemplo está concebido para ilustrar las funciones del objeto <i>map</i> y poner de manifiesto las semejanzas de tratamiento con el objeto <i>list</i> acompañado de un <i>iterator</i>.</Text> 5210 <Text id="1227">Al igual que <i>list</i>, <i>map</i> es una clase de contenedor. Sin embargo, cuando se declara una variable de este tipo, es preciso especificar dos cosas: el tipo de Ãndice y el tipo de elemento<FootnoteRef id=" 4"/>. Como se puede apreciar en la lÃnea 19, se obtiene una matriz asociativa que almacena números enteros indizados por cadenas utilizando <i>char*</i> (que es la manera de declarar una cadena en C++) como tipo de Ãndice, seguido de <i>int</i> como tipo de elemento.</Text>5229 <Text id="1227">Al igual que <i>list</i>, <i>map</i> es una clase de contenedor. Sin embargo, cuando se declara una variable de este tipo, es preciso especificar dos cosas: el tipo de Ãndice y el tipo de elemento<FootnoteRef id="5"/>. Como se puede apreciar en la lÃnea 19, se obtiene una matriz asociativa que almacena números enteros indizados por cadenas utilizando <i>char*</i> (que es la manera de declarar una cadena en C++) como tipo de Ãndice, seguido de <i>int</i> como tipo de elemento.</Text> 5211 5230 <Text id="1228">Existen diversas maneras de almacenar elementos en la matriz asociativa. En las lÃneas 20-22 del ejemplo se utiliza el Ãndice de la matriz sobrecargada [ ] para inicializar el cuadro con la edad de las tres personas. La semejanza entre <i>total_int_table</i>, que efectúa el cálculo principal en el programa, y <i>total_int_list</i> en la Figura <CrossRef target="Figure" ref="programming_a_list_of_integers"/> es notable. De hecho, estos dos objetos son casi idénticos y no es una coincidencia. STL recurre en gran medida a la herencia, de tal modo que objetos diferentes utilizan las mismas operaciones fundamentales. Asà ocurre sobre todo con los <i>iterators</i>. Las pequeñas diferencias entre las dos funciones consisten en que el <i>iterator</i> procede aquà de <i>map<char*, int></i>, y que el acceso a sus elementos se hace con la instrucción curr->second(); en efecto, la derreferenciación de la variable <i>(*curr)</i> está definida para devolver un objeto de tipo <i>pair</i>. Esta operación registra el nombre del Ãndice ( <i>first</i>) y el valor del elemento ( <i>second</i>), pero sólo nos interesa este último. Por lo demás, el código permanece igual. La única diferencia que persiste âel cambio del único argumento de la función de puntero a referenciaâ es superficial.</Text> 5212 5231 <Text id="1229">El código de Greenstone utiliza ampliamente otros dos tipos STL: <i>vector</i> (vector) y <i>set</i> (conjunto). El primero facilita las matrices dinámicas y el segundo admite las operaciones matemáticas de conjunto como la unión, la intersección y la diferencia.</Text> … … 5245 5264 </Footnote> 5246 5265 <Footnote id="3"> 5247 <Text id="1248" />5266 <Text id="1248">Debe darse cuenta de que las versiones más recientes de la colección Demo usan un clasificador de JerarquÃa para mostrar el metadato Cómo. En este caso se mostrará ligeramente diferente de cómo aparece en la Figura <CrossRef target="Figure" ref="list_classifier"/>.</Text> 5248 5267 </Footnote> 5249 5268 <Footnote id="4"> -
trunk/gsdl-documentation/manuals/xml-source/es/Install_es.xml
r13781 r13949 79 79 <Text id="23">Las distintas opciones para las versiones Windows y Unix de Greenstone</Text> 80 80 </Title> 81 <File width="642" height="295" url="images/Install_Fig_1. gif"/>81 <File width="642" height="295" url="images/Install_Fig_1.png"/> 82 82 </Figure> 83 83 <Text id="24">Hay muchos factores que inciden (o pueden incidir) en el procedimiento de instalación. Antes de proseguir la lectura, deténgase en los siguientes puntos:</Text> … … 145 145 </Title> 146 146 <Content> 147 <Text id="45">En el CD-ROM hay dos programas binarios Windows distintos: la <i>Biblioteca Local</i> y la <i>Biblioteca Web</i>. La instalación por defecto mencionada más arriba selecciona la versión <i>Biblioteca Local</i>. Le recomendamos encarecidamente que utilice esta versión. La Biblioteca Web, que es mucho más difÃcil de instalar, sólo es necesaria si usted utiliza ya un servidor Web y experimenta conflictos de asignación de puerto al usar la Biblioteca Local. A pesar de su modesto nombre, la Biblioteca Local ofrece una capacidad completa y autónoma de servidor Web.</Text>147 <Text id="45">En el CD-ROM hay dos programas binarios Windows distintos: la <i>Biblioteca Local</i> y la <i>Biblioteca Web</i>. La instalación descrita más arriba selecciona la versión <i>Biblioteca Local</i>. Le recomendamos encarecidamente que utilice esta versión. La Biblioteca Web, que es más difÃcil de instalar, sólo es necesaria si usted utiliza ya un servidor Web y quiero usarlo para Greenstone . A pesar de su modesto nombre, la Biblioteca Local ofrece una capacidad completa y autónoma de servidor Web.</Text> 148 148 <Text id="46"><b>La Biblioteca Local.</b> Este programa permite, a cualquier computadora equipada con Windows, distribuir colecciones Greenstone previamente creadas. La colección de demostración de Greenstone se instalará automáticamente; se pueden instalar también las demás colecciones que figuran en el CD-ROM (véase la Sección <CrossRef target="Chapter" ref="greenstone_collections"/>). El programa de Biblioteca Local es el mismo utilizado en los CD-ROM producidos por el sistema Greenstone.</Text> 149 149 <Text id="47">La Biblioteca Local está destinada a utilizarse en computadoras autónomas o en computadoras que aún no están equipadas con un servidor Web. Contiene un pequeño servidor Web incorporado para que otras computadoras en la misma red puedan también acceder a la biblioteca. (Sin embargo, este servidor Web tiene una capacidad de configuración limitada.)</Text>
Note:
See TracChangeset
for help on using the changeset viewer.