php-general Digest 6 Aug 2006 06:31:46 -0000 Issue 4277
Topics (messages 240188 through 240197):
Re: Sending data to persistent process stdin
240188 by: Ville Mattila
240190 by: Stut
Re: PHP Frameworks - Opinion
240189 by: Manuel Lemos
240193 by: Robert Cummings
Re: The difference between ereg and preg?
240191 by: Dave M G
240194 by: Robert Cummings
Using preg_match to find Japanese text
240192 by: Dave M G
Re: PayPal's PHP SDK on Windows
240195 by: phpwizard02
#comment, (* comment *), -- Any good alternatives to <!-- HTML comments? -->
240196 by: Micky Hulse
240197 by: Micky Hulse
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
php-general@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
Stut kirjoitti:
1) Find out how to create a named pipe and start mpg123 to take its
input from that named pipe. Your PHP scripts can then write commands to
that pipe.
Thanks Stut, rather good idea... I tried following commands:
mkfifo mpg
mpg123 -R < mpg
And in another shell
echo "LOAD mp3file.mp3\n" > mpg
Unfortunately, the mpg123 quits immediately without any response... In
general, the idea sounds good, but there is still something uncompatible.
Ville
--- End Message ---
--- Begin Message ---
Ville Mattila wrote:
> Stut kirjoitti:
>> 1) Find out how to create a named pipe and start mpg123 to take its
>> input from that named pipe. Your PHP scripts can then write commands to
>> that pipe.
>>
>
> Thanks Stut, rather good idea... I tried following commands:
>
> mkfifo mpg
> mpg123 -R < mpg
>
> And in another shell
> echo "LOAD mp3file.mp3\n" > mpg
>
> Unfortunately, the mpg123 quits immediately without any response... In
> general, the idea sounds good, but there is still something uncompatible.
There's really no good reason that shouldn't have worked. I suggest you
find an mpg123 mailing list and ask them why that happened.
-Stut
--- End Message ---
--- Begin Message ---
Hello,
on 08/04/2006 05:47 PM Robert Cummings said the following:
>>>>>> The point of the post is that there is no framework in particular to
>>>>>> recommend. I use my own packages for my needs. They suit me well. It
>>>>>> does not mean they will suit everybody.
>>>>> How would you know that there is no framework to recommend if you neve
>>>>> ruse anyone's code but your own. How could you have possibly given any
>>>>> framework sufficient attention to have any idea of its pros and cons?
>>>> I know many frameworks that exist, I have seen their code and their
>>>> documentation, which is more than enough to reach the conclusion that
>>>> using the frameworks that exist is not better that using my own
>>>> solutions for my own purposes.
>>> Aaaah, so you are trully a genius to be able to at a glance of
>>> documentation and source code fully deduce the usefulness of something.
>>> I bow before you.
>> Be seriuos. Nobody needs to actually use any framework to see that it is
>> not suitable for your needs, when you can just browse the source code
>> and documentation. It would be insane to try all PHP frameworks that
>> exist to reach that conclusion.
>
> And there's the rub... your article was not about what YOU needed it was
> what YOU considered to be the best framework for everyone based on
> briefly browsing the code. Your article, if it had any real merit, would
> have reported on the actual trial of a substantial number of frameworks
> so that you could provide a valuable analysis instead of superficial
> opinion. Remember a recommendation, is not about YOU, it's about those
> reading the article. I can agree with your previous statement until you
> start recommending it in general.
My article is mine. It was not written for you but rather to the
PHPClasses site users in first place. Therefore it includes whatever I
think it is best for me to mention. If you do not agree and think it
should be something else, go and write your own article in your own blog
rather than bossing me to do something different, as if I owe you anything.
>>>>> You can't have your cake and eat it too. You're either pro-choice with a
>>>>> myriad of choices to choose from, or you're anti-choice and want only
>>>>> one framework style. Get of the fence!
>>>> Having standard API specifications does not prevent anybody to choose
>>>> using solutions based on APIs that do not conform to any standard
>>>> specifications.
>>>>
>>>> Furthermore I do not think that seem to understand the difference
>>>> between an API specification and API implementation. J2EE is an API
>>>> specification with many implementations from different vendors: Sun,
>>>> IBM, Oracle, BEA, JBoss (this last one is Open Source). You can choose
>>>> the implementation you want.
>>>>
>>>> There is plenty of choice to anybody. If you want to use a J2EE
>>>> implementation to build your applications, otherwise you are free to use
>>>> something else.
>>>
>>> It's seems people have chosen... and they've chosen not to bother with
>>> some kind of standard API. That's not to say one won't emerge, but it
>>> doesn't seem like it's important at this time.
>> Sure, but you are missing the point about the way Java specifications
>> are built. They gather around interested players in the field of each
>> kind of framework, so it is more consensual that just an unilateral
>> proposal.
>>
>> If version 1.0 of an API is not good enough, they gather again,
>> eventually joining more interested players and build a better
>> specification. For instance, JDBC API specification had at least 3 major
>> versions.
>>
>> There is no need to create a new completely backwards incompatible API
>> specification. Everybody would loose with that.
>>
>> Building a completely new API specification would make sense if it was
>> for very different purposes.
>
> I wasn't missing the point. I am quite aware of how the process works
> behind closed doors with a select few high profile companies and
> committees. I'm also quite aware of the pros of standardization, but I
> don't necessarily feel that hand picking the standard is necessarily
> better than an emergent standard. Either way, as I keep saying, if there
> was a strong enough desire for such standardization then I'm sure people
> would be forming such groups. maybe with the launch of Zend Framework
> there will be a rallying point, but then again, maybe it will just be
> yet another framework.
People cannot have desire for something that they do not know or do not
have a vision about its benefits. Sun had a good vision about defining
API specification standards. It attracted many companies, including
competitors that made Java adoption grow enourmously.
Zend does not seem to have such vision. Zend Framework is an
implementation, not a specification. Without a well defined
specification, nobody can provide alternative implementations even if
they wanted.
I am afraid that Zend Framework is fated to be just yet another PHP
framework struggling against other frameworks for a small piece of
adoption share.
I am sure their project would have much better adoption if they focused
on building a specification resulting from a consense among other strong
players in the PHP development scene, like Sun did with Java framework
API specifications, allowing alternative implementations of the same API.
>>> There's this thing called an adapter pattern. Great for retrofitting
>>> other people's code without actually modifying it.
>> That is what Metabase and PEAR::MDB2 do, database adapting, same API
>> and same behavior for all supported databases.
>>
>> Furthermore, the plug-in sub-classes that support different databases,
>> only override a few base class methods . It would not be hard to adapt
>> them for more API.
>>
>> I just do not have the time nor the interest to build variants for the
>> bazillions of other database abstraction layers.
>>
>> Some do not even support the necessary abstraction features. For
>> instance, AFAIK other database abstraction layers besides Metabase and
>> PEAR::MDB2 do not support pattern escaping.
>>
>> This is necessary to escape wildcards characters that should be taken
>> literally in patterns. It is needed to implement the auto-complete
>> feature using SQL conditions of type field LIKE 'typed-text%'. If
>> typed-text contains % or _, it must be escaped. Some databases like MS
>> SQL need to escape other characters too.
>
> If there was enough need for Metabase to support other layers then I'm
> sure the community would be submitting the code for you. But then again,
> you probably wouldn't accept outside code into your own codebase since
> that would violate your internal dislike for external code *lol*.
> Touché!
Your obcession to diss everything I say is preventing you to see the
things the way they are.
I do not have a problem using other people's code, my problem is relying
on packages that need to be evolved to address my needs but I do not
control of their development. I control Metabase development, therefore
there is no problem in accepting other peoples contributions of patches
or even complete drivers.
As a matter of fact Metabase always had many, many contributions, unlike
you imagined, as you may see in the contributors roll with the
respective credit for the contributed work here:
http://www.meta-language.net/metabase.html#3.1.4
>>>> Everybody looses opportunities with this. If there was a standard API
>>>> database specification for PHP like PDBC similar to JDBC, there would be
>>>> no such problem.
>>> There are two ways for standards to come about. They can be hand picked
>>> or they can emerge. Hand picked requires the "community organization" of
>>> which you speak. Emergent standards requires the popular vote. I'm in
>>> the latter camp, let the developers speak to the merits of any given
>>> standard. And if they don't speak, it's probably not important.
>> Right. The problem is that in the PHP world there are too many
>> incompatible APIs for the same purposes in use by many people. This does
>> not help people like the original poster that wanted specific
>> recommendations. He will have too loose a lot of time and patience,
>> probably to reach the conclusion that he will have to write his own
>> framework.
>
>>From your earlier statement, he could supposedly choose a framework just
> from browsing the source code. At any rate, he probably wasted time
> reading your article that purported to recommend a framework when in
> fact it had nothing of substantial value to say about any particular
> framework.
If you ever paid attention to what I wrote, my recommendation to the
original poster to read the article was about giving recommendations on
how to pick frameworks that suit his needs, rather than recommending any
specific frameworks. I am pasting the relevant quote of my original
reply so you can get a grip for once.
> Anyway, you may want to read this more in depth reflection of the state
> of the PHP framework world and recommendations on how to pick what suits
> best for you:
>
> http://www.phpclasses.org/blog/post/52-Recommended-PHP-frameworks.html
--
Regards,
Manuel Lemos
Metastorage - Data object relational mapping layer generator
http://www.metastorage.net/
PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/
--- End Message ---
--- Begin Message ---
On Sat, 2006-08-05 at 15:36 -0300, Manuel Lemos wrote:
> Hello,
>
> on 08/04/2006 05:47 PM Robert Cummings said the following:
> >>>>>> The point of the post is that there is no framework in particular to
> >>>>>> recommend. I use my own packages for my needs. They suit me well. It
> >>>>>> does not mean they will suit everybody.
> >>>>> How would you know that there is no framework to recommend if you neve
> >>>>> ruse anyone's code but your own. How could you have possibly given any
> >>>>> framework sufficient attention to have any idea of its pros and cons?
> >>>> I know many frameworks that exist, I have seen their code and their
> >>>> documentation, which is more than enough to reach the conclusion that
> >>>> using the frameworks that exist is not better that using my own
> >>>> solutions for my own purposes.
> >>> Aaaah, so you are trully a genius to be able to at a glance of
> >>> documentation and source code fully deduce the usefulness of something.
> >>> I bow before you.
> >> Be seriuos. Nobody needs to actually use any framework to see that it is
> >> not suitable for your needs, when you can just browse the source code
> >> and documentation. It would be insane to try all PHP frameworks that
> >> exist to reach that conclusion.
> >
> > And there's the rub... your article was not about what YOU needed it was
> > what YOU considered to be the best framework for everyone based on
> > briefly browsing the code. Your article, if it had any real merit, would
> > have reported on the actual trial of a substantial number of frameworks
> > so that you could provide a valuable analysis instead of superficial
> > opinion. Remember a recommendation, is not about YOU, it's about those
> > reading the article. I can agree with your previous statement until you
> > start recommending it in general.
>
> My article is mine. It was not written for you but rather to the
> PHPClasses site users in first place. Therefore it includes whatever I
> think it is best for me to mention. If you do not agree and think it
> should be something else, go and write your own article in your own blog
> rather than bossing me to do something different, as if I owe you anything.
I've been registered with the PHPClasses site for a couple of years at
least now. I get the regular emails and I've never taken issue in the
past. But this particular one was waaaaay out there.
> >>>>> You can't have your cake and eat it too. You're either pro-choice with a
> >>>>> myriad of choices to choose from, or you're anti-choice and want only
> >>>>> one framework style. Get of the fence!
> >>>> Having standard API specifications does not prevent anybody to choose
> >>>> using solutions based on APIs that do not conform to any standard
> >>>> specifications.
> >>>>
> >>>> Furthermore I do not think that seem to understand the difference
> >>>> between an API specification and API implementation. J2EE is an API
> >>>> specification with many implementations from different vendors: Sun,
> >>>> IBM, Oracle, BEA, JBoss (this last one is Open Source). You can choose
> >>>> the implementation you want.
> >>>>
> >>>> There is plenty of choice to anybody. If you want to use a J2EE
> >>>> implementation to build your applications, otherwise you are free to use
> >>>> something else.
> >>>
> >>> It's seems people have chosen... and they've chosen not to bother with
> >>> some kind of standard API. That's not to say one won't emerge, but it
> >>> doesn't seem like it's important at this time.
> >> Sure, but you are missing the point about the way Java specifications
> >> are built. They gather around interested players in the field of each
> >> kind of framework, so it is more consensual that just an unilateral
> >> proposal.
> >>
> >> If version 1.0 of an API is not good enough, they gather again,
> >> eventually joining more interested players and build a better
> >> specification. For instance, JDBC API specification had at least 3 major
> >> versions.
> >>
> >> There is no need to create a new completely backwards incompatible API
> >> specification. Everybody would loose with that.
> >>
> >> Building a completely new API specification would make sense if it was
> >> for very different purposes.
> >
> > I wasn't missing the point. I am quite aware of how the process works
> > behind closed doors with a select few high profile companies and
> > committees. I'm also quite aware of the pros of standardization, but I
> > don't necessarily feel that hand picking the standard is necessarily
> > better than an emergent standard. Either way, as I keep saying, if there
> > was a strong enough desire for such standardization then I'm sure people
> > would be forming such groups. maybe with the launch of Zend Framework
> > there will be a rallying point, but then again, maybe it will just be
> > yet another framework.
>
> People cannot have desire for something that they do not know or do not
> have a vision about its benefits. Sun had a good vision about defining
> API specification standards. It attracted many companies, including
> competitors that made Java adoption grow enourmously.
>
> Zend does not seem to have such vision. Zend Framework is an
> implementation, not a specification. Without a well defined
> specification, nobody can provide alternative implementations even if
> they wanted.
>
> I am afraid that Zend Framework is fated to be just yet another PHP
> framework struggling against other frameworks for a small piece of
> adoption share.
>
> I am sure their project would have much better adoption if they focused
> on building a specification resulting from a consense among other strong
> players in the PHP development scene, like Sun did with Java framework
> API specifications, allowing alternative implementations of the same API.
>
>
>
> >>> There's this thing called an adapter pattern. Great for retrofitting
> >>> other people's code without actually modifying it.
> >> That is what Metabase and PEAR::MDB2 do, database adapting, same API
> >> and same behavior for all supported databases.
> >>
> >> Furthermore, the plug-in sub-classes that support different databases,
> >> only override a few base class methods . It would not be hard to adapt
> >> them for more API.
> >>
> >> I just do not have the time nor the interest to build variants for the
> >> bazillions of other database abstraction layers.
> >>
> >> Some do not even support the necessary abstraction features. For
> >> instance, AFAIK other database abstraction layers besides Metabase and
> >> PEAR::MDB2 do not support pattern escaping.
> >>
> >> This is necessary to escape wildcards characters that should be taken
> >> literally in patterns. It is needed to implement the auto-complete
> >> feature using SQL conditions of type field LIKE 'typed-text%'. If
> >> typed-text contains % or _, it must be escaped. Some databases like MS
> >> SQL need to escape other characters too.
> >
> > If there was enough need for Metabase to support other layers then I'm
> > sure the community would be submitting the code for you. But then again,
> > you probably wouldn't accept outside code into your own codebase since
> > that would violate your internal dislike for external code *lol*.
> > Touché!
>
> Your obcession to diss everything I say is preventing you to see the
> things the way they are.
You're deluding yourself as to your importance. I really don't have an
obsession with you. Having had very little interaction with you in the
past leaves me with a generally agnostic opinion. Furthermore I'm npt
having any trouble whatsoever seeing the way things are. Perhaps you are
the one having clarity trouble.
> I do not have a problem using other people's code, my problem is relying
> on packages that need to be evolved to address my needs but I do not
> control of their development. I control Metabase development, therefore
> there is no problem in accepting other peoples contributions of patches
> or even complete drivers.
>
> As a matter of fact Metabase always had many, many contributions, unlike
> you imagined, as you may see in the contributors roll with the
> respective credit for the contributed work here:
>
> http://www.meta-language.net/metabase.html#3.1.4
That's nice. So what are you complaining about?
> >>>> Everybody looses opportunities with this. If there was a standard API
> >>>> database specification for PHP like PDBC similar to JDBC, there would be
> >>>> no such problem.
> >>> There are two ways for standards to come about. They can be hand picked
> >>> or they can emerge. Hand picked requires the "community organization" of
> >>> which you speak. Emergent standards requires the popular vote. I'm in
> >>> the latter camp, let the developers speak to the merits of any given
> >>> standard. And if they don't speak, it's probably not important.
> >> Right. The problem is that in the PHP world there are too many
> >> incompatible APIs for the same purposes in use by many people. This does
> >> not help people like the original poster that wanted specific
> >> recommendations. He will have too loose a lot of time and patience,
> >> probably to reach the conclusion that he will have to write his own
> >> framework.
> >
> >>From your earlier statement, he could supposedly choose a framework just
> > from browsing the source code. At any rate, he probably wasted time
> > reading your article that purported to recommend a framework when in
> > fact it had nothing of substantial value to say about any particular
> > framework.
>
> If you ever paid attention to what I wrote, my recommendation to the
> original poster to read the article was about giving recommendations on
> how to pick frameworks that suit his needs, rather than recommending any
> specific frameworks. I am pasting the relevant quote of my original
> reply so you can get a grip for once.
>
>
> > Anyway, you may want to read this more in depth reflection of the state
> > of the PHP framework world and recommendations on how to pick what suits
> > best for you:
> >
> > http://www.phpclasses.org/blog/post/52-Recommended-PHP-frameworks.html
Oh I paid perfect attention. If you read what I originally wrote you'll
see that I was commenting on the article itself that you suggested since
I and many others find great fault with it. For your benefit I've pasted
below my original comment:
--------
I've read it before... it was crud. You provide no recommendation for
any framework but instead try to pimp phpclasses. From what I gathered
you haven't even actually tried anywhere in the vicinity of 10% of the
frameworks in existence and yet you feel obliged to write a commenatary
called "Recommended PHP Frameworks" in which you don't even recommend a
framework. Additionally somehow while pimping phpclasses you also feel
it necessary to indicate how you don't use any code other than what you
write yourself. Egads, if you won't use the code on your site why the
hell should anyone else?"
--------
At any rate, this thread grows long and booooooooooooooring. I'm signing
off from it permanently (unless there some other interesting post not
including your self-indulgent feelings of persecution).
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
--- End Message ---
--- Begin Message ---
Robert,
Thank you for replying.
Check out the greediness modifier. Greediness determines whether it
extends the matching to the largest possible match or the smallest
possible match. By default regexes are greedy.
By "greediness modifier", do you mean the preg_set_match, the
preg_set_order, and preg_pattern_order arguments?
The documentation on the PHP site does mention the term "greedy", but to
me it's not very clear about explaining which modifiers are responsible
for which behaviour.
I've experimented with each, and to me it seems like they all behave the
same, so perhaps "greediness" is determined by some other modifier?
--
Dave M G
--- End Message ---
--- Begin Message ---
On Sun, 2006-08-06 at 10:39 +0900, Dave M G wrote:
> Robert,
>
> Thank you for replying.
> >
> > Check out the greediness modifier. Greediness determines whether it
> > extends the matching to the largest possible match or the smallest
> > possible match. By default regexes are greedy.
>
> By "greediness modifier", do you mean the preg_set_match, the
> preg_set_order, and preg_pattern_order arguments?
>
> The documentation on the PHP site does mention the term "greedy", but to
> me it's not very clear about explaining which modifiers are responsible
> for which behaviour.
>
> I've experimented with each, and to me it seems like they all behave the
> same, so perhaps "greediness" is determined by some other modifier?
RTFM ;)
http://ca.php.net/manual/en/reference.pcre.pattern.modifiers.php
Search for greedy or more specifically ungreedy :)
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
--- End Message ---
--- Begin Message ---
PHP list,
While I'm only just learning about regular expressions in another
thread, I still seem to be finding exceptional situations which have me
questioning the extent to which preg expressions can be implemented.
(The following contains UTF-8 encoded Japanese text. Apologies if it
comes out as ASCII gibberish.)
What I have are sentences that look like this:
気温 【きおん】 (n) atmospheric temperature; (P); EP
について (exp) concerning; along; under; per; KD
I want to divide the first line into three variables, $word, $reading,
and $meaning. And I want to divide the second line into two variables,
$word and $meaning.
If I can figure out how to extract the first variable, $word, then I can
figure out the rest. But that first step seems to be a doozy.
The way I see it, I could do it two ways. One is to take out all the
pull out all the characters up to the first occurrence of a space, and
assume that it's Japanese. Not that I'm sure how to write that
expression, but maybe I could.
But it seems like it would be a lot more sophisticated if I could
determine if a word was Japanese by testing it's Unicode value or some
similar method. That way I would be less vulnerable to slight
variabilities in positioning of words in the source material.
Looking at all the multibyte related functions in the PHP manual, it
seems there are options for testing the type of encoding, but not for
the type of language or character set.
http://jp2.php.net/manual/en/ref.mbstring.php
However, I could be wrong about this (and it would be nice if I was).
Searching the web, I came across this guy's script to test if characters
were above the usual ASCII range in Unicode, and could therefore be
assumed to be Japanese:
http://www.randomchaos.com/documents/?source=php_and_unicode
But this seems unwieldy, as I think, if I understand it correctly, I'd
have to test each individual word. I could use it to test if there was
any Japanese at all in a string, but I'm not confident I could use it to
extract words.
So I'm a little stuck. If anyone has any advice to help get me started,
it would be much appreciated.
Thank you for your time and help.
--
Dave M G
--- End Message ---
--- Begin Message ---
You have to edit your php.ini file and make sure the following two lines are
uncommented:
extension=php_curl.dll
extension=php_openssl.dll
Then, restart your Apache server and everything should work fine after that.
-=-=-=-=-=-=-=-=-
Attention Developers! Make up to $1000 per referral with PayPal's
https://www.paypal.com/cgi-bin/webscr?cmd=_web-referrals-mrb-outside
Merchant Referral Bonus
Want to
https://www.paypal.com/cgi-bin/webscr?cmd=_wp-standard-overview-outside
accept credit cards online ? Visit PayPal
https://www.paypal.com/us/cgi-bin/webscr?cmd=_merchant-outside Merchant
Services for
https://www.paypal.com/cgi-bin/webscr?cmd=_wp-pro-overview-outside online
payment processing made easy.
Now offering Payflow
https://www.paypal.com/us/cgi-bin/webscr?cmd=_payflow-gateway-overview-outside
payment gateway solution -
https://www.paypal.com/us/cgi-bin/webscr?cmd=_merchant-outside online credit
card processing with
https://www.paypal.com/cgi-bin/webscr?cmd=_payflow-fraud-overview-outside
fraud protection ,
https://www.paypal.com/cgi-bin/webscr?cmd=_payflow-recurring-billing-overview-outside
recurring billing , and other
https://www.stage2qa144.paypal.com/cgi-bin/webscr?cmd=_profile-comparison
payment services to work with your http://solutions.paypal.com/procarts/
shopping cart and
https://www.paypal.com/cgi-bin/webscr?cmd=_payflow-about-ima-outside
internet merchant account .
Developer Resources: https://www.paypal.com/integration PayPal Integration
Center , https://www.paypal.com/developer PayPal Developer Network ,
http://www.pdncommunity.com/pdn/blog?blog.id=devblog PayPal Developer Blog
--
View this message in context:
http://www.nabble.com/PayPal%27s-PHP-SDK-on-Windows-tf2054950.html#a5669860
Sent from the PHP - General forum at Nabble.com.
--- End Message ---
--- Begin Message ---
Hi,
Hopefully this is not a completely stupid question, but... Any
alternatives to using HTML comments in an XHTML 1.0 Strict docutment?
For example, I could do this:
XHTML
XHTML
XHTML
<?=# Comment goes here.?>
XHTML
XHTML
XHTML
That might work for some situations...
Any other alternatives? I would like to find a way of adding comments to
an XHTML PHP page that is quick and easy.
TIA.
Cheers,
Micky
--- End Message ---
--- Begin Message ---
Micky Hulse wrote:
Any other alternatives? I would like to find a way of adding comments to
an XHTML PHP page that is quick and easy.
Ah, nevermind... I should have never posted this question.
This solved my problem (IE duplicate char bug):
<!--[if !IE]>Put your commentary in here...<![endif]-->
I was trying to think of ways to include comments in my html templates
that did not involve actual html comments.
Anyway, after posting, I realized that PHP would not really do the trick...
More info here if anyone interested:
<http://www.positioniseverything.net/explorer/dup-characters.html>
Sorry for spamming list. I have not had much sleep lately.
Cheers,
Micky
--- End Message ---
