Gestor de Noticias Alligator

PROYECTO FIN DE CICLO
Gestor de Noticias
‘Alligator’
Carlos Vázquez Lizarraga

Los documentos, elementos gráficos, vídeos, transparencias y otros recursos didácticos incluidos en este
contenido pueden contener imprecisiones técnicas o errores tipográficos. Periódicamente se realizan cambios
en el contenido. Fomento Ocupacional FOC SL puede realizar en cualquier momento, sin previo aviso,
mejoras y/o cambios en el contenido
Es responsabilidad del usuario el cumplimiento de todas las leyes de derechos de autor aplicables. Ningún
elemento de este contenido (documentos, elementos gráficos, vídeos, transparencias y otros recursos
didácticos asociados), ni parte de este contenido puede ser reproducida, almacenada o introducida en un
sistema de recuperación, ni transmitida de ninguna forma ni por ningún medio (ya sea electrónico, mecánico,
por fotocopia, grabación o de otra manera), ni con ningún propósito, sin la previa autorización por escrito de
Fomento Ocupacional FOC SL.
Este contenido está protegido por la ley de propiedad intelectual e industrial. Pertenecen a Fomento
Ocupacional FOC SL los derechos de autor y los demás derechos de propiedad intelectual e industrial sobre
este contenido.
Sin perjuicio de los casos en que la ley aplicable prohíbe la exclusión de la responsabilidad por daños,
Fomento Ocupacional FOC SL no se responsabiliza en ningún caso de daños indirectos, sean cuales fueren
su naturaleza u origen, que se deriven o de otro modo estén relacionados con el uso de este contenido.
© 2011 Fomento Ocupacional FOC SL todos los derechos reservados.

Índice
1. Introduccion ........................................................................................ ¡Error! Marcador no definido.
2. Estudio del Problema............................................................................ ¡Error! Marcador no definido.
2.1 Funciones y rendimientos deseados......................................................¡Error! Marcador no definido.
2.2 Objetivos ................................................................................................................................... 4
2.3 Planteamiento y evaluación del problema ...................................................................................... 4
2.4 Justificación de la solución elegida ........................................................¡Error! Marcador no definido.
3. Análisis del Problema ....................................................................................................................... 5
3.1 Modelado de la Solución ................................................................................................................ 7
3.2 Recursos humanos, hardware y software ......................................................................................... 10
3.3 Planificación temporal ................................................................................................................. 27
4. Ejecución del proyecto ............................................................................. ¡Error! Marcador no definido.
5. Pruebas e Implatación .............................................................................. ¡Error! Marcador no definido.
5.1 Pruebas realizadas en el proyectos .......................................................¡Error! Marcador no definido.
5.2 Implantación del proyecto ...................................................................¡Error! Marcador no definido.
6. Documentación del Proyecto .......................................................................................................... 34
6.1 Manual de instalación................................................................................................................ 34
6.2 Manual de usuarios ................................................................................................................... 34
6.3 Manual de Adminsitración.......................................................................................................... 40
6.4 Cumpliemento de los objetivos iniciales ....................................................................................... 48
6.5 Mejoras del proyecto................................................................................................................... 4
Gestor de noticias
1. Introduccion, Justificacion y alternativas
1.1 Introducción:
El proyecto de gestión de noticias consiste principalmente en un núcleo de librerías
destinadas a desarrollar las funciones más comunes de un periódico digital típico. En
torno a estas librerías se disponen una aplicación de escritorio a través de la que
podemos gestionar las entradas, maquetar los contenidos, previsualizarlos y en
definitiva estructurar la página. Finalmente una aplicación Web Windows Forms se
encarga, sobre la información recogida de la base de datos y que ha sido
manipulada y estructurada por las librerías, de servirla al usuario final en forma de
una página web dinámica.
1.2 Justificación
Para la elección del proyecto, mas allá de cuestiones como la originalidad, u otras
consideraciones secundarias, he primado las cuestiones prácticas que consoliden los
conocimientos del módulo, por lo que he tenido en cuenta mayormente que englobe
las principales materias impartidas en el curso; Implementación de librerías,
orientación a objetos, aplicaciones de escritorio, consultas, manejo de bases de
datos y programación Web. Finalmente pretendo incluir al menos un lenguaje no
usado en el curso como complemento adicional. Un módulo en JavaScript.
1.3 Planteamiento y evaluación de diversas soluciones.

El proyecto puede ser enfocado desde las siguientes aproximaciones alternativas:
-Un trabajo desarrollado en asp.net, altamente acoplado y codificado dentro de cada

pagina. Sin utilización de plantillas y sin desarrollar una librería especializada mas
allá de funciones genéricas. Esta aproximación nos lleva a un proyecto de rápido
desarrollo y nula reutilización en otros entornos web (tiendas online, blogs, etc.). El
mantenimiento es más dificultoso ya que el límite entre lógica y estructura esta
menos definido. También tiene el inconveniente de que no podría ser modificado por
usuarios sin conocimientos del lenguaje ni de la estructura de la página, en un
enfoque orientado hacia el programador y no hacia el diseñador web.
-Adaptación de un gestor de código libre: Existen varios gestores de gran difusi ón,
algunos especializados en el ámbito de los periódicos online como por ejemplo
OpenCms. Esta alternativa nos obliga primero a documentarnos y conocer bien la
lógica del programa antes de intentar adaptarlo a nuestras necesidades. La
desventaja de esta alternativa es que si bien el proceso de rediseño puede ser
bastante ágil, ya que disponemos de toda la funcionalidad de forma prexistente, no
podemos en principio estimar el tiempo que necesitaremos dedicar a el conocimiento
de la aplicación, ni el nivel de complejidad que nos vamos a encontrar. En contra,
una vez familiarizados con ella podremos aplicar la solución a una gran variedad de
proyectos con unos plazos de entrega muy ajustados.
-Utilización de HTML estático: Esta alternativa es de todas la menos optima.

Utilizable solo en caso de no disponer de las herramientas o conocimientos para
desarrollarla de forma dinámica. Es de todas la más rápida de llevar a cabo, pero su
mantenimiento y actualización resulta cuanto menos caótico en un entorno
monousuario, y prácticamente imposible en uno multiusuario. Encontrar los puntos
de inserción adecuados a las noticias en un bosque de etiquetas HTML es complejo.
Al no estar basado en plantillas, rediseñar el sitio puede conllevar a tener que
rescribir el código completo de la página. De cualquier forma, no conseguiríamos
obtener un gestor de esta forma, en última instancia el gestor será el programa que
utilicemos para editar el código HTML de forma manual.
-La misma aproximación propuesta con combinaciones de tecnologías, frameworks y

lenguajes diferentes. Podríamos usar php en vez de asp, java en vez de c#, o
eclipse en vez de visual studio, pero mas allá de los puntos fuertes y débiles, o las
particularidades sintácticas de cada lenguaje la tarea que tenemos por delante será
en dificultad y tiempo de desarrollo bastante parecida.
2. Objetivos Marcados
El proyecto debe alcanzar los siguientes objetivos:
-Contenido dinámico: La página presentará y formateará información almacenada en

una base de datos. No se implantará una solución basada en HTML estático.
-Modularidad: Las funciones estarán bien definidas y encapsuladas en clases. En la

medida de lo posible se evitará el acoplamiento al proyecto, o se disminuirá al
máximo para poder ser reutilizado en otros proyectos con los mínimos cambios.
-Abstracción de datos: Todas las consultas de datos, y los parámetros de conexión

correspondientes a una determinada sintaxis SQL se encuentran centralizados en
una única clase y no distribuidos por toda la solución. Est o permite la rápida
portabilidad a otros SGBD.
-Solución basada en plantillas y módulos: Una filosofía orientada al diseñador web,

no al programador, en la cual se estructura la pagina en pequeños módulos basados
en plantillas que el usuario podrá modificar y reutilizar fuera del código fuente del
programa, sin ningún tipo de conocimiento de programación, sino de determinadas
etiquetas que indiquen funciones típicas en el procesamiento posterior.
-Interface de maquetado: Un gestor básico de contenidos, que al menos tenga las

funciones más elementales, editar, borrar y añadir noticias, con la posibilidad de
previsualizar los contenidos a medida que se avanza en el maquetado.
-Contenido predefinido: Una colección típica de plantillas y consultas que se ut ilizan

en la mayoría de los periódicos digitales. Menú, noticias resaltadas, noticias mas
leídas, videos, galerías de imágenes, etc., con el que poder trabajar desde el
principio con un mínimo esfuerzo en rediseño.
-Agilizado de respuesta: Funcionalidades de cacheado de pagina y de modulo, para

agilizar el proceso de devolución de la pagina al usuario, ya que el proceso de
generar un portal con un numero elevado de módulos de noticias puede consumir
demasiado tiempo.
-Comentarios: Se incluirá la posibilidad de recopilar información del usuario en forma

de comentarios y anexar los mismos al pie de las noticias.
-Modulo en JavaScript: Uno de los objetivos es introducir al menos una tecnología o

lenguaje no utilizado en el curso, para ello crearé un slider en este lenguaje.
-Prueba Online: Mas allá de presentar la solución, además se intentara desplegar el

proyecto en un servidor web gratuito para comprobar su funcionamiento online.
3. Recursos software y hardware a utilizar
3.1 Recursos software

Se usarán las siguientes herramientas software:
Microsoft Visual Studio 2008, Dreamweaver CS3 (creación de módulos), Photoshop,

Microsoft Access 2010, Microsoft Visio 2010, e IIS en el lado del servidor.
Se usarán los siguientes lenguajes:
C# para las librerías, HTML y CSS para las plantillas, SQL para las consultas a
BBDD, Asp.Net para el código web, JavaScript y la interface DOM para un Slider.
Nota: En principio la elección más lógica del gestor de BBDD debiera ser SQL Server
que es el sistema que hemos tratado en el curso. Sin embargo, y teniendo en cuenta
el plazo de entrega, a la hora de desplegar la solución y buscar un servidor gratuito
la necesidad de hacerlo sobre este último puede complicarse debido a las
restricciones y política del hosting. En este sentido la utilización se Access, como un
simple archivo que centraliza los datos y que se ubica en una simple carpeta de la
solución es una elección que facilita mucho este proceso. Sin embargo en caso de
que la aplicación requiriese una alta concurrencia esta decisión seria inadecuada, se
toma solo por tratarse de un ejercicio.
3.2 Recursos Hardware

Estimar las especificaciones hardware para una aplicación online esta siempre
principalmente vinculado tanto al número de visitas concurrentes que tendrá el sitio,
como al tiempo de procesamiento que necesitamos para responder a esas visitas.
Esta cuestión será siempre el núcleo del que derivaremos nuestras características
hardware.
En principio, si la aplicación va a desplegarse en un hosting contratado, esta cuestión

podrá ser solventada mas fácilmente, una vez que conozcamos el desempeño real
de la aplicación, contrataremos el plan mas adecuado a nuestras necesidades.
Esta ventaja no esta disponible en caso de que la pagina este destinada a alojarse
en un servidor propio y este deba ser adquirido junto a la aplicación.
Resulta bastante complejo conocer la arquitectura hardware necesaria que requerirá
un software en proyecto, sin realizar ningún tipo de prueba de rendimiento, incluso si
establecemos un numero aproximado de visitas por día.
En el módulo de sistemas realizamos un trabajo sobre el montaje y el presupuesto
de un equipo servidor de prueba. Está dentro del segmento básico, y podría utilizarse
como punto de partida.
DELL PowerEdge™ T110 II
Procesador: Intel Core i3-2100, 2C/4T, 3.10GHz, 3M Cache, 65W TDP

Memoria: 8GB Memory, DDR3, 1333MHz
S.Operativo: Microsoft SBS 2011, Essentials Edition, Spanish
Conectividad Raid: C2A - RAID0 with On-board SATA Controller
Disco Duro: 2x 500GB, SATA, 3.5-in, 7.2K RPM Hard Drive
Tarjeta de Red: Intel® PRO/1000PT GbE Single Port Server Adapter,
Lector Dvd: 16X DVD-ROM Drive with SATA
Teclado: Spanish (QWERTY) Dell KB212-B QuietKey USB Keyboard Black
Monitor: Dell 17-inch E170S European Value Flat Panel - Black (TCO99)
Precio: 1264 Euros
3. Análisis del Problema

3.1 Modelado de la Solución
Contenido:
-Modelado UML
-Clases: Interfaces y breve definición.
-Modelo Relacional
-Esquema de la Base de datos.
-Recursos Hardware y software
-Planificación temporal.
void BeginTransaction(System.Data.IsolationLevel Isolation);
void Close();
void CommitTransaction();
OleDbConnection Connection { get; }
ErrorStore Errors { get; }
void Open();
void RollBackTransaction();
OleDbTransaction Transaction { get; }
Definición de la clase: Se encarga de

establecer y mantener una conexión con
una base de datos de tipo access.
Incluye métodos tanto para establecer la
conexión como para realizar operaciones
transaccionales.
void Add(FileCache CssFile);

void Clear();
string GetCssPathList();
Definición de la clase: Mantiene una colección de

ficheros de hojas de estilo (css).
void Add(string Description, string SourceError,
ErrorTypes ErrorType);
void Clear();
List<LibraryGeneral.Msg.Errors.ErrorStore.ErrorMsgObj>
ErrorCollection { get; }
string GetStoredErrors();
void Merge(ErrorStore SourceError);
Definición de la clase: Es la clase que

utilizan el resto de objetos para el
manejo de errores. Permite almacenar los
mensajes de error, su procedencia y el
nivel del error en una colección, asi
como mezclarse con otros objetos
ErrorStore.
Encapsula una clase ErrorMsgObj, que es

la base de la colección, y recopila las
propiedades antes descritas, asi como la
posibilidad de copiarse (clone) para la
funcionalidad merge de la clase
propietaria.
string Content { get; set; }

string Name { get; }
string Path { get; }
string RelativePath { get; }
Definición de la clase: FileCache tiene

como función cargar en memoria un
fichero del disco duro. Es la base de
otra clase como
FileConfigurationManager, y se utiliza
principalmente para acceder a las
plantillas HTML y CSS sin tener que
perder tiempo en acceso a disco.
:
string AddValue(string Section, string Key, string Value);

string GetFullContent();
string GetValue(string Section, string Key);
Definición de FileConfigReader: Permite

almacenar en memoria un fichero de texto
plano con el formato:
[SECCION]
Clave1:valor1
Clave2:valor2
Este objeto se utiliza como almacén para

muchas de las variables globales del sistema
y opciones de configuración, ya que permite
editarse y modificarse con facilidad sin
necesidad de conocimientos de informática ni
aplicaciones especiales.
void AddCommentToModule(string NameType, int IdModule);

void DeleteMainModule(string NameType, int IdModule, int
IdTagValue);
void DeleteMedadataModule(int IdMeta, string NameTable);
void MaintainLenghtMeta(FileConfigReader FileConfig);
void MantainCachePost(PostTemplateCollection
PostCollection);
void MantainCacheWeb();
void NewOrDeleteTransModule(string NameType, int
IdModule);
void NewVisitorToNew(int IdNew);
void RebuildTemplateCollection(PostTemplateCollection
TemplateCollection);
void UpdateMainModule(string NameType, int IdModule, int
IdTagValue);
void UpdateMetadataModule(string NameType, int IdModule);
void UpdateProviderProfile(int IdProviderProfile);
void UpdateTransModule(string NameType, int IdModule);
Definición de la clase: Recoge toda una serie

de operaciones que tienen como objetivo comun
el mantenimiento del sistema. Tanto de la
base de datos como de los objetos creados.
Incluye mantenimiento para los registros que
se van desbordando del portal, el borrado de
la cache de modulo y de web alcanzando un
periodo de expiración, reconstruir la
colección de plantillas y la actualización de
los campos TimeStamp de la base de datos para
un correcto cacheado de modulo.
:
void Add(bool State, int Width, int

Identificator, int InsertionIndex);
void CorrectPointers(int FromPosition, int
LenghtCorrection);
bool GetEmptyInsertionIndex(int StartIndex,
out int PostWidth, out int PointerIndex);
bool GetEmptyInsertionIndex(int StartIndex,
out int PostWidth, out int PointerIndex, out
int InsertionIndex);
bool GetEmptyInsertionIndexByWidth(int
StartIndex, int WithIn, out int
PointerIndex);
bool GetEmptyInsertionIndexByWidth(int
StartIndex, int WithIn, out int
PointerIndex, out int InsertionIndex);
int GetLastPointerIndex { get; }
void GetValuesPointer(int Identificator, out
bool State, out int Width, out int
InsertionIndex);
bool IsCompletlyFilled();
void ResetState();
void SetFilled(int Identificator);
Definición de la clase: Las

plantillas, a la hora de resolver
los modulos, necesitan una
coleccion de punteros dentro de su
contenido string para realizar una
inserción rápida. Este proceso se
realiza antes de que la aplicación
este lista para servir las paginas
y evita que se tenga que buscar
las etiquetas de reemplazo una a
una cuando se recibe la solicitud
de la página. Los objetos que
gestionan una pagina hacen
referencia a un objeto PagePointer
que tiene funcionalidad para
buscar huecos de inserción vacios
o por anchura y crear una
colección de Pointers para esa
pagina especifica.

PageTemplateProvider GetPageTemplateProvider(string
NameProvider, int? MaxPosts, int? Category, UrlObj Url);
Definición de la clase: Los proveedores de

página entregan un objeto
PageTemplateProvider con los registros que
deben mostrarse a nivel de página recogiendo
todo su maquetado. Se usan tanto para el
portal, como para las vistas de categorías y
el detalle de noticias.
:
void GetPost(out string CodePost, out string CssPost,

PostTemplateCollection PostTemplates, int IdModule, int
IdStyle, int IdProvider);
void GetPostCentered(out string CodePost, out string
CssPost, PostTemplateCollection PostTemplates, int
IdModule, int IdStyle, int IdProvider);
Definición de la clase: Esta clase permite

realizar una previsualizacion de un módulo de
pagina. Recibe un proveedor de módulo y a
partir de este lo construye. Permite también
contralar su ubicación en la pagina.
bool BuildPageCacheable(UrlObj Url, bool WithMarkers);

bool BuildPageNonCacheable(UrlObj Url, bool WithMarkers);
string Code { get; }
string CssPathList { get; }
string ErrorMessages();
ErrorStore Errors { get; set; }
Definición de la clase: Es una

abstracción de una pagina web completa.
Se utiliza para la vista de portal y de
categorías. Dispone de colecciones de
ficheros Css, un objeto PagePointers
para controlar las inserciones, un
proveedor de pagina para su maquetado y
una colección de modulos de estilos.
Tiene funcionalidad para renderizar la
pagina tanto en modo NoCacheable (no se
guarda en memoria el contenido html de
los modulos) y cacheable (se almacenan
el contenido para próximas solicitudes,
más rapido)
DataRow GetMetaLinked(int IdMeta);
DataTable GetSourceData { get; }
Definición de la clase: Es la clase que encapsula

los proveedores de página.
bool BuildPageCacheable(UrlObj Url, bool WithMarkers);

string CssPathList { get; }
Definición de la clase: Es una

especilizacion de PageTemplate, tiene
mayores funciones de maquetado, tales
como modulos cuyo proveedor de datos es
dependientes de otro modulo como por
ejemplo, las noticias y sus comentarios.
Tiene funcionalidad para multiples
diseños de página según la estructura de
la plantilla de la pagina. Se utiliza
para el detalle de la noticia.
:
PostTemplateProvider GetTemplateProvider(int
IdModule, int Style, int ProvProfilefk,
PageTemplateProvider PageProvider, int LinkedTo);
PostTemplateProvider
Provider_IdentificationMarker(string IdPosition,
string StylePosition);
PostTemplateProvider
Provider_TypicalCommentsRelateds(string
MaxPostRelated, int IdModule, int Style,
PageTemplateProvider PageProvider, int LinkedTo);
Definición de la clase: Los

proveedores de módulo entregan a cada
sección de la pagina los datos
necesarios para resolver los campos
de su plantilla. Cada Post o módulo
tiene uno o varios proveedores
basados en su familia, por lo que
algunos son intercambiables. Dispone
de métodos para recuperar estos
proveedores pero son privados ya que
no se recuperan directamente desde
esta clase.
:
bool BuildDynamicCachePost(PostTemplateProvider
DataProvider);
string CodeTemplate { get; }
string Css { get; }
FileCache CssFileCache { get; }
void DeleteCacheExpired();
bool GetCachedPosts(int IdItem, int IdLink, DateTime
DateItem, out string ValueItem);
string Html { get; }
string Identificator { set; }
ErrorStore MErrors { get; }
string Name { get; }
void SetCachedPosts(int IdItem, int IdLink, string Code,
DateTime DateItem);
Descripción de la clase: Esta clase representa un

modulo, o una de las plantillas que sumadas
conforman una pagina. Cada módulo tiene su estilo css
y su estructura html. La clase tiene funcionalidad para
recibir un proveedor de modulos para resolver sus
etiquetas, crear y mantener los punteros de inserción,
cachear los resultados para próximas solicitudes e
identificar determinados tokens o etiquetas
especializadas sobre el comportamiento que debe
seguir la plantilla como Default, Necessary o Linked.
Las clases propietarias PostField y section se encargan
de esta última tarea y CacheResult del cacheado.
:
bool BuildTemplateCollection();
void ClearCacheResult();
PostTemplate Get(string NameModule);
SortedList<string, LibraryGestorNews.PostTemplate>
GetCollection { get; }
CssPathCollection GetPathCollections { get; }
Descripcion de la clase: Se trata de una

colección de objetos PostTemplate. Se
inicializa antes de que el servidor
empiece a devolver paginas. Devuelve a
los objetos pagetemplage,
pagetemplatestatic y pagesimplepost la
plantilla que necesite según este
configurado su maquetado en la base de
datos. La construcción de la colección
se define según los estilos que tengamos
incluidos como activos en la base de
datos.
DataRow DataRowSingle { get; }

DataTable DataTableMultiple { get; }
Descripción de la clase: El proveedor de

Módulo, entrega a la plantilla (posttemplate)
la información necesaria para resolver sus
campos.
void AddNonQueryToTransaction(string NameQuery);
void CloseConnection();
void CommitTransaction();
AccessConnection ConectionObj { get; }
int ExecuteNonQuery(string QueryName);
bool ExecuteNonQueryInTransaction();
DataTable GetData(string QueryName);
string GetDataScalar(string QueryName);
GetStylesPosts();
void OpenConnection();
bool Overfloaded(int IdMeta);
StringQueryCollection QueryCollection { get; }
void RollBackTransaction();
bool SetNotResizable(int IdMeta);
bool TryBeginTransaction();
Definición de la clase: Engloba todas la

consultas sobre la base de datos. Tanto los
proveedores de pagina, de módulo, ejecución
de acciones de mantenimiento. Tiene
funcionalidad transaccional. En caso de tener
que migrar la aplicación a un SGDB diferente
habría simplemente que reconvertir la
sintaxis de este módulo a las nuevas
particularidades de SQL y cambiar el modulo
AccessConnection por otro diferente.
public static string

GetValueDelimitedBy(string StringSource,
char Token, int Element)
public static string[]
GetArrayStringDelimitedBy(string
StringSource, string Token)
public static string[]
GetArrayStringDelimitedByArray(string
StringSource, string[] Token)
public static bool
GetArrayStringDelimitedBy(string
StringSource, string TokInit, string TokEnd,
List<string> ValueList, List<int> IndexList,
out string SourceWithoutValues)
public static string
TruncateMaxLenghtByWords(string InString,
int MaxLenght, string TokenMore)
public static void
GetComponentDatetime(DateTime DateTimeIn,
out string DayText, out int DayNum, out
string MonthText, out int MonthNum, out int
YearNumFull, out int YearNumShort)
public static SortedList<string,string>
GetParametersFromUrl(string Url, out string
UrlBase)
public static string GetUrlFromParameters(
SortedList<string,string> Parameters, string
UrlBase)
Definición de la clase: Clase general

para el manejo de strings. Es static,
por lo que no es necesario
inicializarla.
:
bool AddQueryString(string QueryName, string QueryString);

StringQueryCollection.StringQuery GetQueryString(string
QueryName);
Definición de la clase: La clase querys mantiene

una clase StringQuerycollection. Esta clase
mantiene una colección de querys, indexadas por
su nombre, junto con el conjunto de parámetros
y valores necesarios para poder ejecutarse. Para
lanzar una query se obtiene el StringQuery
correspondiente de la colección, se establecen
sus parámetros con addparameter, getparameter
o setparametervalue y se lanza la query. De este
ultima tarea se encarga el objeto querys
mencionado que puede recuperar valores
escalares, realizar selects o enviar consultas de
acción (ExecuteNonQuery). Con este objeto, una
vez definida la string de la consulta es muy fácil
invocarla sin tener que instanciar objetos
connection o command específicos para ella.
bool AddParameter(string Key, string Value);

void Dispose();
bool GetParameter(string Key, out string Value);
string Url { get; }
string UrlBase { get; }
Definición de la clase: Encapsula una ruta html y

permite añadir y recuperar parametros de ella
con el formato:
(url?parameter1=valor&parameter2=valor2)
bool SetWeb(string Url, string HtmlCode, string CssCode);
bool TryGetWeb(int Url, out string HtmlCode, out string
CssCode);
Definición de la clase: Aunque el cacheado por módulo nos

permite una respuesta mas agil a las solicitudes de la
pagina, se establece un cacheado de nivel superior a nivel
de pagina completa. Ante una solicitud de una pagina se
comprueba si existe en la base de datos su url, y en tal
caso se recupera su ultima versión. Es el sistema mas
rápido pero tiene deficiencias con respecto al cacheado
por modulos que que la pagina no se muestra de forma
dinámica y requieren recacheados periódicos.
Esquema de Datanews.mdb
AUTHOR
Columnas
IdAuthor Entero largo 4

NameAuthor Texto 255
CATEGORY
Columnas
IdCategory Entero largo 4

NameCategory Texto 255
COMMENTS
Columnas
IdComment Entero largo 4

IdNew Entero largo 4
Commentary Memo -
DateCommentary Fecha/Hora 8
Nick Texto 255
FAMILYPROVIDERS
Columnas
IdFamily Provider Entero largo 4

NameFamily Prov ider Texto 255
FONTSIZES
Columnas
IdSize Entero largo 4

SizeName Texto 255
SizeValue Texto 255
Lock ed Sí/No 1
METADATA
Columnas
IdMeta Entero largo 4

IdModule Entero largo 4
NameTy pefk Texto 255
DateMeta Fecha/Hora 8
Location Entero 2
IdSty lePositionfk Entero largo 4
Resizable Sí/No 1
Ov erfloaded Entero largo 4
TimeStampValue Fecha/Hora 8
Link edTo Entero largo 4
METADATACATEGORY
Columnas

NameTy pefk Texto 255
IdCategory fk Entero largo 4
Location Entero 2
IdSty lePositionfk Entero largo 4
MultiCategory Sí/No 1
Resizable Sí/No 1
Ov erfloaded Entero largo 4
METADATADYNAMIC
Columnas

NameTy peFk Texto 255
Location Entero largo 4
TempDescription Texto 255
NestedLev el Entero largo 4
NEWS
Columnas

IdSectionfk Entero largo 4
Author Texto 255
Tag Texto 255
Body Memo -
ImageAv atarSrc Texto 255
Link FullNew Texto 255
AuthorPhoto Texto 255
IdTagFk Entero largo 4
DateNew Fecha/Hora 8
Visitors Entero largo 4
Publish Sí/No 1
NEWSCONTAINERS
Columnas
IdContainer Entero largo 4

NameContainer Texto 255
Link Header Texto 255
ExcludeContent Sí/No 1
NEWSCONTAINERSTRANS
Columnas
IdContainerTrans Entero largo 4
IdSty leContainerfk Entero largo 4
IdContainerfk Entero largo 4
IdProv iderProfilefk Entero largo 4
Title Texto 255
SubTitle Texto 255
ImageHead Texto 255
ImageFoot Texto 255
NEWSTRANS
Columnas
IdTrans Entero largo 4

NameContainerfk Texto 255
IdSty leNewfk Entero largo 4
IdSizeFk Entero largo 4
Summary Texto 255
Title Texto 255
ImageSrc Texto 255
FootPictureText Texto 255
ShortBody Memo -
ORPHANS
Columnas
IdOrphan Entero largo 4

IdSty leOrphanfk Entero largo 4
PROVIDERS
Columnas
IdProv ider Entero largo 4

AliasProv ider Texto 255
NameProv ider Texto 255
IdFamily Providerfk Entero largo 4
PROVPROFILES
Columnas
IdProv iderProfile Entero largo 4

NameProfile Texto 255
IdProv iderfk Entero largo 4
MinRowsIterate Entero 2
MaxRowsIterate Entero 2
MultiKey Word Texto 255
ContainerKey Word Texto 255
Only Update Sí/No 1
SECTIONPOST
Columnas
IdSectionPost Entero largo 4

NameSec Texto 255
IdCategory fk Entero largo 4
STYLE
Columnas
IdSty le Entero largo 4

NameFamily Texto 255
WidthValue Texto 255
NameSty le Texto 255
Enabled Sí/No 1
Sy stem Sí/No 1
DescriptionSy stem Texto 255
STYLEPOSITION
Columnas
IdSty lePosition Entero largo 4

NameSty lePosition Texto 255
TAG
Columnas
IdTag Entero largo 4

NameTag Texto 255
TYPEMODULES
Columnas
IdTy peModule Entero largo 4

NameTy pe Texto 255
WEBCACHE
Columnas
IdRev ision Entero largo 4

Url Texto 255
HtmlCode Memo -
CssCode Memo
3.2 Recursos hardware y software
Recursos software
Se usarán las siguientes herramientas software:
Microsoft Visual Studio 2008, Dreamweaver CS3 (creación de módulos), Photoshop,

Microsoft Access 2010, Microsoft Visio 2010, e IIS en el lado del servidor.
Se usarán los siguientes lenguajes:
C# para las librerías, HTML y CSS para las plantillas, SQL para las consultas a
BBDD, Asp.Net para el código web, JavaScript y la interface DOM para un Slider.
Nota: En principio la elección más lógica del gestor de BBDD debiera ser SQL Server
que es el sistema que hemos tratado en el curso. Sin embargo, y teniendo en cuenta
el plazo de entrega, a la hora de desplegar la solución y buscar un servidor gratuito
la necesidad de hacerlo sobre este último puede complicarse debido a las
restricciones y política del hosting. En este sentido la utilización se Access, como un
simple archivo que centraliza los datos y que se ubica en una simple carpeta de la
solución es una elección que facilita mucho este proceso. Sin embargo en caso de
que la aplicación requiriese una alta concurrencia esta decisión seria inadecuada, se
toma solo por tratarse de un ejercicio.
Recursos Hardware
Estimar las especificaciones hardware para una aplicación online esta siempre
principalmente vinculado tanto al número de visitas concurrentes que tendrá el sitio,
como al tiempo de procesamiento que necesitamos para responder a esas visitas.
Esta cuestión será siempre el núcleo del que derivaremos nuestras características
hardware.
En principio, si la aplicación va a desplegarse en un hosting contratado, esta cuestión

podrá ser solventada mas fácilmente, una vez que conozcamos el desempeño real
de la aplicación, contrataremos el plan mas adecuado a nuestras necesidades.
Esta ventaja no esta disponible en caso de que la pagina este destinada a alojarse
en un servidor propio y este deba ser adquirido junto a la aplicación.
Resulta bastante complejo conocer la arquitectura hardware necesaria que requerirá

un software en proyecto, sin realizar ningún tipo de prueba de rendimiento, incluso si
establecemos un numero aproximado de visitas por día.
En el módulo de sistemas realizamos un trabajo sobre el montaje y el presupuesto
de un equipo servidor de prueba. Está dentro del segmento básico, y podría utilizarse
como punto de partida.
DELL PowerEdge™ T110 II

Procesador: Intel Core i3-2100, 2C/4T, 3.10GHz, 3M Cache, 65W TDP
Memoria: 8GB Memory, DDR3, 1333MHz
S.Operativo: Microsoft SBS 2011, Essentials Edition, Spanish
Conectividad Raid: C2A - RAID0 with On-board SATA Controller
Disco Duro: 2x 500GB, SATA, 3.5-in, 7.2K RPM Hard Drive
Tarjeta de Red: Intel® PRO/1000PT GbE Single Port Server Adapter,
Lector Dvd: 16X DVD-ROM Drive with SATA
Teclado: Spanish (QWERTY) Dell KB212-B QuietKey USB Keyboard Black
Monitor: Dell 17-inch E170S European Value Flat Panel - Black (TCO99)
Precio: 1264 Euros
Nota: Ya fueron entregadas en la anterior fase, pero al verlas en la programación de

esta entraga las vuelvo a incluir.
3.3 Planificación temporal
La planificación se establece en tres fases principales. La primera es el desarrollo de la librería,

implementando las interfaces ya establecidas, la segunda es crear una aplicación de escritorio básica
para gestionar la base de datos, y la tercera realizar algunas pruebas en un hosting para ver el
funcionamiento de la web. Dado el corto plazo disponible la mayor parte del tiempo se dedicara a la
librería dejando la gestión de la base de datos como una tarea rápida secundaria.
Periodo Tarea
20-10-2012 / 10-11-2012 Implementación de la librería y el modulo javascript
11-11-2012 / 16-11-2012 Desarrollo de una app de escritorio básica para gestión de la BD
17-11-2012/ 18-11-2012 Pruebas en Hosting
5.-Pruebas e Implantación
5.1-Pruebas realizadas en el proyecto
Las pruebas sobre el proyecto se dividen en dos fases. La primera sobre el Gestor de contenidos y la
siguiente sobre el proyecto de pagina w eb.
Sobre el gestor de contenidos he realizado las correspondientes clases de equivalencia y casos de prueba
sobre los datos que acepta la interface.
CLASES DE EQUIVALENCIA NOTICIAS:

CLASES DE EQUIVALENCIA TRANSFORMACIONES
CLASES DE EQUIVALENCIA MAQUETACION NOTICIAS
CLASES DE EQUIVALENCIA MAQUETACION CONTENEDORES
CLASES DE PRUEBA
[NOMBRE DEL ALUMNO][CICLO] PÁGINA 5]]

Nota: En el resultado se incluye el tipo de error que se produciría si no existiese control de errores. Error
C. significa error controlado. Se incluye el fichero excell ya que los datos de las tablas se muestran muy pequeños
en estas capturas.
Sobre la pagina w eb he realizado unas pruebas de carga utilizando la aplicación gratuita Jmeter. Se establecen 3
escenarios sobre los que se han realizados las pruebas y sobre los que se muestran los resultados. Uno Optimo en
el que el servidor aun dispondría de cierto margen de seguridad para admitir algo mas de sobrecarga. Uno Limite
en el que el servidor se encuentra absolutamente saturado. Y uno Extremo en el que se ha desbordado
la capacidad del servidor. A través de estos escenarios podemos establecer el numero de solicitudes máximas que
se pueden gestionar por minuto. Las pruebas se han realizado tanto en local como en el hosting de la pagina,
sin embargo para comprobar exclusivamente las características y rendimiento de la aplicación eliminando los
factores derivados de los tiempos de resolución de dns, el redireccionamiento de dominio gratuito
contratado, y las limitaciones de respuesta del hosting también gratuito, se incluyen solo las pruebas con IIS en
local. Estas pruebas miden por tanto el tiempo que trata la aplicación en gestionar las solicitudes sin ningún tipo
de interferencia y se considera el tiempo de respuesta mínimo que la aplicación puede responder a las
solicitudes. Esta rendimiento esta determinado por el equipo en el que se realizan las pruebas. Un modesto
ordenador Dual de 1800 Mhz con 3
Gb de Ram. La ejecución de estos test sobre un verdadero servidor de pago debería arrojar resultados muchísimo
mejores.
ESCENARIO OPTIMO:
1000 USUARIOS SOLICITANDO CONEXION EN UN PERIODO DE 400 SEGUNDOS (1 SOLCITUDx0.4 sds)
En esta prueba se observa un rendimiento constante de solicitudes. Los picos finales corresponden a una
advertencia de antivirus y muestra lo dependiente que son los resultados a el entorno de ejecución. En este test no
se ha inicializado la aplicación en la primera solicitud. En esta primera solicitud no puede gestionarse el cacheado
de Modulo implementado en la aplicación y por lo tanto los resultados de la solicitud son muy altos en la solicitud 1.

aquí se Observa con la primera solicitud consume mas de cuatro segundos. Este retraso se acumula a medida que
se van acumulando usuarios y se va suavizando con el tiempo.
En el gráfico vemos la caída de rendimiento inicial por la primera solicitud, muy acusada, junto con el inicio de los
test de prueba, la linea azul se corresponde con la recuperación del ritmo de respuestas. El mapa de puntos negros
indica el tiempo real de respuesta y la linea violeta el promedio. Vemos que permanece estable durante
la ejecución de toda la prueba excepto la primera variación inicial.
Un resumen de la prueba de estrés, las solicitudes varían entre 381 ms y 9091. Con un promedio de de 507. Unas
dos paginas por segundo.

ESCENARIO LIMITE:
1000 USUARIOS SOLICITANDO CONEXION EN UN PERIODO DE 350 SEGUNDOS (1 SOLCITUDx0.35 sds)
En este caso si se ha realizado una primera solicitud previa de pagina para descongestionar la aplicación y tener
disponible el cacheado de pagina. Los resultados son muy parecidos, existe una acumulación inicial de solicitudes,
este lo achaco a la caída de rendimiento del servidor que coincide con el inicio del test.
Aquí se demuestra como la primera solicitud tan solo consume 544 ms, demostrando que la aplicación
esta cacheando. Los tiempo sin cache están entre los 3 segundos.
El sumario del test. Aunque el promedio por pagina es menor se ha respondido a las mil solicitudes con
mas prontitud. Vemos el rendimiento incrementado en 2,8 respuestas por segundo frente a las 2,4 anteriores.

ESCENARIO EXTREMO:
1000 USUARIOS SOLICITANDO CONEXION EN UN PERIODO DE 300 SEGUNDOS (1 SOLCITUDx0.3sds)
Vemos como la gráfica tiene una orientación invertida. Los usuarios solicitan pagina con mas rapidez de lo que el
servidor es capaz de gestionar las solicitudes. Los tiempos se acumulan y se producen retrasos significativos.
Al final de la prueba, en las ultimas solicitudes se pueden observar retrasos de hasta 88 segundos frente a los 500
ms de la prueba Optima que se muestra a continuación. Como se ve la ultima solicitud en la prueba optima son de
466 ms. Se produce un retraso de 88000 ms en una pequeña variación en el incremento de carga. Esto se debe a
que una vez superado el umbral de respuesta del servidor los resultados son acumulativos.

FOMENTO OCUPACIONAL FOC ®
Aquí se aprecia como el promedio y los tiempos de respuesta tienen linea ascendente. Desconozco porque se
produce una mayor dispersión de los tiempos de respuesta a medida que las solicitudes en cola van
aumentando. Puede que tenga algo que ver con la memoria ram, pero no soy capaz de interpretar porque
los puntos son tan consistentes (tiempos de respuesta casi idénticos) al principio de la gráfica y se van
difuminando al final.
5.2 – Implantación del proyecto:
He subido una versión de la pagina w eb a un servidor
gratuito. Ww w.tecnocompile.net.ms -
Es una versión completa de la w eb con algunas actualizaciones de noticias, comentarios, y funcionalidad de las
categorías.
Notas:
1)El host ha expirado intentare volverlo a poner disponible en los próximos días.
2)Inesperadamente Firefox ha dejado de mostrar los estilos utilizar preferentemente chrome o IE
[NOMBRE DEL ALUMNO] [CICLO] PÁGINA 33]]
6. Documentación del Proyecto
6.1 Manual de instalación
Manual de instalación de Alligator Manager:

Prerequisitos de instalación: Microsoft framework .Net 4.0
1) Ejecute el archivo AlligatorSetup.exe
2) Pulse en Siguiente
3) Elija si quiere que el programa este disponible para el usuario actual o para todos lo
usuarios y pulse en examinar para seleccionar la carpeta de instalación.

4) Pulse aceptar y de nuevo siguiente para iniciar el proceso de instalación
5) Una vez finalizado el proceso abra la carpeta de instalación y ejecute el archivo
Nota: He desinstalado la maquina virtual y he instalado la versión Standalone de

framework 4.0 pero al intentar instalar me sigue solocitando conexión a la red y no he
conseguido establecerla. Espero que no de ningún problema pero solo he podido
comprobarlo en mi maquina local por ese motivo.
Instalación de Alligator Web:
1) Suba el archivo AlligatorWeb.zip al hosting contratado. Generalmente todos los servidores

tienen una opción de file manager o gestor de archivos, desde la que podrá subir el
fichero. Una vez en el servidor deberá elegir la opción de descomprimirlo.
2) El proyecto trabaja directamente sobre una ruta r elativa por lo que no tendrá que
especificarla, el programa la detectara y la almacenara en memoria. Sin embargo si tendrá
que realizar un cambio en el fichero config.gnc.
3) Abra el fichero config.gnc ubicado en App_config
4) Dentro de la Sección [SERVER] cambie la clave

Domain:http://localhost:1228/ a la url que le proporcionara su hosting
[SERVER]
Domain: http://heechee-001-site1.smarterasp.net/
NewParameter1:IdNew
NewDetailPage:Detail.aspx
Ir al dominio de la pagina, si no redirecciona correctamente incluir explícitamente la pagina

principal Main.aspx. http://heechee-001-site1.smarterasp.net/Main.aspx
5) Tener en cuenta que la primera solicitud puede demorarse algo d e tiempo ya que realiza
los procesos de inicialización y almacenamiento. A partir de la segunda y hasta que
transcurra un tiempo desde el cierre de la ultima sesión las subsiguientes peticiones serán
muchos mas rápidas ya que recogerán los resultados del cacheado de modulo.
6) La página ha sido diseñada para verse correctamente en chrome y Firefox. IE presenta

algunos problemas estéticos no demasiado obvios. Esto se debe a ciertas particularidades
de las css de IE que aun no han sido resueltas.

7) Este guía no pretende ser una enumeración exhaustiva de los pasos necesarios para
poner a punto la página web. Dependiendo del hosting contratado deberán seguirse una
serie de pasos adicionales y formalidades, tales como establecer los niveles de seguridad,
la apertura de FTP, establecer los ficheros como lectura, escritura, públicos o privados,
disponer del componente MDAC para base de datos Access o instalarlo etc. También
ciertos servidores obligan a tener los archivos en ciertas ubicaciones especiales como las
bases de datos. Estos pasos deberán consultarse con el apoyo técnico del hosting en
cuestión.
6.2 Manual de usuarios
Manual de Alligator Manager:
Introducción:
Alligator Manager es una aplicación que nos permite gestionar visualmente la base de
datos que utiliza la aplicación web.
A continuación se irán mostrando las ventanas principales, sus secciones y significado
de cada una, y datos sobre su modo de utilización, así como conceptos necesarios para
entender la lógica de la aplicación.

En la ventana principal que nos aparece al iniciar la aplicación se nos ofrece la posibilidad de
elegir entre la gestión de noticias o el apartado de maquetación. Ambas opciones están en la
parte superior y serán accesibles durante toda la vida de la aplicación.
Secciones:
(1) : Barra de edición de noticias. Nos permite añadir, editar, eliminar y guardar los
distintos registros de noticias.
(2) : Pestañas de navegación: Nos permite pasar a distintos aspecto de las noticias. En
body nos muestra el cuerpo de la noticia. Transformaciones nos muestra los
distintos estilos asignados a la noticia, se comentara más adelante.
(3) : Grid con las Noticias almacenadas en la base de Datos.
IdNew: Identificador de noticia. Lo utilizaremos cada vez que queramos referirnos a

la noticia. La representación visual nos ayudara a identificar de qué bloque se trata.
IdSection: El identificador de la sección de la noticia. Cada sección se corresponde
con la categoría a la que pertenece la noticia. Las categorías nos permiten realizar
subconsultas de las mismas a través del menú superior del portal.
Author: El Nombre del autor de la noticia.
Tag: Es una palabra clave para relacionar las noticias entre si. No es necesaria.
Body: Cuerpo de la noticia. El cuerpo podrá incluir todas las etiquetas HTML
necesarias así como las referencias a recursos externos como fotografías o videos.
ImageAvatar: Ciertas noticias, como el listado de las más leídas, pueden necesitar
una representación pequeña de las mismas. Este campo nos permite direccionar
esta imagen a través de una ruta http.
LinkFullNew: El enlace que lleva a la noticia. Es requerido pero el sistema lo
ignorara si se establece la Url Automática.
AuthorPhoto: El nombre del autor de la fotografía si existe y la noticia requiere
fotografía.
IdTagFk: Se trata de un identificador de palabra clave. Se introduce a través del
desplegable explicado mas adelante.
DateNew: La Fecha en que se inserto o modifico por última vez la noticia.
Visitors: El numero de visitas que ha recibido la noticia. No se puede modificar
manualmente. Actualmente la aplicación no dispone de funcionalidad para detectar y
contabilizar las visitas, solo para tenerlas en cuenta a la hora de mostrar resultados.
Publish: Nos permite mantener una noticia en modo de edición, o sin completa r y
que el sistema no la tenga en cuenta a la hora de publicarla. Una vez activado a true
la noticia pasara a formar parte de los resultados de la página web.
(4) Controles para la edición de los campos: El modo de UrlAutomatica nos permite que
la propia página web establezca una dirección de redireccionamiento automático
basado en el identificador de noticias. En caso de no querer utilizarlo, como por
ejemplo enlazar a un recurso externo, utilizara el campo Enlace si se establece
como no automático.
(5) Previsualizacion de la noticia: Elige uno de los estilos de que dispone la noticia y lo
muestra. Nos sirve para identificar la noticia ya que su identificador numérico no nos
proporciona ninguna información.
(6) Controles de Zoom del visualizador: Controla el Zoom del visualizador y nos permite
adaptar el tamaño a las dimensiones de la noticia que estemos viendo.

Concepto de transformación:
Dentro de la página web una noticia puede ocupar distintas posiciones o

paginas. Una noticia puede estar en la zona del encabezado y mostrar un diseño
especial, más amplio y resaltado. Con el paso del tiempo esta noticia será
desplazada a la pila (explicado mas adelante) y su estilo será más discreto. A su vez
al chiclear sobre cualquiera de ellas veremos una vista ampliada de la misma con un
diseño a su vez diferente. Cada una de estos estilos es lo que denomino
transformaciones. Una noticia puede tener tantas como quiera.
Concepto de Proveedor de Noticia:
Cada noticia se muestra en pantalla formateada a través de una plantilla, que

elegimos en la pantalla transformaciones como el estilo. Cada estilo requiere un
determinado proveedor que resuelva los datos de esa noticia. Los proveedores no
se eligen independientemente, sino a través de perfiles de proveedor que nos
permiten asignar al proveedor ciertos parámetros, como numero de resultados, etc.
Los proveedores se agrupan en familias para poder compatibilizar o no un estilo con
un proveedor. No ha habido tiempo de establecer esa compatibilidad por lo que
aparecerán todos los proveedores disponibles para cada estilo. Si se elige el
proveedor inadecuado la noticia no se mostrara correctamente o se producirán
errores Esto queda como una de las muchísimas mejoras pen dientes.
Listado de Perfiles de Proveedor disponibles:
FrontPage: Proporciona datos para la noticia en su posición de portada

TopTecnology: Devuelve todas las noticias relacionadas con el contenedor de
Tecnología.
TopCiencia: Devuelve todas las noticias relacionadas con el contenedor de
Ciencia.
MostReaded: Devuelve un listado de las 5 noticias mas leídas.
Efemérides: Información proveniente de la tabla especial Multipropósito.
Devuelve información especial con relación al día actual, como acontecimientos,
citas, etc.
Videos: Un listado de videos relacionados con el contenedor de Videos.

FirstView: Un perfil de datos parecido a FirstNew utilizado para noticias de
cabecera. Incorpora menos información.
StaticModule: Perfil dedicado a aquellos elementos que no requieren proveedor
de datos. Tales como banners o imágenes.
NewDeveloped: Este perfil devuelve el detalle ampliado de la noticia.
NewDevRelateds: Devuelve un conjunto de 5 resultados de las noticias
relacionadas a la actual por su Tag.
CommentsNormal: Devuelve los comentarios relacionados a la noticia actual.
Concepto de Contenedor: Un contenedor es una plantilla, que esta diseñada para

admitir un conjunto de noticias y poder insertarlas en su interior. Se han diseñado
contenedores para noticias mas leídas, videos, efemérides y contenedores para
noticias que se asignan manualmente. Los contenedores vienen predefinidos pero
no existe actualmente una interface para editarlos o modificarlos.
Secciones de la interface:
(1) : Barra de acciones para la edición, eliminación, insertado y guardado de las

transformaciones.
(2) Controles para la edición de los campos.
(3) Previsualizacion de la transformación en curso.
(4) Grid con las actualizaciones de la noticia almacenadas en la base de datos.
Campos del Grid:
IdTrans: Un auto numérico, lo gestiona la BD para diferenciar las

transformaciones.
IdNew: El identificador de noticia.
NameContainer: El nombre del contenedor si la noticia esta asignada a un
contenedor.
Summary: Un pequeño resumen de la noticia que se utiliza por determinadas
plantillas, como las de la página inicial.
Title: El titulo de la Noticia:
SizeName: El tamaño de letra de la noticia. Dispone de varios rangos, los más
utilizados por las páginas web que he visitado.
ImgSrc: Url de la imagen de la transformación.
FootPictureText: Texto del pie de foto de la transformación.

ShortBody: Es una introducción de la noticia. Un resumen ampliado de la

misma para el portal.
NameProfile: El nombre del perfil del proveedor de la transformación.
NameSytle: El nombre del estilo de la plantilla de la transformación.
Introducción:
El formulario de maquetación nos permite diseñar el aspecto de la pagina principal

del sitio web, utilizaremos los identificadores de modulo y los identificadores de
posición en la plantilla para ubicarlos.
Definición de la Interface:
(1) : Pestañas para alternan entre maquetación de noticias y maquetación de

contenedores
(2) : Previsualizador de modulo/Contenedor en curso
(3) : Previsualizacion de maquetado de página.
(4) : Grid con las noticias pertenecientes a la página almacenadas en la base de
datos.
IdModule: Identificador del modulo. Noticia/Contenedor
DateMeta: Fecha de la inserción del modulo en la página.
Location: Posición de inserción dentro de la pagina.

Resizable: Pertenencia del modulo a la sección de cabecera o a la pila.
LinkedTo: Modulo dependiente de otro modulo. -1 Indica modulo independiente
Modo: Forma de posicionamiento en la pagina. Dynamic indica que el programa
intentara colocar el modulo en el lugar mas adecuado atendiendo a los huecos
disponibles, las transformaciones de la noticia, y la fecha de inserción. FullFixed
fuerza a la noticia a posicionarse en una localización específica siempre y
cuando exista una transformación adecuada para esa posición.
(5) Barra de menús para insertar, eliminar, editar y guardar nuevos elementos en la
base de datos en la que se basa la pagina web.
(6) Listado de las noticias disponibles en la base de datos para ser incluidas en la
pagina principal de la aplicación.
(7) Controles para editar las posiciones de la plantilla de la página web.
(8) Identificador de posición en la plantilla: A la hora de insertar un determinado
modulo en la página web, introduciremos este identificador para ubicar la
noticia/contenedor en esa posición específica. Solo necesario en caso de elegir
la opción FullFixed. En la leyenda del identificador aparece también el modo de
posicionamiento que tiene actualmente esta noticia.
Introducción:

El formulario de Maquetación de contenedores es análogo al de noticias con la diferencia que

son contenedores lo que se insertan en la página, se describen únicamente las sec ciones
específicas de este formulario.
(1) : Previsualizacion del Contenedor.

(2) : Contenedores almacenados en la base de datos y que ya forman parte de la página web.
(3) : Contenedores disponibles para la inserción en el diseño de la página.
Nota: El campo No Repetir esta definido por defecto a true, indica que si una noticia esta
asignada a un contenedor, no se debe duplicar fuera de este en las consultas dinámicas. Por
ejemplo en las categorías.
6.3 Manual de Administración
Dado que durante la confección de este documente se han introducido varios aspectos a
incluir aquí, me centrare en aquellos que aun no han sido desarrollados.
1) Concepto de plantillas, sintaxis de etiquetas y ejemplo.
La aplicación web utiliza para cada uno de los módulos dos ficheros que establecen la
estructura y estilo de las mismas. Uno de ellos tendrá extensión .htf y se encontraran la
carpeta HtmlTemplates y otra con extensión .css en la carpeta CssTemplates. De los
dos ficheros el primero será la plantilla que determina la estructur a del módulo y los
campos a resolver y la segunda toda la información referida a los estilos de hoja en
cascada.
Una plantilla no es mas que un fragmento de código HTML que incluye ciertos
metadatos que hacen referencia a como deben resolverse ciertas porciones del código,
en que campo están basados y ciertos parámetros que determinan la forma adecuada
de resolverse. Para este propósito la aplicación utiliza una serie de tokens o etiquetas y
ciertos parámetros de resolución. Los identifico a continuación a ntes de poner un
ejemplo.
Antes de ello hablare sobre los datos que recopilan todas las plantillas.
Independientemente del proveedor de datos al que una plantilla este asociado, cada
plantilla esta relacionada necesariamente con dos estructuras de datos.
Una es un único registro con un número determinado de campos, el nombre de campo

será el identificador de resolución. La otra fuente de datos es un conjunto de registros.

Esto es así porque en los módulos hay ciertas características como el titulo o el
encabezado que son únicas para todo el modulo, y otras como las noticias relacionadas
por ejemplo, que son múltiples para el mismo modulo. A partir de ahora los
referenciaremos como conjuntos de resultados simple o compuesto. Ciertas etiquetas
harán referencia al conjunto de registros y otras al registro simple. Las etiquetas
delimitan los metadatos de su interior con un token de inicio y de fin. A continuación los
detallo.
Etiquetas de resolución:
[!...!] : Reemplazadores: Esta es la etiqueta más básica. En su interior se encuentra el

nombre del campo de la base de datos que debe resolverse antes de devolverse el código
HTML. Por ejemplo el código [!Titulo!] en cualquier parte de la plantilla no será tomado
literalmente, en su lugar se buscara en el conjunto de resultados simple el campo titulo, y se
remplazara por su valor en la plantilla. Esta etiqueta es configurable y puede modificarse en el
archivo de configuración cambiando los valores correspondientes a ReplacerTokInit:[! Y
ReplacerTokEnd:!]
[+…+]: Iteradores: Los iteradores indican que todos los reemplazadores anidados
dentro de ellos y que tengan el parámetro Linked==True (explicado mas adelante) deberán
resolverse una vez por cada registro que exista en el conjunto de resultados múltiple. Para
verlo con un ejemplo:
Visitar:
[+
[!Relacionados!,,Linked==True]
+]
Devolverá una salida de tantos enlaces relacionados como se suministren en el

conjunto de registros múltiples.
Visitar:
-Descubierta Nueva galaxia
- Científicos logran…
- La música es cada vez más…

En cierto sentido el iterador funciona como un bucle for each, pero dado que uno de los
requisitos a la hora de iniciar el proyecto fue que estuviera orientado al diseñador, sin
conocimientos previos de programación, no es necesario introducir ningún tipo de código para
realizar tal proceso, con tan solo introducir este token el recorrido for…each se realiza
transparentemente por la aplicación. Los Iteradores pueden modificarse en el a rchivo de
configuración en las claves IteratorTokInit:[+ y IteratorTokend:+]
Token de Sección pendiente de resolución: |% : Este token no tiene un modelo de inicio y fin
es igual para ambos. Su significado es que si cualquiera de los campos con el atribut o
necessary==True (mas adelante) no puede resolverse (resultado null o “”) toda la sección se
omite completamente en la salida del código HTML. Lo explicare en un ejemplo.
En los módulos de noticias es típico que algunas de ellas dispongan de una fotograf ía y otras
no. Para evitar que sea necesario crear una plantilla para cada versión se puede utilizar una
codificación como la que sigue que servirá en ambos escenarios:
|%<div class="foto" >

<a href="[!LinkFullNew,,Necessary==True!]" >
<img src="[!ImageSrc,,Necessary==True!]" border="0" width="390" height="219"
alt="[!FootPictureText!] | [!AuthorPhoto!]" title="[!FootPictureText!] | [!AuthorPhoto!]" />
<p><a href="[!LinkFullNew!]" >[!FootPictureText!] | [!AuthorPhoto!]</a></p>
</div>|%
Esta es una sección de la plantilla bakgrey_module_autoresizable.htf. Tanto el campo

LinkFullNew como ImageSrc tienen establecido el atributo Necessary a True. Toda la sección
referida a la fotografía de la notica esta englobada en un token de sección. Si cual quiera de los
campos necesarios, es decir el enlace de la imagen, o la propia imagen no pueden resolverse
(tendrán “” en la base de datos) deberá interpretarse que se trata de un modulo sin fotografía y
como consecuencia toda la sección será omitida, este incluye otros campos como el pie de foto
o el autor.
(Una misma plantilla con dos comportamientos diferentes.)
El token de sección puede modificarse en el archivo de configuración modificando la key

SectionTok:|%
Tokens delimitadores y de igualdad:
,, - == : Los Tokens delimitadores entre parámetros son dos comas (,,) y el de igualdad es el de
dos símbolos de igual (==). Se modifica en el archivo de configuración en las keys
ParameterTokDelimiter:,, y ParameterTokEqual:==
"[!ImageSrc,,Necessary==True!]"
A continuación se describen los parámetros que pueden asociarse con cualquier etiqueta de
resolución.
Linked==True : Se trata de un campo perteneciente al conjunto de resultados múltiple.

Necessary==True : Se trata de un campo que su omisión provoca la eliminación de toda la
sección asociada.
MaxLenght=Value: Siendo value el número máximo de caracteres que aceptara la resolución
del campo. Si se supera dicho limite el programa añadirá automáticamente la cadena ‘[…]’.
Esto evita que los campos demasiado largos desequilibren el diseño css de la pagina.
Ejemplo de una Plantilla HTML:


<div class="noticia_grey">
|%<div class="foto" >
<a href="[!LinkFullNew,,Necessary==True!]" >
<img src="[!ImageSrc,,Necessary==True!]" border="0" width="390" height="219" alt="[!FootPictureText!] |
[!AuthorPhoto!]" title="[!FootPictureText!] | [!AuthorPhoto!]" />
<p><a href="[!LinkFullNew!]" >[!FootPictureText!] | [!AuthorPhoto!]</a></p>
</div>|%
<p class="antetitulo_grey ">
<strong>
<a href="/elmundo/espana.html">[!NameSec!]</a>
</strong>
[!Summary,,MaxLenght==38!]</p>
<h3 |%style="font-size:[!SizeValue,,Necessary==True!]px"|%>
<a href="[!LinkFullNew!]" title="[!Title!]">[!Title!]</a>
</h3>
<p class="firma">
<strong class="autor">[!Author!]</strong>
| <span class="localizacion_grey">[!NameSec!]</span>
</p>
<p class="p_white">[!ShortBody,,MaxLenght==244!]</p>
<p class="comenta_grey">
<a href="/elmundo/2012/06/26/espana/1340718471.html#comentarios">[!ComCount!] Comentarios</a>
</p>
|%<ul class="apoyos">
[+<li class="cuadrado"><a
href="[!LinkFullNew,,Necessary==True,,Linked==True!]">[!Summary,,Necessary==True,,Linked==True!]</a></li>+]
</ul>|%
</div>
:
Resultado:
2) El archivo de configuración Config.gnc:
Otro tema que no se ha tocado en todo el documento y que no puede deducirse

fácilmente de la lectura del código es el significado del archivo de configuración. A
continuación se pegara el contenido de dicho archivo y se comentaran a la derecha el
significado de los valores más significativos.
[TOKENS] ;Sección de Identificadores o Tokens

ReplacerTokInit:[! ;Reemplazador para resolución de campos Inicio
ReplacerTokEnd:!] ; Reemplazador para resolución de campos Inicio
IteratorTokInit:[+ ; Iterador inicio
IteratorTokEnd:+] ;Iterador Fin
SectionTok:|% ;Identificador de sección omisible
IteratorTokField:# ;identificador que no se utiliza, versiones antiguas
NecessaryTok:& ;identificador que no se utiliza, versiones antiguas
ParemeterTokDelimiter:,, ;Identificador de separación entre parámetros
ParameterTokEqual:== ;Identificador de igualdad en el parámetro
[PATHS] ;Sección de las rutas de la aplicación
HtmlPath:Templates\HtmlTemplates ;Ruta relativa de las plantillas
CssPath:Templates\CssTemplates ;Ruta relativa de los estilos Css
DbName:DataNews.mdb ;Nombre de la base de datos
DbPath:BD ;Ruta relativa de la base de datos
PageHtmlPath:Templates\PageHtmlTemplates ;Ruta relativa de las plantillas de pagina
PageCssPath:Templates\PageCssTemplates ;Ruta relativa de los estilos de pagina
PostHtmlPath:Templates\PostHtmlTemplate ;Ruta relativa de las plantillas de modulo
[HTMLSMAPPING] ;Sección de mapeo de estilos
Regular1_390:Regular_Module_Autoresizable.htf ;Relación entre nombre plantilla en Bd y nombre de plantilla en fichero
HightLight1_100:HightLight1_100_file.htf
BackGrey_390:BackGrey_Module_Autoresizable.htf
WithHeader_100:WithHeader_100_file.htf
Regular1_340:Regular_Module_Autoresizable.htf
Regular1_230:Regular_Module_230.htf
ColumnBlue_230:Container_Simple_Blue_AutoSizable.htf
ColumnRed_230:Container_Simple_Red_AutoSizable.htf
ColumnOrange_230:Container_Simple_Orange_AutoSizable.htf
ContainerTopReads_230:Container_Top_Reads_Autosizable.htf
ContainerVideosHorizontal_1000:Container_Videos_Horizontal_1000.htf
Efemeride_230:Efemeride_AutoSizable.h tf
Efemeride_340:Efemeride_AutoSizable.htf
Efemeride_390:Efemeride_AutoSizable.htf
HeaderSimple_570:Header_Simple_570.htf
HeaderShort_400:Header_Short_400.htf
MainHeader_1000:Main_Header_1000.htf
FooterInformation_1000:Footer_Information_1000.htf
NewDeveloped_490:NewDeveloped_autosizable.htf
Relateds_240:Relateds_Autosizable.htf
Comments_490:Comments_Autosizable.htf
Identificator:Identificator_Position.htf ; Plantilla que sirve de identificador (Numero en cabecera)
EmptyTemplate:EmptyTemplate.htf ; Plantilla que se usa en secciones vacías.
[CSSSMAPPING] ;Sección de Mapeo de estilos
Regular1_390:Regular_Module_Autoresizable.css ;Relación entre nombre de estilo en Bd y nombre de fichero
HightLight1_100:HightLight1_100_file.css
BackGrey_390:BackGrey_Module_Autoresizable.css
WithHeader_100:WithHeader_100_file.css
Regular1_340:Regular_Module_Autoresizable.css
Regular1_230:Regular_Module_230.css
ColumnBlue_230:Container_Simple_Blue_AutoSizable.css
ColumnRed_230:Container_Simple_Red_AutoSizable.css
ColumnOrange_230:Container_Simple_Orange_AutoSizable.css
ContainerTopReads_230:Container_Top_Reads_Autosizable.css
Efemeride_230:Efemeride_AutoSizable.css
HeaderSimple_570:Header_Simple_570.css
HeaderShort_400:Header_Short_400.css
ContainerVideosHorizontal_1000:Container_Videos_Horizontal_1000.css
MainHeader_1000:Main_Header_1000.css
FooterInformation_1000:Footer_Information_1000.css
NewDeveloped_490:NewDeveloped_autosizable.css
Relateds_240:Relateds_Autosizable.css
Comments_490:Comments_Autosizable.css
Identificator:Identificator_Position.css ;Código css de la plantilla de identificación
EmptyTemplate:EmptyTemplate.css ;Código css de la plantilla de sección sin asignar
[PAGETEMPLATE] ;Sección de la página principal, Main.aspx
UsingHtml:Simplest ;Plantilla de pagina que usa la pagina principal
usingCss:Simplest ;Css que usa la plantilla de pagina principal
UsingQueryMainPage:MetaNewsToMain ;Proveedor de datos que usa la pagina principal
UsingEmptyTemplate:EmptyTemplate ;Plantilla que de sección vacía en la pagina principal
[POSTTEMPLATE] ;Sección de las plantillas pagina de modulo
UsingHtml:SimplestPost ;Plantilla que usa la pagina de modulo

[PAGECATEGORYTEMPLATE] ;Sección de páginas de categorías
UsingQueryMainPageCategorized:MetaNewsToCategory ;Proveedor de datos par alas paginas de categorías
UsingHtml:SimplestCategorized ;Plantilla que usan las paginas de categorías
usingCss:SimplestCategorized ;Css que usan las paginas de categorías
[HTMLTEMPLATE] ;Sección de Pagina de css Global
GlobalCss:GlobalCss.css ;Css global. Se añade siempre.
[SIMPLEST] ;Datos de la plantilla de pagina simplest
MaxPosts:42 ;Numero de módulos
StartHeap:11 ;Inicio de la pila de noticias
StartPage:7 ;Inicio de la cabecera de la pagina
SafeMargin:20 ;Numero de módulos de desbordamiento antes de borrado
[SIMPLESTCATEGORIZED] ;Datos de la plantilla de pagina de pagina categoría
MaxPosts:33
StartHeap:11
StartPage:10
SafeMargin:20
[PAGEDEVELOPED.PTF] ;Información de la página de detalle de noticia
StartPage:10 ;Identificador de la primera noticia
UsingQuery:metanewstodynamic ;Proveedor de datos de la pagina de detalle de noticia
[EXTENSIONS] ;Sección de extensiones
HtmlStyle:htf ;Extensión htf para plantillas de modulo
CssStyle:css ;Extensión css para estilos de plantilla de modulo
PageStyle:ptf ;Extensión de ptf para plantillas de pagina
[GENERAL] ;Valores Generales
WidthAvatar:50 ;Anchura de imagen Avatar
HeightAvatar:50 ;Altura de imagen Avatar
IdentificatorCss:Identificator ;Clave de identificador css
[CACHEPOST] ;Sección de cacheado de modulo
CaducityHours:24 ;Periodo de caducidad en la reconstrucción de la cache
[SERVER] ;Sección de serv idor
Domain:http://localhost:1228/ ;Dominio en el que se encuentra la aplicación web
NewParameter1:IdNew ;Clave de identificador de detalle de noticia
NewDetailPage:Detail.aspx ;Nombre de pagina de detalle de noticia
Contenido y definición de las secciones y claves del archivo Config.gnc
3) Plantillas de Pagina:
Para la organización de los módulos dentro de la estructura de la página se utilizan las
plantillas de página. Constan de un identificador de posición y uno de anchura. De la
construcción de esta plantilla depende la estructura general de la página y la ub icación
de todos los módulos. Las plantillas de pagina al igual que las de modulo tienen
asignada un fichero de código css. Su carpeta es PageHtmlTemplates y
PageCssTemplates. A continuación añado la estructura de simplest.pft que es la
página principal o Main.aspx.
<div class="container">
[!7:1000!] ;Posición de Encabezado (Tecnocompile)
<div class="header">
<div class="cabeceraleft"> ;A dos columnas
[!8:570!] ;Posición Noticia Izquierda
</div>
<div class="cabeceraright">
[!9:400!] ;Posición de 2 noticias a la derecha
[!10:400!]
</div>
</div>
<div class="sidebar1"> ;A tres columnas
[!11:390!] ;Noticias de la columna izquierda
[!12:390!]
[!13:390!]
[!14:390!]
[!15:390!]
[!16:390!]
[!17:390!]
[!18:390!]
[!19:390!]
[!20:390!]
[!21:390!]
</div>
<div class="content">
[!22:230!] ;Noticias de la columna Central
[!23:230!]
[!24:230!]
[!25:230!]
[!26:230!]
[!27:230!]
[!28:230!]
[!29:230!]
[!30:230!]
[!31:230!]
</div>
<div class="sidebar2">
[!32:340!] ;Noticias de la columna Derecha
[!33:340!]
[!34:340!]
[!35:340!]
[!36:340!]
[!37:340!]
[!38:340!]
[!39:340!]
[!40:340!]
[!41:340!]
</div>
<div class="footer">
<div class="footervideos"> ;A 1 columna
[!42:1000!] ;Modulo de videos
</div>
[!43:1000!] ;Pie de Pagina
</div>
</div>
Tanto las plantillas de modulo como de pagina a la hora de resolver los campos utilizan
un sistema de indexación. Cada campo a resolver o posición de pagina tiene asociado
un valor numérico que se utiliza a la hora de insertar el campo o el modulo. Esto ha ce
que el tiempo de resolución sea mucho mas rápido que un simple método replace que
recorra todo el documento una y otra vez de principio a fin.

6.4 Cumplimento de los objetivos iniciales
Muestro a continuación una grafica acerca del cumplimiento de los 10 puntos que se
establecieron como objetivos del proyecto.
Hay tres tareas en las que no se ha conseguido un 100 % de cumplimiento a mi juicio las
causas son las siguientes:
Interface de Maquetado: Aunque la interface de maquetado es funcional y cumple

inicialmente con los objetivos marcados, se ha realizado con muy poco tiempo, como una fase
adicional al desarrollo de la librería. El principal problema es de usabilidad, con ciertas
ralentizaciones. Demás han aparecido ciertos problemas o incompatibilidades que hacen que
el control Web de .net sea demasiado sensible con respecto al resto de navegadores y
muestre algunos módulos de forma incorrecta.
Modulo JavaScript: El modulo JavaScript ha sido desarrollado y será incluido en el resultado

final pero requiere algunas modificaciones. La primera es su bajo rendimiento sobre Firefox, la
segunda es un problema que muestra en la inicialización que muestra durante unos instantes
todas las imágenes de la galería antes de ajustarlas al carrusel.
Feedback: Con Feedback me refiero a las respuestas en forma de comentarios que el usuario
puede enviar sobre las noticias. Se ha tenido en cuenta estos comentarios al mostrar cada
detalle apareciendo al pie. Pero no se ha introducido la interface pa ra que el usuario pueda
escribirlos desde la interface. Considero pues que la tarea esta a un 50%
Incompatibilidad Firefox: Ha aparecido una incompatibilidad con Firefox. Ha sido a ultima

hora con la introducción de el modulo javascript. Es un problema sencillo referente a las rutas
css pero no he tenido tiempo de solventarlo, por lo que en este momento es un objetivo no
cumplido.
6.5 Mejoras del proyecto
Además de todas las incluidas en el apartado anterior causantes de un cumplimiento menor al

100% las principales mejoras serian.
Adaptar el proyecto a un SGBD: El proyecto utiliza Access por cuestiones de simplicidad y

rapidez en el desarrollo pero he comprobado que tendría bastantes inconvenientes en un
entorno de producción real.
1)
La principal es que con Access modifico las tablas en local y rescribo la bd en el
servidor para las actualizaciones. Este sistema además de incomodo es
impracticable por los tiempos de subida a medida que la base de datos vaya
alcanzando mayor peso. Hay que implementar un servicio de conexión remoto a un
sistema de gestión de base de datos como SQL Server en el servidor y centralizar
ahí todos los cambios.
2)
Los accesos a Access son muy lentos, en parte porque Access en las aperturas
de conexiones crea un fichero ldb que hace que rendimiento baje. Se han l imitado
estas aperturas al mínimo pero SQL Server mejoraría este aspecto, así como las
velocidades en las consultas y transacciones.
3)
Por ultimo se han encontrado algunas limitaciones en la sintaxis de Access que
han sido solucionadas parcialmente con cierta dificultad. Una de ellas es la función
RowCount inexistente en Access, otra es la imposibilidad de crear desencadenadores,
que me hubieran sido muy útiles en las operaciones de mantenimiento.

Mejoras en la usabilidad: La interface de maquetación aunque cumple su

objetivo básico, debe madurarse mas, y hacerla mas intuitiva. La selección de la
posición de los módulos en vez de realizarse introduciendo manualmente el
identificador, podría realizarse simplemente clicando en el modulo en cuestión.
Mejora en el tiempo de respuesta: He comprobado que los servidores en

producción de webs de noticias tienen un tiempo de respuesta de en torno a 250 -270
ms. La Librería actual en el mejor de los escenarios y sin tiempos de resolución de dns
ronda los 450 ms. Habría que optimizar y simplificar el código para conseguir disminuir
esos valores. Aun hay ciertas tareas que podrían preprocesarse una vez al inicializarse
en vez de hacerlo por cada solicitud.
3) Desarrollo de Maquetado: La interface de maquetado debería transformarse en

una aplicación con una visión más amplia, que pudiera gestionar todas las tablas del
proyecto. No debería quedar ninguna modificación que debiera realizarse
manualmente sobre el gestor de la base de datos.
4) Módulos adicionales: Habría que crear una nueva categoría de módulos que
pudiesen incorporar asp.net para ciertas operaciones más complejas que requieren
necesariamente codificación. Un ejemplo serian las típicas encuestas de las páginas
de noticias.
6.5 Bibliografía:
Todo el proyecto ha sido realizado consultando o bien el temario del curso o bien algunas
paginas web y un libro de JavaScript que pongo a continuación.
Msdn Library: http://msdn.microsoft.com/es-es/library/ms123401.aspx

Stack Overflow: http://stackoverflow.com
Dom Scripting: Web design with JavaScript and the document object model : Jeremy Keith

Gestor de Noticias Alligator

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Gestor de Noticias Alligator

Enviado por

Direitos autorais:

Formatos disponíveis

PROYECTO FIN DE CICLO

Carlos Vázquez Lizarraga

© 2011 Fomento Ocupacional FOC SL todos los derechos reservados.

1.3 Planteamiento y evaluación de diversas soluciones.

-Un trabajo desarrollado en asp.net, altamente acoplado y codificado dentro de cada

-Utilización de HTML estático: Esta alternativa es de todas la menos optima.

-La misma aproximación propuesta con combinaciones de tecnologías, frameworks y

-Contenido dinámico: La página presentará y formateará información almacenada en

-Modularidad: Las funciones estarán bien definidas y encapsuladas en clases. En la

-Abstracción de datos: Todas las consultas de datos, y los parámetros de conexión

-Solución basada en plantillas y módulos: Una filosofía orientada al diseñador web,

-Interface de maquetado: Un gestor básico de contenidos, que al menos tenga las

-Contenido predefinido: Una colección típica de plantillas y consultas que se ut ilizan

-Agilizado de respuesta: Funcionalidades de cacheado de pagina y de modulo, para

-Comentarios: Se incluirá la posibilidad de recopilar información del usuario en forma

-Modulo en JavaScript: Uno de los objetivos es introducir al menos una tecnología o

-Prueba Online: Mas allá de presentar la solución, además se intentara desplegar el

3. Recursos software y hardware a utilizar

3.1 Recursos software

Microsoft Visual Studio 2008, Dreamweaver CS3 (creación de módulos), Photoshop,

Se usarán los siguientes lenguajes:

3.2 Recursos Hardware

En principio, si la aplicación va a desplegarse en un hosting contratado, esta cuestión

DELL PowerEdge™ T110 II

Procesador: Intel Core i3-2100, 2C/4T, 3.10GHz, 3M Cache, 65W TDP

3. Análisis del Problema

Definición de la clase: Se encarga de

void Add(FileCache CssFile);

Definición de la clase: Mantiene una colección de

Definición de la clase: Es la clase que

Encapsula una clase ErrorMsgObj, que es

string Content { get; set; }

Definición de la clase: FileCache tiene

string AddValue(string Section, string Key, string Value);

Definición de FileConfigReader: Permite

Este objeto se utiliza como almacén para

void AddCommentToModule(string NameType, int IdModule);

Definición de la clase: Recoge toda una serie

void Add(bool State, int Width, int

Definición de la clase: Las

ErrorStore Errors { get; }

Definición de la clase: Los proveedores de

void GetPost(out string CodePost, out string CssPost,

Definición de la clase: Esta clase permite

bool BuildPageCacheable(UrlObj Url, bool WithMarkers);

Definición de la clase: Es una

Definición de la clase: Es la clase que encapsula

bool BuildPageCacheable(UrlObj Url, bool WithMarkers);

Definición de la clase: Es una

Definición de la clase: Los

Descripción de la clase: Esta clase representa un

Descripcion de la clase: Se trata de una

DataRow DataRowSingle { get; }

Descripción de la clase: El proveedor de

Definición de la clase: Engloba todas la

public static string

Definición de la clase: Clase general

bool AddQueryString(string QueryName, string QueryString);

Definición de la clase: La clase querys mantiene

bool AddParameter(string Key, string Value);

Definición de la clase: Encapsula una ruta html y

Definición de la clase: Aunque el cacheado por módulo nos

IdAuthor Entero largo 4

IdCategory Entero largo 4