FAQ
Quisiera comentar un proyecto en el cual, lamentablemente, no he podido
avanzar demasiado por mi inexperiencia con Yacc y Lex.

Siendo que el PHP se usa principalmente para generar páginas de web y, creo
que cada vez más en el futuro también servicios de web (por ejemplo noticias
mediante RSS), esto implica emitir XML o HTML. En general, para no ser
repetivivo, en adelante me referiré al conjunto HTML (y todas sus
variedades) y XML simplemente como XML.

Es cierto que herramientas como Smarty u otros procesadores de templates
disminuyen la cantidad de XML generado y que mucho puede ser generado por
funciones o clases que encapsulen toda la generación de 'tags' de tal manera
que el programa de aplicación tenga poco de XML en el, sin embargo, no
importa cuántas capas se pongan entre medio de la aplicación y el navegador
o el programa cliente del servicio de web, el caso es que antes o después,
en algún punto se han de generar tags de XML.

PHP, como cualquier otro lenguaje de programación estructurado, y XML
comparten el concepto de bloque. En PHP cada bloque se encierra entre
llaves, en XML entre un tag de inicio y uno de final. Aunque se pueden
encontrar excepciones, es natural que ambos bloques se aniden de forma
compatible. Con esto quiero decir que, si uno emite un <p> dentro de un
condicional if(), es natural que antes de terminar el bloque if() se cierre
el <p> con un </p>. No hacerlo así implicaría desbalancear los bloques y
esto no estaría correcto (es cierto que un navegador puede ignorarlo y
presentarlo bien, pero no es el caso). Esto quiere decir que el bloque <p>
queda totalmente anidado dentro del bloque if().

Por ello, se me ocurrió que sería muy bueno que la estructura de bloques de
XML quedara claramente manifiesta dentro de la estructura de bloques de PHP
con una sintaxis compatible, de alguna forma, que el bloque de XML se
representara con instrucciones nativas de PHP y que sus bloques se
encerraran con llaves, al igual que los de PHP.

Asi es como se me ocurrió el agregado de dos instrucciones nuevas para PHP,
TAG y ATT, que se abreviarían con los símbolos < y @. Agregar instrucciones
a un lenguaje no es cosa fácil, implicaría un 'fork', una práctica que no es
bueno alentar. Por ello se me ocurrió que podría hacerse mediante un
precompilador, tal como inicialmente el C++ era un precompilador que
generaba código fuente en C.

Estas instrucciones se podrían usar de la siguiente forma, por ejemplo, un
párrafo de texto alineado sobre derecha se podría codificar así:

<p {
@align 'right';
echo 'Este es el texto alineado sobre derecha';
}

El <p emitiría un '<p', dejando pendiente el cierre del tag de inicio a la
espera de qué encuentre más adelante. El @align indicaría un atributo (en
inglés al signo @ se le llama 'at sign' de allí que lo usara para denominar
al ATributo). En este caso, el atributo es align y su valor el literal
'right'. Luego viene la instrucción echo, que forzaría al precompilador a
generar el cierre del tag de inicio, o sea el '>' y emitir el texto que se
le indica. Finalmente, la llave del cierre de bloque debe extraer la pila
el simbolo que representa la instrucción conque se ha iniciado el bloque, en
este caso la instruccion '<' y su valor 'p', con lo cual emitirá un '</p>'.

En definitiva, el ejemplo de código precedente habrá generado lo siguiente:

echo '<p', ' align="right"', '>', 'Este es el texto alineado sobre derecha',
'</p>';

En este código he omitido, por claridad, la simple optimización de ir
concatenando los literales para hacer una única cadena.

Formalmente, las instrucciones podría expresarse de la siguiente manera:

< etiqueta instrucción

Donde:
< es el símbolo '<',
etiqueta es un nombre válido de una etiqueta de XML
instrucción puede ser una única instrucción o un bloque encerrado entre
llaves, como en el ejemplo.

Alternativamente se puede prever que el símbolo < fuera seguido por una
variable, que sería fácil de distinguir de la etiqueta literal por compenzar
con $.

A su vez, la instrucción ATT se podría expresar como:

@nombre expresión

Donde:
@ es el símbolo '@',
nombre es un nombre válido de atributo (como en el caso anterior, podría
ser una variable)
expresión es cualquier expresión de PHP que genere el valor que se le
quiera dar al atributo.

Para mostrar el uso de variables, el ejemplo anterior podría escribirse así:

$parrafo = 'p';
$alineamiento = 'align';
$derecha = 'right';
$texto = 'Este es el texto alineado sobre derecha';

<$parrafo {
@$alineamiento $derecha;
echo $texto;
}

Que generaría:

echo '<',$parrafo,' ' ,
$alineamiento,'="',$derecha,'"',">",$texto,'</',$parrafo,'>';

Cuál es la razón de todo esto? Primero porque se me ocurrió, como afición,
que sería interesante que hiciera algo con el Yacc y el Lex, aunque admito
que me superó. Esto puede no ser compartido con los potenciales usuarios,
así que tiene que haber algo más.

Yo he llegado a programar en assembler y en montones de lenguajes que ya
casi no existen. Recuerdo cuando los lenguajes estructurados comenzaron a
aparecer. Alguien aún se acuerda de la instrucción Goto? Bueno, el goto
permitía saltar de un punto cualquiera de un programa a cualquier otro
lugar. Nada de estructura, nada de bloques, todo se podía. A este se le
llamaba 'código spaghetti' pues era todo enredado, imposible de seguir. El
código estructurado impedía esta libertad y nos costó bastante trabajo
darnos cuenta que eran más las ventajas que las limitaciones. El código era
más simple, mejor estructurado, más fácil de entender y todo ello llevaba a
que tuviera menos errores.

Actualmente, de la forma que generamos XML lo que estamos haciendo es muy
parecido al 'código spaghetti' que eran nuestros programas. Como en
definitiva no hacemos más que concatenar cadenas de texto arbitrarias,
podemos generar lo que querramos sea para bien o mal. Los estructura
impuesta por los lenguajes estructurados mejoró la calidad del código. Me
gustaría ver esa misma mejora de calidad a nivel del XML que generamos.

Al usar el mismo tipo de estructura para el código PHP que para el XML, una
ventaja es que podemos usar dos herramientas muy habituales de cualquier IDE
para validarlas. Por un lado un Code Beautifier permite hermosear ambos
bloques, por otro, la función de buscar llaves apareadas nos permite
asegurarnos de no dejar ningún tag sin cerrar. De las comillas que deben
encerrar los argumentos de un atributo, ni hablar pues esas las generaría el
precompilador por sí solo y no hay nada de qué preocuparse.

Finalmente, como una validación aún más estricta, podríamos declarar a qué
DTD o Schema debe responder el código XML generado, de tal maneras de
validar aquello que fueramos a generar a nivel compilador. Deberíamos
disponer de una declarativa que permitiera indicar el DTD o Schema y un
segundo argumento, opcional, que indicara la entidad o el xpath del Schema a
que debe responder una función, pues una función o clase, en general, sólo
generará un segmento del Schema. Esta misma declaración no sólo permitiría
validar el XML que genera la función sino que, además, permitiría verificar
que la función es llamada sólo en el punto adecuado de la estructura global
del XML de la página.


Dado que yo también uso templates y funciones para mis aplicaciones, debo
admitir que he debido buscar un poco entre mis fuentes para encontrar alguno
en que realmente hubiera generado HTML directamente, pero aquí les pongo un
ejemplo más completo de lo que propongo. Aprovecho para mostrar cómo
resuelvo el asunto de llenar un combo con valores dependientes de otro. En
este caso, cargo las provincias en función del pais seleccionado.

Les comento que al reescribirlo dentro de mi IDE, me encontré conque al
final me aparecía la última llave subrayada en rojo, claro indicio de que
estaba desapareada. El Code Beautifier me permitió encontrar rápidamente el
error, cosa que pude hacer a nivel del código fuente, en lugar de lo
habitual que es darle una corrida y ver qué ocurrió.

// Según $IdDireccion contenga un valor mayor que cero o no, sé si es un
registro existente para mostrar
// o un nuevo para generar.

if ($IdDireccion) {
// si existe, lo consulto
$row = mysql_query_row('
Select
Direccion1,Direccion2,CodPos,Ciudad,Direcciones.IdProvincia,Paises.IdPais
from Direcciones
inner join Provincias on Direcciones.IdProvincia =
Provincias.IdProvincia
inner join Paises on Provincias.IdPais = Paises.IdPais
where IdDireccion = '
. $IdDireccion
);
$IdPais = $row['IdPais'];
$IdProvincia = $row['IdProvincia'];
} else {
// si es un registro nuevo ($IdDireccion == 0) entonces cargo los
valores predeterminados de país y provincia
$IdPais = LeeParam('PaisPredeterminado', 'AR');
$IdProvincia = LeeParam('ProvinciaPredeterminada', 1);
}

// En este iframe es dónde se cargará dinámicamente el combo correspondiente
a las provincias.
// Inicialmente usa el pais predeterminado, luego es recargado a partir del
combo de paises
// Noten que aquí comienza el uso de las instrucciones < y @
<IFRAME {
@Id 'iFrameProvincias';
@src 'Select.php?Name=IdProvincia&Select=1&Valor=' . $IdPais;
@onLoad
'document.getElementById("xProvincias").innerHTML=iFrameProvincias.document.body.innerHTML';
@style 'display:none';
}
// Noten que en los atributos no estoy limitado a poner solamente cadenas de
caracteres,
// también puedo usar variables.
// El form esta ya abierto, no aparece dentro de este código
<input {
@type 'hidden';
@name 'IdDireccion';
@value $IdDireccion;
}
// Noten a partir de aquí cómo la estructura de la tabla se hace tan obvia
como la
// estructura misma del código en PHP
<table {
<tr {
<th {
@rowspan 2;
@valign "top";
// Aquí he usado otra abreviatura que no he mencionado, el signo
? en lugar de 'echo'
? 'Direcci&oacute;n';
}
<td {
<input {
@name 'Direccion1';
@size 50;
@value $row['Direccion1'];
}
}
}
// noten que el uso de las llaves es tan opcional como lo es en PHP.
// Si un bloque está compuesto de una única instrucción, no es necesario
encerrarlo entre llaves.
<tr <td <input {
@name 'Direccion2';
@size 50;
@value $row['Direccion2'];
}
<tr {
// Aqui vuelve a repetirse lo mismo. No es necesario poner las
llaves en el TH y el TD
// pero si lo ha sido en el TR precedente, pues encierra dos
instrucciones
// y también lo es en el INPUT, pues encierra dos instrucciones, en
este caso atributos.
<th 'Código Postal';
<td <input {
@name 'CodPos';
@value $row['CodPos'];
}
}
<tr {
<th 'Ciudad';
<td <input {
@name 'Ciudad';
@size 50;
@value $row['Ciudad'];
}
}
<tr {
<th 'Provincia';
<td {
@Id 'xProvincias';
// El contenido del combo es provisto por esta función que,
// a partir de una instrucción de SQL (la función ArmaSql la he
comentado en otro mensaje)
// genera el HTML correspondiente a un combo con el nombre
indicado en el primer argumento
// las duplas valor => descripción provistas por el SQL del
segundo argumento
// y si hubiera un tercer argumento, será el valor
preseleccionado
// Noten cómo es posible mezclar literales, variables,
funciones.
MuestraCombo(
'IdProvincia'
, CargaCombo(ArmaSql('Select IdProvincia,Descr from
Provincias where IdPais = ?s order by Descr' , $IdPais))
, $IdProvincia
);
}
}
<tr {
<th 'País';
// Este combo es el que selecciona pais y en función del pais
seleccionado
// recarga el combo de provincias con las que le correspondan.
// Noten en la función MuestraCombo un cuarto argumento que no se
usó en la llamada anterior
// este cuarto argumento es un array de la forma evento => acción
<td MuestraCombo('IdPais'
, CargaCombo('Select IdPais,Descr from Paises order by Descr')
, $IdPais
, array('onChange' =>
"document.getElementById('iFrameProvincias').src =
'Select.php?Name=IdProvincia&Select=1&Valor=' + this.value ")
);
}
}

Search Discussions

  • Satyam at Apr 2, 2005 at 9:23 pm
    Si sabes Yacc Y Lex, tengo una lista grande como una casa de preguntas, pero
    en principio, lo que necesitaría ver es si lo que yo comento es viable y
    útil.

    En principio, creo que no hay conflictos en el uso de los símbolos < y @
    como se indica. El simbolo @ no se usa en PHP y el signo < se usa como
    operador lógico binario (o sea, entre dos expresiones) con lo que es
    perfectamente posible distinguirlo del simbolo < usado como instrucción.

    Creo que tampoco se da ninguna ambigüedad en el uso del literal con el
    nombre del tag o atributo, o una variable. Esto excluye el uso de
    constantes y funciones que devuelven valor, pero creo que esto no es
    necesario.

    O sea, esto es posible:

    <p

    y también

    $p='p'
    <$p

    Pero los siguientes no:

    define('PARRAFO', 'p')
    <PARRAFO

    Pues en este caso no podría distinguir entre una constante llamada PARRAFO y
    el tag PARRAFO, que no existe.

    Tampoco sería posible o, mejor dicho, no sería fácil implementar:

    <strtolower($parrafo)

    pues la forma más simple de hacer el parsing sería tomar todo hasta el
    primer caracter inválido como nombre de tag. En este caso, sin embargo, la
    presencia de paréntesis daría lugar a darse cuenta que es una función y
    podría buscarse la vuelta.

    Este tipo de cuestiones de validez sintáctica y semántica hacen a un buen
    diseño y hasta encontrar cómo avanzar en el parser con Yacc y Lex es un
    esfuerzo bien empleado, pues cualquier problema irresoluble en este sentido
    invalida totalmente el proyecto.

    Gracias

    Satyam

    ----- Original Message -----
    From: "Vladimir Hernández" <interco@linuxbaja.org>
    To: "Satyam" <Satyam@satyam.com.ar>
    Sent: Saturday, April 02, 2005 10:35 PM
    Subject: Re: [PHP-ES] Instrucciones específicas para XML/HTML

    Hay algo que se pueda hacer?

    --
    Vladimir Hernández
    http://linuxbaja.org
    Linux registered user # 374079
  • Jordi Canals at Apr 3, 2005 at 1:28 am

    On Apr 2, 2005 11:23 PM, Satyam wrote:

    En principio, creo que no hay conflictos en el uso de los símbolos < y @
    como se indica. El simbolo @ no se usa en PHP y el signo < se usa como
    operador lógico binario (o sea, entre dos expresiones) con lo que es
    perfectamente posible distinguirlo del simbolo < usado como instrucción.
    El símbolo @ sí se utiliza en PHP. Se incluye delante de una llamada a
    función cuando deseas desahibilitar la generación de errores.

    Salu2.
  • Satyam at Apr 3, 2005 at 1:34 pm
    Tienes razon!!!! Y en este caso, no veo forma de discriminar por contexto
    el uso de @ para deshabilitar la detección de errores y el atributo.

    Gracias, este es el tipo de ayuda que necesito, ver las cosas que he pasado
    por alto.

    Satyam


    "Jordi Canals" <jcanals@gmail.com> wrote in message
    news:f5b8d433050402172875b31062@mail.gmail.com...
    On Apr 2, 2005 11:23 PM, Satyam wrote:

    En principio, creo que no hay conflictos en el uso de los símbolos < y @
    como se indica. El simbolo @ no se usa en PHP y el signo < se usa como
    operador lógico binario (o sea, entre dos expresiones) con lo que es
    perfectamente posible distinguirlo del simbolo < usado como instrucción.
    El símbolo @ sí se utiliza en PHP. Se incluye delante de una llamada a
    función cuando deseas desahibilitar la generación de errores.

    Salu2.
  • Rafael Salazar at Apr 4, 2005 at 6:17 pm
    Opiniones "dentro" del mensaje --por cierto, creo que "XHTML" hubiera
    sido más acertado ;)

    Satyam wrote:
    Es cierto que herramientas como Smarty u otros procesadores de templates
    disminuyen la cantidad de XML generado y que mucho puede ser generado por
    funciones o clases que encapsulen toda la generación de 'tags' de tal manera
    que el programa de aplicación tenga poco de XML en el, sin embargo, no
    importa cuántas capas se pongan entre medio de la aplicación y el navegador
    o el programa cliente del servicio de web, el caso es que antes o después,
    en algún punto se han de generar tags de XML.
    Creo que esto depende, más que otra cosa, en el flujo que dicta el
    análisis del proyecto. Personalmente he visto varias aplicaciones web
    que tienen completamente separada la funcionalidad de la interfaz, y no
    tienen mayor problema (además el código generado es muy limpio, si el
    programador / diseñador respeta la indentación)
    PHP, como cualquier otro lenguaje de programación estructurado, y XML
    comparten el concepto de bloque. En PHP cada bloque se encierra entre
    llaves, en XML entre un tag de inicio y uno de final. Aunque se pueden
    encontrar excepciones, es natural que ambos bloques se aniden de forma
    compatible. Con esto quiero decir que, si uno emite un <p> dentro de un
    condicional if(), es natural que antes de terminar el bloque if() se cierre
    el <p> con un </p>. No hacerlo así implicaría desbalancear los bloques y
    esto no estaría correcto (es cierto que un navegador puede ignorarlo y
    presentarlo bien, pero no es el caso). Esto quiere decir que el bloque <p>
    queda totalmente anidado dentro del bloque if(). [···]
    Asi es como se me ocurrió el agregado de dos instrucciones nuevas para PHP,
    TAG y ATT, que se abreviarían con los símbolos < y @. Agregar instrucciones
    a un lenguaje no es cosa fácil, implicaría un 'fork', una práctica que no es
    bueno alentar. Por ello se me ocurrió que podría hacerse mediante un
    precompilador, tal como inicialmente el C++ era un precompilador que
    generaba código fuente en C.
    Creo que sería mejor utilizar caracteres inexistentes (y tal vez mejor
    aún, caracteres inválidos) en PHP, aunque esto reduce el conjunto de
    caracteres disponibles. Los que mencionas tienen significado en PHP, y
    aunque tal vez pudieras ingeniártelas para distinguir los casos de
    alguna forma, creo que te facilitarías la vida desechando estos casos
    desde el inicio.
    Estas instrucciones se podrían usar de la siguiente forma, por ejemplo, un
    párrafo de texto alineado sobre derecha se podría codificar así:

    <p {
    @align 'right';
    echo 'Este es el texto alineado sobre derecha';
    } [···]
    En definitiva, el ejemplo de código precedente habrá generado lo siguiente:

    echo '<p', ' align="right"', '>', 'Este es el texto alineado sobre derecha',
    '</p>';

    En este código he omitido, por claridad, la simple optimización de ir
    concatenando los literales para hacer una única cadena.
    Lo óptimo sería justamente como lo tienes actualmente, usando la
    instrucción "echo", separando los "parámetros" con comas, y utilizando
    comillas simples. Me parece recordar un artículo de este tema en Zend.

    [···]
    Cuál es la razón de todo esto? [···]
    Yo he llegado a programar en assembler y en montones de lenguajes que ya
    casi no existen. Recuerdo cuando los lenguajes estructurados comenzaron a
    aparecer. Alguien aún se acuerda de la instrucción Goto? Bueno, el goto
    permitía saltar de un punto cualquiera de un programa a cualquier otro
    lugar. Nada de estructura, nada de bloques, todo se podía. A este se le
    llamaba 'código spaghetti' pues era todo enredado, imposible de seguir. El
    código estructurado impedía esta libertad y nos costó bastante trabajo
    darnos cuenta que eran más las ventajas que las limitaciones. El código era
    más simple, mejor estructurado, más fácil de entender y todo ello llevaba a
    que tuviera menos errores.

    Actualmente, de la forma que generamos XML lo que estamos haciendo es muy
    parecido al 'código spaghetti' que eran nuestros programas. Como en
    definitiva no hacemos más que concatenar cadenas de texto arbitrarias,
    podemos generar lo que querramos sea para bien o mal. Los estructura
    impuesta por los lenguajes estructurados mejoró la calidad del código. Me
    gustaría ver esa misma mejora de calidad a nivel del XML que generamos. [···]
    Dado que yo también uso templates y funciones para mis aplicaciones, debo
    admitir que he debido buscar un poco entre mis fuentes para encontrar alguno
    en que realmente hubiera generado HTML directamente, pero aquí les pongo un
    ejemplo más completo de lo que propongo. Aprovecho para mostrar cómo
    resuelvo el asunto de llenar un combo con valores dependientes de otro. En
    este caso, cargo las provincias en función del pais seleccionado. [···]
    // Noten a partir de aquí cómo la estructura de la tabla se hace tan obvia
    como la
    // estructura misma del código en PHP
    <table {
    <tr {
    <th {
    @rowspan 2;
    @valign "top";
    // Aquí he usado otra abreviatura que no he mencionado, el signo
    ? en lugar de 'echo'
    ? 'Direcci&oacute;n';
    }
    <td {
    <input {
    @name 'Direccion1';
    @size 50;
    @value $row['Direccion1'];
    }
    }
    } [···]
    // Este combo es el que selecciona pais y en función del pais
    seleccionado
    // recarga el combo de provincias con las que le correspondan.
    // Noten en la función MuestraCombo un cuarto argumento que no se
    usó en la llamada anterior
    // este cuarto argumento es un array de la forma evento => acción
    <td MuestraCombo('IdPais'
    , CargaCombo('Select IdPais,Descr from Paises order by Descr')
    , $IdPais
    , array('onChange' =>
    "document.getElementById('iFrameProvincias').src =
    'Select.php?Name=IdProvincia&Select=1&Valor=' + this.value ")
    );
    }
    }
    Interesante, tengo una función similar a "MuestraCombo()", y ese 4
    parámetro, aunque no lo he necesitado, me parece una muy buena (y
    lógica) idea; es una de ésas ideas que uno dice "¿cómo es que no se me
    había ocurrido?"

    En resumen, creo que es una idea por demás interesante, lo ideal sería
    poder "hackear" el código de PHP para implementar este tipo de
    instrucciones de forma más eficiente y totalmente transparente, pero
    sería demasiado pedir :| Un problema que veo es que no estoy seguro de
    que el código PHP resultante del pre-compilado sea eficiente, amén de la
    legibilidad del mismo.

    Me agradaría mucho de que me informaras si tu idea llegó a buen fin, y
    poder probar el resultado (y si puedo ayudar en algo, avísame --no
    conozco Yacc ni Lex) Personalmente creo que con algo de disciplina al
    momento de "codificar" (i.e: "escribir código") y el uso de plantillas
    (incluso más sencillas que Smarty) se puede obtener un excelente
    resultado en el código 'XHTML', aunque, de nuevo, espero poder probar la
    implementación de esta idea tuya :)
    --
    Atentamente,

    J. Rafael Salazar Magaña
    Innox - Innovación Inteligente
    +52 (33) 3615 5348 ext. 205
    rsalazar@innox.com.mx
    http://www.innox.com.mx
  • Satyam at Apr 5, 2005 at 9:20 am
    Te respondo todo breve aqui arriba.

    Use XML como la expresion más generica para toda esa familia de 'MLs'
    (markup languages), en definitiva, XHTML es un XML que responde a ese
    'schema' particular de XML.

    El uso de caracteres < y @ en lugar de palabras claves (tag y att) se debe a
    que, en primer lugar es más breve y en segundo porque nunca crearía
    conflicto con código existente pues, dado que las palabras tag y att no
    están dentro de la lista de palabras reservadas de PHP, bien puede que
    existan aplicaciones que las estén usando.

    No es problema usar un simbolo repetido en tanto sea posible desambiguar su
    uso, esto es, distinguir cuando se debe interpretar de una forma y cuando de
    otra. Tal es el caso del ; en PHP que, dentro de un for() no implica el fin
    de la instrucción. O el caso del = en Basic que puede significar asignación
    o comparación por igual, y el significado queda claro por el contexto.

    Acertijo:

    A = 0
    A=A=A

    Qué valor queda en A al final de esto? Si fuera PHP (o C o JavaScript),
    primeramente, le faltarían los ; al final de cada instrucción y A quedaría
    igual, en el caso de Basic, esto funciona y A queda en TRUE pues en la
    segunda instrucción, el primer = es una asignación y el segundo una
    comparación, como A es igual a A, la comparación da true, y ese es el valor
    que se le asigna a A

    En este caso, el signo < es fácil desambiguarlo cuando se usaría como TAG y
    cuando como comparación, no así el simbolo @, ese se me escapó hasta que
    Jordi me lo hizo notar, y la verdad es que no hay otro caracter que me sea
    tan satisfactorio como el @.

    Es más rápido esto:

    echo '<p>esta es una prueba</p>';

    que esto:

    echo '<p>', 'esta es una prueba','</p>';

    en tanto la longitud total del string sea relativamente corta, cuando pasa
    de cierto tamaño, conviene fraccionarlo pues le evitas trabajo de
    reasignación de bloques de memoria en el 'heap'. Puede sino que lo que te
    haya venido a la mente es que es mejor esto:

    $texto = 'esta es una prueba';
    echo '<p>',$texto,'</p>';

    que esto:

    $texto = 'esta es una prueba';
    echo '<p>'.$texto.'</p>';

    Finalmente, gracias por el comentario sobre MuestraCombo y el 4to parámetro
    y por tus comentarios.

    Satyam

    "Rafael Salazar" <rsalazar@innox.com.mx> wrote in message
    news:20050404181729.2715.qmail@lists.php.net...
    Opiniones "dentro" del mensaje --por cierto, creo que "XHTML" hubiera sido
    más acertado ;)

    Satyam wrote:
    Es cierto que herramientas como Smarty u otros procesadores de templates
    disminuyen la cantidad de XML generado y que mucho puede ser generado por
    funciones o clases que encapsulen toda la generación de 'tags' de tal
    manera que el programa de aplicación tenga poco de XML en el, sin
    embargo, no importa cuántas capas se pongan entre medio de la aplicación
    y el navegador o el programa cliente del servicio de web, el caso es que
    antes o después, en algún punto se han de generar tags de XML.
    Creo que esto depende, más que otra cosa, en el flujo que dicta el
    análisis del proyecto. Personalmente he visto varias aplicaciones web que
    tienen completamente separada la funcionalidad de la interfaz, y no tienen
    mayor problema (además el código generado es muy limpio, si el programador
    / diseñador respeta la indentación)
    PHP, como cualquier otro lenguaje de programación estructurado, y XML
    comparten el concepto de bloque. En PHP cada bloque se encierra entre
    llaves, en XML entre un tag de inicio y uno de final. Aunque se pueden
    encontrar excepciones, es natural que ambos bloques se aniden de forma
    compatible. Con esto quiero decir que, si uno emite un <p> dentro de un
    condicional if(), es natural que antes de terminar el bloque if() se
    cierre el <p> con un </p>. No hacerlo así implicaría desbalancear los
    bloques y esto no estaría correcto (es cierto que un navegador puede
    ignorarlo y presentarlo bien, pero no es el caso). Esto quiere decir que
    el bloque <p> queda totalmente anidado dentro del bloque if(). [···]
    Asi es como se me ocurrió el agregado de dos instrucciones nuevas para
    PHP, TAG y ATT, que se abreviarían con los símbolos < y @. Agregar
    instrucciones a un lenguaje no es cosa fácil, implicaría un 'fork', una
    práctica que no es bueno alentar. Por ello se me ocurrió que podría
    hacerse mediante un precompilador, tal como inicialmente el C++ era un
    precompilador que generaba código fuente en C.
    Creo que sería mejor utilizar caracteres inexistentes (y tal vez mejor
    aún, caracteres inválidos) en PHP, aunque esto reduce el conjunto de
    caracteres disponibles. Los que mencionas tienen significado en PHP, y
    aunque tal vez pudieras ingeniártelas para distinguir los casos de alguna
    forma, creo que te facilitarías la vida desechando estos casos desde el
    inicio.
    Estas instrucciones se podrían usar de la siguiente forma, por ejemplo,
    un párrafo de texto alineado sobre derecha se podría codificar así:

    <p {
    @align 'right';
    echo 'Este es el texto alineado sobre derecha';
    } [···]
    En definitiva, el ejemplo de código precedente habrá generado lo
    siguiente:

    echo '<p', ' align="right"', '>', 'Este es el texto alineado sobre
    derecha', '</p>';

    En este código he omitido, por claridad, la simple optimización de ir
    concatenando los literales para hacer una única cadena.
    Lo óptimo sería justamente como lo tienes actualmente, usando la
    instrucción "echo", separando los "parámetros" con comas, y utilizando
    comillas simples. Me parece recordar un artículo de este tema en Zend.

    [···]
    Cuál es la razón de todo esto? [···]
    Yo he llegado a programar en assembler y en montones de lenguajes que ya
    casi no existen. Recuerdo cuando los lenguajes estructurados comenzaron
    a aparecer. Alguien aún se acuerda de la instrucción Goto? Bueno, el
    goto permitía saltar de un punto cualquiera de un programa a cualquier
    otro lugar. Nada de estructura, nada de bloques, todo se podía. A este
    se le llamaba 'código spaghetti' pues era todo enredado, imposible de
    seguir. El código estructurado impedía esta libertad y nos costó
    bastante trabajo darnos cuenta que eran más las ventajas que las
    limitaciones. El código era más simple, mejor estructurado, más fácil de
    entender y todo ello llevaba a que tuviera menos errores.

    Actualmente, de la forma que generamos XML lo que estamos haciendo es muy
    parecido al 'código spaghetti' que eran nuestros programas. Como en
    definitiva no hacemos más que concatenar cadenas de texto arbitrarias,
    podemos generar lo que querramos sea para bien o mal. Los estructura
    impuesta por los lenguajes estructurados mejoró la calidad del código.
    Me gustaría ver esa misma mejora de calidad a nivel del XML que
    generamos. [···]
    Dado que yo también uso templates y funciones para mis aplicaciones, debo
    admitir que he debido buscar un poco entre mis fuentes para encontrar
    alguno en que realmente hubiera generado HTML directamente, pero aquí les
    pongo un ejemplo más completo de lo que propongo. Aprovecho para mostrar
    cómo
    resuelvo el asunto de llenar un combo con valores dependientes de otro.
    En este caso, cargo las provincias en función del pais seleccionado. [···]
    // Noten a partir de aquí cómo la estructura de la tabla se hace tan
    obvia
    como la
    // estructura misma del código en PHP
    <table {
    <tr {
    <th {
    @rowspan 2;
    @valign "top";
    // Aquí he usado otra abreviatura que no he mencionado, el
    signo
    ? en lugar de 'echo'
    ? 'Direcci&oacute;n';
    }
    <td {
    <input {
    @name 'Direccion1';
    @size 50;
    @value $row['Direccion1'];
    }
    }
    } [···]
    // Este combo es el que selecciona pais y en función del pais
    seleccionado
    // recarga el combo de provincias con las que le correspondan.
    // Noten en la función MuestraCombo un cuarto argumento que no se
    usó en la llamada anterior
    // este cuarto argumento es un array de la forma evento => acción
    <td MuestraCombo('IdPais'
    , CargaCombo('Select IdPais,Descr from Paises order by
    Descr')
    , $IdPais
    , array('onChange' =>
    "document.getElementById('iFrameProvincias').src =
    'Select.php?Name=IdProvincia&Select=1&Valor=' + this.value ")
    );
    }
    }
    Interesante, tengo una función similar a "MuestraCombo()", y ese 4
    parámetro, aunque no lo he necesitado, me parece una muy buena (y lógica)
    idea; es una de ésas ideas que uno dice "¿cómo es que no se me había
    ocurrido?"

    En resumen, creo que es una idea por demás interesante, lo ideal sería
    poder "hackear" el código de PHP para implementar este tipo de
    instrucciones de forma más eficiente y totalmente transparente, pero sería
    demasiado pedir :| Un problema que veo es que no estoy seguro de que el
    código PHP resultante del pre-compilado sea eficiente, amén de la
    legibilidad del mismo.

    Me agradaría mucho de que me informaras si tu idea llegó a buen fin, y
    poder probar el resultado (y si puedo ayudar en algo, avísame --no conozco
    Yacc ni Lex) Personalmente creo que con algo de disciplina al momento de
    "codificar" (i.e: "escribir código") y el uso de plantillas (incluso más
    sencillas que Smarty) se puede obtener un excelente resultado en el código
    'XHTML', aunque, de nuevo, espero poder probar la implementación de esta
    idea tuya :)
    --
    Atentamente,

    J. Rafael Salazar Magaña
    Innox - Innovación Inteligente
    +52 (33) 3615 5348 ext. 205
    rsalazar@innox.com.mx
    http://www.innox.com.mx
  • Rafael Salazar at Apr 5, 2005 at 5:40 pm
    Ehm... sólo para aclarar.

    Satyam wrote:
    Use XML como la expresion más generica para toda esa familia de 'MLs'
    (markup languages), en definitiva, XHTML es un XML que responde a ese
    'schema' particular de XML.
    Lo mencioné porque también aplicaría para HTML, que no es XML (en todo
    caso sería una versión de XHTML, pues estaría "bien formado", pero
    seguiría "identificándose" como HTML), como sea no es importante.
    El uso de caracteres < y @ en lugar de palabras claves (tag y att) se debe a
    que, en primer lugar es más breve y en segundo porque nunca crearía
    conflicto con código existente pues, dado que las palabras tag y att no
    están dentro de la lista de palabras reservadas de PHP, bien puede que
    existan aplicaciones que las estén usando.
    Creo que no fui del todo claro, lo que recomendaba (y es sólo eso), era
    utilizar _caracteres_ no usados por PHP, e incluso creo que sería mejor
    utilizar caracteres que PHP considere inválidos; incluso añadía que no
    iban a ser muchas las opciones.
    No es problema usar un simbolo repetido en tanto sea posible desambiguar su
    uso, esto es, distinguir cuando se debe interpretar de una forma y cuando de
    otra. Tal es el caso del ; en PHP que, dentro de un for() no implica el fin
    de la instrucción. O el caso del = en Basic que puede significar asignación
    o comparación por igual, y el significado queda claro por el contexto.
    De acuerdo, como dije anteriormente, sólo era una recomendación.

    [···]
    En este caso, el signo < es fácil desambiguarlo cuando se usaría como TAG y
    cuando como comparación, no así el simbolo @, ese se me escapó hasta que
    Jordi me lo hizo notar, y la verdad es que no hay otro caracter que me sea
    tan satisfactorio como el @.
    Por algo "@" es el símbolo para atributo por excelencia, me pregunto si
    será originado por el XSLT...

    [···]
    Puede sino que lo que te
    haya venido a la mente es que es mejor esto:

    $texto = 'esta es una prueba';
    echo '<p>',$texto,'</p>';

    que esto:

    $texto = 'esta es una prueba';
    echo '<p>'.$texto.'</p>';
    Tienes razón, no me fijé que eran literales y no variables, tal vez me
    confundí con algún otro fragmento de código.
    Finalmente, gracias por el comentario sobre MuestraCombo y el 4to parámetro
    y por tus comentarios.
    No te olvides de hacerme saber si tu idea se materializa, quisiera
    probarlo :)
    --
    Atentamente,

    J. Rafael Salazar Magaña
    Innox - Innovación Inteligente
    +52 (33) 3615 5348 ext. 205
    rsalazar@innox.com.mx
    http://www.innox.com.mx
  • Satyam at Apr 7, 2005 at 2:14 pm
    Disculpa que no te contestara más puntualmente, no me explico cómo lo marqué
    leído cuando en realidad no lo había visto.

    En realidad, el preprocesador no sería de generar XML mal formado. A cada
    tag le correspondería un end-tag con exactamente las mismas letras en
    mayúsculas y minúsculas, los valores de los atributos estarían siempre
    encerrados entre comillas, no habría tags desapareados y tags como br o hr
    que no contienen texto serían siempre generados como <br /> y <hr />. O
    sea, en realidad no llegaría a usar la 'tolerancia' que tienen los
    navegadores para aceptar HTML mal formado. Lo único 'mal formado' que
    podría generar, si no se le indicara un Schema contra el cual validad, sería
    el uso de tags en mayúsculas y minúsculas indistintamente. O sea, a cada
    <p> le correspondería un </p>, pero en otro lugar podría haber un juego de
    <P> y </P>. Esto en el caso de que no se indicara un Schema contra que
    validar.


    No te cuestionaba lo que me decías respecto del uso de caracteres,
    simplemente pretendía aclararlo mejor, especialmente sobre la posibilidad de
    reutilizar caracteres existentes, tal como el < pues el parser es una
    máquina de estado y puede discriminar cuando encuentra un < cuando esta en
    estado de esperar una instrucción de cuando encuentra el mismo símbolo
    cuando está resolviendo una expresión. Prefiero, sin embargo, atenerme a
    caracteres del juego US-ASCII pues estos no tienen problema de
    representación sobre distintas plataformas. Por otra parte, las
    herramientas para crear parsers, Yacc y Lex pueden llegar a dar errores con
    caracteres para los cuales no están previstos. Si uso un caracter fuera del
    US-ASCII, y alguien recompilara los fuentes de Yacc y Lex en otra
    plataforma, podría dar resultados imprevistos.

    Es cierto que el @ se usa en XSLT, no se si lo saqué de allí o simplemente
    me surgió por la misma asociación de ideas que a ellos, ATtribute - AT-sign.
    Lamentablemente el parser si espera encontrar un @ cuando espera una
    instrucción, lo cual hace imposible distinguir un uso y otro.

    Creo que me he de resignar a cambiarlo por el símbolo & que, si bien también
    se usa en PHP, el contexto es otro distinto y puede discriminarse un uso y
    otro. La excusa, no demasiado satisfactoria, para elegir este símbolo es
    que es el mismo que se usa para separar los argumentos en un URL, a todas
    luces una excusa bastante pobre.

    Satyam






    "Rafael Salazar" <rsalazar@innox.com.mx> wrote in message
    news:20050405174048.14730.qmail@lists.php.net...
    Ehm... sólo para aclarar.

    Satyam wrote:
    Use XML como la expresion más generica para toda esa familia de 'MLs'
    (markup languages), en definitiva, XHTML es un XML que responde a ese
    'schema' particular de XML.
    Lo mencioné porque también aplicaría para HTML, que no es XML (en todo
    caso sería una versión de XHTML, pues estaría "bien formado", pero
    seguiría "identificándose" como HTML), como sea no es importante.
    El uso de caracteres < y @ en lugar de palabras claves (tag y att) se
    debe a que, en primer lugar es más breve y en segundo porque nunca
    crearía conflicto con código existente pues, dado que las palabras tag y
    att no están dentro de la lista de palabras reservadas de PHP, bien puede
    que existan aplicaciones que las estén usando.
    Creo que no fui del todo claro, lo que recomendaba (y es sólo eso), era
    utilizar _caracteres_ no usados por PHP, e incluso creo que sería mejor
    utilizar caracteres que PHP considere inválidos; incluso añadía que no
    iban a ser muchas las opciones.
    No es problema usar un simbolo repetido en tanto sea posible desambiguar
    su uso, esto es, distinguir cuando se debe interpretar de una forma y
    cuando de otra. Tal es el caso del ; en PHP que, dentro de un for() no
    implica el fin de la instrucción. O el caso del = en Basic que puede
    significar asignación o comparación por igual, y el significado queda
    claro por el contexto.
    De acuerdo, como dije anteriormente, sólo era una recomendación.

    [···]
    En este caso, el signo < es fácil desambiguarlo cuando se usaría como TAG
    y cuando como comparación, no así el simbolo @, ese se me escapó hasta
    que Jordi me lo hizo notar, y la verdad es que no hay otro caracter que
    me sea tan satisfactorio como el @.
    Por algo "@" es el símbolo para atributo por excelencia, me pregunto si
    será originado por el XSLT...

    [···]
    Puede sino que lo que te haya venido a la mente es que es mejor esto:

    $texto = 'esta es una prueba';
    echo '<p>',$texto,'</p>';

    que esto:

    $texto = 'esta es una prueba';
    echo '<p>'.$texto.'</p>';
    Tienes razón, no me fijé que eran literales y no variables, tal vez me
    confundí con algún otro fragmento de código.
    Finalmente, gracias por el comentario sobre MuestraCombo y el 4to
    parámetro y por tus comentarios.
    No te olvides de hacerme saber si tu idea se materializa, quisiera
    probarlo :)
    --
    Atentamente,

    J. Rafael Salazar Magaña
    Innox - Innovación Inteligente
    +52 (33) 3615 5348 ext. 205
    rsalazar@innox.com.mx
    http://www.innox.com.mx

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-general-es @
categoriesphp
postedApr 2, '05 at 2:21p
activeApr 7, '05 at 2:14p
posts8
users3
websitephp.net

People

Translate

site design / logo © 2022 Grokbase