Hi all,
I have pushed into my repo, the code for visualizing GIS data. I used SVG
for this purpose and i'm writing the SVG tags accordingly. This allows the
users without JS support also to view the visualizing oppose to using jQuery
SVG to generate SVGs. Further it allows the SVGs to be saved, which is one
of the upcoming features. However I use jQuery SVG to manipulate the SVGs
(zoom and pan), so the users with JS support gets a better user experience.
I have also integrated two small libraries [1],[2] to allow panning the SVG
on dragging and zooming on mouse wheel movement. These are not strictly
needed but nice to have ones.
One problem of SVG is the IE versions <=8 does not support is. I am using
the GD library to generate a PNG image for them and this is in line with
saving those visualization to various formats.
You can test this out at my demo server[3] using the data in the opengis
table. Please be kind enough to share your comments.
--
Thanks and Regards,
Madhura Jayaratne
[1] http://brandonaaron.net/code/mousewheel/docs
[2] http://threedubmedia.com/
[3] http://demo.phpmyadmin.net/gsoc-madhura/index.php
On Tue, May 31, 2011 at 9:54 PM, Tyron Madlener <tyronx(a)gmail.com> wrote:
> On Tue, May 31, 2011 at 5:34 PM, Madhura Jayaratne <madhura.cj(a)gmail.com>
> wrote:
> >
> >
> > On Tue, May 31, 2011 at 6:01 PM, Tyron Madlener <tyronx(a)gmail.com>
> wrote:
> >>
> >> On Tue, May 31, 2011 at 12:39 PM, Madhura Jayaratne
> >> <madhura.cj(a)gmail.com> wrote:
> >> > Hi all,
> >> > I have pushed into my repo, the code for visualizing GIS data. I used
> >> > SVG
> >> > for this purpose and i'm writing the SVG tags accordingly. This allows
> >> > the
> >> > users without JS support also to view the visualizing oppose to using
> >> > jQuery
> >> > SVG to generate SVGs. Further it allows the SVGs to be saved, which is
> >> > one
> >> > of the upcoming features. However I use jQuery SVG to manipulate the
> >> > SVGs
> >> > (zoom and pan), so the users with JS support gets a better user
> >> > experience.
> >> > I have also integrated two small libraries [1],[2] to allow panning
> the
> >> > SVG
> >> > on dragging and zooming on mouse wheel movement. These are not
> strictly
> >> > needed but nice to have ones.
> >> > One problem of SVG is the IE versions <=8 does not support is. I am
> >> > using
> >> > the GD library to generate a PNG image for them and this is in line
> with
> >> > saving those visualization to various formats.
> >> > You can test this out at my demo server[3] using the data in the
> opengis
> >> > table. Please be kind enough to share your comments.
> >> >
> >
> > Hi Tyron,
> > Thank you for your time.
> >>
> >> 2 things I noticed:
> >> - When zooming it doesn't zoom relative to the cursor position
> >
> >
> > Yes, I think this should be addressed. I'm looking into it.
> >>
> >> - I couldn't use any of the form fields below - the svg area was always
> in
> >> focus
> >
> >
> > What do you mean by 'form fields below'? You mean the links referring to
> > the GIT version and all(bottom right)? Yes, that link does not seems to
> > work. But the link in the advertisement on bottom left is working. Wonder
> > how that happens.
>
> No the input fields below the graph. Width, Height, Label column, Spatial
> column
>
>
Actually they are suppose to be on the left side of the visualization, not
below. I think i need to set the default width a bit low so this does not
happen. Didn't notice it since i'm using a wide screen.
About the issue, found the bug and it's now resolved. You should be able see
when the demo server gets updated.
--
Thanks and Regards,
Madhura Jayaratne
Hi all,
I've pushed the implementation of feature "Remember the last way user sorted tables" when browsing tables. You may try it at the demo server [0].
Current implementation only remember the sorting in the session variable. So, when you logout and login again, the sorting will be refreshed.
In order to keep it persistent across session, I will add a new table in phpMyAdmin database and store the sorting and maybe other "browsing"-related data in there later.
In the settings page, I added new boolean field (RememberConfig) under
Settings -> Main frame -> Browse mode -> Remember table's sorting
I set the default value to "true", so you can test the demo without changing any settings.
Any feedback or suggestion is really appreciated.
Regards,
--
Aris Feryanto
Hi all,
I have pushed into my repo the code for spatial index support in
phpMyAdmin.
Spatial indexes are allowed only for a spatial columns, so with the new
feature the option is available only for spatial columns.
Further, when editing, restrictions are placed not to let the user define
spatial indexes on multiple columns or specify size as it is also not
allowed.
You can test the feature on the demo server[1] and you may use 'opengis'
database which has spatial data.
--
Thanks and Regards,
Madhura Jayaratne
[1] http://demo.phpmyadmin.net/gsoc-madhura
Hi there,
I have a few questions about some things that I've been working on, but
am not too sure about.
First, I'm fetching the parameters for routines from the mysql database,
since they are not available from the information_schema database. I
wonder if users on shared hosting will be able to use this? As far as I
know, these users will not have even read access to the mysql db, but
maybe there is some way around this, like fetching as the control user
or something? So is it a bad idea and should I be instead parsing the
output of SHOW CREATE statements?
Next, I've used the following queries to get and manipulate the status
of the event scheduler:
"SHOW GLOBAL VARIABLES LIKE 'event_scheduler'",
"SET GLOBAL event_scheduler='ON'" and
"SET GLOBAL event_scheduler='OFF'"
While they work just fine for the root account, again I wonder what are
the chances of this working on shared hosting.
Next, I need to refactor some JS code that is only common to routines,
triggers and events. Can you guys think of a good filename for that? I
thought about just putting that code in functions.js, but then it'll be
loaded often for pages that don't need it. And also, if it is the best
for that code to go into functions.js, I'd rather keep it in a different
file until later, so that I don't have merge every time someone pushes
their changes to functions.js.
Thoughts?
By the way, I just published a blog post[1] with my report for the first
week of coding. Let me know what you make of it, like if is it a
reasonable report and if I missed something that needed to be posted.
Also my repository[2] and demo server[3] are fully up to date and I
would appreciate any feedback regarding the features that I've pushed.
Thanks,
Rouslan
[1]: http://roccivic.blogspot.com/2011/05/first-week-of-coding-over.html
[2]: http://repo.or.cz/w/phpmyadmin/roccivic.git/shortlog/refs/heads/rte
[3]: http://demo.phpmyadmin.net/gsoc-rouslan/
Hi Marc,
I worked with create table dialog and currently faced with some problems
with it.
I rewrote the table_create click event in the navigation.js and it popups
the dialog correctly with the form. Then for the form submit and increase
the number of fields withing the dialog, I used same code which was at the
functions.js. Currently following scenarios are working as follows.
1. Create a table using the link at navigation bar - works correctly
2. Create a table using the form at the db_structure and
db_operations - works
correctly
3. First create the table using navigation bar and then create another
table using the form at db_structure and db_operations - This popups
couple of dialog boxes (two or three) with a dialog with the entered table
name (1 in image )and others with the empty name(2 in image). (as shown in
the scenario 3 in the doc [1]).
4. First create the table using the forms and then create another table
using the link at the navigation bar - After submitting the
create_table_form at the dialog it shows that the required fields are empty.
I tried many ways to find what is the problem with this, but could not
solve. Is there any special place where I can submit the current changes as
a patch to you, so you can check it.
[1] -
https://docs.google.com/document/d/1nf11ta4TXvG53JOmb7xANIB0GT7v9Rj8GdbAH_I…
<https://docs.google.com/document/d/1nf11ta4TXvG53JOmb7xANIB0GT7v9Rj8GdbAH_I…>Please
help me on this issue.
Regards,
Thilanka.
--
L G Thilanka Kaushalya
Computer Science & Engineering,
University of Moratuwa,
Sri Lanka
Connect with me at,
Gmail : lgtkaushalya(a)gmail.com
Twitter : @thilanka_k
Facebook : Thilanka Kaushalya
Yahoo : lgtkaushalya(a)yahoo.com
Blog : http://coders-view.blogspot.com/
Hi Tyron,
On 24 Mei 2011, at 20:13, Tyron Madlener <tyronx(a)gmail.com> wrote:
> On Tue, May 24, 2011 at 2:49 PM, Aris Feryanto <aris_feryanto(a)yahoo.com> wrote:
>> On 24 Mei 2011, at 17:17, Marc Delisle <marc(a)infomarc.info> wrote:
>>
>>> Le 2011-05-24 03:19, Aris Feryanto a écrit :
>>>> Hi all,
>>>>
>>>> I've just merged my branch with the current phpMyAdmin official master
>>>> branch and want to add a new field in the settings page.
>>>> But, when I open settings page, then open some settings tab, I noted that
>>>> the green arrow button to restore default value is always shown on every
>>>> fields.
>>>> I also have confirmed this on the phpMyAdmin demo page.
>>>> Is some recent changes cause this?
>>>
>>> Hi Aris,
>>> thanks for noticing this.
>>>
>>> Using the technique explained in [0], it seems that this happened when
>>> upgrading from jQuery 1.4.4 to 1.6.1.
>> I found a link [0] and in the section "Upgrading From 1.5.2 to 1.6.1", there
>> are some notes about the new split of .attr() into two functions: .attr()
>> and .prop(). And I looked into config.js, there are a lot of usage of
>> .attr('tagName'), which is in jQuery 1.6.1 must be accessed through
>> .prop('tagName'). I think we can do a quick replace of .attr('X'), for some
>> X which is now considered as property in jQuery 1.6.1.
>> [0] http://blog.jquery.it/2011/05/12/jquery-1-6-1-released/
>
> I think you are incorrect. That behavior was indeed implemented in
> jQuery 1.6, but reverted back in 1.6.1.
>
> Hence the sentence in the blog:
> - "When updating from 1.5.2 to 1.6.1, you should not have to change
> any attribute code."
> - "However, as previously stated, jQuery 1.6.1 will allow you to use
> .attr() just as it was used before in all situations."
>
> So the bug (theoretically) should not come from the .attr() behavior.
>
Later in the blog, I see that even it is said that jQuery 1.6.1 will allow you to use .attr() just as it was used before in all situations, some DOM element only can be retrieved using .prop(). In the "preferred usage" table, while most properties are still supported for backward compatibility with .attr() (thicked gray), you can see some other attributes, including "tagName", only thicked for .prop().
I already tried this in Chrome's developer tools and using .attr('tagName') returns undefined.
--
Aris Feryanto