Forum: General Discussion

Forum for any topic of interest to the Qcodo community, including questions about the framework itself.
-10-5Prev| 13 / 124 |Next+5+10

QDbTree control

thread: 19 messages  |  last: about 2 years ago  |  started: thursday, january 10, 2008, 10:11 pm pst

 
 
Previous|12|Next

#1  |  vakopian (Los Angeles, CA)
Thursday, January 10, 2008, 10:11 PM PST

I just added a new control in the downloads section called QDbTree:
<http://www.qcodo.com/downloads/item.php/170>

It's one of the first building blocks in a generic query builder/reporter application/component that I'm shooting for. It uses the QMetadata class I described here: <http://www.qcodo.com/forums/topic.php/2805/1>

Feedbacks and discussions welcome.

-Vartan

#2  |  VexedPanda (Calgary, AB) Canada
Tuesday, January 15, 2008, 7:39 AM PST

Beautiful. I've been thinking of doing the same for some time, for the same reasons.
I look forward to any further work you do on this!

#3  |  vakopian (Los Angeles, CA)
Wednesday, January 16, 2008, 3:57 PM PST

Thanks Vexed. I just added a new version (2.0) which adds support for circular references and _type tables.

#4  |  vakopian (Los Angeles, CA)
Thursday, January 17, 2008, 2:21 PM PST

Hey Vexed,
I just found this old thread that you started about building a reporting tool:
<http://www.qcodo.com/forums/topic.php/1187/1/2/?strSearch=report>
Did anything come out of it? Although I saw that thread today (after QDbTree was done), it looks like item (1) in your list is pretty close to what I was thinking of when I did this QDbTree (see the GetQQNode() method in there). In fact as I mentioned above, my motivation for QDbTree was to make it part of the reporting tool I was thinking of.
I also saw this page <http://code.google.com/p/qreport/> from Mike, which seams to focus on the output in a paginated control, but doesn't deal with the configuration part. Also it looks it's been inactive for a long time.
It seams there is a lot of interest for such a tool, but it's pretty scattered and hasn't been materialized to a usable state.
I think I'm gonna take a shot at this type of tool, but would first like to see if other people are currently working on a similar solution.

-Vartan

#5  |  VexedPanda (Calgary, AB) Canada
Thursday, January 17, 2008, 2:34 PM PST

Yeah, so far that has still stayed a dream. Basically no clients are screaming for it, so no time has been alloted it.
Even if we did need something now, dbQwikReport would have a large chance of being our tool of choice, just because of the implementation time it would save us. (We're perpetually swamped here.)

So I'm afraid all I'm really able to offer at this point is encouragement, and some suggestions / constructive criticism when appropriate.

#6  |  VexedPanda (Calgary, AB) Canada
Friday, May 9, 2008, 9:03 AM PDT

Has there been any work done on supporting reverse-references?
I want to build a complete GUI driven Query Builder, and that's going to be a major requirement of doing so.

#7  |  vakopian (Los Angeles, CA)
Friday, May 9, 2008, 6:29 PM PDT

Hey Vexed,

If you mean going from the “one” side to the “many” side of a one-to-many relationship, then the current version does not support it. Just to clarify on an example: if you have

Employer  ------------  Employee
           1        n

it will allow to navigate from Employee to Employer, but not backwards. So it would look like this:

+ Employee
   |--------Employer
              |_...
+ Employer 
   |-... (no Employee here)

Do you have an example/scenario how your Query Builder would use the collections in a query? Or some other arguments why having these collections is a good idea?
If this is the only thing holding you back from starting the Query Builder (and using QDbTree for it), I think I can add it in.

-Vartan

#8  |  VexedPanda (Calgary, AB) Canada
Monday, May 12, 2008, 10:26 AM PDT

Sure, a quick example is if I want a report on all the employees in a company.
The base node would be employee, because that's got all the contact info we want to report on.

So then the user would be presented with a QDBTree with only the Employee table at the root. (I guess the option to specify a root DB node may also need to be added to the QDBTree.) From there they would choose Employee->Company->Name, Equals, and enter in the company name they were interested in.

The system would then spit out all the employee information, on employees that meet the created conditions.

I guess the next step after that would be storing generated queries in the DB to re-run / edit at later dates, so some sort of SetNamePath / SetQQNode functionality would be great.

#9  |  vakopian (Los Angeles, CA)
Monday, May 12, 2008, 11:15 AM PDT

What you have described is not a “reverse-references” to me, but it could just be a matter of definition :-). QDbTree can already do your example. It would not do Company -> Employees though (notice the plural).

My local version of QDbTree can also do the user specified root (I thought I already had it in 2.0, but I guess not). I will upload this new version shortly.

Parsing the path back to show it in the QDbTree (with SetNamePath) would be a nice feature, I agree. I'll think about it.

-Vardan

#10  |  VexedPanda (Calgary, AB) Canada
Monday, May 12, 2008, 11:25 AM PDT

My bad, you're right. A better example is to run a report on all the addresses that belong to employees in a given company, where the address table holds the employee_id as a foreign key.


 
 
Previous|12|Next

John 3:16  •  Romans 12:1-8
Copyright © 2005 - 2012, Quasidea Development, LLC
This open-source framework for PHP is released under the terms of The MIT License.