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]



> 1. Not reasonable. You're loading object data - why don't load ALL object
> data?

I do currently load topic content without using topic_content_id and have
no problems with that at all.

> 2. After the topic_create(), you still have to run that select one way or
> another - otherwise you don't get content.

If topic_list_content_modify() would use topic_id as a parameter instead
of topic_content_id, I wouldn't need to run any additional queries. I have
enough info about topic and it's content already: topic_id+language_id.
I may be missing a bigger picture, though.


>
> 2007/4/27, sergey@total-knowledge.com <sergey@total-knowledge.com>:
>>
>> The reasons are:
>> 1. No need to pass any umo_content_id throughout all site.
>> 2. No need to run an additional query on UMO creation to get
>> umo_content_id by umo_id.
>>
>>
>> > Once again - can anybody tell me why a combination of parent id and
>> data
>> > makes more sense than object id?
>> > You're going to edit or update an object, and object id uniquely
>> > identifies
>> > that object. A combination of parent object id and object data does
>> not
>> > (in
>> > general case).
>> > This is a universal approach. It's simpler, it's faster, it's more
>> > reliable.
>> >
>> >
>> > 2007/4/27, sergey@total-knowledge.com <sergey@total-knowledge.com>:
>> >>
>> >> My opinion is: stored procedures should deal with UMO content IDs
>> >> internally. Combination of umo_id + lang_id is good enough to
>> correctly
>> >> identify UMO content. I added language dropdowns on topic create/edit
>> >> pages and now it makes perfect sense.
>> >> I dealt with JSP online stores which used multiple languages for
>> >> category/product names and descriptions. For the same category query
>> >> string contained the same category_id no matter which language_id was
>> >> used. I think we should do the same.
>> >>
>> >>
>> >> > BTW, default language is always 1. You probably mean - preferred
>> >> language.
>> >> > I
>> >> > probably should add such function - it may become handy:
>> >> >
>> >> > current_user_language_id()
>> >> >
>> >> > 2007/4/27, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:
>> >> >>
>> >> >> Alexey Parshin wrote:
>> >> >> > I wouldn't worry about it too much. Any object should be
>> identified
>> >> by
>> >> >> ID.
>> >> >> Internally - yes :)
>> >> >> > This is the basic requirement. The ID itself is meaningless, but
>> it
>> >> >> > allows to avoid any problems with object identification.
>> >> >> > BTW,  I don't see how identifying a content with topic ID and
>> >> language
>> >> >> > is less exposing than identifying it with content ID.
>> >> >> Not as-is, but if, let's say, you wanted to be able to refer to
>> >> default
>> >> >> topic_content by passing
>> >> >> null for a language (since the one with default language has a
>> >> special
>> >> >> meaning), you could
>> >> >> do it with my way of identification, but not with yours... In your
>> >> case,
>> >> >> UI would have to first
>> >> >> explicitly find out what default language is, and then retrieve
>> >> relevant
>> >> >> content object.
>> >> >>
>> >> >> --
>> >> >> Ilya A. Volynets-Evenbakh
>> >> >> Total Knowledge. CTO
>> >> >> http://www.total-knowledge.com
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > Alexey Parshin,
>> >> > http://www.sptk.net
>> >> >
>> >>
>> >>
>> >>
>> >
>> >
>> > --
>> > Alexey Parshin,
>> > http://www.sptk.net
>> >
>>
>>
>>
>
>
> --
> Alexey Parshin,
> http://www.sptk.net
>



Authoright © Total Knowledge: 2001-2008