Dear All

I'm about to start a large'ish project (> 260 tables) that contains a
lot of recursive joins.

It's a CRUD app (will have lots of grids), but I'll need to display
some table data in tree structures.

Table Example :

   Fields - OIDName : Int, NameText : String, OIDParent : Int

   With a join like OIDName ->> OIDParent

Last time I looked, we don't have a database tree view.

Anyone know how to fudge it (without too much of an impact on
maintainability)?

Any pointers to examples would be deeply appreciated ( shamefully, I've
not done a lot with EWB to date).

Many thanks

Robert

R Horbury-Smith wrote:

> Anyone know how to fudge it (without too much of an impact on
> maintainability)?

It sort of depends on what you have to do with it. I found that it was
quite easy to take an Object list and display them using panels and
labels on the panels etc. What you could do in EWB2 is use the new
layout options to create a list of labels with different indents, so
they will appear in a tree. But that would depend whether you want to
interact with them much. For display/selection this would work. For
manipulation, it would get harder. But fundamentally, I'd say it was
not hard to take a code data structure and create an analogue of it in
display components. By separating them sufficiently, maintenance or
future changes shouldn't be hard.

--

Matthew Jones

Robert,

<< I'm about to start a large'ish project (> 260 tables) that contains a lot
of recursive joins.

It's a CRUD app (will have lots of grids), but I'll need to display some
table data in tree structures.

Table Example :

Fields - OIDName : Int, NameText : String, OIDParent : Int

With a join like OIDName ->> OIDParent

Last time I looked, we don't have a database tree view.

Anyone know how to fudge it (without too much of an impact on
maintainability)? >>

I would definitely consider using EWB 2 for this.  Even though EWB 2 does
*not* have a treeview control yet, it's much easier to create one using EWB
2 than EWB 1.x.  The other thing is that EWB 2 has things like a virtual
grid, which is important for dealing with datasets that don't just have a
few hundred rows in them.

How many rows are you looking to use in such a treeview ?  The complicating
factor is whether the treeview needs to be virtual or not.  A virtual
treeview is a bit harder than a non-virtual treeview, for obvious reasons.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> I would definitely consider using EWB 2 for this.  Even though EWB 2
> does not have a treeview control yet, it's much easier to create one
> using EWB 2 than EWB 1.x.  The other thing is that EWB 2 has things
> like a virtual grid, which is important for dealing with datasets
> that don't just have a few hundred rows in them.

Thanks Tim.

I will be upgrading to EWB2 - just thinking about
alternatives/possibilities for this particular project.

>
> How many rows are you looking to use in such a treeview ?  The
> complicating factor is whether the treeview needs to be virtual or
> not.  A virtual treeview is a bit harder than a non-virtual treeview,
> for obvious reasons.

Not many - hundreds perhaps, not thousands. Main problem is that the
nodes need to be collapsible, and nested to n levels (where n = "I
don't know"). Otherwise I'd just use a CTE in a stored procedure and
indent the heirarchy during the query (on the middle tier).

Frankly I'd prefer not to get caught up in component creation - might
turn into a whole new project on it's own .

Cheers Tim.

Robert

Thanks Matthew.

I think I get the idea.

Problem is the data is dynamic (and the user may choose to expand any
number of nodes in the table simultaniously (while leaving most
collapsed) - to any level, so a visual array of static objects won't
work for me (unless you're suggesting that I paint the lables at
runtime in response to user interactions).

Food for thought

Cheers

Robert



Matthew Jones wrote:

> ...
> It sort of depends on what you have to do with it. I found that it was
> quite easy to take an Object list and display them using panels and
> labels on the panels etc. What you could do in EWB2 is use the new
> layout options to create a list of labels with different indents, so
> they will appear in a tree. But that would depend whether you want to
> interact with them much. For display/selection this would work. For
> manipulation, it would get harder. But fundamentally, I'd say it was
> not hard to take a code data structure and create an analogue of it in
> display components. By separating them sufficiently, maintenance or
> future changes shouldn't be hard.



--
Robert Horbury-Smith

R Horbury-Smith wrote:

> Problem is the data is dynamic (and the user may choose to expand any
> number of nodes in the table simultaniously (while leaving most
> collapsed) - to any level, so a visual array of static objects won't
> work for me (unless you're suggesting that I paint the lables at
> runtime in response to user interactions).

You can create new labels as they expand a branch. The whole thing is
very responsive. My web shop uses a set of panels and updates according
to the actions of the user, and the data coming in. My group
application is much more dynamic still, and creates displays quite
dynamically. Basically, I think you'll be amazed at how simple this
stuff actually can be. And that's even before EWB2's fancy new
capabilities.

Have a look at
http://matthew-jones.com/making-a-prettier-grid-in-elevate-webbuilder/
for how I did my "grid".

--

Matthew Jones

Thanks Matthew - nice blog by the way.

Robert

Matthew Jones wrote:

> ...
>
> Have a look at
> http://matthew-jones.com/making-a-prettier-grid-in-elevate-webbuilder/
> for how I did my "grid".