UniverseUniversity


Home Projects Jobs Clientele Contact

uu


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Sure. I have plenty of other things to work at.

> Please, before you make technical decisions regarding consult with Ilya.
>
> sergey@total-knowledge.com wrote:
>> 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
>>>
>>>
>>
>>
>>
>
> --
>
> Anatoly Volynets, Co-Founder
> total-knowledge.com
> culturedialogue.org
>
>



Authoright © Total Knowledge: 2001-2008