[prev in list] [next in list] [prev in thread] [next in thread] 

List:       binarycloud-dev
Subject:    Re: [binarycloud-dev] Wtf about NDF?
From:       "alex black" <enigma () turingstudio ! com>
Date:       2004-03-20 23:25:18
Message-ID: 1512.172.142.187.51.1079825118.squirrel () turingstudio ! com
[Download RAW message or body]

> And the idea was to have a repository of already written classes
> (vortex) that we could use from ndf without rewriting them.
> So if I want to assemble existing apps on my page, i should be able to
> do this from ndf, and not necessarily write a class for this.

I agree of course with this, but I shoudl qualify:

one should be able to create output from a set of apps in a structure and
apply any additional templates to that output (in addition of course to
changing the app templates, etc) - but I think it is safe and reasonable
to expect that people would not modify App NDFs unless they needed some
specific behavior (or wanted to remove something) and took the time to
understand the app.

I.e. if you have communication from parent to child within an app that
uses fixed IDs, any developer modifying the NDF of an app would need to
know what they were doing. I think that's fine.

> Of course, this is the case:
>
>   YourForm::Init() {
>      parent::Init();
>      if ($this->GetState() == FORM_COMPLETE) {
>         $this->SetTpl('ok.tpl');
> 	foreach($this->children as $child) {
>  	   $child->Destroy();
>         }
>      }
>   }

I don't think that example provides the flexibility we need. It would
obviously work :) - but I think we need something different (but then I
have more messages to read...)

> control what children will render in the Init() logic (positive instead
> of destroying; this breaks the automatic rendering of the tree).

I agree with the basic sense of jason's request - I may not agree with
individual details.

> He means that since Nodes cannot easily control what children will
> render depending on logic (except with using Destroy), my solution for
> multi-page forms is to redirect to next page on success.

Which is fine in some cases and not really possible or useful in other cases.



> Hey, Form changes were always done following your recommandations !!
> Last one I followed was to have FormInputs do the data retrieval,
> filtering and validation. All this proved to be good ideas, but please
> don't say you never designed !

Actually (though I need to look and am away from a machine I can do a CVS
checkout on) - I think Form is 99% what I recommended, so I am certainly
not saying that.

Node is different - it's exactly what I recommended, with a little stuff
added to that recommendation! :)

> The one that is certainly not mature is the r2/EntityForm.

Indeed not.

> I agree with Manuel that we cannot call "children" in ndf node defs that
> are only possibilities. Params are like a hack, that's why i propose to
> separate real children and 'stock' of defs to be used by the class.

Ok, if it's a question of nomenclature... I don't particularly care about
the name children, though it is a technically correct term.

How about <contains> instead? Or... no, contains would be good.

> please provide us a real case of requirements for a multi-page form and
> for Table (from sologig or from any other real problem). Then we work
> till we can agree on how this case should be right coded and we make the
> changes on Node/Form/Table. But theoritical discussions on Node then
> hacks on Form and Table have proven to be time consuming and useless.

I agree - and point well taken, I'll do that.

_a



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@binarycloud.tigris.org
For additional commands, e-mail: dev-help@binarycloud.tigris.org

[prev in list] [next in list] [prev in thread] [next in thread]