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]



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