Re: an outsiders view
Nathan White <[email protected]> Fri, 16 Dec 2005 13:19:12 -0500
| Newsgroups | gmane.comp.lib.binarycloud.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============0764283622==
Content-Type: multipart/alternative;
boundary="----=_Part_9562_13598412.1134757152010"
------=_Part_9562_13598412.1134757152010
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
> The Conf class was rewritten some time ago. It then introduced this
> concept of paths.
>
> This thought has crossed my mind too. I'm a bit concerned about
> speed, but i like the idea...
I don't see where this setup would have a big impact on speed. I have been
using some of these concepts with no signs of slow down.
This format could be used for all sorts of info.
>
> eg. instead of;
>
> $parent =3D $this->getParent();
> $related_node =3D $parent->getChild('someid')
>
> one could do:
>
> $related_node =3D $this->getRelatedNode('../someid');
Exactly. One idea I had on this was creating node resource types, I was
thinking it could be implemented like xml namespaces. The rationale behind
this is the concept of specialized nodes. Like filter nodes, validator
nodes, processor nodes and render nodes. This would make things operate mor=
e
like a "cloud" and less like a tree.
eg:
$this->getNodesByType("whatever");
I haven't used the events ever at all. But i think i see were this
> could go. Elaborate please...
First of all the Event Class needs a bit of a modification so it is silent
when an emit is fired and no "slot" is connected to the "signal". I also
think that the event class needs to have a detach method so a slot can
disconnect itself if it needs to. Maybe there is a special handler for node
events where event handling is all done through node name references inside
of Conf.
I also feel that this idea is dependant on nodes not having so much
responsibility in the heavy lifting. I guess when I think of nodes in terms
of Binarycloud I think of all nodes having a default state, this means that
all nodes should always have a valid response. This would mean that there
would be no need for the render related functions. I think getOutput is
enough. If this function was aware of the requesting node, it could render
its output according to its resource type and the resource type of its
parent. Actually when you think of nodes all sharing Conf then there is nee=
d
for nodes giving output unless they are a render node.
My idea with events extends the concept of node types, this would make
chaining nodes very easy. For example
_processDefintion() would fire $event->emit("Node.ProcessDefinition");
Validators nodes could be listening for this and validate the defintion
or Filter nodes could be listening and depending on a condition processes
the Definition differently
_constructTree() would fire $event->emit("Node.ConstructTree");
getOutput() would fire $event->emit("Node.Output");
Translator nodes could insert themselves so they could transparently handle
nodes going from one type to another.
or a Filter node could filter the output back to the request.
etc...
The concept of the events on nodes would really be dependant on the conf to
help remove the need for interfaces. When an event is triggered it could
look in a nodes conf namespace and see if the params its looking for are
set. This makes extending in all directions really easy. Naming conventions
will become a critical issue if this method is adopted.
Personally I do like XML and I do not see the diff in editing php
> array's or xml files. Especially since the via the xml one can use
> <node:include>. Which would become a function or something in php.
> messy to my opinion.
Ok I can let that go no problem.
an interface to edit ndf's should also be possible... there are not
> that complex (params, templates, template params, contains &
> includes). 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 help out.
are you using php 4 or 5?
>
>
I prefer 5 and using this for all small and personal projects, I still use
php4 with some clients :-(
------=_Part_9562_13598412.1134757152010
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
<br>
<div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(=
204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The Conf cla=
ss was rewritten some time ago. It then introduced this<br>concept of paths=
.
<br><br>This thought has crossed my mind too. I'm a bit concerned about<br>=
speed, but i like the idea...</blockquote><div><br>
I don't see where this setup would have a big impact on speed. I have
been using some of these concepts with no signs of slow down.<br>
</div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px=
solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">T=
his format could be used for all sorts of info.<br><br>eg. instead of;<br><=
br>$parent =3D $this->getParent();
<br>$related_node =3D $parent->getChild('someid')<br><br>one could do:<b=
r><br>$related_node =3D $this->getRelatedNode('../someid');</blockquote>=
<div><br>
Exactly. One idea I had on this was creating node resource types, I was
thinking it could be implemented like xml namespaces. The rationale
behind this is the concept of specialized nodes. Like filter nodes,
validator nodes, processor nodes and render nodes. This would make things o=
perate more like a "cloud" and less like a tree.<br>
<br>
eg:<br>
<br>
$this->getNodesByType("whatever");<br>
<br>
<br>
</div><br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I haven't used th=
e events ever at all. But i think i see were this<br>could go. Elaborate pl=
ease...
</blockquote><div><br>
First of all the Event Class needs a bit of a modification so it is
silent when an emit is fired and no "slot" is connected to the
"signal". I also think that the event class needs to have a detac=
h
method so a slot can disconnect itself if it needs to. Maybe there is a
special handler for node events where event handling is all done
through node name references inside of Conf.<br>
<br>
I also feel that this idea is dependant on nodes not having so much
responsibility in the heavy lifting. I guess when I think of nodes in
terms of Binarycloud I think of all nodes having a default state, this
means that all nodes should always have a valid response. This would
mean that there would be no need for the render related functions. I
think getOutput is enough. If this function was aware of the requesting
node, it could render its output according to its resource type and the
resource type of its parent. Actually when you think of nodes all
sharing Conf then there is need for nodes giving output unless they are
a render node.<br>
<br>
My idea with events extends the concept of node types, this would make chai=
ning nodes very easy. For example <br>
<br>
_processDefintion() would fire $event->emit("Node.ProcessDefinition=
");<br>
Validators nodes could be listening for this and validate the defintion<br>
or Filter nodes could be listening and depending on a condition processes t=
he Definition differently<br>
<br>
_constructTree() would fire $event->emit("Node.ConstructTree&=
quot;);<br><br>
getOutput() would fire $event->emit("Node.Output");<br>
Translator nodes could insert themselves so they could transparently handle=
nodes going from one type to another.<br>
or a Filter node could filter the output back to the request.<br>
<br>
etc...<br>
<br>
The concept of the events on nodes would really be dependant on the
conf to help remove the need for interfaces. When an event is triggered
it could look in a nodes conf namespace and see if the params its
looking for are set. This makes extending in all directions really
easy. Naming conventions will become a critical issue if this method is
adopted.<br>
<br>
</div><br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Personally I do l=
ike XML and I do not see the diff in editing php<br>array's or xml files. E=
specially since the via the xml one can use
<br><node:include>. Which would become a function or something in php=
.<br>messy to my opinion.</blockquote><div><br>
Ok I can let that go no problem.<br>
</div><br>
<br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(2=
04, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">an interface =
to edit ndf's should also be possible... there are not<br>that complex (par=
ams, templates, template params, contains &
<br>includes). But that might change if you need to hook node up in &n=
bsp;a
<br>different way than a simple tree. Not talking about the sepeartion of<b=
r>Node and Rendering.</blockquote><div><br>
I would be more then willing to take on this task or help out.<br>
</div><br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">are you using php=
4 or 5?<br><br>
</blockquote></div><br>
I prefer 5 and using this for all small and personal projects, I still use =
php4 with some clients :-(<br>
<br>
------=_Part_9562_13598412.1134757152010--
--===============0764283622==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
dev mailing list
dev-PnctHDZWAvB/Cz2I37pSEPZ4XP/[email protected]
http://lists.binarycloud.com/mailman/listinfo/dev
--===============0764283622==--