Re: Implementing "Create Topic" [was: Identical UMO titles in UU]

[sergey@total-knowledge.com]

Hmm... My approach was the opposite - I was trying not to store data in
the session, but in request. Ok, I'll store it in the session object then.

> Sergey, your real problem is that you are trying to pass data around
> through
> HTML, hidden fields, etc. instead of simply storing it in the session.
> Think about it, fix it, and both your life and our application will become
> lot better :)
>
> sergey@total-knowledge.com wrote:
>>> 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
>>>
>>>
>>
>>
>>
>
> --
> Ilya A. Volynets-Evenbakh
> Total Knowledge. CTO
> http://www.total-knowledge.com
>
>