Re: [PHP-DOC] MySQLi documentation page mockup
Hannes Magnusson wrote: Do we have the technology to generate this table automatically? :) I can't think of anything. I suppose we could have multiple sets of xpointer() targeted xincludes to get the info and then pre-process it with xslt to generate the table, but that will turn ugly quickly. Same thing with manually maintaining it, at some point people will start forgetting to update the descriptions or aliases or adding functions/props whenever they will be added in the future... Its a no-win situation so whatever way will be picked will have its drawbacks. Well, as a start I'll convert my HTML to DocBook. Over time we can perhaps find a better solution. Thanks, Tony
Re: [PHP-DOC] MySQLi documentation page mockup
On Wed, Oct 1, 2008 at 18:04, Anthony Bedford <[EMAIL PROTECTED]> wrote:
> Hannes Magnusson wrote:
>>
>> The various variations of num_rows looks awkward and confusing, all
>> the various methods and properties return exactly the same thing
>> right? So as far as the user is considered these are all aliases to
>> each other?
>
> Yes agreed, I guess I was highlighting the fact that you can get the same
> info in two ways. So, what is the recommended PHP style, to use a property
> directly or use the accessor methods - I would have thought the latter?
> Whichever is the recommended way we keep, and lose the other one. I will
> also ask the connector guys here what they recommend.
Great :D
>> Although the table contains a great value it is huge and not something
>> that people will "navigate", but I guess there is no real way around
>> it.
>
> There is no way around it as if we are looking up a function (procedural
> interface) as we may have no idea of what class it is associated with, so
> unfortunately we can't split the table on a per-class basis.
Found that out the hard way :)
>> I don't think its worth it to implement it as a first child to a
>> , its to huge to be of any use there - besides the fact
>> http://no.php.net/mysqli already lists most of it.
>> Maybe an appendix ("Alias listing" or whatever) is most appropriate?
>
> OK, so as I understand it from previous discussions this table can't go in
> book.xml. However, I think we could have a link on that page just above the
> "MySQLi — The MySQLi class" bullet point.
Yup, that is easy to do
> Do we have the technology to generate this table automatically? :)
I can't think of anything.
I suppose we could have multiple sets of xpointer() targeted xincludes
to get the info and then pre-process it with xslt to generate the
table, but that will turn ugly quickly.
Same thing with manually maintaining it, at some point people will
start forgetting to update the descriptions or aliases or adding
functions/props whenever they will be added in the future...
Its a no-win situation so whatever way will be picked will have its drawbacks.
-Hannes
Re: [PHP-DOC] MySQLi documentation page mockup
Hannes Magnusson wrote:
The various variations of num_rows looks awkward and confusing, all
the various methods and properties return exactly the same thing
right? So as far as the user is considered these are all aliases to
each other?
Yes agreed, I guess I was highlighting the fact that you can get the
same info in two ways. So, what is the recommended PHP style, to use a
property directly or use the accessor methods - I would have thought the
latter? Whichever is the recommended way we keep, and lose the other
one. I will also ask the connector guys here what they recommend.
At the moment, in the live docs, the property is documented but not the
method. However, the code seems to imply the method is available.
Although the table contains a great value it is huge and not something
that people will "navigate", but I guess there is no real way around
it.
There is no way around it as if we are looking up a function (procedural
interface) as we may have no idea of what class it is associated with,
so unfortunately we can't split the table on a per-class basis.
I don't think its worth it to implement it as a first child to a
, its to huge to be of any use there - besides the fact
http://no.php.net/mysqli already lists most of it.
Maybe an appendix ("Alias listing" or whatever) is most appropriate?
OK, so as I understand it from previous discussions this table can't go
in book.xml. However, I think we could have a link on that page just
above the "MySQLi — The MySQLi class" bullet point. The link could be
called "MySQLi Classes, Methods and Functions Index", "Method and
Function Equivalence Table" or something similar. We can tweak that
later I guess.
Do we have the technology to generate this table automatically? :)
Many thanks,
Tony
Re: [PHP-DOC] MySQLi documentation page mockup
On Wed, Oct 1, 2008 at 12:08, Anthony Bedford <[EMAIL PROTECTED]> wrote:
> Anthony Bedford wrote:
>>
>> And further to that there is another revision at:
>>
>> http://docsrva.mysql.com/public/test3.html
>>
>> I will continue to add content in an effort to find any 'edge' cases.
>>
>
> I have now completed the process of adding content for MySQLi related
> classes[1]. I haven't found anything that didn't 'fit in' to the framework,
> although that isn't to say there isn't something lurking out there that
> could be awkward. :)
The various variations of num_rows looks awkward and confusing, all
the various methods and properties return exactly the same thing
right? So as far as the user is considered these are all aliases to
each other?
Although the table contains a great value it is huge and not something
that people will "navigate", but I guess there is no real way around
it.
> Well, implementing this in the PHP doc system is still to be worked out :)
I don't think its worth it to implement it as a first child to a
, its to huge to be of any use there - besides the fact
http://no.php.net/mysqli already lists most of it.
Maybe an appendix ("Alias listing" or whatever) is most appropriate?
-Hannes
Re: [PHP-DOC] MySQLi documentation page mockup
Anthony Bedford wrote: And further to that there is another revision at: http://docsrva.mysql.com/public/test3.html I will continue to add content in an effort to find any 'edge' cases. I have now completed the process of adding content for MySQLi related classes[1]. I haven't found anything that didn't 'fit in' to the framework, although that isn't to say there isn't something lurking out there that could be awkward. :) I've also added a few functions that only work if mysqlnd is being used (and have marked them accordingly). Well, implementing this in the PHP doc system is still to be worked out :) [1] http://docsrva.mysql.com/public/test4.html Thanks, Tony
Re: [PHP-DOC] MySQLi documentation page mockup
On Fri, Sep 12, 2008 at 18:54, Anthony Bedford <[EMAIL PROTECTED]> wrote: > And further to that there is another revision at: > > http://docsrva.mysql.com/public/test3.html > > I will continue to add content in an effort to find any 'edge' cases. Looks great -Hannes
Re: [PHP-DOC] MySQLi documentation page mockup
And further to that there is another revision at: http://docsrva.mysql.com/public/test3.html I will continue to add content in an effort to find any 'edge' cases. Thanks, Tony Anthony Bedford wrote: Hi, As requested I've been working on a mockup of a possible change to this page: http://www.php.net/manual/en/book.mysqli.php The mockup can be viewed here (with notes): http://docsrva.mysql.com/public/test2.html This is just a simple mockup, you can ignore the colour scheme. :) Here are the requirements as I understand them: 1) The main purpose is to make it easier to find the correct methods and functions. 2) The entries will be links to existing documentation pages (which may also need to be updated). 3) Some methods can have multiple equivalent methods e.g. mysqli_result->free has mysqli_result->close, and mysqli_result->free_result. 4) Static and instance data/methods need to be identified. '::'=static, '->'=instance. This makes it compatible with example code usage. 5) Properties and methods need to be clearly differentiated. 6) Some procedural functions have aliases e.g. mysqli->character_set_name has the alias mysqli_client_encoding. 7) Need to be able to quickly scan for procedural functions (just scan down 'Procedural Interface' column). 8) There will need to be several sections to support multiple classes. The solution I came up with is a simple table that shows the key information. The entries in the table being links to the actual documentation for that method/property. Each 'list of links' on the page referred to above would be replaced by its own table. This means there would be four tables: MySQLi, MySQLi_STMT, MySQLi_Result, and MySQLi_Driver. The list 'Aliases and deprecated Mysqli Functions' would be reduced as the aliases would be in the table. It could become a 'Deprecated Functions' list or simply removed if felt to be of limited value. Now, at this time I don't know whether this is the right way to go, or whether this can actually be done using the PHP doc system. So feedback is appreciated. :) Many thanks, Tony Tony Bedford, Technical Writer Database Technology Group, Sun Microsystems http://sun.com | http://mysql.com
Re: [PHP-DOC] MySQLi documentation page mockup
Ulf Wendel wrote: Assuming that every alias entry is somewhat deprecated and only there for BC reasons, does it have to be in the main table (mockup), wouldn't it be better to "hide" an alias by not showing it in the main table but in a second table "BC/deprecated" below the main overview table? Well, at the moment that's how it is, the alias functions are in a separate list. It may be that people are seeing these functions in old code and then not being able to find the equivalent they should be using. What we could do is just add a note in the alias table heading saying something along the lines of "Do not use - For backwards compatibility only." From the table they can then easily see what they should be using instead. In the separate list they won't see that without digging. Thanks, Tony
Re: [PHP-DOC] MySQLi documentation page mockup
Hannes Magnusson wrote: On Wed, Sep 10, 2008 at 19:13, Anthony Bedford <[EMAIL PROTECTED]> wrote: Hi, As requested I've been working on a mockup of a possible change to this page: http://www.php.net/manual/en/book.mysqli.php The mockup can be viewed here (with notes): http://docsrva.mysql.com/public/test2.html Except the obvious lack of $ for static variables, and () for functions, I think this may just work. OK, I can add those in. Thanks for pointing that out. As per the Docbook specs, cannot have _content_ so this table cannot be on book.mysqli.php. We however could make it an which only contains this table (and whatever relevant info needed). Now the hard part; how to automate this? If I change the description of mysqli_foo_bar() I don't want to need to change it in the appendix too. Why? Because the first 4times everyone would remember to do it, but the 5-8 someone would have to reply to the commit and mention it and then 9th+ everyone would forget until the user gets really confused comparing that table to the actual documentation. Furthermore when the extension will introduce new function/alias in the future noone will remember to add it there too (heck, we don't even remember to add new extension in the correct places, and we have scripts to do that!) Agreed. I'm not sure how it can be done yet though. 3) Some methods can have multiple equivalent methods e.g. mysqli_result->free has mysqli_result->close, and mysqli_result->free_result. Is the table in the mockup an exhausting list of all the current mapping/aliasing between properties, functions and methods? I think its important to figure out all the possible aliases before "acceptance". It wouldn't surprise me if there existed a method, property and two functions all aliased together. Yes, I would not be surprised too. I think as we seem to be heading in approximately the right direction I will go through the mysqli documentation and complete the mockup table with "real" data. That way I can hopefully spot any weird cases. We will then be able to see every scenario, at least for mysqli. The list 'Aliases and deprecated Mysqli Functions' would be reduced as the aliases would be in the table. It could become a 'Deprecated Functions' list or simply removed if felt to be of limited value. That page is a junk yard were I threw stuff which I had no idea what was, as you can see in the history of the file it was once called "Deprecated functions or otherwise wacky stuff.." with a big fat pink warning "This section is a total chaos and need serious looking into" =) OK, I think we could maybe have a table or list just for deprecated functions. There are not too many of them. Thanks, Tony
Re: [PHP-DOC] MySQLi documentation page mockup
On Wed, Sep 10, 2008 at 19:13, Anthony Bedford <[EMAIL PROTECTED]> wrote: > Hi, > > As requested I've been working on a mockup of a possible change to this > page: > > http://www.php.net/manual/en/book.mysqli.php > > The mockup can be viewed here (with notes): > > http://docsrva.mysql.com/public/test2.html Except the obvious lack of $ for static variables, and () for functions, I think this may just work. As per the Docbook specs, cannot have _content_ so this table cannot be on book.mysqli.php. We however could make it an which only contains this table (and whatever relevant info needed). Now the hard part; how to automate this? If I change the description of mysqli_foo_bar() I don't want to need to change it in the appendix too. Why? Because the first 4times everyone would remember to do it, but the 5-8 someone would have to reply to the commit and mention it and then 9th+ everyone would forget until the user gets really confused comparing that table to the actual documentation. Furthermore when the extension will introduce new function/alias in the future noone will remember to add it there too (heck, we don't even remember to add new extension in the correct places, and we have scripts to do that!) > 3) Some methods can have multiple equivalent methods e.g. > mysqli_result->free has mysqli_result->close, and > mysqli_result->free_result. Is the table in the mockup an exhausting list of all the current mapping/aliasing between properties, functions and methods? I think its important to figure out all the possible aliases before "acceptance". It wouldn't surprise me if there existed a method, property and two functions all aliased together. > The list 'Aliases and deprecated Mysqli Functions' would be reduced as the > aliases would be in the table. It could become a 'Deprecated Functions' list > or simply removed if felt to be of limited value. That page is a junk yard were I threw stuff which I had no idea what was, as you can see in the history of the file it was once called "Deprecated functions or otherwise wacky stuff.." with a big fat pink warning "This section is a total chaos and need serious looking into" =) -Hannes
Re: [PHP-DOC] mysqli redirects to mysql
On 14 Jul 2008, at 01:34, Hannes Magnusson wrote: On Mon, Jul 14, 2008 at 01:28, Daniel Convissor <[EMAIL PROTECTED]> wrote: On Sun, Jul 13, 2008 at 01:46:29PM +0200, Hannes Magnusson wrote: On Sat, Jul 12, 2008 at 15:04, Daniel Convissor <[EMAIL PROTECTED]> wrote: Hi Folks: The various http://php.net/mysqli_* function names redirects go to the old mysql_* functions rather than the "new" myslqi_* functions. Is this intentional? No. Okay. So I did some more poking around to figure out how the redirecting is done. I recalled hearing that an SQLite database was involved. I see that the work is done by phpweb/include/manual-lookup.inc and that an SQLite is used when available and various string replacements / file system checks otherwise. http://us.php.net/mysqli_close mistakenly shows mysql_close http://us3.php.net/mysqli_close properly shows mysqli_close I see you put a fix for the non-SQLite lookups in revision 1.33 of manual-lookup.inc. I went to examine the SQLite database, manual-lookup.sqlite, which is supposed to be in phpweb/backend. But I didn't see it on cvs.php.net http://cvs.php.net/viewvc.cgi/phpweb/backend/. I'm confused. Its not in CVS, it is generated by the rsync box using systems/gen-phpweb-sqlite-db.php There are some open related phpweb bug reports too... please have a look while resolving this issue. Also note that this sqlite database is rsynced to mirrors so you may download it from a mirror too. Also note that only about half of the mirrors use this sqlite database. Regards, Philip
Re: [PHP-DOC] mysqli redirects to mysql
On Mon, Jul 14, 2008 at 01:28, Daniel Convissor <[EMAIL PROTECTED]> wrote: > On Sun, Jul 13, 2008 at 01:46:29PM +0200, Hannes Magnusson wrote: >> On Sat, Jul 12, 2008 at 15:04, Daniel Convissor >> <[EMAIL PROTECTED]> wrote: >> > Hi Folks: >> > >> > The various http://php.net/mysqli_* function names redirects go to the >> > old mysql_* functions rather than the "new" myslqi_* functions. Is this >> > intentional? >> >> No. > > Okay. So I did some more poking around to figure out how the redirecting > is done. I recalled hearing that an SQLite database was involved. I see > that the work is done by phpweb/include/manual-lookup.inc and that an > SQLite is used when available and various string replacements / file > system checks otherwise. > > http://us.php.net/mysqli_close > mistakenly shows mysql_close > > http://us3.php.net/mysqli_close > properly shows mysqli_close > > I see you put a fix for the non-SQLite lookups in revision 1.33 of > manual-lookup.inc. > > I went to examine the SQLite database, manual-lookup.sqlite, which is > supposed to be in phpweb/backend. But I didn't see it on cvs.php.net > http://cvs.php.net/viewvc.cgi/phpweb/backend/. I'm confused. Its not in CVS, it is generated by the rsync box using systems/gen-phpweb-sqlite-db.php -Hannes
Re: [PHP-DOC] mysqli redirects to mysql
On Sun, Jul 13, 2008 at 01:46:29PM +0200, Hannes Magnusson wrote: > On Sat, Jul 12, 2008 at 15:04, Daniel Convissor > <[EMAIL PROTECTED]> wrote: > > Hi Folks: > > > > The various http://php.net/mysqli_* function names redirects go to the > > old mysql_* functions rather than the "new" myslqi_* functions. Is this > > intentional? > > No. Okay. So I did some more poking around to figure out how the redirecting is done. I recalled hearing that an SQLite database was involved. I see that the work is done by phpweb/include/manual-lookup.inc and that an SQLite is used when available and various string replacements / file system checks otherwise. http://us.php.net/mysqli_close mistakenly shows mysql_close http://us3.php.net/mysqli_close properly shows mysqli_close I see you put a fix for the non-SQLite lookups in revision 1.33 of manual-lookup.inc. I went to examine the SQLite database, manual-lookup.sqlite, which is supposed to be in phpweb/backend. But I didn't see it on cvs.php.net http://cvs.php.net/viewvc.cgi/phpweb/backend/. I'm confused. Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
Re: [PHP-DOC] mysqli redirects to mysql
On Sat, Jul 12, 2008 at 15:04, Daniel Convissor <[EMAIL PROTECTED]> wrote: > Hi Folks: > > The various http://php.net/mysqli_* function names redirects go to the > old mysql_* functions rather than the "new" myslqi_* functions. Is this > intentional? No. -Hannes
Re: [PHP-DOC] MySQLi extension
On 2/11/07, Friedhelm Betz <[EMAIL PROTECTED]> wrote: Hi Philip, > And, should we keep track (document) > _when_ extensions became stable? Nice too have, but not really necessary, imho. For PECL, the information is on the PECL website. For php-src, it's maybe worth documenting, but it will clutter the docs, and I'm not sure the info is really useful. Mehdi
Re: [PHP-DOC] MySQLi extension
Hi Philip, And, should we keep track (document) _when_ extensions became stable? Nice too have, but not really necessary, imho. Regards Friedhelm
Re: [PHP-DOC] MySQLi extension
This was already fixed in the English translation, so it's up to the Germans to catch up (-: On that note, Philip just said to me "i wonder if we can create a way to store "important" items across translations, like for example, deprecated status (ex. mysqli from that thread)" After a bit of brainstorming, we came up with the idea of creating extension-specific status entities that reference an extension's status, globally (because this sort of thing isn't translation specific). For example, we'd add new global entities: etc. (remember, &warn.experimental; is translated) That way, this sort of thing would never happen (once the &status.foo; entities make it into the various reference.xml files. bah.. the more the entities, the slower the build becomes. So, let's not interfere with translators work :P Nuno Sure it would add one new entity per extension (that would be used in each translation) so although this is a lot I don't feel the slower build time (wonder how much?) is reason enough to not do it. If we do this, the status of all extensions in every translation will be correct and doing this requires zero additional work for translators. Because most translations are on life support (let's not talk about that now), this feature is even more important. BUT, what else will it lead to? Can we come up with a different/better solution that also takes into account other things, like prototypes? Livedocs? A big +1 on the idea. Who is working on the mega patch? I heard Mehdi is but don't know for sure :) And on a related note, what about having a docweb tool scan for EXPERIMENTAL files in php- src, the stable state in PECL (keeping in mind branching), and compare this information to this new status file. Something like that might even help all three locations stay updated. And, should we keep track (document) _when_ extensions became stable? Regards, Philip
Re: [PHP-DOC] MySQLi extension
Hello, Philip Olson wrote: - Original Message - This was already fixed in the English translation, so it's up to the Germans to catch up (-: On that note, Philip just said to me "i wonder if we can create a way to store "important" items across translations, like for example, deprecated status (ex. mysqli from that thread)" After a bit of brainstorming, we came up with the idea of creating extension-specific status entities that reference an extension's status, globally (because this sort of thing isn't translation specific). For example, we'd add new global entities: etc. (remember, &warn.experimental; is translated) That way, this sort of thing would never happen (once the &status.foo; entities make it into the various reference.xml files. bah.. the more the entities, the slower the build becomes. So, let's not interfere with translators work :P Nuno Sure it would add one new entity per extension (that would be used in each translation) so although this is a lot I don't feel the slower build time (wonder how much?) is reason enough to not do it. If we do this, the status of all extensions in every translation will be correct and doing this requires zero additional work for translators. Because most translations are on life support (let's not talk about that now), this feature is even more important. BUT, what else will it lead to? Can we come up with a different/better solution that also takes into account other things, like prototypes? Livedocs? A big +1 on the idea. Who is working on the mega patch? Mehdi
Re: [PHP-DOC] MySQLi extension
Hi, Philip Olson wrote: - Original Message - This was already fixed in the English translation, so it's up to the Germans to catch up (-: On that note, Philip just said to me "i wonder if we can create a way to store "important" items across translations, like for example, deprecated status (ex. mysqli from that thread)" After a bit of brainstorming, we came up with the idea of creating extension-specific status entities that reference an extension's status, globally (because this sort of thing isn't translation specific). For example, we'd add new global entities: etc. (remember, &warn.experimental; is translated) That way, this sort of thing would never happen (once the &status.foo; entities make it into the various reference.xml files. bah.. the more the entities, the slower the build becomes. Hey, a computer is a tool to make things magically happen, even for translators ;-) I don't buy this argument without any rough figures. So, let's not interfere with translators work :P Nuno As Sean said: this sort of thing isn't translation specific. Sure it would add one new entity per extension (that would be used in each translation) so although this is a lot I don't feel the slower build time (wonder how much?) is reason enough to not do it. If we do this, the status of all extensions in every translation will be correct and doing this requires zero additional work for translators. Correctness counts more than build time no? Friedhelm
Re: [PHP-DOC] MySQLi extension
- Original Message - This was already fixed in the English translation, so it's up to the Germans to catch up (-: On that note, Philip just said to me "i wonder if we can create a way to store "important" items across translations, like for example, deprecated status (ex. mysqli from that thread)" After a bit of brainstorming, we came up with the idea of creating extension-specific status entities that reference an extension's status, globally (because this sort of thing isn't translation specific). For example, we'd add new global entities: etc. (remember, &warn.experimental; is translated) That way, this sort of thing would never happen (once the &status.foo; entities make it into the various reference.xml files. bah.. the more the entities, the slower the build becomes. So, let's not interfere with translators work :P Nuno Sure it would add one new entity per extension (that would be used in each translation) so although this is a lot I don't feel the slower build time (wonder how much?) is reason enough to not do it. If we do this, the status of all extensions in every translation will be correct and doing this requires zero additional work for translators. Because most translations are on life support (let's not talk about that now), this feature is even more important. BUT, what else will it lead to? Can we come up with a different/better solution that also takes into account other things, like prototypes? Livedocs? Regards, Philip
Re: [PHP-DOC] MySQLi extension
bah.. the more the entities, the slower the build becomes. So, let's not interfere with translators work :P Nuno - Original Message - This was already fixed in the English translation, so it's up to the Germans to catch up (-: On that note, Philip just said to me "i wonder if we can create a way to store "important" items across translations, like for example, deprecated status (ex. mysqli from that thread)" After a bit of brainstorming, we came up with the idea of creating extension-specific status entities that reference an extension's status, globally (because this sort of thing isn't translation specific). For example, we'd add new global entities: etc. (remember, &warn.experimental; is translated) That way, this sort of thing would never happen (once the &status.foo; entities make it into the various reference.xml files. Thoughts? S
Re: [PHP-DOC] MySQLi extension
Sean Coates wrote: [...] That way, this sort of thing would never happen (once the &status.foo; entities make it into the various reference.xml files. Thoughts? Big +1 Friedhelm
Re: [PHP-DOC] MySQLi extension
>> This was already fixed in the English translation, so it's up >> to the Germans to catch up (-: On that note, Philip just said to me "i wonder if we can create a way to store "important" items across translations, like for example, deprecated status (ex. mysqli from that thread)" After a bit of brainstorming, we came up with the idea of creating extension-specific status entities that reference an extension's status, globally (because this sort of thing isn't translation specific). For example, we'd add new global entities: etc. (remember, &warn.experimental; is translated) That way, this sort of thing would never happen (once the &status.foo; entities make it into the various reference.xml files. Thoughts? S
RE: [PHP-DOC] MySQLi extension
Ok thanks :) I just saw that someone emailed doc-de@ before me so we should be ok soon (hopefully). Andi > -Original Message- > From: Sean Coates [mailto:[EMAIL PROTECTED] > Sent: Monday, February 05, 2007 9:50 PM > To: Andi Gutmans > Cc: phpdoc@lists.php.net > Subject: Re: [PHP-DOC] MySQLi extension > > Hi, > > > http://de3.php.net/manual/de/ref.mysqli.php > > MySQLi isn't experimental to the best of my knowledge. This > was probably never removed. > > This was already fixed in the English translation, so it's up > to the Germans to catch up (-: > > S >
Re: [PHP-DOC] MySQLi extension
Hi, > http://de3.php.net/manual/de/ref.mysqli.php > MySQLi isn't experimental to the best of my knowledge. This was probably > never removed. This was already fixed in the English translation, so it's up to the Germans to catch up (-: S
Re: [PHP-DOC] mysqli doc cleanup
On Tue, 26 Apr 2005, Gabor Hojtsy wrote: > > Does anyone object to removing the deprecated alias function > > files from ext.mysqli that are now mysqli_stm_* functions? > > For example: mysqli_stmt_fetch() versus mysqli_fetch(). Then > > the real functions will refer to the alias using > > &info.deprecated.alias; > > The question is whether depreciated functions will be findable with > http://php.net/function_name et al. They should be... Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org
Re: [PHP-DOC] mysqli doc cleanup
Does anyone object to removing the deprecated alias function files from ext.mysqli that are now mysqli_stm_* functions? For example: mysqli_stmt_fetch() versus mysqli_fetch(). Then the real functions will refer to the alias using &info.deprecated.alias; The question is whether depreciated functions will be findable with http://php.net/function_name et al. Goba
Re: [PHP-DOC] MySQLi methods should be reflected into CHM INDEX
Judging from 'num_rows', how would you decide if it is an sqlite, mysqli, etc. object method? Goba Let's say the entry in the index would be something like: num_rows (SQLite) num_rows (MySQLi) Is that OK ? Yep, if someone has the time to look into implementing it :) Goba
Re: [PHP-DOC] MySQLi methods should be reflected into CHM INDEX
> Judging from 'num_rows', how would you decide if it is an sqlite, > mysqli, etc. object method? > Goba Let's say the entry in the index would be something like: num_rows (SQLite) num_rows (MySQLi) Is that OK ? Gabriel PREDA
Re: [PHP-DOC] MySQLi methods should be reflected into CHM INDEX
I switched to using MySQLi... I'm using Edit+ that has the ability to link to the CHM version of the manual... whenever the cursor is on a function name at CTRL+1...3..4 it will open the manual at that function... However when using object oriened style with MySQLi this will not happen... because there is no "num_rows" (from $mysqli->num_rows ) entry in the index ! Can those methods be added in the index ?!? Judging from 'num_rows', how would you decide if it is an sqlite, mysqli, etc. object method? Goba
Re: [PHP-DOC] mysqli-fetch-assoc
Aloha Enrique, I changed the text a little bit (copied it from ext/mysql :). Thx for the hint! Cheers Georg
Re: [PHP-DOC] mysqli-fetch-assoc
> Hi, > > There is a paragraph that i don´t understand that says: > > If two or more columns in the result set have the same column name, the > associative array > returned by the mysqli_fetch_assoc function > will contain the value of > the last column of that name. If you must work with result sets > with this properity, the > mysqli_fetch_row should be used which returns > an numerically-indexed > array instead. > > In the part where is said: >If you must work with result sets with this properity, the > mysqli_fetch_row >should be used which returns an numerically-indexed array instead. > > For my understanding, it should be : >If you must NOT work with result sets with this property, the > mysqli_fetch_row >should be used which returns an numerically-indexed array instead. > I believe the way georg wrote it is correct, aside from a misspelling and 'function' should be after mysqli_fetch_row. I think it may be best to e-mail georg any suggestions/patches you may have as he is working hard on the mysqli docs. > Or something similar. But of course it is just my opinion, so Ill wait > for advice. > > Enrique García Briones > > Kenneth
Re: [PHP-DOC] MySQLi dockbook structure
See also mysqli_prepare, mysqli_stmt_errno, mysqli_stmt_error, mysqli_bind_result as well as the return values, etc. I'm fine with the methodsynopsis ;) From my view it's easier to read cause you see on first look what you need - you don't have to read the complete text e.g. if you forgot return types, and want to check it in documentation. This manpage like structure was what I have been proposing for a long time :) Rasmus said that the docs should be consistent, and if we change to this style, it would be logical to change the docs at once. But IMHO we will not be able to do that, and this structure is more logical, so why not to keep it? It does not seem to be confusing. so we need a mega patch ? ;) I can work on it if needed ! Would not be a good gift for translators :) In case you have the time and mood, livedocs needs more attention. Sorry that I am not too active currently, but we are in organizing the second hungarian PHP conference [1] in all our free time, which will be a bigger and better event than the previous one, while still being free for all visitors thanks to hard to find the sponsors :) And also a new version of our nonprofit webmastering portal is few days from being announced, so I am quite busy... [1] http://phpconf.hu/ (only in Hungarian) Goba
Re: [PHP-DOC] MySQLi dockbook structure
Gabor Hojtsy wrote: See also mysqli_prepare, mysqli_stmt_errno, mysqli_stmt_error, mysqli_bind_result as well as the return values, etc. I'm fine with the methodsynopsis ;) From my view it's easier to read cause you see on first look what you need - you don't have to read the complete text e.g. if you forgot return types, and want to check it in documentation. This manpage like structure was what I have been proposing for a long time :) Rasmus said that the docs should be consistent, and if we change to this style, it would be logical to change the docs at once. But IMHO we will not be able to do that, and this structure is more logical, so why not to keep it? It does not seem to be confusing. so we need a mega patch ? ;) I can work on it if needed ! didou
Re: [PHP-DOC] MySQLi dockbook structure
See also mysqli_prepare, mysqli_stmt_errno, mysqli_stmt_error, mysqli_bind_result as well as the return values, etc. I'm fine with the methodsynopsis ;) From my view it's easier to read cause you see on first look what you need - you don't have to read the complete text e.g. if you forgot return types, and want to check it in documentation. This manpage like structure was what I have been proposing for a long time :) Rasmus said that the docs should be consistent, and if we change to this style, it would be logical to change the docs at once. But IMHO we will not be able to do that, and this structure is more logical, so why not to keep it? It does not seem to be confusing. Goba
Re: [PHP-DOC] MySQLi dockbook structure
Hi, > > See also > > mysqli_prepare, > mysqli_stmt_errno, > mysqli_stmt_error, > mysqli_bind_result > > > as well as the return values, etc. I'm fine with the methodsynopsis ;) From my view it's easier to read cause you see on first look what you need - you don't have to read the complete text e.g. if you forgot return types, and want to check it in documentation. Georg
Re: [PHP-DOC] MySQLi dockbook structure
Derick Rethans wrote: On Wed, 18 Feb 2004, Mehdi Achour wrote: Georg used a different structure for the .xml files, here's the result : http://www.php.net/manual/en/function.mysqli-fetch.php Should we change the files structures for consistency ? Just keep it until we have a good way of documenting OO extensions. I was more talking about this part : See also mysqli_prepare, mysqli_stmt_errno, mysqli_stmt_error, mysqli_bind_result as well as the return values, etc. I'm fine with the methodsynopsis ;) didou
Re: [PHP-DOC] MySQLi dockbook structure
On Wed, 18 Feb 2004, Mehdi Achour wrote: > Georg used a different structure for the .xml files, here's the result : >http://www.php.net/manual/en/function.mysqli-fetch.php > > Should we change the files structures for consistency ? Just keep it until we have a good way of documenting OO extensions. regards, Derick
Re: [PHP-DOC] mysqli extension
I remember the rpl functions have been removed by Georg for some reason. You should contact Georg Richter ([EMAIL PROTECTED]) for more information on the extension. Goba [EMAIL PROTECTED] wrote: I noticed (after commiting files over dead revisions) that some of the replication functions were removed. Should I again remove these files or wait for the information from MySQL about the lib? Kenneth
RE: [PHP-DOC] MySQLI Documentation
heh, welcome to the wonderful issues of php-gtk.. > -Original Message- > From: Gabor Hojtsy [mailto:[EMAIL PROTECTED] > Sent: 22 November 2003 17:29 > To: Georg Richter > Cc: [EMAIL PROTECTED] > Subject: Re: [PHP-DOC] MySQLI Documentation > > > >>The DOMXML extension has this kind of documentation. > > > > No, DOMXML only supports OO-Syntax, not OO and procedural style. > > Also class->method is hard to read instead to have a list of > properties and > > methods for different objects. > > Well, the dir class has some true OO documentation, but there is not > much real OO docs in the XML sources. > > The dir class uses classsynopsys: > http://www.docbook.org/tdg/en/html/classsynopsis.html > > This enables you to provide an overwiev of the class, but does not let > you add documentation for methods or attributes. I would suggest you > document the mysqli class with this syntax on the intro page of the > mysqli section, and then note on each function page that there is an OO > syntax to use it. > > Unfortunately I have never used DocBook to document OO stuff, so I have > no personal experience. > > Goba
Re: [PHP-DOC] MySQLI Documentation
But I did, see http://www.vl-srm.net/doc/class.srmapp.php (it needs a bit of tweaking though as the constructor doesn't look good yet). I tweaked some of the DSSSL that I copied from the PHP Doc stuff, and backporting it is possible, it just takes a bit of time. The XML for this is attached. I thought that repeating the classynopsys many times is not a good idea... But as there is nothing against it in the docbook manual, it might be a good solution for our problem. In case Derick's changes will be ported to phpdoc. It would help much in providing docs for PHP 5. Goba
Re: [PHP-DOC] MySQLI Documentation
On Sat, 22 Nov 2003, Gabor Hojtsy wrote: > >>The DOMXML extension has this kind of documentation. > > > > No, DOMXML only supports OO-Syntax, not OO and procedural style. > > Also class->method is hard to read instead to have a list of properties and > > methods for different objects. > > Well, the dir class has some true OO documentation, but there is not > much real OO docs in the XML sources. > > The dir class uses classsynopsys: > http://www.docbook.org/tdg/en/html/classsynopsis.html > > This enables you to provide an overwiev of the class, but does not let > you add documentation for methods or attributes. I would suggest you > document the mysqli class with this syntax on the intro page of the > mysqli section, and then note on each function page that there is an OO > syntax to use it. > > Unfortunately I have never used DocBook to document OO stuff, so I have > no personal experience. But I did, see http://www.vl-srm.net/doc/class.srmapp.php (it needs a bit of tweaking though as the constructor doesn't look good yet). I tweaked some of the DSSSL that I copied from the PHP Doc stuff, and backporting it is possible, it just takes a bit of time. The XML for this is attached. Derick Class reference Class SRM This class is used to establish and maintain a connection to the SRM Daemon. Description SRM stringhost intport arrayglobals mixedfunction ... The SRM class maintains the connection with the daemon. It also manages global variables and an interface to the functions in the extension modules. Constructor stringhost intport The class constructor connects the script to the SRM daemon. There are two parameters necessary for this to be accomplished. The host parameter is the IP address of the machine where the SRM daemon is running. The second parameter is the port on which the specificed SRM daemon is listening for incoming connection requests. The example below makes a connection to an SRM daemon on the same host, running on port (the default port). Connecting to an SRM Daemon Global variables The SRM class is capable of managing global variables for an application. These global variables are stored within the SRM daemon, and are accessible to every script connected to the daemon. It's possible to access the global variables with the globals array found within the SRM object. The example below shows how to set and get these variables. Using global variables globals['foo'] = 807; /* display the contents of global variable 'bar' */ echo $con->globals['bar']; ?> Functions Explain the function library (written in PHP) and calling functions in SRM modules. Class SRMApp Instantiate a class on the remote Daemon. Description SRMApp SRMApp resourcesrm stringapplication_id inthandle mixedvarname void __abort mixed function mixedparameter ... The class SRMApp is able to work with remote objects. After instantiating the class, it is possible to interact with a remote object exactly like if the object was instatiated in a local script. Constructor SRMApp objectsrm stringapplication_id The srm is an SRM object as returned by the constructor like so: $obj = new SRM(). The application_id is the name of the Banana desired to be accessed remotely. The Banana will be started if one was not already started. The handle to a Banana is stored in the object property handle. If a Banana was already running, only the handle is returned. In both cases this constructor returns an SRMApp object that can be used within the script. Properties inthandle This property contains a unique identifier to the remote Banana. This property should never be altered by a user, and should be considered read-only. In the future, the handle system might go away when the extension is ported over to ZendEngine 2. mixedvarname Other properties may be used with this object, and are handled like standard properties to a generic PHP Class. The example below shows the difference between a local class, and a remote Banana class.
Re: [PHP-DOC] MySQLI Documentation
The DOMXML extension has this kind of documentation. No, DOMXML only supports OO-Syntax, not OO and procedural style. Also class->method is hard to read instead to have a list of properties and methods for different objects. Well, the dir class has some true OO documentation, but there is not much real OO docs in the XML sources. The dir class uses classsynopsys: http://www.docbook.org/tdg/en/html/classsynopsis.html This enables you to provide an overwiev of the class, but does not let you add documentation for methods or attributes. I would suggest you document the mysqli class with this syntax on the intro page of the mysqli section, and then note on each function page that there is an OO syntax to use it. Unfortunately I have never used DocBook to document OO stuff, so I have no personal experience. Goba
Re: [PHP-DOC] MySQLI Documentation
> Hi Georg! > The DOMXML extension has this kind of documentation. No, DOMXML only supports OO-Syntax, not OO and procedural style. Also class->method is hard to read instead to have a list of properties and methods for different objects. Georg
Re: [PHP-DOC] MySQLI Documentation
Hi Georg! during the last days I changed a lot in php5's ext/mysqli. Now I have some "minor" problems: How to document oo-syntax? - objects - methods - properties For all methods and properties there exists a procedural function too, so a function entry should be also method/property and function. E.g. $mysql->affected_rows (Property) mysqli_affected_rows (Function) or $mysql->query (method) mysqli_query (Function) Does anybody have similar/same problems and a solution how to document it? The DOMXML extension has this kind of documentation. Goba
Re: [PHP-DOC] MySQLi
Gabor Hojtsy wrote: BTW we also have a TODO item here for Hartmut. We need to have a PHP 5 version availabilty information field in the docs now, not only PHP 3 and 4. Given that MySQLi is only available for PHP 5 if I understand correctly. this is going to be tricky because PHP 5 is in the same CVS repository as PHP 4 ... -- Hartmut Holzgraefe <[EMAIL PROTECTED]> -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
