It is simple to use:
1) Extract files to extension directory
2) Enable the extension in the extensions section of the administration
web page
3) Under Roles and Permissions, add a permission for anyone who should
be able to
create objects through this model for all access to the ObjectCreator
module.
(regular object creation permissions will still take effect, even though
you
are granting all access to this module)
4) Where you would normally place a form to create an object, change
the
post action to be this module:
{* Are we allowed to create new object under this node? *}
{section show=fetch( content, access,
hash( access, 'create',
contentobject, $node,
contentclass_id, 'comment' ) )}





{section-else}

{"You are not allowed to create comments."|i18n("design/base")}

{/section}
5) You can now add hidden (or not) input fields to set the default
attribute
value on the newly created object. The user will be taken to the
edit page and have the option to change the value there, of
course.

Where attributename is the name of the attribute (not the number).
Note
that it does't take quite the same format as the usual edit pages. For
example,
to set a date attribute, you'd just use something like:

Instead of the usual 3 fields for month, day and year.
Object Creator PHP Class
I've taken code from a number of places, both from ez.no and from other
example
extensions, and made a class for object creation. It is useful standalone
for
importing from other systems. You can include it directly and create
objects
with a one line function call. See
"ObjectCreator/modules/ObjectCreator/ezobjectcreator.php".
Limitations
As of yet, this module does not handle every attribute data type. To
know what
it does and doesn't do, look at the select statement inside of
ezobjectcreator.php
mentioned in the last section.
Incorporation into ezp mainline?
I would love to see this incorporated
into the main ezp development. This is what would need to happen:
1) All I did was cut-n-paste the code from content/action into my
module,
trim it down significantly and add a small loop to handle all the
"default_attributename" post fields. This part would be easy to
incorporate.
2) The more difficult part is that the conversion from string value
to
attribute data type is not currently handled cleanly. Ideally appropriate
functionality would be added to each of the data type php classes. I

started out attempting to use their fetchObjectAttributeHTTPInput()
style
function calls, but those require the object attribute
id's in the POST variables, and those id's don't exist until after
the
object is created.