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

[sergey@total-knowledge.com]

Ok then, each UMO will have "Create New Version" link. This makes things
much easier, b/c now we don't have to worry about locking an UMO while
author is making his changes.
Questions:
1. What if all author does is clicking on "Create New Version" link?
topic_create_version() will be called and we'll have a bunch of new
records in DB.
2. What if author makes changes ,but drops his UMO without publishing it?
It's never going to be used by any author or visible in UI. Are we going
to delete all data related to this UMO from DB?


>
> 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
>