Re: XML/HTML specific instructions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Burhan Khalid" <phplist@xxxxxxxxxxxx> wrote in message 
news:424B9D92.9060407@xxxxxxxxxxxxxxx
> Satyam wrote:
>> This is just an idea I'm (quite  unsuccessfully) been working on.
>>
>> It appears to me that PHP sits between a database and a web browser.
>>
>> On the database side, something I would love to have is embedded SQL, as 
>> it exists in some other languages such as C (for example, see: 
>> http://www.csee.umbc.edu/help/oracle8/server.815/a68022/sql.htm)
>>
>> At least, what the minimum I would like is to have the very same variable 
>> types all the way from the database end to the browser end.
>>
>> Anyway, Embedded SQL is to much to ask.  What I was working on, though I 
>> got nowhere due to my lack of experience with Yacc and Lex is to have 
>> HTML or XML directly as part of the language (I will just say XML from 
>> now on, to indicate both HTML and XML) .
>
> http://www.php.net/sqlite
>

You are pointing me to SQl functions.  Embedded SQL is something completely 
different, and I would appreciate your either learning what I am talking 
about before replying or, otherwise, not replying at all.

>> You see, both PHP and XML are block structured.  Nevertheless, when we 
>> program PHP, we only see one set of blocks, those enclosed by curly 
>> braces{}.  Most IDEs even check those for pairing, and we have Code 
>> Beautifiers to indent them properly.  The other set of blocks, those 
>> enclosed by XML tags are invisible to the program, though keeping track 
>> of those blocks is just as important.
>>
>> Moreover, logic indicates that one set of blocks is compatible with the 
>> other.  That is, if you are generating an XML block within an if 
>> (condition) block, the XML block has to be closed, you can't just open it 
>> and leave it open.  When the if() block closes, the XML block has to as 
>> well. Can you point any case when this might not be so?  Don't bother, I 
>> can give you examples myself, but good programming practice can straigten 
>> that code out nicely.
>
> I don't agree with you here at all.  Why should PHP (which is not a XML 
> parsing/validating engine) give two hoots about how you are generating 
> content?
>

Not the point, anyway.

>> So, this is what I thought.  I probably re-invented the wheel and if 
>> anybody can point me to the source, I'll be just as happy.
>>
>> I would like to see a couple of  additions to PHP, which could very well 
>> be implemented as a pre-compiler, in
>> the form of two new instructions, TAG and ATT which could also be 
>> abbreviated to < and @.
>>
>> The following piece of code show how to use them:
>>
>> <p {
>>     @align 'center';
>>     echo 'este es el texto del párrafo';
>> }
>>
>> Which would produce, after precompiled:
>>
>> echo '<p align="center">este es el texto del párrafo</p>';
>
> Here you are building a templating engine into PHP, which IMHO is not a 
> very good idea. Why? Many reasons. You'd have to compensate for other 
> forms of markup, such as XML, XHTML, the different XML "standards" 
> floating out there (like Docbook).  Others might say what about CSS? I can 
> go on and on here.
>

I gave and HTML example just to make it something familiar.  I have been 
saying XML all along and if you trouble yourself with reading any further 
before replying, yoy would see that I do mention means to comply with 
different XML schemas (which you call "standards").  CSS is an unfortunate 
case where a standard so closely related to XML technologies has a syntax so 
way out of anything related.  Should something like CSS be designed today, 
it would use XML.

>> Just in case you wonder, yes, the text is in Spanish and it is alread 
>> optimized in the sense that all the literal string segments that could be 
>> strung together has been put in just one string in just a single call to 
>> echo.
>>
>> So, the TAG or < instruction would be followed by a valid tag name and 
>> then a statement. The statement, as usual, can be replaced by a statement 
>> block, enclosed in curly braces.  I don't see any need for the tag name 
>> to be enclosed in any kind of quotes.   A variable instead of a literal 
>> tag name
>> should also be valid.  Thus:
>>
>> $p = 'p';
>> <$p { etc. }
>>
>> would do the same.  This syntax would prevent functions as a source of 
>> tag names, which would be a very rare case and taking it under 
>> consideration would really make the whole thing too cumbersome.
>>
>> The ATT (attribute) or @ instruction is to be followed by a valid 
>> attribute name and an expression providing the value. The attribute name 
>> can be the value of a variable, so that
>>
>> $attribute = 'align';
>> @$attribute 'center';
>>
>> Once again functions cannot be used.
>>
>> Why all these?
>>
>> Basically, I don't want to keep track manually of how my XML blocks are 
>> build.
>
> This is not the job of the programming language either.  PHP is not a XML 
> validating/generating engine.  Its your job (as the developer) to make 
> sure what your program creates is valid.
>
>> Even a Code Beautifier would be able to handle the proper nesting of XML 
>> (with these instructions) along PHP.  The code would simply look good, 
>> and that means it would be easy to get it right.  Actually, while 
>> re-writing the example code below, the brace matching in my IDE caught a 
>> missing curly brace in one <input instruction.
>
> There are already technologies that beautify XML (namely xsl); and 
> programs that will do this for you. Again, this should not be in the core 
> of PHP since part of the attraction and popularity of PHP is that its 
> extremely flexible.

Yes, once generated, but the thing is that to first beautify generated XML 
you have to first generate it.  I am talking about haveing it checked, 
beautified and validated right in the source code, not after being run, 
which is, somehow, delaying the checking to the debugging step, with the 
further problem of trying out all the possible runtime alternatives.

>
>> I would also add a declarative statement to handle XML validation.  The 
>> declaration would have a reference to a DTD or Schema that describes the 
>> XML to be generated.  Optionally, the declaration would also give an 
>> xpath string which would indicate what part of the schema is being 
>> validated. This would allow the declaration to be used in functions or 
>> classes where only fragments of the full schema are being generated.
>>
>> And, by the by, I wouldn't mind the precompiler to take ? as a synonym 
>> for echo.
>
> If you enable short open tags,
>
> <?= "hello" ?> == <?php echo "hello" ?>
>

This is not what I meant.

>> Please notice that I am not trying to solve any specific programming 
>> problem, and yes, I could use templates (actually I do) and I could do a 
>> library of functions to echo XML without my actually having to assemble 
>> the XML strings.  It doesn't matter how many layers you put in between 
>> your application and your XML strings, in the end, at some point, you 
>> have to echo some XML.  It is not a problem I am trying to solve, it is a 
>> feature I would like to see.
>>
>>
>> Just an example of a more substantial piece of code:
>>
>> <table {
>>     <tr {
>>         <th {
>>             @rowspan 2;
>>             @valign "top";
>>             // Here I am using the ? instead of echo
>>             ? 'Direcci&oacute;n';
>>         }
>>         <td {
>>             <input {
>>                 @name 'Direccion1';
>>                 @size 50;
>>                 @value  $row['Direccion1'];
>>             }
>>         }
>>     }
>>     // notice the use of curly braces is just as optional
>>     // as anywhere else in PGP
>>     // This might be not propper coding practice, but it's up to the 
>> coder.
>>     <tr <td <input {
>>         @name 'Direccion2';
>>         @size 50;
>>         @value $row['Direccion2'];
>>     }
>>     <tr {
>>         // Same thing here.  There is no need to put curly braces in the 
>> TH
>> and TD tags
>>         // but it is in the previous TR and the following INPUT
>>         <th 'Código Postal';
>>         <td <input {
>>             @name 'CodPos';
>>             @value $row['CodPos'];
>>         }
>>     }
>> }
>>
>> So, this is what I had in mind and, though I tried to get somewhere with 
>> Bison and Flex, the results have not been good, it is way over my 
>> abilities. Thus, I though that someone is sure to know way more than I do 
>> and might be interested.
>
> Don't get me wrong here, I think its a great idea -- but not one that 
> should be a part of the PHP core.  In my opinion, it should be an 
> additional library that can be added by those that are creating 
> xml-specific PHP applications.  Perhaps a class in PEAR?

No way to do it that way.  I am talking about the structure of the language 
itself.  When , for example, a closing curly brace means popping out of the 
stack the INPUT tag pushed several nesting levels above, checking whether 
the openning tag has been close (which in an INPUT tag should not have 
bneen) and, in this case echoing a "/>" or, had it been a P tag, with 
contents, a "</p>".  Those are things that a compiler or pre-compiler can 
figure out, no functions can since, basically, a closing curly brace cannot 
be a function call, right?

Satyam


>
> My $0.02
> Burhan 


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux