[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Yet another idea
It's important not to overcomplicate things. Don't forget that there will
always be a basic "default" theme, which designers will be basing their
stuff on. It'll have all the correct syntax for loops, etc.
If 70% of loops are single-level, and we can make them more readable
in the way you suggest, and have C++ code for the remaining 30% that
require a bit more complex code to make functionality, then so be it.
BTW, I made a simple test:
I have shown the code below to my wife (she has some C/JavaScript/HTML
knowledge - no previous C++ exposure), and asked her what she thinks it
does.
She had no problem interpreting it correctly.
<table>
<%
for(std::vector<Topic>::iterator topic = topics.begin();
topic!=topics.end(); topic++)
{
out<<"<TR><TD><A
HREF=\"ViewTopic?tid="<<topic->id()<<"\">"<<topic->title()<<"</A></TD></TR>"<<std::endl;
}
%>
</table>
I think any adequate person can deal with reading and modifying
code above.
Alexey Parshin wrote:
C++ iterators is something I'm trying to hide.. If we can't find a
good way to present embedded loops, then the whole idea is useless.
I'm trying to imagine how we can use it.. Something like:
Topics.forEach(
" topic template 1 here ",
SubTopics.forEach( " subtopic template here "),
" topic template 2 here "
);
It isn't a problem to implement variable number of parameters. It's a
problem then we have too much C++ again :(
2008/7/1 Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:
Alexey Parshin wrote:
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.
Aha. Now I understand somewhat better what you meant, and like it far more
:)
Re: embedded loops, we can either solve it by making a complex ways of
defining which substitutions cause calls to sub-objects forEach(), or just
by going
back to good old C++ iterators, in those rare cases that need it.