Re: [ppa-dev] The future of the xtree code in ppa

[Karl O. P. <ko...@me...>]

On 06/13/2013 05:32:25 PM, Jehan-Guillaume (ioguix) de Rorthais wrote:
> On 03/06/2013 04:27, Karl O. Pinc wrote:
> > Hi,
> > 
> > I've been looking at the xtree "database browser" code
> > and have begun some extensions of it to support the
> > ability to see views mixed in with tables, or not.
> 
> Mh. Why would you want to have table and views mixed all together?

Mh.  Why would you want them separated?  ;-)  My users can't tell
the difference, and shouldn't have to.

You can, by the by, add foreign data wrappers into the mix as
well.  They also look like tables.

> 
> I prefer having small branches in the tree, with table, views,
> matviews
> in their own branches, than having all of them in a long, big, slow 
> to
> load branch, not to mention scrolling much more to find your object 
> in
> the branch...Moreover, the current tree is pretty close to the
> pgAdmin's
> one, which helps user to switch between tools without too much
> differences.

No worries.  I'm not proposing getting rid of having separate
branches for tables, views, matviews, and fdws.  What I'm
proposing is being able to let the user choose whether to see
separate branches or not.

If you care about the underlying storage model you can see
them separately.  If you don't and all you want to do is
see what data exists so that you can query/browse/insert/whatever
then you can see them all mixed together.  As a db
admin I want to be able to substitute a table for a view
for a fdw and vice versa without confusing the less 
sophisticated user who just wants to be able to get to
his data.  Again, I'm not removing anything.  I'm adding.
Do you guys have a problem with this as a feature?

FWIW, to avoid big, slow, long branches I have the build
system create schemas which contain views into various
areas of the larger db, by topic or whatever.
These scheamas contain nothing but views to deliver
just those portions of the db to the targeted users.
This has worked increasingly well as views have
become updatable and otherwise more like tables.
(Although this is not the motivation for the above.)
(I thought about frobbing ppa to do this, but views
seemed the best approach.)  Basically, I've gotten
to the point where there's enough plain old tables 
in the db that people get dazed.

> 
> > The last message from ioguix disturbed me and got me
> > thinking.  I don't want to work against the project's
> > direction and I've vague memories of discussions
> > regarding javascript and the db browser tree's future.
> > 
> > I want to discuss whether there is any thought that the xtree
> > code might be replaced before I put in more work.  I've looked
> > back through the mailing list and see no such discussion,
> > but for some reason I think this may have been
> > discussed on IRC,
> 
> Yeah, it has been discussed here and there...
> 
> > perhaps with a thought to using
> > a jQuery plugin like jstree -- in the context of
> > needing a newer jQuery.  (jstree requires
> > jQuery 1.9, I think.)  Since I've patches to remove
> > some dependencies on jQuery 1.8 this might be in
> > the offing.
> 
> Yes, that is a project floating around, replacing the current tree
> with
> a jquery one.

Any thoughts on which one?

> 
> > I lean toward the "if it ain't broke don't fix it" side
> > of things, especially since it would be non-trivial
> > and I think we'd require extensions beyond a basic
> > "tree browser" to support the functionality we
> > currently have.
> 
> The problem about xtree is that it is a dead wood stick. It is not
> maintained anymore, we already fixed a bunch of bug in there and
> there's
> still some more (like the auto-expand opening differents branches on
> refresh with new objects).
> 
> Moreover, since we moved to jquery, it would be much better now to 
> use
> a
> plugin which is a maintained project and give much more flexibilty in
> code. Xtree code is just horrible to deal with.
> 
> > Please give me some guidance here.  I don't want
> > to put work into xtree that won't get committed
> > because xtree isn't wanted.  (You may not like
> > the code for other reasons, but that's another
> > story.)
> 
> Well, I'm not the only one speaking for the project, I would like to
> know Robert's point of view. But I think xtree must die.

I'm willing to kill xtree, as part of my larger plan to (optionally)
show the user relations and ignore the underlying storage (per above).
But I'd need to know what to replace it with.  jstree works for me.
Do people want something else?

More to the point, could I get a patch that allows the user to
choose between seeing either all relations together or split
into tables, views, matviews, fdws into PPA?  Or is this out
of the question?
 
> On the a side note, I would really like to see the frames die as well
> and this tree integrated in the main page with a switch to show/hide
> it.
> Not to mention the huge ergonomic win, we have a patch to set a
> different PPA theme based on the serveur or db or user you are on. It
> should really be just applying a css stylesheet, but we have to mess
> with frames and a bunch of js to refresh to tree as well...beurk.

+1  But one thing at a time.

It'd also be nice to have separate state (cookies) for different
windows/tabs in the browser.  This might obviate the need for
per server/db themes -- depending on cookie lifetime, etc.
Anyway it's something to think through when the time comes.

(Backend theme state is powerful, but also something of intrusion
on the backend.  I too thought about backend state when
it comes to solving the problem of "this db has a confusing
number of tables".  If we ever start keeping state in the
backend I may want to propose some sort of table categorization
solution.)


Karl <ko...@me...>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein