Do we really need `pre_hook` and `object_hook` in update_from_external_object?

[jamadden]

This project does not actually use them, and they add substantial overhead even when they aren't used.

Are they used internally? If so, for what? Can we find another way to do that? I just spot checked some places and in the core internal code, everybody passes None.

[jzuech3]

I believe nti.contenttypes.presentation (all the lesson assets) use pre_hooks.

[jamadden]

For what? Is it just to get around implementing an internalizer class?

[papachoco]

In trying to support legacy content we need to switch mimetypes; in addition there are places ntiid are a list .. instead of single field.

[jamadden]

What? Can't you just register the internalizer for the old mime type?

[papachoco]

We will.. give u a few days to add those in

[papachoco]

object_hook is very legacy (use in assessments processing) and when updating a course outline.

[jamadden]

This is a major feature request, it won't go in without a new PR and it could easily be postponed, take all the time you need. And if a new ZCML directive (I'm assuming the non-legacy internalizers are registered via <registerAutoPackageIO>) would help, let me know that too.

[jamadden]

object_hook is very legacy (use in assessments processing) and when updating a course outline.

Without putting too much time into it right now, any idea what it would take to get rid of that?

[papachoco]

I'd say about a week .. counting on @jzuech3 time

[papachoco]

I thin we can register mimetype factories for those legacy objects. I don't think we need a a new directive.

<adapter factory=".datastructures.***"
		 for="nti.base.interfaces.IDict"
		 provides="nti.externalization.interfaces.IMimeObjectFactory"
		 name="application/vnd.nextthought.****" />

[jamadden]

OK. I would consider this on the nice-to-have list. It will directly improve the performance of all object reads proportional to how many objects there are by some factor. Function calls in CPython, even trivial ones, aren't super cheap.

There may be some other things we can do for the no-op versions of the functions to get a lot of the way there to removing them in terms of perf, I'd have to benchmark...but that wouldn't improve the code clarity.

[jamadden]

I thin we can register mimetype factories for those legacy objects.

Yeah, the <adapter> ZCML is what you need. I was just thinking that one that lets you register like an existing adapter but with a new name (much like the security descriptors let you do for classes) might be nice. Just depends on how many there are:

<ext:registerMimeFactoryAlias 
    like="the new mime type"
    name="the old mime type" />

[papachoco]

There are about 19 legacy obejcts .. we could use such new directive command for 9 of them.

[jamadden]

Probably not worth it, then, especially since these should theoretically ultimately go away.