[
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