Cual seria la mejor solución

28/11/2006 - 11:08 por Ramon Espuga | Informe spam
Hola a todos,

tendría que hacer una pequeña aplicación donde hay diversos tipos de
usuarios que acceden a una lista de WSS v2. El tema es que los usuarios
standard son los que tendrían que añadir nuevos items a la lista y los
usuarios de control son los que tendrían que dedicarse a completar y
gestionar dicha información. Para ello esta claro que para una misma lista
deben haber formularios diferentes ya que unos usuarios deben poder
introducir y ver unos campos y otros usuarios deben poder introducir y ver
otros campos distintos.

Se me ocurren varias formas de realizar esta implementación, pero no
acabo de ver claro cual puede ser la mejor de cara al posterior
mantenimiento y escalabilidad de la aplicación. Como lo realizariais
vosotros?

Muchísimas gracias,

Ramon

Preguntas similare

Leer las respuestas

#1 Gustavo
28/11/2006 - 22:33 | Informe spam
Hola Ramon,
Si puedo meter la cucharada, lo primero que se me ocurre es utilizar
InfoPath, pero ya se lo que todos van a decir (instalar InfoPath en todos los
computadores, pagar licencias, que rollo...). De resto, con la forma clasica:
una lista con un solo usuario que puede hacer de todo, una WebPart o pagina
aspx que permite introducir datos en la lista por medio de un Impersonador.
Sobre la WebPart o pagina aspx tienes todo el control de mostrar campos como
quieras, y de implementar tu propia autorizacion...
Suerte,
Gustavo
http://www.gavd.net/servers/default.aspx
http://geeks.ms/blogs/gvelez/


"Ramon Espuga" wrote:

Hola a todos,

tendría que hacer una pequeña aplicación donde hay diversos tipos de
usuarios que acceden a una lista de WSS v2. El tema es que los usuarios
standard son los que tendrían que añadir nuevos items a la lista y los
usuarios de control son los que tendrían que dedicarse a completar y
gestionar dicha información. Para ello esta claro que para una misma lista
deben haber formularios diferentes ya que unos usuarios deben poder
introducir y ver unos campos y otros usuarios deben poder introducir y ver
otros campos distintos.

Se me ocurren varias formas de realizar esta implementación, pero no
acabo de ver claro cual puede ser la mejor de cara al posterior
mantenimiento y escalabilidad de la aplicación. Como lo realizariais
vosotros?

Muchísimas gracias,

Ramon



Respuesta Responder a este mensaje
#2 Ramon Espuga
29/11/2006 - 12:49 | Informe spam
Hola Gustavo,

como bien dices InfoPath no sería la solución ya que debería instalarse
en todas las máquinas cliente y pagar licencias para cada uno de ellos.

La solución de realizar los diferentes formularios con ASPX o mediante
una WebPart, es la que tiene más numeros. El problema es que al hacerlo así
cualquier cambio en un campo o el añadir un campo nuevo requeriría modificar
todos los formularios o WebParts, vamos al fin y al cabo reprogramar,
complicando así en parte el mantenimiento.

A mi se me ocurre la idea de hacer una WebPart parecida al
ListFormWebPart, pero con algún tipo de zona de configuración donde puedas
escoger que campos mostrar o no. Hasta ahí más o menos bien, el problema que
veo es como renderizar los campos del mismo modo que lo hace Sharepoint,
obteniendo el tipo, tamaño y demás de cada campo y renderizarlo segun
FLDTYPES.XML. Supongo que esta sería la solución óptima, pero bajo mi punto
de vista bastante costosa ya que no se como renderizar los campos igual que
lo hace Sharepoint de forma más o menos simple (Si sabeis alguna os estaria
muy agradecido si me la podeis decir)

Viendo entonces que las 2 soluciones de programación que se me ocurren
tienen alguna pega (Si en la 2a pudiese renderizar los campos de forma fácil
sería ideal), me preguntaba si no habría alguna forma de hacerlo como con
FrontPage pero permitiendo tener más de un formulario. Es decir hacer una
copia del NewForm.aspx de la lista, eliminar los campos innecesarios y
publicarlo con otro nombre, por ejemplo NewFormUser.aspx pero sin perder el
NewForm.aspx permitiendo así tener 2 formularios distintos de entrada de
datos para la misma lista. De este modo cada vez que se añadiese un campo a
la lista, también debería modificarse el formulario, pero la forma de
modificarlo sería mucho más fácil, permitiendo incluso que fuese el mismo
usuario administrador que ha añadido el campo a la lista el que lo hiciese.


Muchas gracias,

Ramon



"Gustavo" wrote in message
news:
Hola Ramon,
Si puedo meter la cucharada, lo primero que se me ocurre es utilizar
InfoPath, pero ya se lo que todos van a decir (instalar InfoPath en todos
los
computadores, pagar licencias, que rollo...). De resto, con la forma
clasica:
una lista con un solo usuario que puede hacer de todo, una WebPart o
pagina
aspx que permite introducir datos en la lista por medio de un
Impersonador.
Sobre la WebPart o pagina aspx tienes todo el control de mostrar campos
como
quieras, y de implementar tu propia autorizacion...
Suerte,
Gustavo
http://www.gavd.net/servers/default.aspx
http://geeks.ms/blogs/gvelez/


"Ramon Espuga" wrote:

Hola a todos,

tendría que hacer una pequeña aplicación donde hay diversos tipos de
usuarios que acceden a una lista de WSS v2. El tema es que los usuarios
standard son los que tendrían que añadir nuevos items a la lista y los
usuarios de control son los que tendrían que dedicarse a completar y
gestionar dicha información. Para ello esta claro que para una misma
lista
deben haber formularios diferentes ya que unos usuarios deben poder
introducir y ver unos campos y otros usuarios deben poder introducir y
ver
otros campos distintos.

Se me ocurren varias formas de realizar esta implementación, pero no
acabo de ver claro cual puede ser la mejor de cara al posterior
mantenimiento y escalabilidad de la aplicación. Como lo realizariais
vosotros?

Muchísimas gracias,

Ramon



Respuesta Responder a este mensaje
#3 Ramon Espuga
01/12/2006 - 11:34 | Informe spam
Hola Gustavo,

De acuerdo contigo. El tema de la renderización, es que me gustaría
renderizarlos del mismo modo que lo hace WSS. Para ello, para cada campo
debería buscar en FLDTYPES.XML su RenderPattern, generar un a plantilla XSL
y transformar el XML que define el campo utilizando esta plantilla. FLDTYPES
está escrito utilizando CAML. Sabes si existe algún transformador de CAML a
XSLT o algun CAML parser donde le pase el XML que define el campo y el
fichero FLDTYPES y saque el HTML asociado?

Muchísimas gracias,

Ramon


"Gustavo" wrote in message
news:
Hola Ramon,
"problema es que al hacerlo así cualquier cambio en un campo o el añadir
un
campo nuevo requeriría modificar todos los formularios" -> No
necesariamente. La logica de tu programa puede leer que campos existen en
la
Lista, y de que tipo son, y generar la interface dinamicamente, de tal
forma
que si cambias algo en la lista, automaticamente sera visible en tu
programa.
Ademas, campos en listas tienen metadata que puedes usar para mostrarlos o
no, o puedes crear tus propios campos de "metadata" para los campos de
"data".
Para la renderizacion puedes usar una transformacion de HTML (XLST), de
tal
forma que cada campo se renderice de una forma particular, si quieres.
Saludos,
Gustavo
http://www.gavd.net/servers/default.aspx
http://geeks.ms/blogs/gvelez/


"Ramon Espuga" wrote:

Hola Gustavo,

como bien dices InfoPath no sería la solución ya que debería
instalarse
en todas las máquinas cliente y pagar licencias para cada uno de ellos.

La solución de realizar los diferentes formularios con ASPX o
mediante
una WebPart, es la que tiene más numeros. El problema es que al hacerlo
así
cualquier cambio en un campo o el añadir un campo nuevo requeriría
modificar
todos los formularios o WebParts, vamos al fin y al cabo reprogramar,
complicando así en parte el mantenimiento.

A mi se me ocurre la idea de hacer una WebPart parecida al
ListFormWebPart, pero con algún tipo de zona de configuración donde
puedas
escoger que campos mostrar o no. Hasta ahí más o menos bien, el problema
que
veo es como renderizar los campos del mismo modo que lo hace Sharepoint,
obteniendo el tipo, tamaño y demás de cada campo y renderizarlo segun
FLDTYPES.XML. Supongo que esta sería la solución óptima, pero bajo mi
punto
de vista bastante costosa ya que no se como renderizar los campos igual
que
lo hace Sharepoint de forma más o menos simple (Si sabeis alguna os
estaria
muy agradecido si me la podeis decir)

Viendo entonces que las 2 soluciones de programación que se me
ocurren
tienen alguna pega (Si en la 2a pudiese renderizar los campos de forma
fácil
sería ideal), me preguntaba si no habría alguna forma de hacerlo como con
FrontPage pero permitiendo tener más de un formulario. Es decir hacer una
copia del NewForm.aspx de la lista, eliminar los campos innecesarios y
publicarlo con otro nombre, por ejemplo NewFormUser.aspx pero sin perder
el
NewForm.aspx permitiendo así tener 2 formularios distintos de entrada de
datos para la misma lista. De este modo cada vez que se añadiese un campo
a
la lista, también debería modificarse el formulario, pero la forma de
modificarlo sería mucho más fácil, permitiendo incluso que fuese el mismo
usuario administrador que ha añadido el campo a la lista el que lo
hiciese.


Muchas gracias,

Ramon



"Gustavo" wrote in message
news:
> Hola Ramon,
> Si puedo meter la cucharada, lo primero que se me ocurre es utilizar
> InfoPath, pero ya se lo que todos van a decir (instalar InfoPath en
> todos
> los
> computadores, pagar licencias, que rollo...). De resto, con la forma
> clasica:
> una lista con un solo usuario que puede hacer de todo, una WebPart o
> pagina
> aspx que permite introducir datos en la lista por medio de un
> Impersonador.
> Sobre la WebPart o pagina aspx tienes todo el control de mostrar campos
> como
> quieras, y de implementar tu propia autorizacion...
> Suerte,
> Gustavo
> http://www.gavd.net/servers/default.aspx
> http://geeks.ms/blogs/gvelez/
>
>
> "Ramon Espuga" wrote:
>
>> Hola a todos,
>>
>> tendría que hacer una pequeña aplicación donde hay diversos tipos
>> de
>> usuarios que acceden a una lista de WSS v2. El tema es que los
>> usuarios
>> standard son los que tendrían que añadir nuevos items a la lista y los
>> usuarios de control son los que tendrían que dedicarse a completar y
>> gestionar dicha información. Para ello esta claro que para una misma
>> lista
>> deben haber formularios diferentes ya que unos usuarios deben poder
>> introducir y ver unos campos y otros usuarios deben poder introducir y
>> ver
>> otros campos distintos.
>>
>> Se me ocurren varias formas de realizar esta implementación, pero
>> no
>> acabo de ver claro cual puede ser la mejor de cara al posterior
>> mantenimiento y escalabilidad de la aplicación. Como lo realizariais
>> vosotros?
>>
>> Muchísimas gracias,
>>
>> Ramon
>>
>>
>>



email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaRespuesta Tengo una respuesta
Search Busqueda sugerida