Re: UMO interface functions

[sergey@total-knowledge.com]

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.
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
>