Changeset 13949


Ignore:
Timestamp:
2007-02-27T09:39:17+13:00 (17 years ago)
Author:
lh92
Message:

Updated to be consistent with the English manuals. Many thanks to Jesus Tramullas

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  
    132132<CodeLine>xcopy  /s  d:\collect\dlpeople\* import</CodeLine>
    133133<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>
    135135<CodeLine>perl –S import.pl dlpeople</CodeLine>
    136136<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>
     
    254254<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>
    255255</th>
    256 <th> </th>
    257256<th>
    258257<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>
     
    16871686<TableContent>
    16881687<tr>
    1689 <th width="@width"/>
    1690 <th width="@width"/>
     1688<th/>
     1689<th/>
    16911690<th>
    16921691<Text id="408"><b>Objetivo</b></Text>
     
    17171716</tr>
    17181717<tr>
     1718<th width="60"/>
    17191719<th>
    17201720<Text id="416"><i>RecPlug</i></Text>
     
    17311731</tr>
    17321732<tr>
     1733<th width="60"/>
    17331734<th>
    17341735<Text id="420"><i>GAPlug</i></Text>
     
    17451746</tr>
    17461747<tr>
     1748<th width="60"/>
    17471749<th>
    17481750<Text id="424"><i>TEXTPlug</i></Text>
     
    17591761</tr>
    17601762<tr>
     1763<th width="60"/>
    17611764<th>
    17621765<Text id="428"><i>HTMLPlug</i></Text>
     
    17731776</tr>
    17741777<tr>
     1778<th width="60"/>
    17751779<th>
    17761780<Text id="432"><i>WordPlug</i></Text>
     
    17871791</tr>
    17881792<tr>
     1793<th width="60"/>
    17891794<th>
    17901795<Text id="436"><i>PDFPlug</i></Text>
     
    18011806</tr>
    18021807<tr>
     1808<th width="60"/>
    18031809<th>
    18041810<Text id="440"><i>PSPlug</i></Text>
     
    18151821</tr>
    18161822<tr>
     1823<th width="60"/>
    18171824<th>
    18181825<Text id="444"><i>EMAILPlug</i></Text>
     
    18291836</tr>
    18301837<tr>
     1838<th width="60"/>
    18311839<th>
    18321840<Text id="448"><i>BibTexPlug</i></Text>
     
    18431851</tr>
    18441852<tr>
     1853<th width="60"/>
    18451854<th>
    18461855<Text id="452"><i>ReferPlug</i></Text>
     
    18571866</tr>
    18581867<tr>
     1868<th width="60"/>
    18591869<th>
    18601870<Text id="456"><i>SRCPlug</i></Text>
     
    18711881</tr>
    18721882<tr>
     1883<th width="60"/>
    18731884<th>
    18741885<Text id="460"><i>ImagePlug</i></Text>
     
    18851896</tr>
    18861897<tr>
     1898<th width="60"/>
    18871899<th>
    18881900<Text id="464"><i>SplitPlug</i></Text>
     
    18991911</tr>
    19001912<tr>
     1913<th width="60"/>
    19011914<th>
    19021915<Text id="468"><i>FOXPlug</i></Text>
     
    19131926</tr>
    19141927<tr>
     1928<th width="60"/>
    19151929<th>
    19161930<Text id="472"><i>ZIPPlug</i></Text>
     
    19441958</tr>
    19451959<tr>
     1960<th width="60"/>
    19461961<th>
    19471962<Text id="481"><i>GBPlug</i></Text>
     
    19581973</tr>
    19591974<tr>
     1975<th width="60"/>
    19601976<th>
    19611977<Text id="485"><i>TCCPlug</i></Text>
     
    21882204<Figure id="xml_format">
    21892205<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>
    21912207<SubTitle>
    2192 <Text id="547">a) Definición de Tipo de Documento (DTD);</Text>
     2208<Text id="547">(a)</Text>
    21932209</SubTitle>
    21942210</Title>
     
    22072223<Text id="548"/>
    22082224<SubTitle>
    2209 <Text id="549">b) Ejemplo de archivo de metadatos</Text>
     2225<Text id="549">(b)</Text>
    22102226</SubTitle>
    22112227</Title>
     
    22912307<File width="605" height="280" url="images/Dev_Fig_12.png"/>
    22922308</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>
    22942310<Figure id="datelist_classifier">
    22952311<Title>
     
    23132329<TableContent>
    23142330<tr>
     2331<th width="132"/>
    23152332<th>
    23162333<Text id="576"><b>Argumento</b></Text>
     
    23242341<Text id="578"><i>Hierarchy</i></Text>
    23252342</th>
     2343<th width="92"/>
    23262344<th>
    23272345<Text id="579">Clasificación jerárquica</Text>
     
    23642382<Text id="588">List</Text>
    23652383</th>
     2384<th width="92"/>
    23662385<th>
    23672386<Text id="589">Lista alfabética de los documentos</Text>
     
    23882407<Text id="594"><i>SectionList</i></Text>
    23892408</th>
     2409<th width="92"/>
    23902410<th>
    23912411<Text id="595">Lista de las secciones en los documentos</Text>
     
    23962416<Text id="596"><i>AZList</i></Text>
    23972417</th>
     2418<th width="92"/>
    23982419<th>
    23992420<Text id="597">Lista de documentos dividida por intervalos alfabéticos</Text>
     
    24202441<Text id="602"><i>AZSectionList</i></Text>
    24212442</th>
     2443<th width="92"/>
    24222444<th>
    24232445<Text id="603">Como <i>AZList</i> pero incluye cada sección del documento</Text>
     
    24282450<Text id="604"><i>DateList</i></Text>
    24292451</th>
     2452<th width="92"/>
    24302453<th>
    24312454<Text id="605">Similar a <i>AZList</i> pero ordenada por fechas</Text>
     
    26602683<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>
    26612684<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>
    26632686</Indented>
    26642687<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>
    26662689</Indented>
    26672690<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>
    26692692</Indented>
    26702693<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>
    26722695</Indented>
    26732696<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>
    26752698</Indented>
    26762699<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>
    26782701</Indented>
    26792702<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>
     
    28782901</th>
    28792902<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>
    28812904</th>
    28822905</tr>
     
    29552978</th>
    29562979<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>
    29582981</th>
    29592982</tr>
     
    30743097</Bullet>
    30753098<Bullet>
    3076 <Text id="792">activando la función <i>filter( )</i> mediante el protocolo nulo.</Text>
     3099<Text id="792">activando la función <i>filter()</i> mediante el protocolo nulo.</Text>
    30773100</Bullet>
    30783101</BulletList>
     
    30963119<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>
    30973120<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( )</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>
     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>
    30993122</Content>
    31003123</Subsection>
     
    32843307<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&lt;unsigned short&gt;</i> y que recibe el nombre abreviado de <i>usvector</i>.</Text>
    32853308<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>
    32873310<Figure id="overloaded_operators_to_text_t" class="withLineNumber">
    32883311<Title>
     
    33283351</th>
    33293352<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( )</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&lt;text_t&gt;</i>) para rellenar con los datos leídos.</Text>
     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&lt;text_t&gt;</i>) para rellenar con los datos leídos.</Text>
    33313354</th>
    33323355</tr>
     
    33443367</th>
    33453368<th width="450">
    3346 <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>
     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>
    33473370</th>
    33483371</tr>
     
    33603383</th>
    33613384<th width="450">
    3362 <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>
     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>
    33633386</th>
    33643387</tr>
     
    34383461<CodeLine>};</CodeLine>
    34393462</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>
    34413464<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>
    34423465<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>
     
    34733496<CodeLine>void mgq_stemword (unsigned char *word);</CodeLine>
    34743497</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( )</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>
    3476 <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>
     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>
    34773500<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>
    34793502</Content>
    34803503</Subsection>
     
    35143537<CodeLine>}; </CodeLine>
    35153538</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( )</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>
     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>
    35193542<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>
    35203543<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>
     
    36113634<CodeLine>};</CodeLine>
    36123635</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>
    36143637</Content>
    36153638</Part>
     
    36613684</BulletList>
    36623685<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>
    36643687<Figure id="how_a_filter_option_is_stored">
    36653688<Title>
     
    38033826</th>
    38043827<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>
    38063829</th>
    38073830</tr>
     
    39233946<tr>
    39243947<th width="132">
    3925 <Text id="952"><i>get_protocol_name( )</i></Text>
     3948<Text id="952"><i>get_protocol_name()</i></Text>
    39263949</th>
    39273950<th width="397">
     
    39313954<tr>
    39323955<th width="132">
    3933 <Text id="954"><i>get_collection_list( )</i></Text>
     3956<Text id="954"><i>get_collection_list()</i></Text>
    39343957</th>
    39353958<th width="397">
     
    39393962<tr>
    39403963<th width="132">
    3941 <Text id="956"><i>has_collection( )</i></Text>
     3964<Text id="956"><i>has_collection()</i></Text>
    39423965</th>
    39433966<th width="397">
     
    39473970<tr>
    39483971<th width="132">
    3949 <Text id="958"><i>ping( )</i></Text>
     3972<Text id="958"><i>ping()</i></Text>
    39503973</th>
    39513974<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( )</i>.</Text>
    3953 </th>
    3954 </tr>
    3955 <tr>
    3956 <th width="132">
    3957 <Text id="960"><i>get_collectinfo( )</i></Text>
     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>
    39583981</th>
    39593982<th width="397">
     
    39633986<tr>
    39643987<th width="132">
    3965 <Text id="962"><i>get_filterinfo( )</i></Text>
     3988<Text id="962"><i>get_filterinfo()</i></Text>
    39663989</th>
    39673990<th width="397">
     
    39713994<tr>
    39723995<th width="132">
    3973 <Text id="964"><i>get_filteroptions( )</i></Text>
     3996<Text id="964"><i>get_filteroptions()</i></Text>
    39743997</th>
    39753998<th width="397">
     
    39794002<tr>
    39804003<th width="132">
    3981 <Text id="966"><i>filter( )</i></Text>
     4004<Text id="966"><i>filter()</i></Text>
    39824005</th>
    39834006<th width="397">
     
    39874010<tr>
    39884011<th width="132">
    3989 <Text id="968"><i>get_document( )</i></Text>
     4012<Text id="968"><i>get_document()</i></Text>
    39904013</th>
    39914014<th width="397">
     
    39954018</TableContent>
    39964019</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>
    39984021<Figure id="null_protocol_api">
    39994022<Title>
     
    40334056<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>
    40344057<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( )</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>
    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>
    40374060</Content>
    40384061</Section>
     
    41684191<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>
    41694192<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( )</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>
     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>
    41714194<Figure id="action_base_class_api">
    41724195<Title>
     
    42164239<CodeLine>};</CodeLine>
    42174240</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>
    42194242<Text id="1010">La explicación de las funciones miembro es la siguiente:</Text>
    42204243<BulletList>
    42214244<Bullet>
    4222 <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>
     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>
    42234246</Bullet>
    42244247<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>
    42264249</Bullet>
    42274250<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>
    42294252</Bullet>
    42304253<Bullet>
    4231 <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>
     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>
    42324255</Bullet>
    42334256<Bullet>
    4234 <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>
     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>
    42354258</Bullet>
    42364259<Bullet>
    4237 <Text id="1016"><i>define_internal_macros( )</i> define todas las macros relacionadas con las páginas generadas por esta acción.</Text>
     4260<Text id="1016"><i>define_internal_macros()</i> define todas las macros relacionadas con las páginas generadas por esta acción.</Text>
    42384261</Bullet>
    42394262<Bullet>
    4240 <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>
     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>
    42414264</Bullet>
    42424265<Bullet>
    4243 <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>
     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>
    42444267</Bullet>
    42454268</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>
    42474270</Content>
    42484271</Subsection>
     
    43654388<CodeLine>};</CodeLine>
    43664389</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( )</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>
     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>
    43694392<CodeLine>cout &lt;&lt; text_t2ascii &lt;&lt; display &lt;&lt; “_unamacro_”</CodeLine>
    43704393<CodeLine>                                &lt;&lt; “_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( )</i>. Las demás funciones miembro públicas proporcionan el apoyo de nivel inferior.</Text>
     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>
    43724395</Content>
    43734396</Subsection>
     
    44674490<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>
    44684491<CodeLine>void cgiwrapper (receptionist &amp;recpt,</CodeLine>
    4469 <CodeLine>  text_t collection);</CodeLine>
    4470 </th>
    4471 </tr>
    4472 <tr>
    4473 <th width="140">
     4492<CodeLine>text_t collection);</CodeLine>
    44744493<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>
    44754494</th>
     
    47344753</Title>
    47354754<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>
    47374756<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>
    47414760<Figure id="initialising_greenstone_using_the_null_protocol">
    47424761<Title>
     
    48274846<CodeLine>End.</CodeLine>
    48284847</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( )</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>
     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>
    48344853<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>
    48354854</Content>
     
    51645183<CodeLine>}</CodeLine>
    51655184</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 &lt;list&gt; 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&lt;int&gt; 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>
    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 &lt;list&gt; 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&lt;int&gt; 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>
    51685187<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&lt;int&gt;&amp; head</i>, y sus funciones miembro se activan con la sintaxis <i>head.begin( );</i> y así sucesivamente.</Text>
     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&lt;int&gt;&amp; head</i>, y sus funciones miembro se activan con la sintaxis <i>head.begin();</i> y así sucesivamente.</Text>
    51705189</Content>
    51715190</Section>
     
    52085227</Figure>
    52095228<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>
    52115230<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&lt;char*, int&gt;</i>, y que el acceso a sus elementos se hace con la instrucción curr-&gt;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>
    52125231<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>
     
    52455264</Footnote>
    52465265<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>
    52485267</Footnote>
    52495268<Footnote id="4">
  • trunk/gsdl-documentation/manuals/xml-source/es/Install_es.xml

    r13781 r13949  
    7979<Text id="23">Las distintas opciones para las versiones Windows y Unix de Greenstone</Text>
    8080</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"/>
    8282</Figure>
    8383<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>
     
    145145</Title>
    146146<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>
    148148<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>
    149149<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.