Mail archive
acf

[Acf] RFC: Is OOP needed?

From: Nathan Angelacos <nangel_at_nothome.org>
Date: Tue, 09 Jan 2007 02:08:05 +0000

[sorry, this is a bit long]

Working on the controller <-> model and controller -> view API, and
would like your comments on whether OOP is really needed.

As a general guideline, the model setters will take a set of a values
and return (true, table of values), or (false, table of values) if it fails.

model getters will return (true, table of values) or (false, table of
junk) if it failed.



As a "non-OOP" approach, what about structures of tables, (or arrays of
structures of tables) where the basic table is a "configuration entity"
- a "ce") A "ce" is basically a definition for a form element:

A "ce" is a table with the following keys:
        type = text | select | boolean [checkbox] | link | action | raw
        value = [ the value of the ce ]
        option = modifiers to the type
        label = optional text label for what this thing is
        errtxt = the reason for validation failure, if there was one.


From the "helloworld" example of mvc, the "hostname" ce would look like
this:

hostname={ type="text", value="Alpine", option="", label="Hostname",
errtxt=""}


what might be nice is a helper function that fills the default values:

        hostname=ce(label="Hostname")
        err, hostname = model:get(hostname)


A complex example would be the "interfaces" file, where each interface
would have multiple ce's:


iface[lo] = {
                name=ce(value="lo")
                method=ce(type="select", value="loopback",
                           option={loopback, dhcp, static, ppp})
                address=ce(value="127.0.0.1")
                netmask=ce(value="255.0.0.0") }

iface[eth0] = { .. similar .. }


---
The idea is... you send an interface to networking:set(iface[lo]), and
the model either returns "true" + iface[lo], or it returns "false", and
iface[lo] with the "errtxt" for the failed parameters set.  Example:
iface[lo] = {
		name=ce(value="lo")
		method=ce(type="select", value="binkie", 		
                           option={loopback, dhcp, static, ppp})
		address=ce(value="127.0.0.1")
		netmask=ce(value="barf") }
err, iface[lo] = networking:set(iface[lo])
would return:
	err=false
	iface[lo] = {
		name={value="lo", type="text", option="", errtxt=""},
		method={value="binkie", type="select",
			option={loopback, dhcp,static, ppp},
			errtxt="binkie is not a valid option" },
		address={value="127.0.0.1", type="text", option="" 					errtxt=""),
		netmask={value="barf", type="text", option="",
			errtxt="barf is not a valid netmask" }
		}
			
The iface array is now ready to pass to the view.  well, it will be
wrapped in a form table, but basically, the view now has everything it
needs to render the form (or cli) and the view doesn't have to care
about /how/ it will be rendered.
----
"ce" doesn't need to be OO because nothing is inherited.  Each ce is a
singleton field/object.  The inheritance happens above the ce (e.g. an
"interface" is a class)
But.... since we are discussing the application controller / model/ view
interaction, bigger things than just the "ce" are involved here.  So are
there good reasons to make "akclass" a mandatory part of ACF (the
application?)  Or does this all need more examples? (e.g. write a
working example of the interfaces file, with the non-inherited "ce" widgets)
Thanks.
Received on Tue Jan 09 2007 - 02:08:05 GMT