This is a discussion on Re: Patch: Query favourites within the pgsql Interfaces Pgadmin Hackers forums, part of the PostgreSQL category; --> > >Anyway, it could be rewritten to either not use XML at all, > or to not > >use ...
| |||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| > >Anyway, it could be rewritten to either not use XML at all, > or to not > >use wxxml (say by linking directly to libxml, which is > likely to be on > >the system already considering how many packages use it). It > just makes > >it easier when you don't have to maintain the code youself. > > > > > There must be some XML stuff in std wx, since XRC uses XML, > dunno how reusable that is. It specifically says that the API is not stable and should not be used. (http://cvs.wxwidgets.org/viewcvs.cgi.../xml/xml.h?rev =1.5&content-type=text/vnd.viewcvs-markup and friends) > >As for the fact that you can already store them in standard files - > >sure you can. It's a matter of convenience. > > > Still appears as a duplication of features. What's wrong with > "recent files"? No hierarchy, very very limited number of entries, no control over which entries go on the list (say when you open a one-time file to run, it will still steal a position on the list), no ability to add descriptive entries. I'm sure there are more, but that's what I came up with whlie typing without needing to think about it. > Actually, I'd like it better to have a means of adding > macros/scripts or so to pgAdmin, i.e. wxPython. This would > enable pgAdmin extensions, keeping the pgAdmin core relatively pure. Sure, that'd be nice. Still, that adds a dependency on *python*, which is *huge* compared to wxxml... And I don't see the point in this case. Yes, macro etc would be great functionality, but it's not a replacement for builtin features. If it was, why not rewrite pgadmin in python? //Magnus ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly |
| ||||
| Magnus Hagander wrote: >>>Anyway, it could be rewritten to either not use XML at all, >>> >>> >>or to not >> >> >>>use wxxml (say by linking directly to libxml, which is >>> >>> >>likely to be on >> >> >>>the system already considering how many packages use it). It >>> >>> >>just makes >> >> >>>it easier when you don't have to maintain the code youself. >>> >>> >>> >>> >>There must be some XML stuff in std wx, since XRC uses XML, >>dunno how reusable that is. >> >> > >It specifically says that the API is not stable and should not be used. >(http://cvs.wxwidgets.org/viewcvs.cgi.../xml/xml.h?rev >=1.5&content-type=text/vnd.viewcvs-markup and friends) > > > > > >>>As for the fact that you can already store them in standard files - >>>sure you can. It's a matter of convenience. >>> >>> >>> >>Still appears as a duplication of features. What's wrong with >>"recent files"? >> >> > >No hierarchy, very very limited number of entries, no control over which >entries go on the list (say when you open a one-time file to run, it >will still steal a position on the list), no ability to add descriptive >entries. I'm sure there are more, but that's what I came up with whlie >typing without needing to think about it. > > > > >>Actually, I'd like it better to have a means of adding >>macros/scripts or so to pgAdmin, i.e. wxPython. This would >>enable pgAdmin extensions, keeping the pgAdmin core relatively pure. >> >> > >Sure, that'd be nice. Still, that adds a dependency on *python*, which >is *huge* compared to wxxml... > > I don't mind adding dependencies if benefits are huge (last addition was OGL for graphical explain, which is a std wx contrib module). The few preferred queries I'm using are in some files, and I simply mark and execute them. That's why I can't see any benefit from such a "favourite" feature. >And I don't see the point in this case. > The point is, the scripting option I'm thinking of would allow you to declare your own menu entry for your preferred query (which might consist of a dialogue, formatting your result) so it's not the query you're storing, but but the feature/task/whatever. Just as we have a status display, not just a favourite "select * from pg_status". Regards, Andreas ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend |