php-general Digest 8 May 2005 01:23:58 -0000 Issue 3441

Topics (messages 214671 through 214679):

Re: Reducing size of htm output
        214671 by: Mark Charette
        214673 by: Rory Browne
        214674 by: Rory Browne
        214678 by: M. Sokolewicz

Re: Random but ordered..
        214672 by: Marek Kilimajer

Re: compiling dynamic extensions without root access
        214675 by: Dan Rossi

POST long texts to PHP
        214676 by: SED
        214677 by: Marek Kilimajer

Fastest templating mechanism
        214679 by: Evert | Rooftop Solutions

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 ---
M. Sokolewicz wrote:

> Rory Browne wrote:
>
>> What might be more useful is stripping out comments, If you don't use
>> javascript it is simply a case of replacing all <!-- anything --> with
>> a blank space. If you do though it's more complicated since it is
>> considered good practice to place js inside <!-- .. //--> blocks,
>
>
> excuse me? since when is this considered /good/ practice???
> It's one of those things that are concidered /bad/ practice according to w3...



Interesting. On a page titled "W3C Recommendations" I must be misinterpreting the W3C's examples of hiding scripts from browsers ...


http://www.w3.org/TR/REC-html40/interact/scripts.html#h-18.3.2
--- End Message ---
--- Begin Message ---
> excuse me? since when is this considered /good/ practice???
> It's one of those things that are concidered /bad/ practice according to
>  w3...
Hmmm, didn't know the w3c had an opinion on the usage of <!-- //-->
tags to delimit javascript. I've always been recommended to use them,
to hide the script from browsers that don't support javascript, just
like I use <noscript>, or <noframes> to show messages to browsers that
don't support script or frames.

Can you reference the message/memo/whatever from the w3c that
discourages them. I believe perhaps you took either it or my
suggestion out of context, because I can't fathom a reason why you
wouldn't want to hide js from non-js-capable browsers.


>  and
> > you have the additional talk of replacing out // and /* .. */
> > comments.
> >
> > but if you really want to do it then:
> >
> > function ob_whitespace_removal($str){
> > // would need to dbl_check regex/modifiers
> > return ob_gzhandler(preg_replace("/\s+/m", "  ", $str));
> > }
> >
> > should work, Although for purists/modularity output buffer stacking
> > may be a cleaner technique
> >
> > Re: Internet Explorer Problems:
> > if you check the ob_start or ob_gzhandler pages on the php
> > manual(online version) then you'll find a user-submitted comment
> > saying that MSIE doesn't cache compressed stuff. This doesn't matter
> > for a dynamic website. Try googling, but don't say ob_gzhandler, since
> > this is (allegedly) a problem with IE/gzip compatability, and not the
> > ob_gzhandler implemention(ie search for gzip and not ob_gzhandler).
> >
> >
> > On 5/7/05, Kirsten <[EMAIL PROTECTED]> wrote:
> >
> >>>preg_replace('/s+/', ' ', $html);
> >>>
> >>>but watch out, this js code will work:
> >>>
> >>>var v
> >>>alert(v)
> >>>
> >>>this one will not:
> >>>
> >>>var v alert(v)
> >>
> >>Sure....
> >>but now: how do I access the htm output of the current executing script
> >>before it is send to the user?
> >>
> >>Thanks again
> >>
> >>
> >>>>1) Is there any function to do this (I'm using PHP 4.2) ? Or maybe some
> >>
> >>user
> >>
> >>>>has already done it?
> >>>>2) Is it true that ob_start("ob_gzhandler") can cause problems on IE
> >>
> >>5.5+?
> >>
> >>>don't know. but you can detect these browsers and turn compression off
> >>
> >>--
> >>PHP General Mailing List (http://www.php.net/)
> >>To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >
> >>
> 
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
>

--- End Message ---
--- Begin Message ---
Besides, whether or not it's considered good practice to comment out
js to non-js-capable browsers, a lot of people do it.

And for the record, I wouldn't condone the removal of comments from
code that someone may need to read sometime. HTML outputted from php
is generally however only meant for the browser to parse, and not for
humans to read.

Which brings me to another suggestion:

If you have a lot of long javascript variable/function names, you
could maybe find a way to automagicly  (I mean automaticly, but
automagicly sounds cooler) shorten local variables, function names,
and perhaps other stuff, although I think for the most part linking
the JS, so that it is cacheable is probably a better option.

How about using xml/xslt to only pass on the content that is unique to
each page to the browser. You could use an ob handler to make sure
that the browser was capable of using xslt, and if not parse the xslt
on the server.

--- End Message ---
--- Begin Message --- Seems I'm going a bit too far here :)
The URL quotes which states to denote JS between <!-- --> comment tags is from the HTML 4.0 page. I've been reading lots of XHTML recommendations lately, and have become accustomed to those. In those, when a <script> isn't understood, it's ignored. Besides that fact, it should also be denoted by the CDATA `tags`
<![CDATA[ ...//... ]]>


sorry about making such a fuss of it around here ;) (just personally don't like it either)

Rory Browne wrote:
excuse me? since when is this considered /good/ practice???
It's one of those things that are concidered /bad/ practice according to
w3...

Hmmm, didn't know the w3c had an opinion on the usage of <!-- //--> tags to delimit javascript. I've always been recommended to use them, to hide the script from browsers that don't support javascript, just like I use <noscript>, or <noframes> to show messages to browsers that don't support script or frames.

Can you reference the message/memo/whatever from the w3c that
discourages them. I believe perhaps you took either it or my
suggestion out of context, because I can't fathom a reason why you
wouldn't want to hide js from non-js-capable browsers.



and

you have the additional talk of replacing out // and /* .. */
comments.

but if you really want to do it then:

function ob_whitespace_removal($str){
// would need to dbl_check regex/modifiers
return ob_gzhandler(preg_replace("/\s+/m", "  ", $str));
}

should work, Although for purists/modularity output buffer stacking
may be a cleaner technique

Re: Internet Explorer Problems:
if you check the ob_start or ob_gzhandler pages on the php
manual(online version) then you'll find a user-submitted comment
saying that MSIE doesn't cache compressed stuff. This doesn't matter
for a dynamic website. Try googling, but don't say ob_gzhandler, since
this is (allegedly) a problem with IE/gzip compatability, and not the
ob_gzhandler implemention(ie search for gzip and not ob_gzhandler).


On 5/7/05, Kirsten <[EMAIL PROTECTED]> wrote:


preg_replace('/s+/', ' ', $html);

but watch out, this js code will work:

var v
alert(v)

this one will not:

var v alert(v)

Sure.... but now: how do I access the htm output of the current executing script before it is send to the user?

Thanks again



1) Is there any function to do this (I'm using PHP 4.2) ? Or maybe some

user


has already done it?
2) Is it true that ob_start("ob_gzhandler") can cause problems on IE

5.5+?


don't know. but you can detect these browsers and turn compression off

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


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




--- End Message ---
--- Begin Message --- Ryan A wrote:
Hey,

I have been screwing around with this code for around a day and am hitting a
wall, any
help would be appreciated.


Basically, I am working on a site that queries the DB for companies and the plans the company is offering, the DB is quite big (a few thousand records in each of the 20 tables)

The parameters are taken from the client in the form of a search box and
usually gives around 1000 results per query, they results are then displayed
like this:


company 1 [] plan [] plan [] plan [] plan company 2 [] plan [] plan [] plan company 3 [] plan company 4 [] plan [] plan

So far, no problems (even though the code and the design are mixed together
in the page)
but so far the code is getting the results grouping via $cno, which results
in the lowest being displayed first which gives the first companies who
joined an edge as they are always getting displayed.


Heres the kicker, he wants to have the same display as above....but randomly from the DB *while still* having pagination.. so new joined companies too get displayed and not shoved at the end of the results.

Choices:

1. ORDER_BY RAND(), and keep the full result set (or just the ids) in session

2. add another column, display_order, and update it at regular intervals to random values.
--- End Message ---
--- Begin Message ---

On 08/05/2005, at 1:03 AM, Rory Browne wrote:

I believe(although I stand to be corrected, that there is a threading
MLM on apache 2 - this would rule out dl() AFAIK



We're not using Apache2 yet coz of the thread issue with php however i am setting up a prefork setup for development.

--- End Message ---
--- Begin Message ---
I need to POST long texts through a form to PHP but the text cuts down to
around 64.000 characters. Is there any way to allow longer texts (like in
php.ini)?

Regards,
SED

--- End Message ---
--- Begin Message --- First of all, don't hijack threads. Instead of replying to a message, create a new one.

SED wrote:
I need to POST long texts through a form to PHP but the text cuts down to
around 64.000 characters. Is there any way to allow longer texts (like in
php.ini)?

This is browser limit. Most, if not all, browsers limit textarea field length to this value.

--- End Message ---
--- Begin Message ---
Hi all,

I'm working on a template system which works a bit like a text translation block. The data looks for example like:

beginblock <div class="block">
endblock </div>
beginauthor <span class="author">
endauthor </div>


The list is going to be very large, it will have several overlays and not all pages need all items in the list. (usually just a fraction)


What will be the smartest way to implement this? I need a low-memory cost and fast solution
I can do it with a php script, like:


$list = array(
 'beginblock' => '<div class="block">',

 etc.

);

but this will use up too much memory. I could additionally do it with a textfile, but if I need to loop through it at every lookup it will be slow..

What are your suggestions?

regards,
Evert

--- End Message ---

Reply via email to