[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Implementing "Create Topic" [was: Identical UMO titles in UU]
Alexey Parshin wrote:
2007/5/6, sergey@total-knowledge.com
<mailto:sergey@total-knowledge.com> <sergey@total-knowledge.com
<mailto: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.
Affirmative.
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.
Affirmative again. And, again, UI may hide this from the end user.
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.
More or less. We may want to provide some short-cuts for most common
cases, but still
have to expose and allow to control of full cycle to the user.
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
<mailto:sergey@total-knowledge.com> <sergey@total-knowledge.com
<mailto: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
<mailto:sergey@total-knowledge.com> <sergey@total-knowledge.com
<mailto: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 <http://www.sptk.net>
>> >>
>> >
>> >
>> >
>>
>>
>>
>
>
> --
> Alexey Parshin,
> http://www.sptk.net <http://www.sptk.net>
>
--
Alexey Parshin,
http://www.sptk.net
--
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com