Hi,
On Mon, 2008-06-02 at 11:36 -0500, Carsten Neumann wrote:
> Hi Gerrit,
>
> Gerrit Voss wrote:
> > On Fri, 2008-05-30 at 15:32 -0500, Carsten Neumann wrote:
> >> For custom access fields it is the responsibility of the container to
> >> register appropriate functions with the handle (by calling setAddMethod
> >> etc.) in {get,edit}Handle<FieldName>. Some of these functions might not
> >> be available even (hence all the bool return values).
> >
> > I don't like the way to figure out if something is available after the
> > fact. If you already plan to extend the field description (below)
> > couldn't we use that to query the handle which functions are available ?
> > This way the bool return values can go.
>
> well, yes and no. We can add functions to query what is available, but
> since EditMFieldHandle<FieldContainerPtrMFieldBase> (as the base class
> of the EditFCPtrMFieldHandle<FieldT>) already advertises the pure
> virtual functions, something has to happen if they are called. After all
> what should happen if the handle's replace is called and it can not do
> anything sensible because the field has custom access and no function of
> the container was registered to perform a replace ?
it just does nothing. We can keep the bool values if wanted but the
more important thing was the ability to query what is actually
available, so that the code can decide which path to take without
actually having to make a test call to any of the functions.
> > As for the function registration. Again, if possible I would like to use
> > the fcdEdit to name the function and have the Class, as opposed to
> > Base, implement it.
>
> I've not touched the template files yet, so it is not a problem to make
> the name of the function that is passed to setAddFunction and co.
> customizable.
>
> But how do you get that function name into the handle, i.e. how can the
> handle know that it should call "add<FieldName>" to perform an add ?
> All I've done is extend the mechanism that was already used for add/set,
> are you saying that was a stop gap and the real solution should be
> something different ?
> If yes, that is fine, but from the above I can not really understand
> what that solution should look like. Could you elaborate please ?
Hmm, why would the handle need to know the name of the function ? The
handle either calls the field directly of the function set by
setAddMethod.
> > That is how it is done now for the few functions
> > OpenSG needs internally (e.g. clear) and it removes the need to mess
> > with the init system and to store the registered functions somewhere.
>
> Sorry, I don't understand this part. Basically the problem boils down to
> this:
> - there is some container that stores pointers and the user wants extra
> control over the pointers stored.
> - the user marks the field as custom access in the fcd and the base
> class does not contain functions to manipulate the container.
> - the edit handle for that field should not change the field directly as
> that would bypass the extra control
> - the user implements in the class (not the base) some functions to add
> pointers to the special field.
> - the edit handle somehow has to know that it should call these
> functions of the container.
> Now there are two options:
> 1) make the container a template argument of the handle, have the user
> mention the names of the functions he implements for access in the fcd
> and use this information to generate a specialization of the handle for
> that container/field combination.
>
> 2a) register the functions to call (bound to a container instance) with
> the handle, when it is created.
>
> 2b) store the functions to call in the field description and keep a
> pointer to the container in the handle to call these functions with.
>
> 2a of course is what currently happens with the
> setSetMethod/setAddMethod calls in editHandle<FieldName>.
> What am I missing here ?
jein, currently 2a is happening but the function is taken from the
Container and not ContainerBase. So the user is able to override
the function used by editHandle<FieldName>. editHandle<FieldName>
uses whatever function name comes out of fcd2code, either the default
pushTo<FieldName> or the custom name the user can provide. Whether
or not the function is coming from ContainerBase or Container doesn't
really matter.
Inside the handle we either call the field directly (not yet), as it is
stored inside the handle and we know the exact type, or we call the
callback. So I don't see where the container get's involved, other that
being stored inside the boost function object.
> >> For all access types (std, null-check, custom) get, find and size will
> >> go directly to the field, i.e. read access can not be "intercepted".
> >> This seems to make the most sense given that currently the container
> >> always has at least a get<FieldName> function.
> >>
> >> On the implementation side I'll add
> >> // for custom access fields
> >> typedef boost::function<void (FieldContainer *)> AddMethod;
> >> typedef boost::function<void (UInt32) > RemoveMethod;
> >> typedef boost::function<void (UInt32,
> >> FieldContainer *)> InsertMethod;
> >> typedef boost::function<void (UInt32,
> >> FieldContainer *)> ReplaceMethod;
> >> typedef boost::function<void (void) > ClearMethod;
> >>
> >> to EditMFieldHandle<FieldContainerPtrMFieldBase> and place the
> >> information on what access type to use in the FieldDescription (maybe as
> >> FieldFlags?).
> >
> > ok, except FieldFlags is already taken for the MT/Cluster flags so I
> > would prefer something else, like GenericAccessFlags.
>
> oh, ok, I was not aware that FieldFlags are reserved for these they
> certainly have spare bits ATM, but I can find another place/add another
> variable to FieldDescription to store this info.
ok, I missed you talked about the description FieldFlags and not the
FieldContainer one's. Yeah the descriptions FieldFlags should have
spare bits available for this.
I still did not have time to check the patch, try to do so soon, maybe
it shows where the our assumptions diverge ;-)
kind regards,
gerrit
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
