Hi Gerrit,
Gerrit Voss wrote:
> On Mon, 2008-06-02 at 11:36 -0500, Carsten Neumann wrote:
>> 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.
oh, ok.
>>> 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.
ah, I begin to see where I misunderstood you: We keep the way the handle
holds a bunch of boost::function callbacks and all, but you want the
ability to set the name that is registered with each callback to be
settable from the .fcd file.
>>> 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.
ok, I see. I had thought of a more simplistic solution that required
implementing editHandle<FieldName> in the Class for custom access fields
(that was the reason for the change in r1259). But always using the
generated editHandle<FieldName> and just customizing what function names
it passes to setAddFunction etc is probably more user friendly.
> 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.
nvm, I had misunderstood you (I thought you did not like the whole idea
of using boost::function in the handle and wanted to have the
information which function to call to be placed in the handle at compile
time - and then you'd need a container instance to actually do the call
of course ;) ).
>>>> 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.
ok.
> I still did not have time to check the patch, try to do so soon, maybe
> it shows where the our assumptions diverge ;-)
ok. I think on this one we are not so far away as I though ;) I'll see
if I can update the patch over the day and add the correct fcd magic for
the registration and the query functions, but that should not change the
stuff that is in the patch at this point (much).
Thanks,
Carsten
-------------------------------------------------------------------------
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
