Re: an outsiders view

I am repeating my message here, since devlist persists in 'shrubbing' my emails as 
'attachments'.

>one could do: 
>$related_node = $this->getRelatedNode('../someid'); 

Wim, do you have any input here? 

Well, yes. I could have something to say. 

As we discussed, Bas, I've got a version of Node where all  redundant code is removed: 
Caching, Navigating, Creating. 

-: I deleted Caching since it is a bare copy of Smarty Caching. 

-: I've developed a NodeFactory to encapsulate the tree creating  process. Nodes are 
created using a NodeCreator Object. 

-: Nodes are equipped now with a 'pivot', meaning that all  referencing to an UpperNode 
or a Sibling goes through it's Pivot. 
This frees Nodes from traversing, since the pivot is 'visiting' a  Node on preOrder and 
postOrder traversal. Yes, it works clean and  efficient. 

-: To locate a Node in the tree, I don't think one should use the  naming ID's, since BC 
creates a Top node everywhere with the same  name. Alternatives are position (in the 
tree, horizontally) and  level (in the tree, vertically). However the need to do something  
like that is merely a symptom of bad design. 

-: I came to the conclusion that a Node belongs to a Tree and  points to its Top (I'm 
naming that a 'trunk'), and has some  important anchestor (like form and its inputs). It's 
amazing how  clean and easy the code can find them using the className or  attached 
Interface (I am using Interfaces): isInstanceOf. 

-: Well, the proposed methode of locating a Node using a  slashed_path could be easily 
added to the pivot concept. Must  evaluate that. :-] 

To disclose some more on my private efforts: 

-/ I didn't cope with translation, yet. It seems to me that using  Flexy rather than Smarty 
will do the job, without extending the  code or caching zillion translation files. 

-/ I stuck with Phing, which runs pretty smooth under PHP5. I do  think Phing is 
indispensable. I've introduced a three level  nameSpaceSystem: farm --> crop --> work. 

-/ I've redone the 'project' into an Application Tree. I'm  supporting now plain Static, 
traditional BC, MVC, ActionFacade,  AJAX, Hamlet and Portal. These applicationtypes 
can be mixed  freely and may process in parallel. I'm calling this the Staging. 

-/ I've always had my own 'conf', but it's a component of a  Mapping system: plain Map, 
Object Map, Parameter Map, Tensor Map,  Context Map. So, Children in Node is an 
ObjectMap and Conf is a  TensorMap. Parameters, Definition etc. are straight 
parameter  maps. Mapping is eliminating all those messy isset statements  everywhere. 

In order to comment on the outsiders view: 

-- I think having conf as a main component of any Node is right. 
I've implemented that in my NodeConstructorObject. It adds the  feature of 
'configurable' nodes. 

-- To integrate conf and params is however wrong. There is a  conceptual difference 
between conf and params. Whilst there are  preferences as well, needing a whole 
different interface. 

-- The event system is oke, but lacks registering and calling  runtime Objects. This 
comes into play when accessing Event from  already created Nodes. As said, the 
navigation into the Tree is a  separated class. It means also, that the Node itself *only*  
contains hooks for 'Input', 'Processing' and 'Output'. The  'Hierarchy is the Tree, and it's 
an elegant copy of HIPO,  introduced by IBM in the (19)seventies. 

-- Since BCNode has a 'preInput' and 'postInput' method, several  surrounding methods 
of 'Process' and 'Output', well, honestly,  they can *and* must be replaced by an Event 
like 'onTreeInput',  'onTreeProcess' etc. Node may register to Event for these events  
and process when fired. 

-- Example: I've defined an AccessDenied Event in Rbac. Several  Nodes listen to this 
and do something on firing. Works elegant. 
No need to bail with an errormessage or such. 

Actually, there is so much more to exploit in this type of  framework. It's a pity that some 
key people fled the team with  priorities that do not match the key-purpose of the 
framework. 
To me, personally, their reasons to abandon BC have to do with  fatigue and the need 
for quick results. Off course, their new  home is trendy, exciting and thrilling. However, 
the innovating  thinking was already done at Rails. I compare the enthousiastic  stories 
about Rails with the ones emitted when Alfa-four and/or  C-scape hit the streets. You 
may think 'alfa-what'? Exactly. It's  gone. 
FYI: My very personal feeling is that Rails compares to  professional frameworks as 
DBASEIV does to Oracle. A matter of  taste. 

Enough said about the 'empty' mindSpace. Thoughts as Nathan  expressed are truly 
proof of concept. I agree with quite a lot of  them. Also because they came on my mind 
as well :-) and some of  them are worked out already. See my roadMap: 

-] Currently I'm working on the entity concept and shortly  (thanks, Jason), I've got an 
Eureka feeling about that. 

-] Creole and Jargon are installed in my version, but my system  is still clashing with 
Propel. Entities can be build with an IOC  container, which resembles a NodeTree (well, 
not really, but the  code does). There is a strong relation with the propel-schema in  
XML, the Form-node and CRUD forms (compare scaffolding). In fact  one may 
distinguish the physical database, the scheme describing  it and the FormNodes using 
it. It's just a matter of which comes  first. I think I can build a system utilizing one of 
them at  will, in order to generate the other ones. This in effect means  the availability of 
an iterative system for developing. 

-] Such thing is done before, and is still available in legacy  environments. 

-] IOC: Inversion of Control; see picoContainer. 

Anyway, a lot of things to explore further. For the moment I'm  doing that in a lone 
environment. Don't know if contributing will  get it faster ahead.  
My project is called Okklusion and consists of a few independent  components (some 
prefer saying 'packages'). It's my intention to  go commercial, and/or using a Creative 
Commons License. 

Cheers, 
wim niemans 


_______________________________________________
dev mailing list
dev-PnctHDZWAvB/Cz2I37pSEPZ4XP/[email protected]
http://lists.binarycloud.com/mailman/listinfo/dev