[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Implementing "Create Topic" [was: Identical UMO titles in UU]
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