[Nitro] A uniform structure for components in Nitro -- long post

* William william.full.moon at gmail.com
Fri Jun 30 09:44:53 EDT 2006

Hi Itsme

I too am interested in some form of meta-system specification.  I've been
investing time in Og because it does most of the right things needed for a
base-level meta-programming.  (You didn't sign your mail so I hope I got
your name right enough).   Anyway my email is below for a direct reply .

I would be happy to get into discussion off-list.  I don't know if it is of
general (enough) interest.  Homo sapiens do not always like "difference" or
"change".  I think Nitro is an allied technology, it is not a basis for a
component model that I can see myself.

My perception is that Nitro is not a meta-programming model, it is a MVC (or
more likely V-C-M):


Before the topic changes, smalltalk people might be interested to see that
IBM has released a beta evaluation for their latest modelling VisualAge toy.
It uses their very long acronym language (kind of UML in a half-shell).  

Returning to your mail.  There is a lot of specific implementation assumed
in your email.  I grasp that this is necessary, to establish a firm grasp on
the subject -- However, it is better to be open to some wholistic model, or
systems model of the universe imho.

>> A component model is a server-side tree of components. The 
>> root component might correspond to a presented web page, its 
>> children to <div>s within that page, and 

For example; anything in a "<div>" tag is client side.  I can 'assume' that
you mean there is a server-side 'dictionary' or 'model' of components that
will somehow map to the "<div>" tag. So you have something-k that ultimately
resembles the PHP PEAR library.  Is that the meaning here?


My short response to the big proposition is to enquire about the "vision" a
component structure gives you?

I can see that I might assemble a Lego set of reusable chunks.  The effort
involved seems beyond the pay-back return.  You will end up with something
that looks like TWIKI http://www.twiki.org/ -- So in fact we have a bunch of
reusable WEB pages and building blocks (e.g. calendar control, grid control,
tabbed-control, etc, etc.)

There is merit in that, however as Zimbatm says, how does it help to do what
many many many others have done many many times -- Microsoft is now on it's
fourth or fifth version of components.  The meant-time-to-code a simple
address book program takes more or less the same number of days with
WebForms .net v2 as it did in 1990 with one of the third-party components
libraries or with the Borland C++ gui builder (which I preferred actually).

I want a quantum gain.  Components don't even deliver on a linear gain.
Which means all sober, serious mathematicians should skip them because the
software development model is an N-dimensional geometric domain.  

WHY?  The fictional computer scientist *should* require a geometric
improvement in geometric systems (q.e.d.).  All linear improvements will
eventually be overcome with complexity and real-life.  I trust these points
are intuitive as well as mathematically robust?  

Alternatively, one could look at the same MVC paradigm and suggest that
components need to come in a {M-V-C} sets.  So that components are layered
like the I-Ching, as C1.model, C1.view, C1.controller.

I imagine this messes with your class diagrams.  Class diagrams are
2-Dimensional.  An actual component framework is going to have depth and
breadth.  It is basically 3-Dimensional, because the epitome of the exercise
is replicable-units, viz.: components.

I think there ways to get geometric or quantum improvements in development.
The mechanism is non-linear.  So far, I think of "components" as linear
systems, and now there is at least 20 years of example data to back-up that
perception.  Email if you want to discuss non-linear approaches to solution


William.full.moon at gmail.com
  (2006) Information proprietary and confidential intended for direct
recipient(s) and mutually agreed co-respondents.
  Kiearr'wo -- "Everything is beautiful, sweet, delicious, happy, good".
  The usual greeting & departure of the Ya-idt'midtung people.


-----Original Message-----
From: nitro-general-bounces at rubyforge.org
[mailto:nitro-general-bounces at rubyforge.org] On Behalf Of itsme213
Sent: Friday, 30 June 2006 15:43
To: nitro-general at rubyforge.org
Subject: [Nitro] A uniform structure for components in Nitro -- long post
Importance: Low

Here is something that may have been obvious to others all along. Any and
all comments or flames welcome ...

The context for this ... I was wondering what it would take to give Nitro a
full-fledged component model, where views (and controllers) can be composed
from generic parts either automatically for the default case, or with a DSL
that only specified the delta for the non-default customized case. All view
and controllers do is view and operate on domain objects, and the structure
& metadata of those domain objects is enough to construct the views and

Like Nitro does for persistence, only for views and controllers. Like Wee
without continuations. Mostly like Nemo or Mewa
http://www.adrian-lienhard.ch/files/mewa.pdf, but extended further. I have
attached 2 of the key figures from the latter.

What is "A Component Model"?

A component model is a server-side tree of components. The root component
might correspond to a presented web page, its children to <div>s within that
page, and on down. Each component in that tree is connected to domain
objects via a meta-layer. That meta-layer provides a uniform reflective
interface to all domain objects, their attribute values, and their
operations, and enables totally generic view and editor components to
operate through them.

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.7/379 - Release Date: 29-Jun-2006

More information about the Nitro-general mailing list