Hi everyone,
I'm Yian, currently an undergrad at UC Berkeley. I am interested in participating in phpMyAdmin's GSoC this year as I've used phpMyAdmin for many years (on a number of web applications) and would like to finally make some contributions.
I've looked through the list of project ideas and the source code, and I find that I'm most interested in working on exporting the relations schema to other formats. I'll start going through the source code a bit more and perhaps think about how to export schemas to dia or svg.
Out of curiosity, would exporting the schema to dia involve only exporting the structure whereas exporting to svg might have the data (organized in some user-specified way, like maybe by summing certain fields together for everything with the same X)?
Best, Yian Shang
Yian Shang a écrit :
Hi everyone,
I'm Yian, currently an undergrad at UC Berkeley. I am interested in participating in phpMyAdmin's GSoC this year as I've used phpMyAdmin for many years (on a number of web applications) and would like to finally make some contributions.
I've looked through the list of project ideas and the source code, and I find that I'm most interested in working on exporting the relations schema to other formats. I'll start going through the source code a bit more and perhaps think about how to export schemas to dia or svg.
Out of curiosity, would exporting the schema to dia involve only exporting the structure whereas exporting to svg might have the data (organized in some user-specified way, like maybe by summing certain fields together for everything with the same X)?
Best, Yian Shang
Please don't confuse schema output with the Export feature. In a schema output, only the structure is exported.
On Sat, Mar 20, 2010 at 5:13 AM, Marc Delisle marc@infomarc.info wrote:
Please don't confuse schema output with the Export feature. In a schema output, only the structure is exported.
-- Marc Delisle http://infomarc.info
Ahh, okay, thanks for letting me know.
I just read through some of the comments on the schema output request and I was wondering if there were other export formats besides dia, svg and eps (I think dia itself can convert to both svg and eps) needed? Like perhaps exports for other uml diagram tools?
Finally, would the next step be to implement a feature/fix a bug in phpMyAdmin?
Yian Shang
Hi
Dne Sat, 20 Mar 2010 13:01:00 -0700 Yian Shang yian.shang@gmail.com napsal(a):
I just read through some of the comments on the schema output request and I was wondering if there were other export formats besides dia, svg and eps (I think dia itself can convert to both svg and eps) needed? Like perhaps exports for other uml diagram tools?
Adding more formats can be useful, however the current list include two formats mostly used for embedding graphics into documents (svg and eps) and dia format as one which can be easily edited, what I think it good starting point.
The current generator is quite heavily bound to PDF and it will require lot of changes to make it more generic.
Yian Shang yian.shang@gmail.com napsal(a):
I just read through some of the comments on the schema output request and
I
was wondering if there were other export formats besides dia, svg and eps
(I
think dia itself can convert to both svg and eps) needed? Like perhaps exports for other uml diagram tools?
Adding more formats can be useful, however the current list include two formats mostly used for embedding graphics into documents (svg and eps) and dia format as one which can be easily edited, what I think it good starting point.
The current generator is quite heavily bound to PDF and it will require lot of changes to make it more generic.
Yeah, I looked through the current generator some more and most of the code for the PDF export seems to be focused on exporting the data rather than the schema.
I think, however, the generic class structure for the dia xml export would be similar to he PDF/XML export, as there'd be functions generating headers and footers as well as functions to handle the different types of objects (arrows, boxes, etc) and to handle the relative locations/colors of all uml objects on the grid. Then the function that determines the schema would call each of these auxiliary functions to put the schema into place.
A similar thing could be done for exporting to svg and eps.
Finally, for organization, would there be some sort of overall class that handles processing the schema and then have subclasses for each different format (xml, svg, eps) that takes care of the details of outputting the schema as a diagram? So the overall class might have functions like "determine_schema" whereas each subclass would have "draw_arrow", "draw_box" (which write the xml), etc. Would something like that work?
-- Yian Shang
Hi
Dne Sat, 27 Mar 2010 11:01:40 -0700 Yian Shang yian.shang@gmail.com napsal(a):
Yeah, I looked through the current generator some more and most of the code for the PDF export seems to be focused on exporting the data rather than the schema.
Please do not confuse export (libraries/export/*) with schema generation (pdf_schema.php), these are completely different things (though it might make sense to combine it somehow).
DO
Dne Sat, 27 Mar 2010 11:01:40 -0700 Yian Shang yian.shang@gmail.com napsal(a):
Yeah, I looked through the current generator some more and most of the
code
for the PDF export seems to be focused on exporting the data rather than
the
schema.
Please do not confuse export (libraries/export/*) with schema generation (pdf_schema.php), these are completely different things (though it might make sense to combine it somehow).
That's true, thanks for clarifying.
So since SVG and EPS are both just XML files, would using PHP's DOM libraries to generate them be best? And also, since phpMyAdmin is rewriting things in object-oriented php, would that be the way in which elements of pdf_schema.php are combined into a generic schema generating class and then used by other formats?
Hi
Dne Mon, 29 Mar 2010 02:16:34 -0700 Yian Shang yian.shang@gmail.com napsal(a):
So since SVG and EPS are both just XML files
No, EPS is text format, not a XML. See http://www.tailrecursive.org/postscript/eps.html.
, would using PHP's DOM libraries to generate them be best? And also, since phpMyAdmin is rewriting things in object-oriented php, would that be the way in which elements of pdf_schema.php are combined into a generic schema generating class and then used by other formats?
Well my implementation would consists of base class for rendering the schema with virtual methods for rendering the primitives (box, line, text, ...) and subclasses for each format which would actually implement these methods.
Well my implementation would consists of base class for rendering the schema with virtual methods for rendering the primitives (box, line, text, ...) and subclasses for each format which would actually implement these methods.
I think that makes sense. Would the pdf schema export eventually also be converted to use this framework? (Or is it better left alone since it already works?)
Yian
On Mon, Mar 29, 2010 at 4:53 AM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Mon, 29 Mar 2010 02:16:34 -0700 Yian Shang yian.shang@gmail.com napsal(a):
So since SVG and EPS are both just XML files
No, EPS is text format, not a XML. See http://www.tailrecursive.org/postscript/eps.html.
, would using PHP's DOM libraries to generate them be best? And also, since phpMyAdmin is
rewriting
things in object-oriented php, would that be the way in which elements of pdf_schema.php are combined into a generic schema generating class and
then
used by other formats?
Well my implementation would consists of base class for rendering the schema with virtual methods for rendering the primitives (box, line, text, ...) and subclasses for each format which would actually implement these methods.
-- Michal Čihař | http://cihar.com | http://blog.cihar.com
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Hi
Dne Tue, 30 Mar 2010 01:44:53 -0700 Yian Shang yian.shang@gmail.com napsal(a):
Well my implementation would consists of base class for rendering the schema with virtual methods for rendering the primitives (box, line, text, ...) and subclasses for each format which would actually implement these methods.
I think that makes sense. Would the pdf schema export eventually also be converted to use this framework? (Or is it better left alone since it already works?)
I think it would be easier to first convert it. We don't want to duplicate the code or have need to make the changes in two different code bases.
Hi,
I think it would be easier to first convert it. We don't want to
duplicate the code or have need to make the changes in two different code bases.
That makes sense, thanks for clarifying.
I just recently submitted my proposal, and I'd be very grateful if any feedback can be provided about it.
Thanks, Yian
-
Marc Delisle -
Michal Čihař -
Yian Shang