Re: Implementing "Create Topic" [was: Identical UMO titles in UU]

["Alexey Parshin" <alexeyp@gmail.com>]

2007/5/6, sergey@total-knowledge.com <sergey@total-knowledge.com>:

> Correct me if I'm wrong, but:
>
> 1) An author makes changes only in particular version of UMO, and only if
> version is not published.

That sounds right. Doesn't mean that author has to click on "Create new
vesrion" link before making changes to it's content.

If any changes are made in UI over published UMO,  then the 1) new version should be created 2) changes are applied.
For you, it means two function calls, and that is correct. You request for a single function call is based on the assumption, that an author modifies some 'default' content. However, a topic may have several content records, and any of them may be created/deleted/modified. Therefore, we first create a new version of UMO, and then apply one or multiple modifications. New modifications may be performed many times without creating a new version, if the object is in 'not published' state.

It is possible to auto-create UMO version on any modification attempt (for a published UMO). However, IMHO, the object state (published -> unpublished -> published) should be controlled by an author. An author should fully realize that his changes are not visible till he publishes 'em no matter how long is the publishing process. He should understand how he got there, and how he can get out (publish and make his changes visible).

> 2) As soon as changes are completed, and author is satisfied - he
> publishes
> a UMO.

Yes.

> 3) Any changes after the UMO is published are impossible. If an author
> wants
> any changes - he must make a new version of UMO ( loop to 1) )

Yes, internally. In UI it should look like author updating the current
version.

>
> 2007/5/5, sergey@total-knowledge.com <sergey@total-knowledge.com>:
>>
>> Another argument: once author starts editing UMO he may not know for
>> sure
>> if his changes are minor or versioned. He may make his decision only
>> after
>> he is finished with his changes.
>>
>> > This is not what we have in specs and mailing list discussions, maybe
>> > something changed recently and I missed it, though. Also it's very
>> user
>> > unfriendly imho.
>> > Author makes minor changes to the UMO until he satisfied with it's
>> > content, then publishes it. From UI point of view, when creating new
>> > version of UMO, user expirience should be exactly the same as with
>> minor
>> > changes, except selecting "versioned" radio button on submit(or
>> clicking
>> > "Publish" instead of Save")
>> > Also new version supposed to be created when user changes UMO
>> > content(adds/removes children UMOs) and this should be reflected in
>> > topic_create_version() too.
>> >
>> >
>> >> The idea was - you 1) create version 2) update any information in the
>> >> topic
>> >> The reason for it is pretty simple. Title and description belong to
>> >> content
>> >> record. Since we may have multiple content records (one per
>> language),
>> >> providing a single content record information doesn't make much
>> sense.
>> >> This
>> >> is universal approach for all the UMOs in the database.
>> >>
>> >> 2007/5/5, sergey@total-knowledge.com <sergey@total-knowledge.com>:
>> >>>
>> >>> I'm working implementing versions functionality for topic and have
>> >>> problem
>> >>> with it.
>> >>> Currently topic_create_version() gets only topic ID as a parameter.
>> >>> When
>> >>> author creates new version, he may change title, description and
>> >>> content(child UMOs that belong to this topic). The way this stored
>> >>> procedure work now, it only duplicates all topic properties without
>> >>> updating them.
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Alexey Parshin,
>> >> http://www.sptk.net
>> >>
>> >
>> >
>> >
>>
>>
>>
>
>
> --
> Alexey Parshin,
> http://www.sptk.net
>

-- 
Alexey Parshin,
http://www.sptk.net