Re: custom TreeModel



On 5/19/06, Tamer Mowafy <kalimakhus yahoo com> wrote:
first if the basic idea was to keep only one copy of
data around, you may think of using a reference to the
wrapped container.

>private:
> T m_container;
can be:
T& m_container;

this will allow two-way updates to be automatically
sensed on both the view and model sides.

Yes, that's a good point.  That was an error in my original example.
It should be either a reference or a pointer.

Second you may consider declaring your template
parameters like this:

template < class T, template < class U, class =
allocator <U> > class TContainer>

this makes your class instantiated with both the
container and the type it is storing. I just guess
that this may come handy later on.
In this case the member variable should look like
this:
TContainer<T>&  m_container;

I'd consider this.  Do you have a particular use case in mind?

Another approach that should make your implementation
more generic, is to use iterators to initialize the
class rather than a whole container. This would allow
the class to accept a wider range of containers (even
arrays and pointers). Though this can be problematic,
(After thinking this won't work for the purpose at
hand).

If you initialize it with iterators, doesn't that imply copying the
values to a new container?  That doesn't seem quite what we want.

Last point is the question, should the user inherit
from your class or not? Well, it is there and it has
virtual functions and some will do so even if you
provided some other alternative. Still for the sake of
better view/model separation it should be better that
they don't. You will still need to acquire columns'
values from the user as well as communicating back the
mutations performed on these values through the UI.
One way to do that is to use some helper class let's
say ValuesProvider. The user can inherit from it and
supply a pointer/reference to your class that can call
the helpers functions to get values for each row of
data (or each column individually) as this is needed.
It can pass an iterator over the container. If you
have a reference to the container rather than a copy
such iterators will be valid ones. By the way this
approach is used in the java API of eclipse namely in
the jface package.

I'm having a hard time picturing exactly what sort of interface you're
talking about here.  Do you have any pseudo-code that you could use to
explain a bit more clearly?

Some other approach is to use signals that the user
can connect to and supply column values through his
slots.

For some reason, this seems more complicated to me.  I'm not sure I like it.

I hope these notes are not totally out of point.

Not at all.  Thanks for your comments.

Jonner



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]