Hi
As Kenneth pointed out, E4X is very powerful by itself avoiding the need to
break things down into arrays and multidimensional arrays etc.
As yesterday's threads proved, there are many ways to approach and solve
building an org chart from XML. Probably one of the simplest routes one could
take would be to structure the data much like you would do in a database.
Linking people together through some form of id. Think of how you would build a
database table that describes an org chart. First off it would probably wind up
being something like this:
employeeID (int, allow null false)
managerID (int, allow null true)
firstname (nvarchar(50), allow null false)
lastname (nvarchar(50), allow null false)
jobTitleID (int, allow null false)
managerID points back to a employeeID or is null. Every manager is an employee,
but not all employee's have managers - ie. the CEO (one could claim they report
to the board but lets ignore that). jobTItleID would point to another table
that describes all the job titles to keep data size smaller.
Now if you were to build the XML as a flat "file" using the above you can use
the power of E4X to extract your entire hiearchy very easily. Start like this:
var ceo:XML;
// expect topDogs to be of length 1
try
{
ceo:XML = (Employees..*.(@managerID == 0))[0]; // assumes that when extracting
null from db, you convert null to 0 and all valid ids are > 0 and you expect at
least one item to be 0
} catch(err:Error){
//problems, no matches
trace("ERROR::[" + getQualifiedClassName(this) + "]::parseEmployees() failed to
find a CEO.");
return;
}
// now that you know the CEO, you can take a look for his/her direct reports
(who is he/she a manager of)
var vicePresidents:XMLList = Employees..*.(@managerID == ceo.employeeID);
----------------------------------------------
you get the hint here. You now have a structure that is very fluid, new vps
could be added, new employees can be added at will. New job titles can be added
and your parsing in theory would never have to change.
I'd probably be working this a little more simple than I have above, I'd do it
recursively if I was building out some form of org chart. I'd probably do
something like this
protected var _employees:XML;
public function parseOrgChart(pRootEmployeeID:int=0):void
{
var subordinates:XMLList = _employees..*.(@managerID == pRootEmployeeID);
for each(var subordinate:XML in subordinates)
{
parseOrgChart(subordinate.employeeID);
}
}
obviously one would be creating some form of picture or the like so return type
of void would be either some form of object or the like.
The alternative of course would be to build the subordinates into child nodes
of their managers. then you are not operating on the whole file at once with
your searches. But it also means that if you are moving someone from one
manager to another you are moving a node from one parent to another.
Sincerely
Mark R. Jonkman
----- Original Message -----
From: [email protected]
To: "Flash Coders List" <[email protected]>
Sent: Tuesday, March 23, 2010 8:08:14 AM GMT -05:00 US/Canada Eastern
Subject: Re: [Flashcoders] Recursive:Part II
I won't - the beauty of E4X is to me is that you no longer need to
translate XML into Array or Object like in AS2 days!
--
Kenneth Kawamoto
http://www.materiaprima.co.uk/
On 23 March 2010 11:13, Lehr, Theodore <[email protected]> wrote:
> So does it make sense to think that it would be easier to create an org
> chart/flow chart like look if I first put the xml into a multi-dimensional
> array? Or would I be dealing with the same issues?
_______________________________________________
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
_______________________________________________
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
