headers
Jason Hines | 2 Oct 2004 09:50

nodes


The more I think about these recent Node discussions, the more I think 
we are perhaps pushing the design in a wrong direction.  I'm not only 
referring to Manuel's suggestions, but to some of my own as well.

I think we should take some more steps back to re-examine the Node 
concept and consider the following statement:

In regards to the issue of "modifying tree based on the processed result 
of a child", the base problem exists only in Form.  This illustrates a 
flaw in the Form design I think.

My reasons at this point are 2 fold.

1.  I don't think Node was ever intended to act as a full controller. 
Alex agrees with me that the ability to explicitely manipulate node 
trees within Nodes is a good thing, but we do not seem to be going this 
route.

2.  I think Form can be re-designed better.  If you look at Form and 
FormInput, there is alot of duplicity happening.  I think we should move 
all logic back up the tree, giving all control to Form.php.

This would allow Form.php to do:

foreach child
   if child value exists in request
     child->state = submitted
     if child value is valid
       child->state = complete
(Continue reading)

Permalink | Reply | 7 comments |
headers
Manuel Holtgrewe | 2 Oct 2004 11:42

Re: nodes

Hi Jason.

Form works pretty well now. We need the two distinct passes anyway 
everywhere you need to operate on a initialized grand child.

These are thoughts fitting for r4/r5 and maybe seperating Form logic 
from form presentation would be good, too. However, I do not think we 
should redesign Form once more.

Manuel
Permalink | Reply | 5 comments |
headers
Manuel Holtgrewe | 2 Oct 2004 13:42

Re: How to name methods in Node

Hm...

Maybe an additional Node::processDefinition() method is required for 
better seperation of things in init? This would make using Form by 
extending it easier.

Manuel
Permalink | Reply | 0 comments |
headers
Jason Hines | 2 Oct 2004 17:22

Re: nodes


Manuel Holtgrewe wrote:
> Form works pretty well now. 

Yes it does, but isn't it the case in point proving that we need the 
node modifications?  Where else is there an example?

We need the two distinct passes anyway
> everywhere you need to operate on a initialized grand child.

This seems to be an effect of the Init() splitting into Init() and 
Process().  Before this split, this would have been been possible in 
Init(), after calling parent::init().  JCM, is this correct?

jason
Permalink | Reply | 4 comments |
headers
Jason Hines | 2 Oct 2004 17:28

Re: nodes


Jason Hines wrote:
> We need the two distinct passes anyway
>> everywhere you need to operate on a initialized grand child.
> 
> This seems to be an effect of the Init() splitting into Init() and 
> Process().  Before this split, this would have been been possible in 
> Init(), after calling parent::init().  JCM, is this correct?

Hmm actually, same issue.  You would have needed to call parent::Init() 
twice.  *smacks brain*

jason
Permalink | Reply | 0 comments |
headers
Manuel Holtgrewe | 2 Oct 2004 17:20

RBAC Status

Hi

I just wanted to let you know that Perm now works pretty well:

   - You can add, modify, delete and get users from the perm database
   - You can add, modify, delete and get roles from the perm database
   - You can assign roles to users and deassign roles from users

The unit tests in testsite along with a RBAC Administration GUI in 
testsite can be used as a reference of how to use RBAC in your 
application. I will now start to document the system and let you know 
then.

See

http://svn.binarycloud.com/cgi-bin/trac.cgi/ticket/34

For comments.

Regards,

Manuel
Permalink | Reply | 1 comment |
headers
Jean-Christophe Michel | 2 Oct 2004 19:39
Favicon

Re: nodes

Jason Hines wrote:
> Yes it does, but isn't it the case in point proving that we need the 
> node modifications?  Where else is there an example?
> 
> We need the two distinct passes anyway
> 
>> everywhere you need to operate on a initialized grand child.

> This seems to be an effect of the Init() splitting into Init() and 
> Process().  Before this split, this would have been been possible in 
> Init(), after calling parent::init().  JCM, is this correct?

As I explained in previous thread, you cannot currently use 
child->child->setParam() before it is processed. Splitting allows for this.
--

-- 
Jean-Christophe Michel
Permalink | Reply | 2 comments |
headers
Jean-Christophe Michel | 2 Oct 2004 19:42
Favicon

Re: nodes

Jason Hines wrote:
> If everyone agrees with this (theoretically at least), then I'll proceed.

I don't agree :(
Don't redesign what works.

--

-- 
Jean-Christophe Michel
Permalink | Reply | 0 comments |
headers
Troy Bridoux | 4 Oct 2004 03:41

what about client-side validation???

Does binarycloud not support automatic client-side validation
as any of these provide:

Formsess (smarty-based)
http://formsess.sourceforge.net/

Manuel Lemos's (smarty-based)
http://promoxy.mirrors.phpclasses.org/browse/package/1.html

Vdaemon
http://www.x-code.com/vdaemon_web_form_validation.php

It seems so obvious that client-side validation should come for free
along with server-side validation that I'm convinced I'm just too stupid
to find any documentation on it on binarycloud's web site.

Thanks for proving me wrong.
Permalink | Reply | 4 comments |
headers
Manuel Holtgrewe | 4 Oct 2004 11:31

Re: what about client-side validation???


Am 04.10.2004 um 03:41 schrieb Troy Bridoux:

> Does binarycloud not support automatic client-side validation
> as any of these provide:
>
> Formsess (smarty-based)
> http://formsess.sourceforge.net/
>
> Manuel Lemos's (smarty-based)
> http://promoxy.mirrors.phpclasses.org/browse/package/1.html
>
> Vdaemon
> http://www.x-code.com/vdaemon_web_form_validation.php
>
>
> It seems so obvious that client-side validation should come for free
> along with server-side validation that I'm convinced I'm just too 
> stupid
> to find any documentation on it on binarycloud's web site.
>
> Thanks for proving me wrong.

No, we currently have no client side validation and we have no plan to 
add it yet. It would require yet another change to FormInput and we 
currently do not have the time for rewriting all validators to contain 
client side valition and FormInput to hook this validation in.

Client side validation is very error prone, bound to be insecure since 
the client can switch of JavaScript or use curl to do a form post.
(Continue reading)

Permalink | Reply | 2 comments |

Gmane