>The Conf Class is awesome! Why isn't
incorporated more into >the Node
>class? Instead of having setParam and getParam why
not have a >node
>automagically create its own conf namespace so all
nodes have an >easy
>place to reference; a uniform interface. In
addition with node >creation
>the Conf class could be used to autocreate a tree
manager so you >could
>crawl the tree and pre and post process nodes in
Nathan, Node creation and conf are different holons.
A NodeFactory may create Nodes, but doesn't use conf
Crawling a tree in pre- or postOrder mode, or Depth-
or BreadthFirst mode (I prefer these terms), should
be *outside* Node, indeed. I agree totally.
>I also think the Event class is great. I just think
its a shame >that it
>isn't being used more, Nodes should fire events when
>initialization/process/render steps and fire events
that other >nodes can
>listen for so they can respond without having to
know the >parent/child
>relationship. This would make Nodes insanely
I can' agree less. Though the Event system lacks true
Object registration at the moment.
Otherwise, IMO, a Node should not know it's parent at
A Node may controll it's children, obsoleting the
need of it's children to give feedback. Well, it's
>Having Smarty/Templates integrated so closely to a
node sucks in >my
>option, if you want to output to a template create a
template >node, or
>have a "/template" namespace in Conf. Render should
have >settings like
>HTML,SVG,PDF,JPG etc The public interface to a node
is way too >big.
Most BC people will tend that Smarty is tightly
integrated. Let me tell you from experience: it is
*not*. The Smarty API is copied into the Node.
Eliminating that copied-API is easy without breaking
The idea of resource-types for Nodes is interesting.
Do you have more ideas on that, ie. how to realize
such, or examples?
>Speaking of NDFs, I hate XML config files, they are
great for >porting
>configs from one environment to another but to work
with by hand >is
I do see ndf as a concept, for the moment coded with
I still do use Phing to generate native php arrays.
MyConf has several 'packers'. These support several
line ini, txt, php_script(!), sql and on. But the
concept remains conf and/or ndf. The 'packers' are
>painful. I have patched my Binarycloud install so it
runs native >php
>config files, I find it much easier to deal with. My
though with >this is
>to create a simple web base interface for handling
the >editing/creation of
>config files. In this fashion we could then create
resources and >the
>config manager could automagically manage them and
validate that >all
>required parameters are filled and valid.
Agree on that. It is a definitive need. Though some
will say that it is discussed already and before.
Herewith ignoring that the need-to-have-it is
>There is allready an RenderManager but i am
>not sure you can just add a renderer.
Bas, it would be wonderfull if you may point to
RenderManager in some more extend. I'm afraight that
the term Render is not clear to vereybody in tha same
way. At least to me, that is.....
> But that might change
if you need to hook node up in a
> different way than a simple tree. Not talking about the sepeartion of
> Node and Rendering.
>I would be more then willing to take on this task or
Nodes form a simple Tree. This Tree can be further
parameterized, if there are needs. The next step will
be a Graph. I think if you go that way, the
application of Nodes will be bent as well.
Example: Entities in a database could form a graph
with data and relations. Searching the Graph is an
application, like: find me the fastest travel
connection fromA to B; or: find me the cheapiest
supplier for this DVD recorder; or such.
IMO: there is a fundamental difference between an
Entity and a Node. That's why Nodes form a Tree and
not a Graph. IMO, that is.