Item

[SeiTaN]

No... de eso se encarga el launcher... desde los canales todo sigue igual... lo unico es q yodos los campos q tenga el item llegarian de una funcion a otra sin problema...

La unica modificacion es en el launcher y xbmctools lo demas se sigue usando como hasta ahora pero con la posibilidad de añadir el campo que cada cual mecesite

uhmmm entonces me has dado la razón, no?

canal_a

Código: Seleccionar todo

def mainlist(item):
   itemist =[]
   itemlist.append(Item(title="title", url="url", action="metodo_2", tourl="vengo desde canal A - mainlist"))

   return itemlist

Código: Seleccionar todo

def metodo_2(item):
   itemist =[]
   item.action = "metodo_3"
   itemlist.append(item)

   return itemlist

Código: Seleccionar todo

def metodo_3(item):
   itemist =[]
   item.action= "metodo_launcher"
   itemlist.append(item)

   return itemlist

launcher

Código: Seleccionar todo

def metodo_launcher(item):
   print "launcher -> item.tourl: " + item.tourl

launcher -> item.tourl: vengo desde canal A - metodo_1

¿Correcto?

[divadr]

Seria correcto usando cualquier otro campo que no sea "tourl" ya que eso corresponde a una funcion que tiene el item... pero con cualquier otro nombre funcionaria asi...

[jesus]

Aprovecho para meterme en este jardín también ja ja ja

La clase Item demuestra claramente que no sabía mucho de Python cuando la escribí, es una especie de engendro que hereda estilos de Java, de Javascript, y seguro que algo de Visual Basic

Yo lo arreglaría siguiendo la idea de divadr.

1) Dejamos unos campos fijos mínimos: title, channel, url, ...
2) Arreglamos el problema de la serialización de forma que todos los campos pasen a la URL (con ese "tourl" que suena tan gracioso)
3) Quitamos los campos que no tengan sentido ya (el viejo problema de a ver quién se atreve)

Yo no añadiría demasiados campos, como dice robalo me parece que puede resolverse casi todo con un "extra" como ya tenemos.

De todas formas hay una cosa que solucionar, y es propagar los datos para que un item de un mirror de una película tenga los metadatos de la película. Eso lo resolví en Android de otra forma, usando unos campos "contentTitle", "contentPlot", etc. (a ver si de esta puedo ya subir ese código a Github). Así es todo más claro:

Código: Seleccionar todo

package info.tvalacarta.pelisalacarta.commons;

public class Item {
	public boolean folder = true;

	public String channel = "";
	public String action = "";
	public String extra = "";
	public int page = 0;

	public String title = "";
	public String plot = "";
	public String thumbnail = "";
	public String fanart = "";
	public String fanartBackground = "";
	public String duration = "";
	
	public String url = "";
	public String pageUrl = "";
	public String server = "";
	
	public String contentChannel = "";
	public String contentTitle = "";
	public String contentThumbnail = "";
	public String contentPlot = "";

	public boolean hasContentDetails = false;
	public String contentType = "";
	public String contentSerieName = "";
	public String contentSeason = "";
	public String contentEpisodeNumber = "";
	public String contentEpisodeTitle = "";
	
	public static String CONTENT_TYPE_MOVIE = "movie";
	public static String CONTENT_TYPE_SERIE = "serie";
	public static String CONTENT_TYPE_OTHER = "other";

        ...

En el Item de Android hay un método "setParentContent" donde al crear un item le dices cuál es el Item padre, y eso propaga los metadatos de la película:

Código: Seleccionar todo

	public Item setParentContent(Item item) {
		this.contentChannel = item.contentChannel;
		this.contentTitle = item.contentTitle;
		this.contentThumbnail = item.contentThumbnail;
		this.contentPlot = item.contentPlot;

		this.hasContentDetails = item.hasContentDetails;
		this.contentType = item.contentType;
		this.contentSerieName = item.contentSerieName;
		this.contentSeason = item.contentSeason;
		this.contentEpisodeNumber = item.contentEpisodeNumber;
		this.contentEpisodeTitle = item.contentEpisodeTitle;
		
		return this;
	}

Una cosa interesante en Android es cómo se asignan los atributos del item, cada método "set" devuelve una referencia al item.

De esa forma podía poner cada item en una línea, igual que hacemos en Python:

Código: Seleccionar todo

public static Itemlist mainlist(Item item) {
    Log.d("Seriesflv.mainlist",".");

	Itemlist itemlist = new Itemlist();
	itemlist.add( new Item().setChannel(CHANNEL_NAME).setAction("menuepisodios").setTitle("Últimos episodios añadidos...").setFolder(true) );
	itemlist.add( new Item().setChannel(CHANNEL_NAME).setAction("series").setTitle("Todas las series").setUrl("http://www.seriesflv.net/ajax/lista.php").setExtra("grupo_no=0&type=series&order=titulo").setFolder(true) );
	itemlist.add( new Item().setChannel(CHANNEL_NAME).setAction("series").setTitle("Series más vistas").setUrl("http://www.seriesflv.net/ajax/lista.php").setExtra("grupo_no=0&type=series&order=hits").setFolder(true) );
	itemlist.add( new Item().setChannel(CHANNEL_NAME).setAction("series").setTitle("Telenovelas").setUrl("http://www.seriesflv.net/ajax/lista.php").setExtra("grupo_no=0&type=generos&order=novelas").setFolder(true) );
	itemlist.add( new Item().setChannel(CHANNEL_NAME).setAction("search").setTitle("Buscar...").setFolder(true) );
	
	return itemlist; 
}

[SeiTaN]

Yo lo arreglaría siguiendo la idea de divadr.

1) Dejamos unos campos fijos mínimos: title, channel, url, ...
2) Arreglamos el problema de la serialización de forma que todos los campos pasen a la URL (con ese "tourl" que suena tan gracioso)
3) Quitamos los campos que no tengan sentido ya (el viejo problema de a ver quién se atreve)

Yo creo que lo ideal sería empezar una nueva versión de cero. No sería de cero como tal, porque la mayoría está modularizado.

Si item es la clase básica para utilizar el plugin debería ir rehaciendose el resto en consonancia, así no habría los dolores de cabeza de... antes funcionaba y ahora no funciona.

Por mi se podría intentar y echaré una mano si me lo permitís, así se limpiaría código, he visto funciones y partes de código que están muertas porque ya no existen canales para los que se usaban.

[super_berny]

Yo viendo el debate por TV y resulta q el verdadero debate estaba aqui

Bueno, tengo muchos temas por comentar asi q espero no dejarme ningun hilo pendiente.

Aprovecho para meterme en este jardín también ja ja ja

'Bienvenido a tu casa' jejeje

Yo lo arreglaría siguiendo la idea de divadr.

Completamente de acuerdo. Si no he entendido mal es un sistema abierto en el q cada cual es libre de añadir campos al Item a su voluntad, respetando claro esta unos minimos.

De todas formas hay una cosa que solucionar, y es propagar los datos para que un item de un mirror de una película tenga los metadatos de la película.

Yo creo q la cosa ya esta solucionada: Cada uno puede añadir campos libremente y todos los campos se propangan de una llamada a otra.
Otra cosa es si realmente quieres hacer algo en particular con esos metadatos al crear el xbmcgui.ListItem, en ese caso sugeriria utilizar infoLabels(ya sin el truco del plot claro esta).
Por otro lado siempre me he preguntado (y no he probado por vagancia ) por que creamos un Item nuevo en cada llamada, pudiendo pasar el item anterior modificado:

Código: Seleccionar todo

def foo(item):
    # Aqui hacemos alguna cosa
    item.title= item.title.capitalize()
    # Aqui modificamos la url por ejemplo
    url= item.url.replace(".com",".es")
    # Es decir, vamos modificando los campos del item pasado como parametro
    # Para finalmente crear un nuevo Item ...
    itemlist.append( Item(channel=item.channel, action="listado" , title=item.title , url=url)) 
    # ... cuando en realidad podriamos hacer ...
    item.action = "listado"
    item.url = item.url.replace(".com",".es")
    itemlist.append(item)

Con lo cual no es necesario saber quien es su padre y nos aseguramos pasar todos los campos de 'padres' a 'hijos' (entrecomillas, no confundir con la herencia de POO)

Yo creo que lo ideal sería empezar una nueva versión de cero. No sería de cero como tal, porque la mayoría está modularizado.

Yo no creo q sea necesario empezar de cero, aunque si pequeñas (o no tan pequeñas) modificaciones q mejoren, clarifiquen o aporten cosas nuevas.
De lo que si me alegro es de haya debate sobre estos temas, diferentes estilos y diferentes propuestas para solucionar algun tema. Creo q eso nos enriquece a todos, aunque reservo para Jesus la ultima decision en todo.
Democracia si. Pero al Cesar lo q es del Cesar

[jesus]

Yo lo arreglaría siguiendo la idea de divadr.

Completamente de acuerdo. Si no he entendido mal es un sistema abierto en el q cada cual es libre de añadir campos al Item a su voluntad, respetando claro esta unos minimos.

Algo así, yo me refería más bien a serializar todos los atributos del item para pasarlos a la URL de XBMC, ahora se hace solo para algunos.

De todas formas hay una cosa que solucionar, y es propagar los datos para que un item de un mirror de una película tenga los metadatos de la película.

Yo creo q la cosa ya esta solucionada: Cada uno puede añadir campos libremente y todos los campos se propangan de una llamada a otra.

Igual no te entiendo bien, pero los campos no se propagan todos. Solo aquellos que están en el xbmctools...

Otra cosa es si realmente quieres hacer algo en particular con esos metadatos al crear el xbmcgui.ListItem, en ese caso sugeriria utilizar infoLabels(ya sin el truco del plot claro esta).

A mí me parece una buena idea

Por otro lado siempre me he preguntado (y no he probado por vagancia ) por que creamos un Item nuevo en cada llamada, pudiendo pasar el item anterior modificado:

Código: Seleccionar todo

def foo(item):
    # Aqui hacemos alguna cosa
    item.title= item.title.capitalize()
    # Aqui modificamos la url por ejemplo
    url= item.url.replace(".com",".es")
    # Es decir, vamos modificando los campos del item pasado como parametro
    # Para finalmente crear un nuevo Item ...
    itemlist.append( Item(channel=item.channel, action="listado" , title=item.title , url=url)) 
    # ... cuando en realidad podriamos hacer ...
    item.action = "listado"
    item.url = item.url.replace(".com",".es")
    itemlist.append(item)

Con lo cual no es necesario saber quien es su padre y nos aseguramos pasar todos los campos de 'padres' a 'hijos' (entrecomillas, no confundir con la herencia de POO)

Probablemente es desconocimiento por mi parte... arrastro vicios de varios lenguajes de programación.

De hecho no veo la ventaja de un método a otro, me parece más limpio el primero.

Yo creo que lo ideal sería empezar una nueva versión de cero. No sería de cero como tal, porque la mayoría está modularizado.

Yo no creo q sea necesario empezar de cero, aunque si pequeñas (o no tan pequeñas) modificaciones q mejoren, clarifiquen o aporten cosas nuevas.
De lo que si me alegro es de haya debate sobre estos temas, diferentes estilos y diferentes propuestas para solucionar algun tema. Creo q eso nos enriquece a todos, aunque reservo para Jesus la ultima decision en todo.
Democracia si. Pero al Cesar lo q es del Cesar

Lo malo del item es que afecta a un montón de cosas.

Me parece bien si lo mejoramos, mejorar siempre es bueno

Aunque en mi opinión si el cambio va a afectar a todo el código deberíamos decidir bien lo que vamos a hacer antes de modificarlo.

[divadr]

Lo malo del item es que afecta a un montón de cosas.

Me parece bien si lo mejoramos, mejorar siempre es bueno

Aunque en mi opinión si el cambio va a afectar a todo el código deberíamos decidir bien lo que vamos a hacer antes de modificarlo.

Precisamente por eso me parece que lo mejor es usar un método que, por una parte, nos aseguremos que todas las propiedades del ítem se propaguen a través de la url, y por otra parte, a excepción de unos campos que tienen que estar siempre para que todo funcione correctamente, cada canal puede añadir lo que necesite al ítem, estando seguro que recibirá esos datos en la siguiente función.

de este modo probablemente, no tengamos que tocar el Ítem, nunca mas.

Con el código que yo propongo esto se puede hacer perfectamente, solo hay que modificar en el xbmctools todas los lugares donde se genera las url, y utilizar la función ítem.tourl()

Si un día se ve que es mejor generar la url con otro formato, solo con cambiar las funciones tourl() y fromurl() para el otro formato, todo seguiría funcionando igual.

También creo que hay dejar claro como se usan los campos title, fulltitle:
¿Dónde va el título de la película?
yo pienso que habría que dejar un campo para el titulo de la película y otro para lo que tu quieras que muestre en el listado.. ya que en ocasiones no se sabe si el titulo hay que ponerlo en title, fultitle y luego en el reproductor no sale el titulo correctamente, y si luego queremos por ejemplo buscar subtitulos, no tenemos el titulo limpio para buscar.

[super_berny]

Igual no te entiendo bien, pero los campos no se propagan todos.

Me referia a la propuesta de divadr. Ahi si se propagan todos los campos.

Probablemente es desconocimiento por mi parte... arrastro vicios de varios lenguajes de programación.
De hecho no veo la ventaja de un método a otro, me parece más limpio el primero.

Aqui me he pasado de listo Al ser una lista los objetos se pasan por referencia asi q sucesivos cambios del objeto item (dentro de un bucle de N iteracciones, por ejemplo) produce q al final la lista contenga N veces el mismo item (en concreto el item numero N) Se puede solucionar haciendo copias del objeto item ( listitem.append(copy.copy(item)) ), pero lo veo mas liado.

[jesus]

La diferencia entre el title y el fulltitle era simplemente para quedarme con el nombre de la peli a la hora de descargarla, ya que lo que descargas puede ser un item con titulo "Mirror en streamcloud" cuando tú lo que quieres es "Amanecer rojo [DVDRip]".

Eso es lo que comentaba que resuelvo en Android con los campos "content".

Si es una película los metadatos de la película van aquí:

Código: Seleccionar todo

contentTitle
contentThumbnail
contentPlot

Y si es una serie o un episodio de una serie, además añadimos estos otros:

Código: Seleccionar todo

contentSerieName
contentSeason
contentEpisodeNumber
contentEpisodeTitle

En general un item es una serie, episodio o pelicula si tiene estos tres atributos:

Código: Seleccionar todo

hasContentDetails
contentType
contentChannel

Y la idea es que cuando tienes un item que es una película, por ejemplo, todos los items hijos los creas pasándole ese item como padre.

Por ejemplo, si en una accion de un canal tengo este item que me llega como parámetro:

Código: Seleccionar todo

item = Item(title="Amanecer rojo [DVDRip]")

El itemlist lo construyo con:

Código: Seleccionar todo

itemlist.append(title="Mirror en AAA",parentContent=item)
itemlist.append(title="Mirror en BBB",parentContent=item)
...

Lo único que haces con ese "parentContent" es que aprovechas en el constructor del Item para copiar los campos de contenido de padres a hijos. Este cambio hay que hacerlo en cada canal, lógicamente, porque es ahí donde sabes cuando un item es una película o una serie.

Y de esa forma cuando quieres descargar un vídeo, o mostrar sus metadatos, o añadirlo a la biblioteca ya no tienes que ir al "title", "thumbnail" etc sino al "contentTitle", "contentThumbnail".

En la próxima versión pensaba incluir esto en los canales de la sección de "Novedades" para sacarle algo más de brillo a la versión Skin.

[divadr]

Bueno... mas o menos es lo que yo imaginava... pero claro tal como se usa ahora lo de fulltitle se queda corto.... pero siempre he defendido la idea de buscar la manera para que los datos de la pelicula lleguen hasta el reproductor de manera correcta... porque ahora cada canal lo hace como le parece y no veo que siga ningun patron logico

Es por eso que si hay unos campos especificos para eso... es todo mucho mas sencillo... y hasta el mismo launcher se puede encargar de pasar ese contenido de "padres" a "hijos" pues si el padre contiene algun dato en el campo del nombre de la peli y el hijo no contiene nada... solo hay q pasarlo de uno al otro... sin necesidad de hacer nada en los canales...