> While that may be true of most people that install phpMyAdmin
> themselves,
> it is not true if they are installing it for an ISP type
> setting, where
> there are other users besides the one that installed it.
exactly
> There are quite a few anchors already, and it would not be
> too hard to add
> more.
jup, it will just need a lot of patience...
> <?php
> function PMA_HelpLink($ref)
> {
> globals $cfg;
> if ($cfg['Display_HelpLinks']) {
> $str = '<a href="Documentation.php#'.$ref.'"
> onclick="..."><sup>?</sup></a>';
> } else {
> $str = '';
> }
>
> return $str;
> } // end of the "PMA_HelpLink()" function
> ?>
something like that. Only if Js is enabled it should only point to # and if
there is no js than we don't need to add the onClick. Do we allready have
some js-checking? after all we are using some js every now and then.
And of course we will have to give the section (=filename) as well, and the
function might have to add the language.
> I have the configuration variable there on purpose, as in
> some cases I run
> with limited screen space, and I would want to turn off the
> help links, as
> I know what I am doing.
agreed. though what i am thinking of is a graphic of 10*10 pixels (because i
want to also have it on the side of inputs) and just a text ? is not really
obvious enough (that's for the alt in case you also switched off graphics
;-)
> > 2) wasn't there some thought on having the docu in a
> different format?
> > (sgml, xml or whatever)
> Yes. No format was decided on. I'd be in favour of having the master
> document in SGML/XML, split up into little sections.
> Possible directory structure:
...
> I think XML masters would be ideal, as with XSLT stylesheets on our
> master side when we are rolling a package, we can build all the
> documentation easily. There would also be room to produce more formats
> easily from the XML, such as Info, LaTeX and PDF. I don't
> know if one can
> do this from SGML or not.
yes, there even i agree XML would be a good move *lol* well i wanted to do
some reading on this topics anyway..
> > 3) i expect nobody ever really hoped we could get the whole docu
> > translated, or?
> It will be a slow process for documentation, but it can be done in the
> long term.
at least then we should think of having the files for different languages.
(allthough i expect it would be ok to have the install only in english). but
then there is two problems:
the whole doku in all the languages would be quite a package, so i'd suggest
that the documentation would be split from the main package and is
downloaded seperately in the language the user wants (this also spares us to
have 30 or 40 copies of the english text at the beginning while there is no
translation for some language and we need a file with that name ;-)
and we'd have to think of a way to handle the translations .... what i could
imagine would be to have all strings in a database and do a script that
would enable the translators to translate them online and creating their
languagefile out of it?
simple draft:
table docu
str_id section_id[enum] place_id string
0000001 tbl_qbe 1 Heading 1
0000002 tbl_qbe 1.2 <dt><dd>bla bla....
table transl_chines
str_id translation
0000002 asdfhlsajfh
so when creating the languagefile the script would not find 0000001 in the
transl so it takes it from the table docu (which can be done with a simple
left join transl_chines where str_id is null) and the other from the
translation.
additionally a script like that could of course easily provide the text in
all needed charactersets.
hm.... once again something which might be an idea for a splitted project -
there might be other people apart from PMA that might have a use for that.
--
Mike Beck
mike.beck(a)users.sourceforge.net
Hi List!
>I can extrapolate all of the other functions except
>PMA_INFO_getDB() from this.
>Got any ideas on the last function ?
Since we pass the current db name by url/form
everywhere, I don't think this kind of function inside
the current code. Sorry...
Loïc
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
> > Could somebody please help me with:
> > // returns current database name as string
> > PMA_INFO_getDB()
> > //returns array of table names in given database
> > PMA_INFO_getTables($DBName)
> > //returns array of tables names in current database
> > PMA_INFO_getTables()
> > //returns array of column names in given table
> > PMA_INFO_getColumns($TableName)
> > //returns array of column names in given table inside given database
> > PMA_INFO_getColumns($DBName,$TableName)
>
> all of these allready exist in mysql_wrappers.lib do you need to change
> them?
Thanks Mike.
Hmm, I hadn't noticed those before, and didn't see them when I looked.
Glancing quickly in the file, I see
PMA_mysql_list_tables (like my PMA_INFO_getTables($DBName))
PMA_mysql_list_fields (like my PMA_INFO_getColumns($DBName,$TableName))
I can extrapolate all of the other functions except PMA_INFO_getDB() from
this.
Got any ideas on the last function ?
It wouldn't surprise me if we actually had a variable with it already in
PMA.
--
Robin Hugh Johnson
E-Mail : robbat2(a)orbis-terrarum.net
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639
In writing my SQL parser, I need some functions written that get some
information from MySQL, and I'm not sure of the best way to go about them.
Could somebody please help me with:
// returns current database name as string
PMA_INFO_getDB()
//returns array of table names in given database
PMA_INFO_getTables($DBName)
//returns array of tables names in current database
PMA_INFO_getTables()
//returns array of column names in given table
PMA_INFO_getColumns($TableName)
//returns array of column names in given table inside given database
PMA_INFO_getColumns($DBName,$TableName)
Thanks in advance
--
Robin Hugh Johnson
E-Mail : robbat2(a)orbis-terrarum.net
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639
On Tue, 23 Jul 2002, Marc Delisle wrote:
> Hi Robin,
>
> when do you plan to merge it?
The PMA_STR_* stuff is about to be merged.
PMA_SQP_* later on tonight, I need to rewrite a function again.
So that people can give me a hand in updating the existing codebase to use
the new parser, here is an outline of it.
The basic procedure for using the new SQL parser:
On any page that needs to extract data from a query or to pretty-print a
query, you need code like this up at the top:
($sql contains the query)
$parsedSQL = PMA_SQP_Parse($sql);
If you want to extract data from it then, you just need to run
$SQLinfo = PMA_SQP_Analyze($parsedSQL);
(returned structure of this function is being rewritten presently);
If you want a pretty-printed version of the query, do:
$string = PMA_SQP_FormatHTML($parsedSQL);
(note that that you need to have syntax.css.php3 included somehow in your
page for it to work, I recommend '<link rel="stylesheet" type="text/css"
href="syntax.css.php3" />' at the moment.)
--
Robin Hugh Johnson
E-Mail : robbat2(a)orbis-terrarum.net
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639
Hi List!
Marc wrote:
> What about adding the whole contents of the SQL page,
> on the Structure page, after "propose table structure"?
I agree this idea.
Alexander wrote:
> What about letting the user open a small query window
> via JS by clicking on a link in the left frame? This
> would allow him to use the query box from anywhere.
> I'll build a patch tomorrow.
Good idea as soon it can also work with a browser that
can't parse js (it can be easilly done).
Loïc
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
Hi again!
I've suggested a fix against this bug (tables not linked
are missing in PDF) in the bug tracker. It would be nice
if someone can test it and maybe submit it in the CVS
tree.
Thanks,
Loïc
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
Hi again!
First I must tell you than I no long have access
to any server from my work. So, Robin, I've modified
your but didn't test it. It may then be buggy but I
can't check it.
[About the "PMA_sqlParser_isEscaped()" recursive function]
Marc sent you the valid reply ;)
[About the "===" operator]
>How does one then properly evaluate some expressions?
>$f = FALSE;
>$g = 0
You have to play with the "is_integer()" function.
>My code relies on this difference, as some of the PHP
>functions (strpos namely) return FALSE for not found,
>and integers [0-strlen).
Check users' comments about the "strpos" function in the
online php documentation: we can't rely on the type of
the returned value since different PHP versions return
different type.
The only way to do it is to add a known character before
the string you're searching into, this way you know a zero,
FALSE, empty... value returned means the haystack has not
be found.
>function PMA_sqlParser_strInStr($needle,$haystack)
>{
>- return (strpos($haystack,$needle) !== FALSE);
>-}
>+ return (strpos(' ' . $haystack, $needle) > 0);
>+} // end of the "PMA_sqlParser_strInStr()" function
>Actually breaks the function, stopping it from recognizing
>some things.
The problem is that I can't test it, then it's a bit hard
for me to find where is the error.
>Tell me what text editor you are using with what settings,
>so that I can work out settings for my vim to do this
>properly.
I'm using either UtlraEdit, either vi, either a windows
port of vi...
Have you see the vim settings suggested at the "PEAR coding
standard" web page?
Loïc
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
Hi List!
>Eg for my Parser
>The prefix could be either
>PMAsqp_ or PMA_SQP_
>(I'd go for the second one, as it is still compliant
>with the PEAR naming conventions
Right, the second one is a good choice IMHO.
>As things stand, I have been using
>PMA_sqlParser_* for functions specific to the parser
>PMA_str_* for functions dealing with strings
>and PMA_* for functions not directly specific to the
>parser (the character type matching for example).
OK for "PMA_SQP_" in place of "PMA_sqlParser_" but why
having a prefix for string function?
>From seeing your work, I've made most of the changes
>in my own codebase with the suggestions from the list.
Fine :)
Loïc
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
