php-general Digest 5 Oct 2003 16:35:09 -0000 Issue 2337
Topics (messages 165079 through 165091):
Re: Attempt at putting greedy htmlspecialchars on a diet
165079 by: Gerard Samuel
stripping comments
165080 by: zzz
165081 by: Eugene Lee
165082 by: Marek Kilimajer
165083 by: zzz
php5 and possible oop features/questions
165084 by: Tit \"Black\" Petric
165085 by: Devish
Re: XML Application Objects
165086 by: Terence
165087 by: Terence
165088 by: Terence
OO parent/child relationship
165089 by: Gerard Samuel
165090 by: Curt Zirzow
165091 by: Dan Anderson
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:
[EMAIL PROTECTED]
----------------------------------------------------------------------
--- Begin Message ---
Curt Zirzow wrote:
That is an html entity and is not how it is stored. How that entity
gets displayed depends entirely on what encoding you have set for
the page.
The japanese characters (charset ISO-2022-JP) to use to display the
phrase for 'Contents' is:
^[$B$3$s$F$s$D^[(B
(^[ == escape character)
I can store those exact characters (with the proper escape
character) in a database without a problem
Then I haven't a clue as to why its stored that way, or its just the way
the command line displays the content.
Using postgresql on a database setup for unicode storage, Im getting ->
test=# select topic_title from forum_topics order by topic_time desc
limit 1 offset 4;
topic_title
-------------------------------------------------------------------
testing japanese 社会ニュース
(1 row)
I read your other post, Ill see whats possible with
|get_html_translation_table|
--- End Message ---
--- Begin Message ---
I'm trying to strip comments out of my code. I can get it to strip one
section of comments but the problem comes in when I have more then one
comment section to strip.
I am using this: $code = preg_replace('/\/*(.*?)*\//is', '$1', $code) and
need help fixing my regex.
example:
========
code 1
/* comment 1 */
code 2
/* comment 2 */
code 3
result (bad):
=============
code 1
code 3
result (good):
==============
code 1
code 2
code 3
--- End Message ---
--- Begin Message ---
On Sun, Oct 05, 2003 at 04:46:16AM -0400, zzz wrote:
:
: I'm trying to strip comments out of my code. I can get it to strip one
: section of comments but the problem comes in when I have more then one
: comment section to strip.
:
: I am using this: $code = preg_replace('/\/*(.*?)*\//is', '$1', $code) and
: need help fixing my regex.
:
: example:
: ========
: code 1
: /* comment 1 */
: code 2
: /* comment 2 */
: code 3
:
: result (bad):
: =============
: code 1
: code 3
:
: result (good):
: ==============
: code 1
: code 2
: code 3
How about this:
$code = preg_replace('|/\*.*\*/|msU', '', $code);
--- End Message ---
--- Begin Message ---
You will run into more problems and there are many things you need to
consider, for example "/*" in a string. But token_get_all() will parse
php code for you and will make things much simpler.
zzz wrote:
I'm trying to strip comments out of my code. I can get it to strip one
section of comments but the problem comes in when I have more then one
comment section to strip.
I am using this: $code = preg_replace('/\/*(.*?)*\//is', '$1', $code) and
need help fixing my regex.
example:
========
code 1
/* comment 1 */
code 2
/* comment 2 */
code 3
result (bad):
=============
code 1
code 3
result (good):
==============
code 1
code 2
code 3
--- End Message ---
--- Begin Message ---
Hey perfect Eugene, thanks
-----Original Message-----
From: Eugene Lee [mailto:[EMAIL PROTECTED]
Sent: October 5, 2003 5:14 AM
To: [EMAIL PROTECTED]
Subject: Re: [PHP] stripping comments
On Sun, Oct 05, 2003 at 04:46:16AM -0400, zzz wrote:
:
: I'm trying to strip comments out of my code. I can get it to strip one
: section of comments but the problem comes in when I have more then one
: comment section to strip.
:
: I am using this: $code = preg_replace('/\/*(.*?)*\//is', '$1', $code) and
: need help fixing my regex.
:
: example:
: ========
: code 1
: /* comment 1 */
: code 2
: /* comment 2 */
: code 3
:
: result (bad):
: =============
: code 1
: code 3
:
: result (good):
: ==============
: code 1
: code 2
: code 3
How about this:
$code = preg_replace('|/\*.*\*/|msU', '', $code);
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
will something in the likes of this be possible in php5?
/***/
class some_classname
{
function some_function();
}
function some_classname::some_function($prefix, $text) {
return $prefix.": ".$text."\n";
}
$test = new some_classname;
$test->some_function("Output","Hello World!");
/***/
how about object/class aggregation from php4 (it was experimental and i
imagine it still has a few bugs left, but it was a really usefull
feature)..?
i know the following is possible:
class class_name implements class1, class2, class3 extends parent_class {
...
}
but, can you do something more dynamic, so you can tell which classes to
implement at runtime? class class_name implemenets $vars extends
parent_class ?
--- End Message ---
--- Begin Message ---
if you want to use variable's in a function you need to give
the function the paramaters..if you do not with to use it like that..
declare the vars in the beginning of the class
class classname
{
var $1;
var $2;
}
greetz
--
----------------------------------------------
It's Not God That Created Us, It's Us That Created God!
"Tit "Black" Petric" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> will something in the likes of this be possible in php5?
>
> /***/
>
> class some_classname
> {
> function some_function();
> }
>
> function some_classname::some_function($prefix, $text) {
> return $prefix.": ".$text."\n";
> }
>
> $test = new some_classname;
> $test->some_function("Output","Hello World!");
>
> /***/
>
> how about object/class aggregation from php4 (it was experimental and i
> imagine it still has a few bugs left, but it was a really usefull
> feature)..?
>
> i know the following is possible:
>
> class class_name implements class1, class2, class3 extends parent_class {
> ...
> }
>
> but, can you do something more dynamic, so you can tell which classes to
> implement at runtime? class class_name implemenets $vars extends
> parent_class ?
--- End Message ---
--- Begin Message ---
Robert Cummings wrote:
On Sat, 2003-10-04 at 08:18, Terence wrote:
Bloody hell Rob, you've started me on another rant when I could be in bed ;)
*grin* glad to help out.
XSLT is a pain in the butt if you want to master it - particularly if
you're going from imperative programming to declarative (maybe XPath is
functional, but declaring templates is definately declarative) as many
My understanding, which could very well be incorrect, is that
declarative and functional are synonymous and imperative and procedural
are synonymous. Most of the literature I've read describes XSL as a
functional language, and while XSL is not necessarily XSLT, it is most
definitely a part.
From what I understand, procedural is a subset of imperative and
functional is different from declarative but I may be wrong too. It's
been a long time since I've read up on my theory. Let's just say that
XSLT is very different to what us PHP dudes are normally used to ;)
PHP developers would be. It took me a good twelve months to "get it"
(eg. use XPath filters and not <xsl:if/>). That didn't stop me from
churning out some production applications using XSLT. You can learn the
basics without mastering it and still find it plenty useful. I would
argue that my XSLT skills still leave a lot to be desired, but mastery
of it is still worthwhile persuing. Quite simply, XSLT has a lot of depth.
I also develop in Java and C# where I can re-use all my "template"
knowledge since this knowledge is based on a standard. I plan on having
a play with building web apps in C++ and Python if I get the chance (by
porting the XAO concept). For the time being, it happens that I am more
skilled with PHP so I will develop the XAO architecture and concept in PHP.
It's pointless splitting hairs over the capabilities/advantages of one
templating language over another. If the idea of cross-technology
compatability doesn't appeal to you enough to put the effort in to
master XSLT, then don't master it. Everyone has their own style. XAO is
for object oriented developers of XML-centric applications. I imagine it
won't be everyone's cup of tea even for such a group.
Its the same reason I never bothered to master LISP. It isn't my cup of
tea, generally it isn't most people's cup of tea :) But in all honesty
when a project insists I use XSL(T) then I do.
<<warning: very personal opinion to follow...>>
If you *do* finally decide to master XSLT, you have to conclude that
*any* other templating system is a complete/utter waste of time. (all
While this is a "very personal opinion" you state for others that "you
have to conclude that ..." which changes the opinion from personal to a
foredrawn conclusion of ubiquity.
exactly, and if I wasn't being so opinionated, I would not have the
luxury of being so foredrawn about things. I'd have to take a more
scientific and hence concervative view with adequate disclaimers
declarations about the possibilities and dangers of being incorrect -
like we both did about definitions of functional/declarative and
imperative/procedural (pardon my bad grammar). Although I strongly
suspect you're right since I don't always spend enough time on the theory.
I realise I made a mistake about assuming what "XSLT masters" will have
to conclude being that I am no XSLT master myself. It was ambitious
presumption based on the current trend of my experience with XSLT. And
besides, it was a convenient foregone conclusion for my argument ;)
I thought I had granted myself a licence for this when I prefixed my
opinionation disclaimer.
authors of ``yet another PHP templating system'', please try not to be
offended). I'm not talking about features/functionality either (for
which XSLT is more than adequate), I'm talking about sheer
bothersomeness. ie. I'm fundamentally lazy and I couldn't be bothered
learning "snazzy g.o.a.t. [proprietary] templaty goodness system" --
"crappy" or otherwise -- I don't care how fantastic it is. The reason
why the PHP template has been re-invented so many times, is becuase
there is something missing - IMHO, XSLT fits that gap more than "good
enough". And since it is a standard, it will only get better -- it has a
future. And that, my friends, it good enough for me (being that I am
lazy and all).
This doesn't really affect me personally. My templating system is open
source, I made it and released it without the intent of making money.
While it has a business license it is only because if someone *is* going
to profit from it, then consideration should trickle back to the
developer. Without being argumentative, but rather to be descriptive,
the reason I made my own templating system was because it satisfied my
needs long ago (at which time I already had been exposed to XSLT) and by
creating hooks to custom tags in PHP itself it lent itself to re-use
much of the code I had already developed in PHP for one reason or
another. Another reason is that by not crossing technologies too many
times, it becomes much more reachable to the average "Joe" who may not
have a clue about XSL, XSLT, or even the dependencies necessary to have
it running in PHP (PHP didn't always bundle this technology from what I
recall). Thus if Joe already knows PHP, what better way from him to at
least jump into the foray of separating design from business logic with
a minimal amount of effort. It took you 12 months to master XSL, some
people don't have that luxury of time.
Code re-use is good. Ease of use is good. There are a lot of more than
good templating systems out there (apparently around 80 since last count
at that discussion thread).
One of the things about the whole XSLT vs proprietary templating systems
debate is timing. There's no point arguing that people using
non-standard templating systems in the past are somehow clueless. This
[templating pattern] was the original killer app for the web. One of the
coolest things you could do with a handy practical extraction report
language was make a templating system to avoid the mundane regime that
was programming to the CGI. Hence PHP was born and that's why we all
love it so much.
Back on the issue of timing, XSLT is a relatively new commer, but as you
pointed out, it's been with use for an adequate time now to justify
adoption by the masses. It is my opinion, however, that we have moved on
folks. XSLT represents a distinct and worthy evolution of the web
programming paradigm. It is also my optinion that the depth of
complexity in XSLT risks alienating would-be adopters. (Sorry Raditha).
It is a risk - not a forgone conclusion. I, along with people like
Raditha, would like to encourage web developers in general to have a
little faith in standards that are our lot. We can either lament them,
or leverage them. I believe our persuits will be more fruitful if we
embrace them and leverage their position (as authorotative) to make all
our lives easier. I would argue that it is a medium-to-long-term
investment. I'll let people like Raditha argue that it is [also] of
short-term benefit.
As it happens, XAO supports custom tags, but a savvy user will realise
that using custom tags to expand into display logic is just downright
stupid - it missing the point. Still, the facility is there to allow
expansion of business logic. It seems to have CMS potential - I may be
Custom tags are not always used to expand business logic to display
logic. Sometimes they are used to bundle multi tag display logic into
neat little single tag display logic.
which is exactly how I was suggesting the "savvy" user would use this
feature. It is also why I decided to include the feature in XAO (took me
literally 15 mins to add -- including testing... the xpath version needs
more testing).
More often than not, I have found JSP and CF users still mixing in the
HTML and using custom tags for little more than HTML widgets. I know cos
I also used to do it -- and spend plenty of time maintaining other
people's code which also did it.
using it in the future "form controls" feature -- or I may decide it's
crap and ignore it alltoegether :D The savvy user will always process
the business payload with XSLT - hence maintaining pure separation of
display logic.
IMHO the savvy user will do what is best for the task at hand.
indeed. and what people say about the savy user's practices in a
macroscopic and global context isn't neccesarily mututaly exclusive.
> And while
XSLT is powerful, sometimes it's not the man for the job.
I prefer to say that it is sometimes a pain in the butt ;)
But I have a "warts'n'all" approach because the "all" is worth the
warts. And in this case, the "all" includes those things like standards
leveraging -- which is very high on the priority list for a lazy person
like me who only could be bothered with one templating system. It's like
having your cake and eating it too - well, most of it :)
Just like Java
is more powerful than PHP in many respects, it's not the right man for
the job in much of what we do.
too right.
IMO, PHP has the highest usefulness-to-effort/cost ratio (when it's not
bogged down in shitty APIs as is the case with it's XSLT extension).
Anyways I hope this isn't perceived as a flame or anything other than
just a differing of opinions.
not at all. I enjoy the opportunity to expound the virtues of community
standards participation (and av a good "rant").
PS.
Stop teasing us and give us the link to your open-source solution. I may
be able to poach some ideas for my open-source solution :)
--- End Message ---
--- Begin Message ---
Rush wrote:
"Terence" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
<<warning: very personal opinion to follow...>>
If you *do* finally decide to master XSLT, you have to conclude that
*any* other templating system is a complete/utter waste of time. (all
authors of ``yet another PHP templating system'', please try not to be
offended). I'm not talking about features/functionality either (for
which XSLT is more than adequate), I'm talking about sheer
bothersomeness. ie. I'm fundamentally lazy and I couldn't be bothered
learning "snazzy g.o.a.t. [proprietary] templaty goodness system" --
"crappy" or otherwise -- I don't care how fantastic it is. The reason
why the PHP template has been re-invented so many times, is becuase
there is something missing - IMHO, XSLT fits that gap more than "good
enough". And since it is a standard, it will only get better -- it has a
future. And that, my friends, it good enough for me (being that I am
lazy and all).
Well, I completely agree with you that there is no "one size fits all"
solution for templates, and that one should choose what suites him best.
Anyway, in similar "very personal" way, especially since I am naturaly
biased, I will like to point out my reasons why I prefere my php template
system compared to the xml+xslt combination:
a) xslt templates are "fat" or "dirty" ones if you will, meaning they
contain code, effectively nullifying my major reason to use templates:
separation of html from code. Some people prefer "fat" templetes and try to
stuff whole presentation logic in them while only models reside in php, but
prefer "thin" or "clean" templates, where template is basically resource
produced independently by designer, and php runs presentation and model
code. With fat templates, they usualy get to complex to be coded by web
designers, so they have to be poked by programmers, which means that it is
much more difficult to split the job. Also means that programmer has to code
in 2 languages, php, and in some template language, while in thin templates
model he can code in one language domain.
b) working with xml+xslt requires more footwork than with TT.
Well, again, it is just my reasons. Other people may have other needs and
preferences.
well I have to say I can't disagree with any of your reasons.
One of the major dangers of XSLT is how easy it is to end up with a
mess. In it's defence, I will say that it is also possible to program
cleanly with XSLT and avoid the "code" aspects such as flow-control that
you speak of. I'm still learning how to program XSLT cleanly in
real-world situations. It can be done though.
Like PHP, XSLT has a lot of depth. I've maintained (and produced myself)
some pretty horrid code - but that doesn't stop me from chosing PHP as a
weapon in my arsenal.
I guess one of my main gripes about templating systems is that I can't
re-use them between applications. Because there are so many different
ones to chose from, almost every pre-built, open-source, PHP app that I
download uses a different one. For me, this reason is good enough to
pick the "standard" one and encourage others to do the same.
With XSLT, I can develop HTML widgets and "include" them in different
contexts in different applications -- provided those apps support the
standard.
--- End Message ---
--- Begin Message ---
Rush wrote:
"Terence" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
<<warning: very personal opinion to follow...>>
If you *do* finally decide to master XSLT, you have to conclude that
*any* other templating system is a complete/utter waste of time. (all
authors of ``yet another PHP templating system'', please try not to be
offended). I'm not talking about features/functionality either (for
which XSLT is more than adequate), I'm talking about sheer
bothersomeness. ie. I'm fundamentally lazy and I couldn't be bothered
learning "snazzy g.o.a.t. [proprietary] templaty goodness system" --
"crappy" or otherwise -- I don't care how fantastic it is. The reason
why the PHP template has been re-invented so many times, is becuase
there is something missing - IMHO, XSLT fits that gap more than "good
enough". And since it is a standard, it will only get better -- it has a
future. And that, my friends, it good enough for me (being that I am
lazy and all).
Well, I completely agree with you that there is no "one size fits all"
solution for templates, and that one should choose what suites him best.
Anyway, in similar "very personal" way, especially since I am naturaly
biased, I will like to point out my reasons why I prefere my php template
system compared to the xml+xslt combination:
a) xslt templates are "fat" or "dirty" ones if you will, meaning they
contain code, effectively nullifying my major reason to use templates:
separation of html from code. Some people prefer "fat" templetes and try to
stuff whole presentation logic in them while only models reside in php, but
prefer "thin" or "clean" templates, where template is basically resource
produced independently by designer, and php runs presentation and model
code. With fat templates, they usualy get to complex to be coded by web
designers, so they have to be poked by programmers, which means that it is
much more difficult to split the job. Also means that programmer has to code
in 2 languages, php, and in some template language, while in thin templates
model he can code in one language domain.
b) working with xml+xslt requires more footwork than with TT.
Well, again, it is just my reasons. Other people may have other needs and
preferences.
well I have to say I can't disagree with any of your reasons.
One of the major dangers of XSLT is how easy it is to end up with a
mess. In it's defence, I will say that it is also possible to program
cleanly with XSLT and avoid the "code" aspects such as flow-control that
you speak of. I'm still learning how to program XSLT cleanly in
real-world situations. It can be done though.
Like PHP, XSLT has a lot of depth. I've maintained (and produced myself)
some pretty horrid code - but that doesn't stop me from chosing PHP as a
weapon in my arsenal.
I guess one of my main gripes about templating systems is that I can't
re-use them between applications. Because there are so many different
ones to chose from, almost every pre-built, open-source, PHP app that I
download uses a different one. For me, this reason is good enough to
pick the "standard" one and encourage others to do the same.
With XSLT, I can develop HTML widgets and "include" them in different
contexts in different applications -- provided those apps support the
standard.
--- End Message ---
--- Begin Message ---
Im trying to create some dummy code where child classes can talk to each
other.
Im looking to verify some behaviour Im running into.
When a child extends a parent, from that point on, the parent, has no idea,
on what the child is capable of, or what it contains.
Is that a "real" parent??? ;)
With this script Im getting ->
Fatal error: Call to undefined function: execute() in
/files/www/data/misc/mpn2/index.php on line 47*
*------
<?php
$foo = new base;
$foo->displayPage();
class base
{
var $var;
function base()
{
$this->var['db'] = new db;
$this->var['tpl'] = new smarty;
}
function displayPage()
{
return $this->var['tpl']->display();
}
}
// middle man
class mm
{
}
// child class
class db extends mm
{
var $db = 'database';
function execute()
{
return 'execute';
}
}
// child class
class smarty extends mm
{
var $smarty = 'smarty';
function display()
{
// By the time we are here, both smarty and db are children of mm
// Is it normal for mm to not know what the children are capable
of???
var_dump(parent::execute());
return 'display';
}
}
?>
--- End Message ---
--- Begin Message ---
* Thus wrote Gerard Samuel ([EMAIL PROTECTED]):
> Im trying to create some dummy code where child classes can talk to each
> other.
> Im looking to verify some behaviour Im running into.
> When a child extends a parent, from that point on, the parent, has no idea,
> on what the child is capable of, or what it contains.
> Is that a "real" parent??? ;)
Yep. It wouldn't be good if it did either.
Curt
--
List Stats: http://zirzow.dyndns.org/html/mlists/php_general/
"I used to think I was indecisive, but now I'm not so sure."
--- End Message ---
--- Begin Message ---
> Im looking to verify some behaviour Im running into.
> When a child extends a parent, from that point on, the parent, has no idea,
> on what the child is capable of, or what it contains.
> Is that a "real" parent??? ;)
No but if you really wanted to you could create a framework for parents
to talk to (and discipline if need be) their children.
-Dan
--- End Message ---
