You are asking Category to create say Item. Moving the code as above won't change that. $self will still be the parent
You are assuming:
1) a gizmo knows how create children properly. No. (how can it know how to create a gizmo that won't be written for 6 months?)
2) a gizmo can only have one type of parent. No.
A real world examples of how this defeats writing gizmos:
1)my Form and Card gizmos put javascript in the html HEAD, by overriding print_form(). In 3_1_2 Form paints its own add screen, but in 3_1_3 Category paints Form's add screen, and Category doesn't know how to do that.
for 2) Card is happy with either category or Deck_of_Cards for a parent. In fact you cut and paste a Card back and forth between a Category and a Deck of Cards. If someone writes "fancy-category" it will be happy too.
To fix - "add" has to be in the object itself. Hey -> we're back at the 3.1.2 way.
Beginnings of a solution
==================
Starting Point
--------------
To highlight what we need:
- an object must know how to "create" ITSELF
- Permission checking on "create" must also consider the parent.
Is it just create we need to do this for?:
------------------------------------------
Q: why is "add" different from "delete" or "modify"
A: because once the object is created, it's own permissions apply
Q: what about "paste"? Isn't that in the same boat as "add"
Q: And what about "it's own permissions apply"? If Bob owns a category, and lets Doug create Items in it, but Doug creates Item:You All Suck and Bob is a Facist, shouldn't Bob as category "admin" be allowed to edit or delete?
Q: Or what if Doug creates an Item in Bob's category, but sets it so Bob can't see it. I think Bob as category admin should at least be able to see everything in his category.
I think we need to always be able to check permissions of both the object and it's parent.
Well that actually make stating the goal easier...
Goal
----
- an object must know how to do whatever it does ITSELF
- Permission checking must also consider the parent.
Do we get enough information?
-----------------------------
With "add" we get the iid for the (future) parent and the type of gizmo to create - we are fine
Everywhere else we get the iid of the existing object, and from that we can find the parent - we are fine
What about "add_loop" and "modify_loop"?
Q: What are "add_loop" and "modify_loop"?
A: Sometimes you need to repaint a screen without saving, such as for dependent pop lists. It is a gneral need in nearly all html applications need sooner or later. "add_loop" and "modify_loop" are the names Lee uses for these calls.
- as long as "add_loop" and "modify_loop" pass the same things as add and modify - we are fine
Where do we put the code?
-------------------------
We know we don't want:
- a parent to have to know details about it's children,
- children to have to know details about their parents
This suggest to me, checking the permissions before we ever call the Gizmo, which in turn suggests to me doing the check in the dispatcher in index.pl. - That is just today's thought.
What if a Gizmo wants to control what children it gets
----------------------------------------
Table, Form, Deck_of_Cards all want to do this.
- then add "allow_child()" to the Gizmo hierarchy.
- make sure Gizmo.pm always returns YES, and Table can override
What if a Gizmo wants to control what parent it gets
---------------------------------------
Since execution is passed to the child, it can probably sort this out itself; although one could do "allow_parent()" too.
Summary:
--------
- add permission check to dispatcher in index.pl
- add allow_child() to Gizmo.pm (always return TRUE).
Putting the code in the dispatcher is just my current thought. If someone has a better idea - GREAT.
IMHO what 3_1_3 does is bad, and should not be left as is.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
v3.1.3 looks like a big mistake
Simple Problem
--------------
The object hierarchy is:
Gizmo Prototype
|
Gizmos (category, item, table...)
However the code you've written is like this:
Gizmo Prototype
|
Category Gizmo
|
All Other Gizmos (item, table...)
In other words you put "add" outside the object hierarchy.
The first problem that caused you was with Table. It will affect any gizmo that have children (that is two for me).
To fix it move "www_create_child" to Gizmo.pm.
Hard Problem
------------
An object should know how to do what it does.
You have violated that: In 3.1.3 an object does not know how to create itself.
>iid=$parentid&isa=Category&op=add_child&child_type=[Category|Item|etc]
You are asking Category to create say Item. Moving the code as above won't change that. $self will still be the parent
You are assuming:
1) a gizmo knows how create children properly. No. (how can it know how to create a gizmo that won't be written for 6 months?)
2) a gizmo can only have one type of parent. No.
A real world examples of how this defeats writing gizmos:
1)my Form and Card gizmos put javascript in the html HEAD, by overriding print_form(). In 3_1_2 Form paints its own add screen, but in 3_1_3 Category paints Form's add screen, and Category doesn't know how to do that.
for 2) Card is happy with either category or Deck_of_Cards for a parent. In fact you cut and paste a Card back and forth between a Category and a Deck of Cards. If someone writes "fancy-category" it will be happy too.
To fix - "add" has to be in the object itself. Hey -> we're back at the 3.1.2 way.
Beginnings of a solution
==================
Starting Point
--------------
To highlight what we need:
- an object must know how to "create" ITSELF
- Permission checking on "create" must also consider the parent.
Is it just create we need to do this for?:
------------------------------------------
Q: why is "add" different from "delete" or "modify"
A: because once the object is created, it's own permissions apply
Q: what about "paste"? Isn't that in the same boat as "add"
Q: And what about "it's own permissions apply"? If Bob owns a category, and lets Doug create Items in it, but Doug creates Item:You All Suck and Bob is a Facist, shouldn't Bob as category "admin" be allowed to edit or delete?
Q: Or what if Doug creates an Item in Bob's category, but sets it so Bob can't see it. I think Bob as category admin should at least be able to see everything in his category.
I think we need to always be able to check permissions of both the object and it's parent.
Well that actually make stating the goal easier...
Goal
----
- an object must know how to do whatever it does ITSELF
- Permission checking must also consider the parent.
Do we get enough information?
-----------------------------
With "add" we get the iid for the (future) parent and the type of gizmo to create - we are fine
Everywhere else we get the iid of the existing object, and from that we can find the parent - we are fine
What about "add_loop" and "modify_loop"?
Q: What are "add_loop" and "modify_loop"?
A: Sometimes you need to repaint a screen without saving, such as for dependent pop lists. It is a gneral need in nearly all html applications need sooner or later. "add_loop" and "modify_loop" are the names Lee uses for these calls.
- as long as "add_loop" and "modify_loop" pass the same things as add and modify - we are fine
Where do we put the code?
-------------------------
We know we don't want:
- a parent to have to know details about it's children,
- children to have to know details about their parents
This suggest to me, checking the permissions before we ever call the Gizmo, which in turn suggests to me doing the check in the dispatcher in index.pl. - That is just today's thought.
What if a Gizmo wants to control what children it gets
----------------------------------------
Table, Form, Deck_of_Cards all want to do this.
- then add "allow_child()" to the Gizmo hierarchy.
- make sure Gizmo.pm always returns YES, and Table can override
What if a Gizmo wants to control what parent it gets
---------------------------------------
Since execution is passed to the child, it can probably sort this out itself; although one could do "allow_parent()" too.
Summary:
--------
- add permission check to dispatcher in index.pl
- add allow_child() to Gizmo.pm (always return TRUE).
Putting the code in the dispatcher is just my current thought. If someone has a better idea - GREAT.
IMHO what 3_1_3 does is bad, and should not be left as is.