Re: an outsiders view
"B. Kamer" <[email protected]> Sun, 18 Dec 2005 12:08:57 +0100
| Newsgroups | gmane.comp.lib.binarycloud.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============0095758444==
Content-Type: multipart/alternative; boundary=Apple-Mail-1--169368540
--Apple-Mail-1--169368540
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed
On Dec 16, 2005, at 7:19 PM, Nathan White wrote:
>
> 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 = $this->getParent();
> $related_node = $parent->getChild('someid')
>
> one could do:
>
> $related_node = $this->getRelatedNode('../someid');
Wim, do you have any input here?
> 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 more 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".
simple
> 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 need 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...
Sounds interesting - i am just thinking out loud now;
thought: Validators/Filter are not nodes and do not validate/filter
node definitions, but application data (eg forms).
> The concept of the events on nodes would really be dependant on the
> conf to help remove the need for interfaces.
What do mean by this? Dependant on Conf? I do not see that?
Do mean that you would want to store which node should connect to
which node in Conf? Shouldn't that come from ndf's? Eg. if an ndf has
a <contain> section, on node instanciation (not the init() method)
the node should specify which nodes should be created and listen to
its events.
You talking about removing getChild, getParent etc from the api. This
could be done if the paths of connected nodes '../../
someid' (listened and emiters, or parentS and children) are stored in
the Node itself, not in Conf with setRuntimeValue()? These would then
be available via one/two methods?
or am i misunderstanding?
> _constructTree() would fire $event->emit("Node.ConstructTree");
This would send to every registered node in order of creation, which
is prob not what you want? You only want to send this to registered
listeners of the Node that is emitting.
This leads me to believe something this should be done
$event->emit($this, "Node.ConstructTree");
or
$this->emit("Node.ConstructTree");
> 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.
Again why would that come from Conf?
If it would work one can build NDF's to generate a structure like it
exists currently (should be like this default for backward
compatibility), but one could generate i guess any model (eg MVC)
Any render Nodes should always connect in a treelike fashion... How
would this be specified in the current Node.
>
>
> 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.
Thought: Perhaps we should differentiate between Nodes and smaller
elements (Atoms?) This way a Node would be a collection of Atoms that
might consist of several Controller Classes (Atoms) and perhaps one
Rendering engine. This way we could keep the current notion of a Node
as an important semantic 'entity' of binarycloud.
Thought: Recursiveness and performance.
Wouldn't a 'cloud' of Node be really be sensitive against recursive
emitted events? Perhaps Event should detach a Node after it has been
send init(), process() & render(). etc... this way a node would never
recieve the same event twice.
And currently the NDF's are parsed into a php array of ndf's (see a
cached ndf file for example) that contain's an include function to
generate the tree. Becuase of this the creation of the Node Tree is
currently very fast, since it only need to go recursively over one
array once. The changes incolved here seem to have a considerable
overhead, like generating/maintaining NDF's trees for every Node type
and connecting them to events.
>
> 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.
I do not have the time to give any developmental input here, but pls
go ahead. I do note that an ndf editor needs to become more complex to
>
> 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 :-(
Please note that the r3 branch (php4) is not maintained any more
other then bug fixes. Trac doesn't reflect this yet, but it really
should. Unless enough plp think otherwise, i guess...
Well so far for my thoughts, which I admit are are over the place. I
would like to see a refinement of binarycloud's current structure of
Nodes. The current rule of thumb seems to be NODE EQUALS CONTROLLER &
VIEW which is ( a bit) limited, but really simple too - as a rule it
is very clear. The changes of subject (types of nodes, connected in
any 'cloud'-like structure) is probably very flexible & powerful, but
also adds major complexity for the developer.
I know there were some other attempt by different people to change
the current status quo, but none was agreed too i guess. This isn't
something that should be done quickly and needs some consideration
with an draft/offical proposals and some public scrutinisation by
people more knowledgeable then me... (YES this is an invitation to
you all!)
Bas
--Apple-Mail-1--169368540
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=ISO-8859-1
<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; " class=3D""><SPAN =
class=3D"Apple-style-span"><BR style=3D""><DIV style=3D""><DIV =
style=3D"">On Dec 16, 2005, at 7:19 PM, Nathan White wrote:</DIV><BR =
class=3D"Apple-interchange-newline" style=3D""><BLOCKQUOTE =
type=3D"cite"><BR style=3D""> <DIV style=3D""><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 class was =
rewritten some time ago. It then introduced this<BR style=3D"">concept =
of paths. <BR style=3D""><BR style=3D"">This thought has crossed my mind =
too. I'm a bit concerned about<BR style=3D"">speed, but i like the =
idea...</BLOCKQUOTE><DIV style=3D""><BR style=3D""> 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 style=3D""> =A0</DIV><BR =
style=3D""><BLOCKQUOTE class=3D"gmail_quote" style=3D"border-left: 1px =
solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: =
1ex;">This format could be used for all sorts of info.<BR style=3D""><BR =
style=3D"">eg. instead of;<BR style=3D""><BR style=3D"">$parent =3D =
$this->getParent(); <BR style=3D"">$related_node =3D =
$parent->getChild('someid')<BR style=3D""><BR style=3D"">one could =
do:<BR style=3D""><BR style=3D"">$related_node =3D =
$this->getRelatedNode('../someid');</BLOCKQUOTE></DIV></BLOCKQUOTE><DIV=
style=3D""><BR class=3D"khtml-block-placeholder"></DIV><DIV =
style=3D"">Wim, do you have any input here?</DIV><BR><BLOCKQUOTE =
type=3D"cite"><DIV style=3D""><DIV style=3D"">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 more =
like a "cloud" and less like a tree.<BR style=3D""> <BR style=3D""> =
eg:<BR style=3D""> <BR style=3D""> =
$this->getNodesByType("whatever");<BR style=3D""> <BR style=3D""> <BR =
style=3D""> </DIV><BR style=3D""> <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 the events ever at all. But i =
think i see were this<BR style=3D"">could go. Elaborate please... =
</BLOCKQUOTE><DIV style=3D""><BR style=3D""> 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".<BR></DIV></DIV></BLOCKQUOTE>simple<BR><BLOCKQUOTE =
type=3D"cite"><DIV style=3D""><DIV style=3D""> 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.<BR style=3D""> <BR style=3D""> 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 style=3D"">=
<BR style=3D""> My idea with events extends the concept of node types, =
this would make chaining nodes very easy. For example <BR style=3D""> =
<BR style=3D""> _processDefintion() would fire =
$event->emit("Node.ProcessDefinition");<BR style=3D""> Validators =
nodes could be listening for this and validate the defintion<BR =
style=3D""> or Filter nodes could be listening and depending on a =
condition processes the Definition differently<BR style=3D""> <BR =
style=3D""> _constructTree()=A0 would fire =
$event->emit("Node.ConstructTree");<BR style=3D""><BR style=3D""> =
getOutput() would fire $event->emit("Node.Output");<BR style=3D""> =
Translator nodes could insert themselves so they could transparently =
handle nodes going from one type to another.<BR style=3D""> or a Filter =
node could filter the output back to the request.<BR style=3D""> <BR =
style=3D""> etc...<BR style=3D""></DIV></DIV></BLOCKQUOTE><DIV =
style=3D""><BR class=3D"khtml-block-placeholder"></DIV>Sounds =
interesting - i am just thinking out loud now;</DIV><DIV style=3D""><BR =
class=3D"khtml-block-placeholder"></DIV><DIV style=3D""><DIV =
style=3D"">thought: Validators/Filter are not nodes and do not =
validate/filter node definitions, but application data (eg =
forms).</DIV></DIV><DIV style=3D""><BR =
class=3D"khtml-block-placeholder"></DIV><DIV style=3D""><BLOCKQUOTE =
type=3D"cite"><DIV style=3D""><DIV style=3D"">The concept of the events =
on nodes would really be dependant on the conf to help remove the need =
for interfaces. <BR></DIV></DIV></BLOCKQUOTE><DIV style=3D""><BR =
class=3D"khtml-block-placeholder"></DIV><DIV style=3D"">What do mean by =
this? Dependant on Conf? I do not see that?</DIV><DIV style=3D""><BR =
class=3D"khtml-block-placeholder"></DIV>Do mean that you would want to =
store which node should connect to which node in Conf? Shouldn't that =
come from ndf's? Eg. if an ndf has a <contain> section, on node =
instanciation (not the init() method) the node should specify which =
nodes should be created and listen to its events.</DIV><DIV style=3D""><BR=
class=3D"khtml-block-placeholder"></DIV><DIV style=3D"">You talking =
about removing getChild, getParent etc from the api. This could be done =
if the paths of connected nodes '../../someid'=A0(listened and emiters, =
or parentS and children) are stored in the Node itself, not in Conf with =
setRuntimeValue()? These would then be available via one/two =
methods?</DIV><DIV style=3D""><BR =
class=3D"khtml-block-placeholder"></DIV><DIV style=3D"">or am i =
misunderstanding?</DIV><DIV style=3D""><BR =
class=3D"khtml-block-placeholder"></DIV><BLOCKQUOTE =
type=3D"cite">_constructTree()=A0 would fire =
$event->emit("Node.ConstructTree");</BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV>This would send to every =
registered node in order of creation, which is prob not what you want? =
You only want to send this to registered listeners <I>of the Node</I> =
that is emitting<I>.</I></SPAN><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV><SPAN =
class=3D"Apple-style-span"><I><SPAN class=3D"Apple-style-span" =
style=3D"font-style: normal;">This leads me to believe something this =
should be done</SPAN></I></SPAN></DIV>$event->emit($this, =
"Node.ConstructTree");<DIV><SPAN class=3D"Apple-style-span"><I><SPAN =
class=3D"Apple-style-span" style=3D"font-style: =
normal;">or</SPAN></I></SPAN></DIV><DIV>$this->emit("Node.ConstructTree=
");<SPAN class=3D"Apple-style-span"><I><SPAN class=3D"Apple-style-span" =
style=3D"font-style: normal;"></SPAN></I></SPAN></DIV><DIV><SPAN =
class=3D"Apple-style-span"><I></I><DIV style=3D""><BR><BLOCKQUOTE =
type=3D"cite"><DIV style=3D""><DIV style=3D"">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 style=3D""></DIV></DIV></BLOCKQUOTE><DIV style=3D""><BR =
class=3D"khtml-block-placeholder"></DIV><DIV style=3D"">Again why would =
that come from Conf?</DIV><DIV style=3D""><BR =
class=3D"khtml-block-placeholder"></DIV></DIV><DIV style=3D""><BR =
class=3D"khtml-block-placeholder"></DIV><DIV style=3D"">If it would work =
one can build NDF's to generate a structure like it=A0exists currently =
(should be like this default for backward compatibility), but one could =
generate i guess any model (eg MVC)=A0=A0</DIV><DIV style=3D""><BR =
class=3D"khtml-block-placeholder"></DIV><DIV style=3D"">Any render Nodes =
should always connect in a treelike fashion... How would this be =
specified in the current Node.</DIV><DIV style=3D""><BR><BLOCKQUOTE =
type=3D"cite"><DIV style=3D""><DIV style=3D""> <BR style=3D""> </DIV><BR =
style=3D""> <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 like XML and I do not see the diff in editing =
php<BR style=3D"">array's or xml files. Especially since the via the xml =
one can use <BR style=3D""><node:include>. Which would become a =
function or something in php.<BR style=3D"">messy to my =
opinion.</BLOCKQUOTE><DIV style=3D""><BR style=3D""> Ok I can let that =
go no problem.<BR style=3D""></DIV></DIV></BLOCKQUOTE><DIV style=3D""><BR =
class=3D"khtml-block-placeholder"></DIV><DIV style=3D""><BR =
class=3D"khtml-block-placeholder"></DIV><DIV style=3D"">Thought: Perhaps =
we should differentiate between Nodes and smaller elements (Atoms?) This =
way a Node would be a collection of Atoms that might consist of several =
Controller Classes (Atoms) and perhaps one Rendering engine. This way we =
could keep the current notion of a Node as an =
important=A0semantic=A0'entity' of binarycloud.</DIV><DIV style=3D""><BR =
class=3D"khtml-block-placeholder"></DIV><DIV style=3D"">Thought: =
Recursiveness and performance.</DIV><DIV style=3D""><BR =
class=3D"khtml-block-placeholder"></DIV><DIV style=3D"">Wouldn't a =
'cloud' of Node be really be sensitive against recursive emitted events? =
Perhaps Event should detach a Node after it has been send init(), =
process() & render(). etc... this way a node would never recieve the =
same event twice.</DIV><DIV style=3D""><BR =
class=3D"khtml-block-placeholder"></DIV><DIV style=3D"">And currently =
the NDF's are parsed into a php array of ndf's (see a cached ndf file =
for example) that contain's an include function to generate the tree. =
Becuase of this the creation of the Node Tree is currently very fast, =
since it only need to go recursively over one array once. The changes =
incolved here seem to have a considerable overhead, like =
generating/maintaining NDF's trees for every Node=A0type and connecting =
them to events.=A0</DIV><DIV style=3D""><BR =
class=3D"khtml-block-placeholder"></DIV><BLOCKQUOTE type=3D"cite"><DIV =
style=3D""><DIV style=3D"">=A0</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;">an interface to edit ndf's should also be =
possible... there are not<BR style=3D"">that complex (params, templates, =
template params, contains & <BR style=3D"">includes). But that might =
change if you need to hook node up in=A0=A0a <BR style=3D"">different =
way than a simple tree. Not talking about the sepeartion of<BR =
style=3D"">Node and Rendering.</BLOCKQUOTE><DIV style=3D""><BR style=3D"">=
I would be more then willing to take on this task or help out.<BR =
style=3D""></DIV></DIV></BLOCKQUOTE><DIV style=3D""><BR =
class=3D"khtml-block-placeholder"></DIV><DIV style=3D"">I=A0do not have =
the time to give any developmental input here, but pls=A0go ahead. I do =
note that an ndf editor needs to become more complex to=A0</DIV><DIV =
style=3D""><BR class=3D"khtml-block-placeholder"></DIV><BLOCKQUOTE =
type=3D"cite"><DIV style=3D""><BR style=3D""> <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 style=3D""><BR style=3D""> </BLOCKQUOTE></DIV><BR style=3D""> I =
prefer 5 and using this for all small and personal projects, I still use =
php4 with some clients :-(<BR style=3D""></BLOCKQUOTE><DIV style=3D""><BR =
class=3D"khtml-block-placeholder"></DIV><DIV style=3D"">Please note =
that=A0the r3 branch (php4) is not maintained any more other then bug =
fixes. Trac doesn't reflect this yet, but it really should. Unless =
enough plp think otherwise, i guess...</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV style=3D"">Well so far for =
my thoughts, which I admit are are over the place. I would like to see =
a=A0refinement of binarycloud's current structure of Nodes. The=A0current =
rule of thumb seems to be NODE EQUALS CONTROLLER & VIEW which is ( a =
bit) limited, but really simple too - as a rule it is very clear. The =
changes of subject (types of nodes, connected in any 'cloud'-like =
structure) is probably very flexible & powerful, but also adds major =
complexity for the developer.</DIV><DIV style=3D""><BR =
class=3D"khtml-block-placeholder"></DIV><DIV style=3D"">I know there =
were some other attempt by different people to change the current status =
quo, but none was agreed too i guess. This isn't something that should =
be done quickly and needs some consideration with an draft/offical =
proposals and some public=A0scrutinisation=A0by people =
more=A0knowledgeable=A0then me... (YES this is an invitation to you =
all!)</DIV><DIV style=3D""><BR =
class=3D"khtml-block-placeholder"></DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV>Bas</DIV></SPAN></DIV></BODY></HTM=
L>=
--Apple-Mail-1--169368540--
--===============0095758444==
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
--===============0095758444==--