UniverseUniversity


Home Projects Jobs Clientele Contact

uu


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

Re: UMO interface functions



sergey@total-knowledge.com wrote:
> Yes, that's why I said most of UMOs can be attached to any other UMO,
> let's say lower level UMOs - explanations, tests, problems, dialogs.
>   

Dialogues = DoTs are UMOs of the highest level (just a friendly
reminder), likewise Through Problems are.

> Higher level UMOs like course and topic can be parent only.
> Btw I don't see anything wrong with attaching explanation to problem or
> test. Neither problem nor test UMOs have a field for the subject they are
> related. UMO explanation can be useful in this situation.I tried to predict how it may look in the html mock-ups, for example for a
> test(blue bar on the very top of the page with radio buttons):
> http://gateway.total-knowledge.com/~sergey/UU/TestEdit.html
> you can add an explanation, problem or dialog and attach this test to
> course, topic or explanation.
> I think ANY-2-ANY was of the main ideas of UU.
>
>   
>> I'm not sure if we can attach any UMO to any other UMO. For Instance -
>> attaching a topic to an explanation, or attaching an explanation to
>> problem
>> doesn't make much sense to me.
>> In the present structure of the database, we have only certain connections
>> between UMOs allowed. If we need ANY-2-ANY type of connection - then we
>> need
>> a different DB structure.
>>
>> 2007/4/29, sergey@total-knowledge.com <sergey@total-knowledge.com>:
>>     
>>> Regarding topic_attach_to_topic() and topic_detach_from_topic() types of
>>> stored procedures.
>>> Since most of the UMOs(like problems, tests, dialogs, etc) can be
>>> attached
>>> to any other UMO except themself, imho it makes sense to have only 2
>>> attach/detach stored procedures:
>>> umo_attach() and umo_detach().
>>> Attach should be performed only if child UMO is allowed to be attched to
>>> provided parent UMO.
>>>
>>>
>>>       
>>>> It's not going to work for every UMO. For example, problems have more
>>>> complicated functionality. Also course is much different from others.
>>>>
>>>>         
>>>>> Hello,
>>>>>
>>>>> It looks like we have to standardize the set of the UMO functions.
>>>>>           
>>> Here
>>>       
>>>>> is
>>>>> the typical list that is implemented for topic_list,
>>>>>           
>>> topic_explanation,
>>>       
>>>>> and
>>>>> dialog_of_texts:
>>>>>
>>>>> GRANT EXECUTE ON FUNCTION <UMO>_create(int,varchar(80),text) TO
>>>>>           
>>> PUBLIC;
>>>       
>>>>> GRANT EXECUTE ON FUNCTION <UMO>_delete(int) TO PUBLIC;
>>>>> GRANT EXECUTE ON FUNCTION <UMO>_create_version(int) TO PUBLIC;
>>>>> GRANT EXECUTE ON FUNCTION <UMO>_publish_version(int) TO PUBLIC;
>>>>> GRANT EXECUTE ON FUNCTION <UMO>_add_content(int,int,varchar(80),text)
>>>>>           
>>> TO
>>>       
>>>>> PUBLIC;
>>>>> GRANT EXECUTE ON FUNCTION
>>>>>           
>>> <UMO>_modify_content(int,int,varchar(80),text)
>>>       
>>>>> TO
>>>>> PUBLIC;
>>>>> GRANT EXECUTE ON FUNCTION <UMO>_delete_content(int) TO PUBLIC;
>>>>> GRANT EXECUTE ON FUNCTION <UMO>_attach_to_<parent
>>>>> UMO>(int,int,int,int,int)
>>>>> TO PUBLIC;
>>>>> GRANT EXECUTE ON FUNCTION <UMO>_detach_from_<parent UMO>(int,int) TO
>>>>> PUBLIC;
>>>>>
>>>>> Please, notice: In order to match this standard I had to modify names
>>>>>           
>>> of
>>>       
>>>>> few
>>>>> topic_* functions, related to content and attach/detach.
>>>>>
>>>>> --
>>>>> 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