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

[sergey@total-knowledge.com]

> Don't confuse passing data between requests with passing data within
> request. When data is only relevant withing single request (i.e. piece of
> information retrieved from the database, passed to CSP for rendering),
> you _should_ store it in the request.
> When data persists between requests, you can either store it in HTML as
> hidden field or part of a link, or some such, or you can store it in the
> session.
> Each have their own appropriate uses. Just do not forget about that.

Understood, I'll keep it in mind.

>
> sergey@total-knowledge.com wrote:
>> 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
>>>
>>>
>>>
>>
>>
>>
>
> --
> Ilya A. Volynets-Evenbakh
> Total Knowledge. CTO
> http://www.total-knowledge.com
>
>