Re: [PHP-DOC] RE: quickref.swf
Hi Mitja! the two files to update are originalafter.js, which contains most of the code, and manual_en_contents.txt, which contains a listing of all the files in the /manual/en/ directory (the function list is produced from that). After you edit either, run make to get a new functions.js. Don't touch before.js and middle.js, as they don't end with a new line and should stay that way. See Makefile for what happens where. Basically, the names of functions are extracted from the directory listing and compressed, the javascript is obfuscated (whitespace and comments removed, and variables get shorter names), and everything is put together into functions.js. You should probably add some keywords to processafter.php if you edit the javascript, as all the words that must not be changed must be listed there. Ah, this explains much. I will look at the whole generating system then. Thanks for the explanation. I will probably try and integrate it into phpdoc. Goba
RE: [PHP-DOC] RE: quickref.swf
Hi, the two files to update are originalafter.js, which contains most of the code, and manual_en_contents.txt, which contains a listing of all the files in the /manual/en/ directory (the function list is produced from that). After you edit either, run make to get a new functions.js. Don't touch before.js and middle.js, as they don't end with a new line and should stay that way. See Makefile for what happens where. Basically, the names of functions are extracted from the directory listing and compressed, the javascript is obfuscated (whitespace and comments removed, and variables get shorter names), and everything is put together into functions.js. You should probably add some keywords to processafter.php if you edit the javascript, as all the words that must not be changed must be listed there. Hope that helps, Mitja -Original Message- From: Gabor Hojtsy [mailto:[EMAIL PROTECTED] Sent: 19. november 2003 20:59 To: Mitja Slenc Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [PHP-DOC] RE: quickref.swf > Test: www.xs0.com/php/index.html > D/L: www.xs0.com/php/funclist.zip Hm, what code you have used to compress (ie. obfuscate) the JS file implementing the functionality? I would like to clen up the code, plus add some requested features, while retaining the small size of the file with compressing (ie. obfuscating) the JS. Goba
Re: [PHP-DOC] RE: quickref.swf
Test: www.xs0.com/php/index.html D/L: www.xs0.com/php/funclist.zip Hm, what code you have used to compress (ie. obfuscate) the JS file implementing the functionality? I would like to clen up the code, plus add some requested features, while retaining the small size of the file with compressing (ie. obfuscating) the JS. Goba
Re: [PHP-DOC] Re: quickref.swf
I was about to test the quickref script on fr.php.net but I'm running through some problems : www.xs0.com/php/index.html Mozilla said : Out of memory, source file www.xs0.com/php/functions.js Where is the working version of the script ? This is a working version, at least for me... Goba
Re: [PHP-DOC] Re: quickref.swf
Hi Mitja,
I was about to test the quickref script on fr.php.net but I'm running
through some problems :
www.xs0.com/php/index.html
Mozilla said : Out of memory, source file www.xs0.com/php/functions.js
Where is the working version of the script ?
didou
Gabor Hojtsy wrote:
Test: www.xs0.com/php/index.html
D/L: www.xs0.com/php/funclist.zip
Well, anything else? ;)
Really wonderfull !
Can you improve the autocompletion stuff ?
- try typing "xslt" then hit the space bar :
actual result : "xslt " => No such function
better result : auto-completion that give "xslt_"
Maybe you can simply ban the space char (" ") from the input field ?
Is there anything that needs to be added/improved before we put this up
on a betatesting page? I would like to add this feature to only one
particular (anymirror.)php.net page, so people can play around with it,
and report bugs, before we add it to all pages. That particular page
would probably be search.php, as it seems to be the most logical to me...
It would be nice to drive this project forward, as it would be a great
advance on the site :))
Goba
Re: [PHP-DOC] Re: quickref.swf
Test: www.xs0.com/php/index.html
D/L: www.xs0.com/php/funclist.zip
Well, anything else? ;)
Really wonderfull !
Can you improve the autocompletion stuff ?
- try typing "xslt" then hit the space bar :
actual result : "xslt " => No such function
better result : auto-completion that give "xslt_"
Maybe you can simply ban the space char (" ") from the input field ?
Is there anything that needs to be added/improved before we put this up
on a betatesting page? I would like to add this feature to only one
particular (anymirror.)php.net page, so people can play around with it,
and report bugs, before we add it to all pages. That particular page
would probably be search.php, as it seems to be the most logical to me...
It would be nice to drive this project forward, as it would be a great
advance on the site :))
Goba
[PHP-DOC] Re: quickref.swf
Hi,
It would be nice to hide the layer in case I change my mind
and click into the document area for example. You can only
make the layer disappear now with cleaning the input box...
Fixed - if you move out of the input box, the list goes away
What about adding the possibility of choosing a function in
the generated list using arrow keys ? (up and down) and
validating with Enter ?
Done...
Test: www.xs0.com/php/index.html
D/L: www.xs0.com/php/funclist.zip
Well, anything else? ;)
Really wonderfull !
Can you improve the autocompletion stuff ?
- try typing "xslt" then hit the space bar :
actual result : "xslt " => No such function
better result : auto-completion that give "xslt_"
Maybe you can simply ban the space char (" ") from the input field ?
Nice work Mitja :)
didou
Mitja
[PHP-DOC] RE: quickref.swf
> It would be nice to hide the layer in case I change my mind > and click into the document area for example. You can only > make the layer disappear now with cleaning the input box... Fixed - if you move out of the input box, the list goes away > What about adding the possibility of choosing a function in > the generated list using arrow keys ? (up and down) and > validating with Enter ? Done... Test: www.xs0.com/php/index.html D/L: www.xs0.com/php/funclist.zip Well, anything else? ;) Mitja
Re: [PHP-DOC] Re: quickref.swf
I don't really understand what you are saying here. Could you give an example of this type of compression, or some pointers to more information about it? I only used this 'prefix compression' because I knew it, and it is easy to decompress in JavaScript. It is also quite effective with this list (lots of common prefixes). See the compression method sent in by Mitja :) Seems to be promising in size :) Dynamically loading files using JavaScript is not so easy. Regardless of how easy it is, as it was said in this conversation before, we are not going to add any solution requiring more requests on our servers. The whole point of this new function lookup method is to ease the user's life *and* take off the extra lookup requests from our server in case the user does not type the function name correctly. So we are not going to split the JS file, and load parts dinamically. We are going to compress, compress and compress... I really think loading the full file at once is the best way to go. If the file hasn't loaded yet, you can use the search box like it works now: enter a function name, and press enter to go to the correct manual page. Only if the file has loaded, a list appears when you enter values. If you enter an existing function name, the script will recognise this, and send you directly to the correct manual page. So it is only an addition, which doesn't make the loading of the main page any slower, just like loading an image doesn't prevent you from reading the text on the same page. If we offer the user a direct search function, it should work instantly. That means either it doesn't give any results (if the JS file hasn't loaded yet), or it gives results as you type. You don't have time to wait for an additional file to load. Hm, I see what you mean here, I have not meant this solution originally, but the maunal lookup search box we had for years as a different lookup solution. But programatically everything is possible as you explained, so why not? :) Goba
[PHP-DOC] Re: quickref.swf
B Ferguson wrote: I would have tried a different compression, however, this one may work better as long as the list is all ways alphabetical. If we want to use binary searching, the list should be alphabetical. I see no problem with that: the list is auto-generated, so why not sort it first? To optimize the list further, I would pick several hex characters, preferably in a row that will not occur in a function name. We use these instead of the 123 characters because we can add a default of no value. We would have to pick what the best default value was. It will probably end up being the value that was before it. This would effectively reduce some space and would also make it near to imposable for someone to edit the file in a text editor. This means the file will have to be created by a bot. I don't really understand what you are saying here. Could you give an example of this type of compression, or some pointers to more information about it? I only used this 'prefix compression' because I knew it, and it is easy to decompress in JavaScript. It is also quite effective with this list (lots of common prefixes). The second idea that I think may be good was discussed a little earlier. Break the string up into a single string per letter. Do you mean "break the array up into a single array per letter"? After the user types the first letter of the search word, the drop down list would download and appear. Lets think about how may users are going to type e.. c.. h.o and wait for all the words to come up? Most (I think) would type something like ech..o after they see that the last letter is in fact o. This should give us a little time to load a little file. In my case, I would rather wait a bit for a small file to load rather then go to a search not found page. But I would also rather not wait for a file to load(even if it did load at the begining) if I know what I wanted (and I normally do.) Is anyone following my argument? Fast first page. If you know what you want, don't wait for small file (if you can beat it) and if you don't know what you want, wait a sec. Dynamically loading files using JavaScript is not so easy. I really think loading the full file at once is the best way to go. If the file hasn't loaded yet, you can use the search box like it works now: enter a function name, and press enter to go to the correct manual page. Only if the file has loaded, a list appears when you enter values. If you enter an existing function name, the script will recognise this, and send you directly to the correct manual page. So it is only an addition, which doesn't make the loading of the main page any slower, just like loading an image doesn't prevent you from reading the text on the same page. If we offer the user a direct search function, it should work instantly. That means either it doesn't give any results (if the JS file hasn't loaded yet), or it gives results as you type. You don't have time to wait for an additional file to load. Greetings, Jan Fabry
[PHP-DOC] Re: quickref.swf
Wow, what a conversation. Goba invited me to look onto the conversation and add my input. I am personally disappointed that the swf version was seemingly dismissed without much intellectual conversation. Now. Lets talk about size optimization. I am not sure if someone has already tried the ideas I have but here they are: I would have tried a different compression, however, this one may work better as long as the list is all ways alphabetical. To optimize the list further, I would pick several hex characters, preferably in a row that will not occur in a function name. We use these instead of the 123 characters because we can add a default of no value. We would have to pick what the best default value was. It will probably end up being the value that was before it. This would effectively reduce some space and would also make it near to imposable for someone to edit the file in a text editor. This means the file will have to be created by a bot. The second idea that I think may be good was discussed a little earlier. Break the string up into a single string per letter. After the user types the first letter of the search word, the drop down list would download and appear. Lets think about how may users are going to type e.. c.. h.o and wait for all the words to come up? Most (I think) would type something like ech..o after they see that the last letter is in fact o. This should give us a little time to load a little file. In my case, I would rather wait a bit for a small file to load rather then go to a search not found page. But I would also rather not wait for a file to load(even if it did load at the begining) if I know what I wanted (and I normally do.) Is anyone following my argument? Fast first page. If you know what you want, don't wait for small file (if you can beat it) and if you don't know what you want, wait a sec. We could group xy_1234567890 and any other non-liked or otherwise cast out letters by using php re-directs. I would also hesitate to include all the js needed to run the script in the download file. Brendan
[PHP-DOC] Re: quickref.swf
Seems easier to do this kind of stuff with Javascript... Manuzhai "Gabor Hojtsy" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hi! > > I have this idea for quite a long time now, but have not had the time to > actually propose it :) So read on... > > Today if you would like to use the quickref functionality, you either > use the URL shortcuts or use the form on the site. If you use the form > on the site, you get to the search page, which looks for files named > with a similar pattern to what you searched for (prefixing your input > with common prefixes). You need to wait for the request to end, and if > you mistyped something, you need to start over again (or click on one of > the closest matches found, if any). > > What if we would provide the quickref as a flash file available on all > pages (at the top above the menu or just on manual pages at the top of > the sidebar)? This flash file would have an internal list of functions > (or better a list of those pages you can look up with the quickref > search). Typing in would display a list of the closest matches as you > type, so in case you make a typo, you can correct it right away. Once > you found the function you are looking for you can get to its manual > page with a press of the enter or a click. > > This saves our servers at least one search request (though the quickrefs > now run through some redirection, so cause more requests), and would be > more convinient for those having the plugin installed. I would assume > that the SWF will be cached on the user's machine. > > The only trick is that the function list should be embeded in the SWF > somehow, as if it would download a list_of_functions.txt or whatever > from our server, then we would not gain anything. But that needs to be > modifiable from time to time, so we need to generate the data part of > the source of the SWF somehow, and compile it with PHP :) > > If this seems to be a good proposal, and is implementable, then I have > an idea to further enhance it in the future. We can put in the proto of > the functions (for which many developers look for many times), so we can > display the proto without any further request. This would ease the life > of our users. > > I have no time to allocate for this stuff, and I lack the know-how of > SWF generation in PHP, so I would like to only propose the idea, in case > someone have time to pick it up, and it seems to be acceptable for the > PHP site. > > Goba
