Re: Yet another idea

["Alexey Parshin" <alexeyp@gmail.com>]

Topic is a UMO, with a name, type, and title. Any other fields are not
essintial for this example. topics is ether std::vector<CUMO> as in
current approach, or CRecordSet<CUmo> as I propose to do it.
In that case, CRecordSet class should implement forEach() method.

There is an interesting flaw that my current idea doesn't cover yet.
forEach() works ideally for one-level loops, such as a recordset
converted to some html. However, it doesn't yet provide the method for
embedded loops.

2008/7/1 Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:
> It seems to me there is some disconnect between what I'm asking, and
> what you are answering.
>
> 1. There is a "Topic" class of some sort - it represents a single topic, and
> provides
> methods for accessing its related UMOs (sub-topics, problems, parent topic,
> etc..)
> 2. There is a variable in your example, which you called "topics", and which
> has forEach()
> method. It seems to be of a class, which represents a topic list.
>
> All I want to know, is which class is that and how that class is organized.
>
> Alexey Parshin wrote:
>>
>> Most likely, I'd have to create a view for UMO with the needed fields.
>>  Topic is a UMO. So, the type would by CUMO, for instance.
>>
>> 2008/7/1 Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:
>>
>>>
>>> Let me repeat the question: what is the data type of "topics" variable?
>>>
>>> Alexey Parshin wrote:
>>>
>>>>
>>>> If the list isn't result of the query - it's not related to the
>>>> database and should be static.
>>>> Most likely, I'd have wrappers for all the queries - to keep 'em
>>>> auto-prepared and re-used.
>>>>
>>>> Topic is a UMO. UMOs are stored in umo_version table. There is no name
>>>> or title for a UMO in that table, so we need some query to get it.
>>>> Otherwise, it's trivial.
>>>>
>>>>
>
>



-- 
Alexey Parshin,
http://www.sptk.net