14 replies to this topic

[mikef]

Is there a function (or sequence of functions) I can use to create and populate a new document?

[breezer]

I added the code I had posted to the snippet development forum...

Edited by breezer, 22 November 2005 - 02:28 AM.

[mikef]

Thanks, but I was really hoping there was something in the etomite API that would assist in putting something into the site-content table (optimistic I know ...)
If need be I'll base it on the code in the manager, but then I need to sort out which variables are available from the user side, rather than the manager side.
I want to give some of the wildlife hospital staff and volunteers the ability to submit pages (that will likely end up as news items via the ListDocuments snippet) that I can then verify and publish, so over 50% of the fields will need to be filled. I don't want to tell them to login to the manager, as the main manager page is guaranteed to scare most of them off!

[Ralph]

Thanks, but I was really hoping there was something in the etomite API that would assist in putting something into the site-content table (optimistic I know ...)
If need be I'll base it on the code in the manager, but then I need to sort out which variables are available from the user side, rather than the manager side.
I want to give some of the wildlife hospital staff and volunteers the ability to submit pages (that will likely end up as news items via the ListDocuments snippet) that I can then verify and publish, so over 50% of the fields will need to be filled. I don't want to tell them to login to the manager, as the main manager page is guaranteed to scare most of them off!

You're talking about a more friendly interface for the staff... I'm pretty sure RC3 has all of the required capabilities, or pretty close to all of them... I just might have something kicking around, either done or almost done...

[breezer]

Creating a new document is exactly what this code does...this is nothing like the older guestbooks which used the user_messages table to store the data, all the fields in the site_content table are accessible from the user side in this code.

//create array for database access
        $newGbE = array();
        $newGbE['pagetitle'] ='$pagetitle';
        $newGbE['type'] = 'document';
        $newGbE['description'] = 'what the page is about';    
        $newGbE['published'] = 1;   // auto published   
        $newGbE['published'] = 0;       
        $newGbE['content'] = $pagecontent;
        $newGbE['richtext'] = 0;
        $newGbE['searchable'] = 0;
        $newGbE['cacheable'] = 0;
        $newGbE['parent'] = $gbookFolder;
        $newGbE['createdon'] = time();
        $newGbE['createdby'] = $createdbyadmin; 
        $newGbE['longtitle'] =$pagelongtitle;
       
    // put the data into the database
         $etomite->putIntTableRow($fields=$newGbE, $into=$table);

You could actually take this code and transform it with just a few small modifications to accomplish what you want. Admin verification before publishing is already there, choose the parent folder is in there, admin notification (with or without preview) is included...

[mikef]

Creating a new document is exactly what this code does...this is nothing like the older guestbooks which used the user_messages table to store the data,  all the fields in the site_content table are accessible from the user side in this code.
...
You could actually take this code and transform it with just a few small modifications to accomplish what you want. Admin verification before publishing is already there, choose the parent folder is in there, admin notification (with or without preview) is included...

My apologies - I scanned through the code quickly and missed that bit and also misinterepreted the

  // INSERT a new GuestBook message into superadmin user_messages

as being the part that wrote the information into the database, and so didn't look more carefully.

Ralph, if you have anything that would help too, even uncompleted!

thanks both!

[breezer]

it's all good, hope this helps a bit anyway

[Ralph]

Ralph, if you have anything that would help too, even uncompleted!

Are you looking for a simple means of having documents contributed into one or two folders by the staff where they should be required to enter the least amount of information...:?: Something that doesn't require entering a template name, parent, dates, cached, and some other items...:?: And should everyone be able to access the same documents for editing, by group, or should they only be accessible by the contributor...:?:

[mikef]

What I was really hoping for was a function like:

$id = createDoc($fields)

where fields is an associative array with all the values that I want to set, and the function takes the defaults set in the manager for those not passed in the array (and determines user and date for created and editted, if not supplied). The function then applies any processing required for the fields (eg addslashes(), converts date formats from something sensible into the stored format), and finally creates a new document and returns its id.


How I'm planning to use it initially is:

- user logs in
- is presented with a page showing
-    a drop down of subject areas they may submit an article to
-    and a drop down of galleries they may submit an image to
- user selects one
-    if it a gallery - they'll go the page and have a normal etogal admin interface 
-    if its a subject area for an article 
-       they get a new page with a form containing fields for
-          title (mandatory)
-          long title (optional)
-          description (optional)
-          content (probably one of the editors rather than plain text)
-       when they've finished editting
-          createDoc is called, $fields including the above, plus the appropriate parent id, no search, and unpublished.

I want to use a document so that I can easily move to another area, or convert to a higher level page if I see fit.

Hope that all makes sense.

Edited by mikef, 20 November 2005 - 04:47 PM.

[Ralph]

Yes, that all made sense... That's more or less the way I had envisioned it as well with the exception of the EtoGal part... That might be nice as a Plug-In but I think the basic design could simply use an editors built-in image management features... This concept is inline with some of the work that I am doing to the original EtoBlog which I'm working on making somewhat modular...

[mikef]

Oh, Etogal has nothing to do with the createDoc content - it's just another function I'd give to the users after they'd logged in (EtoGal is used for various galleries in the site, and if it doesn't do what I want i just rewrite bits of it). For normal documents I'd just use the capabilities of a built in editor. All I was looking for was the createDoc function itself (or equivalent), if it existed, not the UI for the users!

I'd written down the UI description only to give some context.

[Ralph]

Oh, Etogal has nothing to do with the createDoc content - it's just another function I'd give to the users after they'd logged in (EtoGal is used for various galleries in the site, and if it doesn't do what I want i just rewrite bits of it). For normal documents I'd just use the capabilities of a built in editor. All I was looking for was the createDoc function itself (or equivalent), if it existed, not the UI for the users!

I'd written down the UI description only to give some context.

The new API function call, checkPermissions(), which has been introduced in RC3 could come in handy for that... Permissions are checked against user roles... I'm sure that a similar function for checking membergroups and/or documentgroups will be forthcoming...

 function checkPermissions($action="",$user="",$id="") {
  //  determine document permissions for a user
  //  $action = any role action name (edit_document,delete_document,etc.)
  //  $user = user id or internalKey
  //  $id = id of document in question
  //  because user permissions are stored in the session data the users role is not required

[mikef]

aargh ...

This isn't going to work. If you try to edit a document from the client side, you replace any snippet or chunk calls with the results of that call, which isn't likely to be what you want ...

[Ralph]

aargh ...

This isn't going to work. If you try to edit a document from the client side, you replace any snippet or chunk calls with the results of that call, which isn't likely to be what you want ...

What I was implying was that checkPermissions would allow you to determine who can do what, but the actual interface and logic would need to be "built-to-fit" depending on task specific needs... The checkPermissions function is a helper tool, not a "turn-key" solution...

[mikef]

What I was implying was that checkPermissions would allow you to determine who can do what, but the actual interface and logic would need to be "built-to-fit" depending on task specific needs... The checkPermissions function is a helper tool, not a "turn-key" solution...

Indeed!

I just hadn't thought through the implications of trying to use the standard client side facilities to edit pages containing snippets and chunks. Once I'd realised it wasn't going to work, I thought I'd better raise it here before someone else reads this thread and decides to go down the same route. I'm giving up on a full function solution for now and giving them a simple editor with no snippet or chunk support, and if they want more they'll have to learn to use the manager.