i just deleted some docu that was still referring to my old parser, and
moved the part about $cfg['PmaNoRelation_DisableWarning'] up where this
variable is in config.inc.
what i am still missing there is $cfg['PmaAbsoluteUri_DisableWarning']
Robin: how can users change the way your parser work (apart from the color)?
specifically i'd like to make him not add newlines in front of the ON in a
LEFT JOIN statement as i am usually working on rather big screens
--
Mike
Hi List,
Just a question about the translation system.
What is the procedure wrt. sync_lang.sh
Eg, I just updated the estonian-iso-8859-1.inc.php file from a
Translations tracker item, should I run that script now?
--
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 Thu, 25 Jul 2002, Lo�c wrote:
> Your parser is a great job :)
Thanks. I tried to test it out as throughly as possible.
> Marc just submitted for me some changes in your
> files. They are just related to coding standard
> problem except a "foreach" I replaced by a while
> for PHP3 compatibility.
Ok.
> At the beginning of "sqlparser.lib.php3" there
> is a constant I renamed from "DEBUGTIMING" to
> "DEBUG_TIMING" but I can't find where it is
> defined. I you can change it...
DEBUG_TIMING and the strange order of function declaraction inside that
block is related to my testing harness for the SQL Parser. I'm going to
keep the testing harness and those calls there for the moment, while the
analyzer and tweaking the Parser is in progress, and probably remove it
around 2.3.2 or 2.3.3 once everything has totally stabilized out.
> Now let's talk about PHP3 compliance problem
> in "sqlparser.lib.php3":
>
> 1. I suggest to replace lines 168-170 by
> $pos = strpos(' ' . $sql, $quotetype, $oldpos) - 1;
> if ($pos < 0) {
> Could you check if it works this way?
No. This does NOT work, as we already start at $oldpos instead of zero.
Instead, this works:
$pos = strpos(' ' . $sql, $quotetype, $oldpos + 1) - 1;
if ($pos < 0) {
Merged in CVS.
> It seems this is the only strpos call where we should
> do different things depending on "not found" and "found
> at the begenning of the string". Am I right?
Presently yes, but I never did complete all of the error detection
functions.
> 2. "trigger_error" is a PHP4 function. Couldn't we use
> "PMA_mysqlDie()" instead?
This is a problem actually. I don't want to terminate the running of the
page just because my SQL Parser can't handle something in the query. I
wanted to just print out a message as to why my parser failed and continue
execution of the page contents. triggering an error with NOTICE level so
that it just prints a message seemed suitable at the time, but I think we
might want to convert to just having a global variable with an error
message for the parser subsystem. Like I said, I never completed the query
error detection at all.
> 3. "print_r" is also a PHP4 function. I suggest to display
> the array "manually".
I was actually just dumping the contents of the analyzer data while I was
working on it. In the end, that function won't be printing any data at
all, but returning it instead.
I've changed that to just return the array for now, and I'll print it out
from my test harness instead.
Merged in CVS.
> 4. "gzcompress" and "gzcompress" can't be used with PHP3 and
> must be tested before use in PHP4 ie
> if (function_exists('gzcompress'))....
I wanted a method in which I could get a specific data dump from a user
containing all the information I needed to fix the SQL Parser.
Just dumping the data base64 encoded got really big, so I was just running
it thru gzcompress before doing the base64 encoding.
Any ideas how I could still shrink the size for the bug posting ?
Considering this, I actually had a major idea. The linux kernel has a
'BUG()' call. For some of our PMA code, a similar thing would actually be
a very useful function call.
Ideally it would print out a human readable message about the bug first of
all, probably in the current language, then a gzip+base64 data chunk, with
instructions to post the chunk on the Bug tracker (maybe even a 'post'
link that partly auto-fills the form ?).
The data chunk can contain whatever we will need in each case. In my
existing use of it, I have a CVS $Id$ tag included for version tracing.
--
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,
Nearly completed the merge of the parser, but I have some questions/notes.
Notes:
1) The Analyzer is _NOT_ working
Questions:
1) Do we need the analyzer right away to get table/column/alias data for
the 2.3.0 release? If not, it can wait for 2.3.1 to replace the existing
data extracters in the code.
2) For the display of the formatted queries, I need to put in a batch of
stylesheet rules. Where is the best place to include my dynamically
generated <style>...</style> data? The only requirement that I have for it
is that the functions have all be defined and that $cfg data is available.
Our login and error pages provide it, but nowhere in the main code can I
find it.
TODO:
1) Add CSS stuff in the correct place
2) Update PMA_format_sql() function to use the new formatter
3) See if everybody likes the output format ;-)
3) Update Documentation.html
4) Update function documentation
Other Notes:
Many thanks to my boss for letting me work on this for all of today (and
still get paid for my job)
It's 5PM now, so I'm heading home. I'll be there in 90 minutes or so,
hopefully somebody has suggestions on the questions about the CSS stuff,
so that I can have the SQL Parser active by tommorow morning.
--
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!
I've suggested a patch against bug #586230 (Table
comments not parsed for HTML) in the bug tracker.
Can anybody test it and commit it if it works?
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
On Wed, 24 Jul 2002, [utf-7] Beck, Mike wrote:
> +AD4- I would actually go against that idea. Have XML master files
> +AD4- instead, as
> +AD4- those can be kept in CVS a lot easier than a database. Each translator
> +AD4- would just open up the XML file in his editor, and update it directly,
> +AD4- then post a patch to the tracker. To keep track of when
> +AD4- changes are made
> +AD4- to the english documentation and not the translations, I
> +AD4- suggest having
> +AD4- small tag in them that is noted as out of date when the
> +AD4- english is updated
> +AD4- and the translation isn't.
>
> well as has been noticed, i am not at all firm with XML yet, so i possibly i
> really thought too complicated there.
Trust me, writing documents in XML directly is even easier than writing
HTML by hand. Since you have control over your own elements and
attributes, the language is usually a lot simpler.
A list might be:
<list type='dot'>
<item>foo</item>
<item>bar</item>
<list>
Paragraph:
<para>I'm a little paragraph. (This is actually SGML compliant I
think)</para>
> possibly it is even ok when we just
> add the new parts to the docu at the end of the file as it is done with the
> language now and when the xml is converted to html, pdf or whatever there is
> a possibility to order the stuff using some tags there? can this be done
> with a XSLT?
Yes, that is definetly doable, but not very common. As for
keeping things straight and easier to edit, the document frequently gets
re-arranged to keep all of the code in the order it will come out. It is a
lot easier to edit when it is already in order.
But it wouldn't be too hard in our language scripting for new sections
being added to be placed at the end of the master files, and then we can
run another script to re-order the XML file via XSLT.
The only skill/knowledge that is needed for doing hard code XML is for
creating your own XSLT and XML Schema documents.
Once you have those, and I can create them when I have a bit of time, you
can feed them to existing tools, and use WYSIWYG XML editors.
--
Robin Hugh Johnson
E-Mail : robbat2(a)orbis-terrarum.net
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639
> 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